Architecture workflow based on Blaauw: Difference between revisions
m (Jan Schoonderbeek moved page Architecture according to Blaauw to Architecture workflow based on Blaauw: better name) |
(update) |
||
| Line 1: | Line 1: | ||
{{Docbookmenu | {{Docbookmenu | ||
|backlink=OIAm_Offering | |backlink=OIAm_Offering | ||
|backlinkname=previous: What does | |backlinkname=previous: What does OIAm offer? | ||
|homelink=OIAm_Introduction | |homelink=OIAm_Introduction | ||
|homelinkname=up: table of contents | |homelinkname=up: table of contents | ||
| Line 11: | Line 11: | ||
---- | ---- | ||
<br> | <br> | ||
In 1972, Gerrit Blaauw<ref name="blaauw"> [[Media:Blaauw Architectuur.pdf| | In 1972, Gerrit Blaauw<ref name="blaauw"> [[Media:Blaauw Architectuur.pdf|"Computer Architecture"]], Gerrit A. Blaauw, Elektronische Rechenanlagen, 1972 heft 4, page 154-159</ref> 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). OIAm proposes a workflow for the infrastructure creation process that borrows heavily from the design stages proposed by Blaauw: | ||
== | ==Functional Design== | ||
''"The architecture of a system can be defined as the functional appearance of the system to the user, its phenomenology"''<ref name="blaauw" />. | This stage in the workflow is the domain of the infrastructure architect. ''"The architecture of a system can be defined as the functional appearance of the system to the user, its phenomenology"''<ref name="blaauw" />. OIAm proposes that at the start of an infrastructure creation process, we limit ourselves to infrastructure functionality, and leave out the actual construction. In this way, we will limit ourselves to the essentials: what does the infrastructure facility need to do? To this end, we can regard the facility as a single infrastructure function, aggregated from basic, atomic infrastructure functions. "Atomic infrastructure function" in this respect means a logical infrastructure function that we do not subdivide any further into sub-functions – at least not at the architecture level. | ||
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 | When such basic 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 common infrastructure services are to be realized by infrastructure functions that are aggregates of these basic infrastructure functions, then these aggregate infrastructure functions will also look very much alike between organizations. Thus, the "architecture" viewpoint proposed by Blaauw leads to a view on infrastructure functionality that can be called "archetypical". OIAm calls these archetypical basic infrastructure functions "Building Block Types", and the common aggregate infrastructure functions "Pattern Types". | ||
''"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."''<ref name="blaauw" /> In any organization, an infrastructure service needs to be delivered within a limited set of organization specific contexts. 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". | |||
''"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."''<ref name="blaauw" /> In any organization, an infrastructure service needs to be delivered within | |||
Thus, implementing an infrastructure service means: | Thus, implementing an infrastructure service means: | ||
| Line 26: | Line 25: | ||
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. | 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. | Note that with the previously presented definition of infrastructure architecture, both the Blaauw “architecture” and “implementation” are subject to the infrastructure architect. | ||
==Technical design== | |||
This stage in the workflow is the domain of the lead infrastructure designer. ''"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."''<ref name="blaauw" /> The technical design is the field of infrastructure designers. It is their responsibility to create from the functional, high level design that the architect provides, a technical design that can lead to a facility that is both feasible and maintainable (including the cost aspect of both). For an infrastructure facility, this involves selection of technologies and products (inasfar as the architect hasn't preselected some of these), determining topographies, creating overviews of high and mid level configuration details, et cetera. | |||
==Realization== | ==Realization== | ||
This stage in the workflow is the domain of the infrastructure lead engineer and his team. The technical design will have to be realized by actually linking and configuring infrastructure hardware components, installing and configuring software such as operating systems and infrastructure applications, and creating and providing infrastructure specific data such as certificates, all within the boundaries set by the technical design. The result will have to be a working infrastructure facility, usually accompanied by a configuration specification. | |||
==References== | ==References== | ||
| Line 37: | Line 39: | ||
{{Docbookmenu | {{Docbookmenu | ||
|backlink=OIAm_Offering | |backlink=OIAm_Offering | ||
|backlinkname=previous: What does | |backlinkname=previous: What does OIAm offer? | ||
|homelink=OIAm_Introduction | |homelink=OIAm_Introduction | ||
|homelinkname=up: table of contents | |homelinkname=up: table of contents | ||
Latest revision as of 18:16, 14 February 2013
|
|
|
| previous: What does OIAm 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). OIAm proposes a workflow for the infrastructure creation process that borrows heavily from the design stages proposed by Blaauw:
Functional Design
This stage in the workflow is the domain of the infrastructure architect. "The architecture of a system can be defined as the functional appearance of the system to the user, its phenomenology"[1]. OIAm proposes that at the start of an infrastructure creation process, we limit ourselves to infrastructure functionality, and leave out the actual construction. In this way, we will limit ourselves to the essentials: what does the infrastructure facility need to do? To this end, we can regard the facility as a single infrastructure function, aggregated from basic, atomic infrastructure functions. "Atomic infrastructure function" in this respect means a logical infrastructure function that we do not subdivide any further into sub-functions – at least not at the architecture level.
When such basic 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 common infrastructure services are to be realized by infrastructure functions that are aggregates of these basic infrastructure functions, then these aggregate infrastructure functions will also look very much alike between organizations. Thus, the "architecture" viewpoint proposed by Blaauw leads to a view on infrastructure functionality that can be called "archetypical". OIAm calls these archetypical basic infrastructure functions "Building Block Types", and the common aggregate infrastructure functions "Pattern Types".
"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 a limited set of organization specific contexts. 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.
Technical design
This stage in the workflow is the domain of the lead infrastructure designer. "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] The technical design is the field of infrastructure designers. It is their responsibility to create from the functional, high level design that the architect provides, a technical design that can lead to a facility that is both feasible and maintainable (including the cost aspect of both). For an infrastructure facility, this involves selection of technologies and products (inasfar as the architect hasn't preselected some of these), determining topographies, creating overviews of high and mid level configuration details, et cetera.
Realization
This stage in the workflow is the domain of the infrastructure lead engineer and his team. The technical design will have to be realized by actually linking and configuring infrastructure hardware components, installing and configuring software such as operating systems and infrastructure applications, and creating and providing infrastructure specific data such as certificates, all within the boundaries set by the technical design. The result will have to be a working infrastructure facility, usually accompanied by a configuration specification.
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 OIAm offer? | up: table of contents | next: Infrastructure architecture and the architectural process |