The OIAm workflow

Introduction

OIAm workflow layers

OIAm uses a distinctive workflow for infrastructure creation, that was inspired by the work of Gerrit Blaauw (see text box below). This workflow is characterized by three separate steps or stages.

• 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.

An archetypical clock

Suppose an architect works at a railway company. The company request an architecture for a clock for use on the platforms of their railway stations. This "time indication facility" must adhere to a specific need of the travellers: all clocks must always show the same time. The architect selects from a reference architecture repository a suitable generic service that models the functionality of the requested facility: "the analogue clock". This functional model could be as simple as the description "the analogue clock is a facility that indicates time with two, optionally three discernible hands moving over a faceplate with indication marks for hours, and optionally minutes/seconds; the smaller hand indicates hours, the larger one minutes; the optional third hand indicates seconds". This functional model does not prescribe how the hands are moved, or any other technical detail, so it is accurate for many time indication tasks, be they a decorative device for the living room (hanging clock), a portable device with audible alarm for travellers (a travel alarm), or a personal wearable device (wristwatch). It is the absence of construction details that make this a truly generic model.

A functional station clock

The architect now applies the company’s requirements to the selected functional model of the generic service. To meet the "all show the same time" requirement, several solution directions are viable. One such solution could be to use very accurate movements; another could be to use a time synchronization network that periodically sends out a synchronization signal, e.g. once per minute. Our architect selects the latter solution direction, and specifies it as an architecture requirement. (Note that he now also has to create the functional model for this synchronization network.) As a result, the architect creates an applied functional model (Figure 2), and delivers it, together with the architecture requirement, to the designer.

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

An actual station clock

In the third stage, the facility’s design is engineered in the physical world. Engineers use generic recipes for realizations, as designers use generic designs, and architects use generic services: the infrastructure facilities under construction are mostly built from standard parts from preferred suppliers, configuration parameters are derived from standard sets of parameters, and the order in which parts of the facility are built, configured and connected is standardized to a high degree.

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

OIAm workflow with an example

When plotting the preceding different steps for designing an infrastructure facility on the layers, we see a pattern that's repeated in every one of the three layers.

• 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.