The OIAm workflow
- a functional stage, where generic functional models are translated into applied functional models, using stakeholder requirements as input, and delivering functional models and sets of architecture requirements as output;
- a technical stage, where generic technical models is translated into applied technical designs, using the architecture requirements and functional models as input, and delivering design specifications and construction models as output;
- a realization stage, where generic construction components are translated into specific constructions, using the design specifications and construction models as input, and delivering the actual constructions with their configuration as output.
In each of the three stages, there is a movement from archetypical or generic models towards applied, more specific models, by which the archetypical model is specialized so that it fits optimally within the target context. In a simple diagram, this model looks like the diagram on the right.
|Early in the 1960s, Gerrit A Blaauw worked with Fred Brooks and Gene Amdahl on the IBM s/360 mainframe. This not only led to some influential new features (such as fixed length 8-bit byte, 32-bit word, and the EBCDIC character set), but also to a new view on the development of IT systems, that Blaauw outlined in a paper as far back as 1972. In this paper, Blaauw proposed to subdivide the design process of a computer system in three distinct stages, which he called architecture, implementation, and realization. Blaauw illustrated these design stages with the example of an (analogue) clock.
When developing OIAm, we built on the ideas of Blaauw to suit the intricacies of modern infrastructure, and derived a version of Blaauw’s three step approach geared to infrastructure creation. The three steps are outlined summarily in the following. Note that the first two steps have been relabelled from Blaauw’s original terms ("architecture" and "implementation"), to prevent misconceptions that the original names could raise.
Stage 1: Functional design
In the first stage of the infrastructure creation process, the architect starts from the requirements of the stakeholders for the target facility. In the (common) case of multiple stakeholders, these requirements must be consolidated into a single, consistent set. Using these consolidated requirements, the architect can then select a generic functional model of an infrastructure service that corresponds with the (main) functionality that the stakeholders requested. This functional model is then specialized to meet the specific needs of the stakeholders as reflected in the consolidated set of stakeholder requirements. Choices made in this stage can be product-neutral, and even technology-neutral, as the following example shows.
Stage 2: Technical design
In the second stage of the infrastructure creation process, the architecture created in the previous stage serves as a means to select one or more generic construction designs that can deliver the requested functionality. These generic construction designs are then specialized, so that they will satisfy the accompanying architecture requirements, resulting in a construction design and accompanying design specifications.
Continuing the example of the station clock: the next step is to take the functional model, and work this into a viable technical design. This work is done by the railway company’s designers, who starts by selecting a fitting type of movement from their own library of generic construction designs. They then specialize this generic design, so that it on the one hand satisfies the provided architecture requirements, and on the other hand also fits the stations’ other infrastructure to which it may be connected. A design is made for an electrically driven movement, that runs the seconds hand at a speed of one revolution per 59 seconds, plus or minus half a second, and then waits for an electric pulse before continuing. The clock will have to be connected not only to the mains for electric power, but also to a synchronization network that delivers this electrical pulse. (Furthermore, from the second functional model from the architects, they will create a design for this synchronization network so that it outputs pulses matching their clock design’s synchronization input specification.)
Stage 3: Realization
Concluding the example of the station clock: the railway company’s instrument makers receive the drawings and specifications of the clock and the synchronization network. They will then select from their catalogues of construction components the parts they need: electrical movements, clock face, hands, enclosures, brackets, connectors, wire et cetera. They then order the parts in the quantity and dimensions needed, assemble and test the ordered platform clocks, then deliver them to station maintenance for installation on the platforms.
Moving from archetypical to implementation patterns
- At the Functional Design layer, the architects complete their design documents by accepting the requirements of the stakeholders, then start from generic architecture patterns, and specialize them into a design pattern that satisfies the proposed requirements and constraints.
- At the Technical Design layer, the designers complete their design documents by accepting the designs and requirements of the architect, then start from generic design patterns, and specialize them into a design pattern that satisfies the architects' requirements.
- At the Realization layer, the engineers build the actual infrastructure facility by accepting the designs and requirements of the designers, then start from generic realization patterns, and specialize them into discrete facilities that satisfies the designers' requirements.
Note that OIAm itself operates in the first layer, providing generic patterns and describing how to specialize this into applied patterns.
Advantages of the OIAm workflow
Working with the OIAm workflow gives the architects the following advantages:
- A clear delineation between the working areas of the architects and the designers;
- A practical approach for collection and processing of stakeholder requirements;
- A structure that supports iterations in the infrastructure creation process.