Architecture workflow based on Blaauw
|
|
|
| previous: What does DYA|Infrastructure offer? | up: table of contents | next: Infrastructure architecture and the architectural process |
In 1972, Gerrit Blaauw[1] described how one could think about computer design as separable domains: architecture, implementation and realization. However, the concepts introduced by Blaauw do not hold just for mainframe architecture, but also for IT architecture (and arguably for all forms of architecture). When working with OIAm, one can readily recognize the three domains as put forward by Blaauw:
Architecture
"The architecture of a system can be defined as the functional appearance of the system to the user, its phenomenology"[1]. When discussing the architecture of an infrastructure facility, we will limit ourselves to the essentials: what does it do? To this end, we regard the facility as an infrastructure service, compounded of basic, atomic infrastructure functions. "Atomic infrastructure function" in this respect means a logical infrastructure function that cannot be meaningfully subdivided into sub-functions – at least not meaningfully for architectural purposes.
When infrastructure functions are described in generic terms, apart from any technical implementation, then they will look identical for most (if not all) organizations. Similarly, when infrastructure services are composed out of basic infrastructure functions, they will also look identical between organizations. And this is precisely what one would expect on an architectural level, according to the definition by Blaauw.
Implementation
"The implementation is the logical structure which performs the architecture. Where the architecture tells what happens, the implementation describes how it is made to happen."[1] In any organization, an infrastructure service needs to be delivered within one organization specific context, or possibly multiple of these. These contexts influence the way in which an infrastructure service must be delivered. For instance, a Ministry of Defence PC in an office in the capital looks different from a PC in the back of an armoured personnel carrier on the battlefield. This is because the context "battlefield" imposes different requirements on the infrastructure facility than the context "office".
Thus, implementing an infrastructure service means: identifying the contexts and their requirements, in which the service must operate, and locating the infrastructure functions that are part of the service in these contexts, and specifying them to a level of detail that can account for the identified requirements. At the implementation level, infrastructure services and functions can still be kept quite generic; there is no need to propose specific products or technical standards (although this is of course possible). However, because of the influences of the contexts, the services and functions can often be expected to be organization-specific. Note that with the previously presented definition of infrastructure architecture, both the Blaauw “architecture” and “implementation” are subject to the infrastructure architect.
Realization
"The physical structure, which embodies the logical design, will be called the realization. Here, the 'which' and 'where' of component selection, allocation, placement and connection will be considered separate from the 'how' of the logical structure."[1] Realization of an infrastructure service is the field of infrastructure designers and engineers. It is their responsibility to create from the implementation a facility that is both feasible and maintainable (including the cost aspect of both). In this phase, infrastructure designs are created and the facilities actually get built.
References
- ↑ 1.0 1.1 1.2 1.3 “Computer Architecture”, Gerrit A. Blaauw, Elektronische Rechenanlagen, 1972 heft 4, page 154-159
|
|
|
|
| previous: What does DYA|Infrastructure offer? | up: table of contents | next: Infrastructure architecture and the architectural process |