The OIAm workflow
Introduction
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.
| 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[1] 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.
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.
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.