Architecture workflow based on Blaauw - Revision history

Jan Schoonderbeek: update

2013-02-14T17:16:59Z

update

← Older revision		Revision as of 17:16, 14 February 2013
Line 1:		Line 1:
	{{Docbookmenu		{{Docbookmenu
	\|backlink=OIAm_Offering		\|backlink=OIAm_Offering
	\|backlinkname=previous: What does ~~DYA{{!}}Infrastructure~~ offer?		\|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\|~~“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). ~~When working with~~ OIAm~~, one can readily recognize~~ the ~~three domains as put forward~~ by Blaauw:		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:

	==~~Architecture~~==		==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" />. ~~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~~.		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 ~~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.		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".

	~~==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."''<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 ~~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:		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==
	~~''"~~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" /> 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~~.		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 ~~DYA{{!}}Infrastructure~~ offer?		\|backlinkname=previous: What does OIAm offer?
	\|homelink=OIAm_Introduction		\|homelink=OIAm_Introduction
	\|homelinkname=up: table of contents		\|homelinkname=up: table of contents

Jan Schoonderbeek: Jan Schoonderbeek moved page Architecture according to Blaauw to Architecture workflow based on Blaauw: better name

2013-02-14T16:49:27Z

Jan Schoonderbeek moved page Architecture according to Blaauw to Architecture workflow based on Blaauw: better name

← Older revision

Revision as of 16:49, 14 February 2013

Peter Oukes: start

2012-11-11T23:22:21Z

start

New page

{{Docbookmenu
|backlink=OIAm_Offering
|backlinkname=previous: What does DYA{{!}}Infrastructure offer?
|homelink=OIAm_Introduction
|homelinkname=up: table of contents
|fwdlink=OIAm Architecture Process
|fwdlinkname=next: Infrastructure architecture and the architectural process
|bgcolor=white
}}
<br>
----
<br>
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). 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"''<ref name="blaauw" />. 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."''<ref name="blaauw" /> 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."''<ref name="blaauw" /> 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==
<references/>
<br>
----
<br>
{{Docbookmenu
|backlink=OIAm_Offering
|backlinkname=previous: What does DYA{{!}}Infrastructure offer?
|homelink=OIAm_Introduction
|homelinkname=up: table of contents
|fwdlink=OIAm Architecture Process
|fwdlinkname=next: Infrastructure architecture and the architectural process
|bgcolor=white
}}