OIAm Architecture Process

previous: Architecture workflow based on Blaauw	up: table of contents	next: The Infrastructure Quality Attributes

---

The OIAm architecture process

Business, information and infrastructure architectures share a common goal: to provide optimum support for an organisation’s operations. This is impossible without input from, and feedback between, the three architectural disciplines. To act effectively within the architectural process and at the same time be sufficiently responsive, each discipline must follow the dynamics and structures which underline their own respective area of competence. This certainly applies to infrastructure architecture, which must make its role easily recognisable by clarifying the terms it uses within the infrastructure domain. The easiest way to do this is to describe infrastructure solutions in logical and functional terms. OIAm defines the “capability” of a solution with a set of quality attributes. Quality attributes also have an important role in harmonizing the architectural process across the three architectural disciplines, because regardless of the underlying (technological) structure, quality attributes can be reconciled across the domains and be used throughout the entire solution. At the same time, they also provide input for the engineering, creation and testing of solutions within their own area of competence. That is why quality attributes are a recurring theme throughout the different phases and activities of infrastructure architecture and why it is of the utmost importance to choose and define quality attributes carefully. At the very least, they must illustrate the unique and inherent quality of an infrastructure solution.

Quality attributes for communication

Cooperation between architecture disciplines demands mutual understanding and agreement on Quality Attributes used

The architectural disciplines must be able to adjust to each other whenever necessary during the architectural process without compromising themselves. They should make clear what they can contribute and indicate their own limits. The full scope of wishes and requirements can not always be fulfilled; particularly if they (even minimally) conflict with each other. Should one of the disciplines want or need to dictate the eventual outcome, it should receive appropriate guidance from the architectural process, keeping in mind that the guidance must be relevant to the specific area of competence. The architectural process will select the quality attributes which are most realistic and appropriate for the direction in which the desired solution should be sought. This set of quality attributes can be seen as a mandate for each discipline to individually work on their own part of the total solution. The quality attributes ensure that the resulting solutions are not developed in isolation, but that they will remain consistent within the complete architectural framework. The set of quality attributes will also provide a means checking and reporting on delivered results.

To avoid disciplines talking at cross purposes, unequivocal agreement is needed on the quality attributes which each discipline brings into the architectural process. These must serve as the basis for the further reconciliation and harmonization of definitions within the architectural process. Infrastructure architecture will provide its own set of quality attributes, alongside the specific quality attributes of the business and information architectures.

Apart from the quality attributes, there are two major restrictions that influence the potential direction of a solution, namely cost and time. These restrictions are imposed by the outside world (usually by the organization) and affect all forms of architecture. Time and money are generally the most important determinants of the scale and quality and thus feasibility of a solution. In many cases, time and money are so restrictive that a different weighting must be given to a number of quality attributes to come up with a realistic solution. As a result, the architectural process will occasionally and justifiably turn into a debate between the parties involved, resulting in a solution that will optimally serve the organization’s interests within the confines imposed by time and money.

Quality Attributes for Infrastructure Architecture

Quality attributes are by nature abstract, because they indicate "how" but not "what". Within the architectural process, relationships are identified between the quality attributes from one discipline and comparable quality attributes in another discipline. This makes it easier to identify how choices made in one area will influence possible solutions in other areas. The more pro-actively this occurs and the more quality attributes that can be reconciled, the more constructive the process will be. Within this harmonization process, "similar" quality attributes will be easily traceable to each other, while others are far more likely to underline the uniqueness of a particular discipline. Nevertheless, a discipline will usually recognize itself in the quality attributes of other disciplines, provided that they have been properly defined and explained.

Keeping in mind the objective of building the infrastructure function as a utility, there are three categories, with two quality attributes each, that express the inherent quality of infrastructure solutions:

• Flexibility (adaptability and scalability);
• Reliability (availability and integrity);
• Maintainability (manageability and accountability).

The six quality attributes defined here do not apply exclusively to infrastructure applications, but they are the guiding set for building "infrastructure as utility".

The participants in the architectural process are not always sufficiently aware of the importance of the quality attributes of their own fields of expertise, and the consequences that their explicit requirements will have on the other areas. It is then up to the other participants to explain the implicit or explicit consequences for their own domain. For example: a certain business architecture solution requires 99.99% "availability". Infrastructure responds by saying they can meet this requirement in terms of "availability", but it will have significant consequences in terms of "scalability" and "money". Business architecture will then be expected to indicate whether, in that light, the specified availability requirement is still justifiable. A situation must be avoided where disciplines impose quality attributes and terms on each other purely to achieve their own goals with disregard for those of the other disciplines, because it is utterly counter-productive and will thwart the architecture process itself. Quality related terminology within one discipline often means something else, or even nothing at all, outside that discipline's domain.

The six dominant quality attributes for the infrastructure domain are explained in more detail in the next section.

---

previous: Architecture workflow based on Blaauw	up: table of contents	next: The Infrastructure Quality Attributes