This paper is available from http://openpdq.com/OpenSystems.
The author can be contacted at mailto:p.henderson@ecs.soton.ac.uk
1 Summary
Based on a stochastic model of the development of a large modular system, we suggest that the cost of development of that system and the time to deliver it (schedule) can both be reduced, if the system is designed with an Open Architecture.
Figure 1. The project cost in dollars per module, against level of openness.
Figure 1 shows the reduction in cost that the model predicts if the openness of the system is increased, according to a definition of openness that we will give in a later section. Openness brings cost and time reduction over and above that available from modularity alone. After giving a brief definition of what we mean by Open Architecture, we discuss the model, the results and insights gained from these results.
2 What we mean by an Open Architecture
A modular system is open, if a reasonable proportion of its interfaces are open, in the sense that their definitions have been published and the means for holding them fixed has been determined.
Figure 2. Modules in an Open Architecture. A proportion of the Interfaces are Open.
Figure 2 shows a block diagram of a (certain level of) a modular system. The boxes are the modules and the lines between them show dependencies, in particlar that one module communicates with another. The existence of a dependency implies an interface between the modules. These interfaces may be proprietary, or open. If the system has been designed with key interfaces made open, so that evolution of the system is made more rapid and more economical, we refer to the system as having an open architecture.
The key aspect of an open interface is that it cannot be unilaterally (or bilaterally) changed. The interface evolves under the governance of an entity independent of the designers of the current solution. While this constrains their local options, it enhances the global properties of the solution, not least its cost and delivery schedule. Open interfaces allow new parties to make the commercial decisions necessary to justify the production of a new module and this in turn leads to increased innovation because of the broadening of the supply base.
Figure 2 needs to be read in a particular way. When an architecture is designed in this way, so that it modules can be plugged together in varying (and evolving) combinations, it assumes the existence of a sedimentary infrastructure that the modules use to communicate with each other. This infrastructure will itself be modular and open. Moreover, the solution represented by the modules in Figure 2 will themselves be organised into a layered hierarchy, because in practice in large systems there will be many hundreds of such modules. We choose not to show these hierarchical aspects on a single diagram. This follows the system architects' normal practice of addressing aspects of the solution at a suitable level of abstraction. A whole system therefore will be described by many such diagrams, which the architects will seek to make consistent and complete.
3 The Business Case for adopting Open Architecture.
The insights presented here are based on a stochastic model of the development of a large system, as well as observations made from studying the development of many real systems. The graphs however are from the model. We make some comments in the next section about the provenance of the model.
The perceived benefits of adopting open architecture are all related to through-life evolution of the delivered system. For very large systems that take many years to develop and deliver it is impossible to even anticipate at the outset all the requirements that will be placed upon it when it is first delivered, let alone those that will appear once the solution is in service, through changes in the environment, through evolution in technology and through innovation. Creating the potential for rapid and economic change is therefore paramount in reducing uncertainty and risk to the customer.
Our model concentrates on the commercial parameters of cost and schedule and attempts to show the degree to which rapid response to new or changed requirements benefits from adopting an Open Architecture.
If the model is at all close to reality then Figure 1 suggests that increasing openess from (say) 20 per cent to 40 per cent can reduce the cost to half. These degrees of openness are, in my opinion, realistic for large commercial systems, the lower figure being realised primarily by the COTS components in the sedimentary layers alone, while the higher level would require a reasonable degree of openness in the application-specific upper layers.
The results presented in Figure 1 are based on a fixed modularity and on a fixed error-rate/rework-cost (see next section for an explanation). The modularity assumes about 4000 basic modules organised into a 3 level hierarchy. The error rate is 10 per cent (1 in 10 design decisions are wrong). Rework involves repeating all the work of building and testing this subsystem and a portion of associated modules determined by the degree of openness.
Varying the fixed parameters of modularity and error-rate leads to similar results. The costs go up or down as one would expect. The shape of the graph remains the same
Figure 1 shows that the cost of producing a module in the context of a large system comes down in a typically exponential way, if the degree of openness is increased. Openess (in our context) means that the definition of interfaces is fixed, and we measure openness as the proportion of interfaces that are open, as oposed to proprietary. In contemporary large scale systems, especially at the upper levels, it is not reasonable to expect all of the interfaces to be open. So we expect a proportion of them to be open. If 20 per cent are open, as opposed to 40 per cent, it is going to cost (according to our model) more than twice as much per module to deliver each module. This is after all the benefits of modularity have been realised (if our model is to be believed).
Figure 3. The project schedule in elapsed days per module, against level of openness.
A similar benefit arises in respect of rapidity of delivery. Figure 3 shows the improvement in schedule that is realised if a modular system has a degree of openness. Again, if the openness according to our measure rises from 20 per cent to 40 per cent, the delivery time per module comes down from 600 days to 300 days (for the initial parameters set for this experiment).
The model that we have used assumes that systems are developed incrementally, so that the cost and schedule predictions are given per module. But in fact, if we apply the model to the whole system, we find the whole system itself follows a similar profile. Perhaps this explains why an open architecture leads to another benefit - increased innovation. Systems can be evolved either by producing enhanced functionality within modules (or within subsystems) or by producing new systems as new organisations of existing components. The idea that system evolution behaves (at least in respect of cost and schedule) more or less as module evolution behaves, suggests that the model we have used is a reasonable one.
It may be a little surprising that the gain in cost and the gain in schedule are more or less of the same degree. Usually one expects that the schedule would be even more reduced than the cost, because the schedule improvements are due to the potential for increased concurrency in the engineering processes. The reality is that, it is modularisation that largely accounts for the increased potential for concurrency in development and hence for reduced schedules, without necessarily reduced costs. Since we have corrected for modularity (by holding it fixed) the benefits in schedule shown by our model are more or less in a linear relationship with the benefits in cost.
4 Note on the Model
The model we have used is a development of Simon's model that was used to explain why a modular system evolves more rapidly than a flat one. We initially calibrated the model by repeating Simon's results and by looking at the benefits of varying degrees of modularity. We then added the extra dimension of openness (according to our definition). The results shown here are for a fixed degree of modularity and varying degrees of openness, thus the benefits are those of openness over an above those of modularity. For very large systems, because of the dominance of legacy structures, it may not be economically possible to make substantial changes to the modularity. Having an open architecture may be the only economic way to support through-life evolution.
The model assumes a modular open architecture which is characterised as follows. Each subsystem (think of Figure 2 as being a subsystem in a network of similar subsystems) is dependent on neighbouring subsystems through either open or proprietary interfaces. The modularity of the solution is determined by the number of levels of subsystems and the fan-out between them. Modularity is a fixed parameter of the model, so that the investigation considers the benefits of openness over and above those of modularity.
The openness of the solution is defined as the proportion of the interfaces that are open, so it is a number between 0 per cent and 100 per cent. However, since the model may not be reliable at the extremes and since, in practice, the extremes are very unlikely in practice, we have restricted ourselves to modelling openness between 20 per cent and 80 per cent.
The model assumes a development process which is characterised as follows. Each subsystem is developed incrementally and tested into acceptability. This is an error-prone process and errors lead to rework. The frequency of errors and the amount of rework they lead to are fixed parameters of the model.
By fixing the modularity and error-rate parameters, it is possible to isolate the benefits of adopting open architecture over and above the benefits of improved modularity and improved error-rates. The particular parameters chosen for the graphs shown here are considered to be close to those that might be experienced in reality. However, different choices for these parameters lead to much the same insights.
All that said, the model used here has not been validated and is still in development, so one should take away the insight, not the numbers. As the model develops, those developments will be presented here.