OIAm decomposition and modeling

Understanding the Infrastructure Architecture Repository

This Infrastructure Architecture Repository contains architecture & design guidelines in the form of construction models at various levels and from various angles. It is constructed by making use of one of the most important tools of OIAm: The Building Blocks Model. The first thing you should know about the Building Blocks Model is that it is primarily a decomposition tool. That means that it is used to dissect infrastructure landscapes into logical dimensions and parts in order to enable structured and methodological modeling (composition). It's like defining the Periodic Table first to practice chemistry subsequently in an orderly fashion.

The Building Blocks Model dissects the infrastructure landscape from five directions:

• Working Areas
• Environments
• Building Blocks
• Elements
• Quality Attributes

A 3D Graphic representation of the model:

3D Graphic of the Building Blocks Model

The decomposition order that is imposed by the model can be described as follows:

An infrastructure landscape consists of several Working Areas (Storage, Network, Server, Middleware, Client Realm). Within each Working Area, some kinds of infrastructure functionality reside (Building Blocks). The Working Area Storage offers for example a Raw Retention facility, the Network Working Area offers Access and data Distribution facilities and the Client Realm Working Area provides User Input, User Output, and other facilities that serve end-users. These facilities (Building Blocks) "live" in an Environment, that means that they are used in a certain business context and that the way of usage that is dictated by this context demands specific quality requirements. Examples of Environments within the Client Realm Working Area are Office, Kiosk and Remote. Within each Environment, quality demands are denoted by Quality Attributes with a value that is fitting to that Environment. On their turn, these values correspond to classes, provisions and/or permutations that are relevant to that Quality Attribute. Applied to the Building Blocks that live in a certain Environment, in the architectural process, architectural guidelines can be associated with a Building Block that is intended to be used in that Environment, in order to live up to the Quality Requirements for this Environment. These guidelines or requirements are denoted as Elements in the Building Block Model.

Some (graphically depicted) examples of the decomposition described above:

Decomposition example from the Working Area Server

Decomposition example from the Working Area Network

Composition is carried out by combining Building Blocks into patterns that offer a complete Solution to an organization. Examples are Application Hosting, Data Center Management and Office Automation. In this knowledge management system, both Pattern Types and Pattern Variants are contained. Pattern Types offer universal combinations of functions that are valid for many organisations. They serve as models or specimens for Pattern Variants, that function as moulds for specific Solutions, to be used within a specific context or a particular use.

Infrastructure modeling prerequisites

Before an infrastructure can be modeled by the infrastructure architects, some groundwork will have to be done first, as indicated in the figure below.

Modeling prerequisites

1. Prior to the actual modeling, the DIR must have been set up and filled with at least the following architecture artefacts, worked out to a sufficient level of maturity:
   1. All Working Areas (WA). Note that our example ArchiSurance stick to the standard five working areas that OIAm suggests (Client Realm, Middleware, Network, Server and Storage).
   2. All Quality Attributes (QA). Note that ArchiSurance stick to the six standard QAs as defined in the OIAm methodology. Under each of these six QAs, ArchiSurance have specified their own quality levels, and the technical measures that should be taken to ensure these levels.
   3. All Environments (ENV). These are ArchiSurance-specific architectural artefacts. Part of the ENV description is the “Quality demands” section, which outlines the minimum requirements that any Building Block Variant (BBV) should satisfy if it is to operate in the Environment.
   4. All Building Block Types (BBT). Note that ArchiSurance stick to the standard BBTs as published in the OIAm methodology as close as possible.
2. All Environments are fitted with relevant Quality Attribute levels that describe the quality they are supposed to offer

   - to applications that use “their” infrastructure facilities, and

   - to the Operations division that manages the infrastructure in this Environment.

Usually this means two or three Quality requirements. The way that the Environment gets to offer these QA levels is by requiring infrastructure facilities (in the form of Building Block Variants, BBVs) to supply ("offer") these QAs at or above the required level. This is indicated in the bottom of figure 1 by the arrow with the bold "requires". By requiring BBVs to supply ("offer") these QA levels, the Environment can be thought to indirectly supply these QA levels to applications, when they use infrastructure operating in this Environment. This is indicated on the right side of figure 1 by the dashed arrow with the bold "offers". Note however, that in the end it’s the BBV itself that actually supplies the application with the quality levels at or above the levels that the application requires. Also note that the Environment only imposes (lower limits on) two or three QA levels on the BBV, while the BBV supplies QA levels for all six QAs. As a final remark: in the end an application has very specific quality demands that actually need to be satisfied by the infrastructure supporting it. Should these demands exceed the baseline that the facilitating Environment(s) offer, then every BBV in the supporting infrastructure must offer these required QA levels, regardless of the lower demands requested by the Environment. Should this short text on Quality Attributes not be completely clear on first reading, please continue to the next section, and revisit this text after completing it.

With this ground work completed, an actual infrastructure can be modeled by the infrastructure architects, as outlined in the next section.

Infrastructure modeling (ideal flow)

Ideal modeling flow

When modeling an infrastructure facility using the OIAm, the following "ideal" modeling flow is suggested. Note that the "actual" modeling flow may be a highly iterative process, while iterations are not shown in this ideal flow.

For starters, an infrastructure facility is specified, required to deliver certain specified infrastructure services to applications, other infrastructure, or perhaps directly to end users. Using the purpose, characteristics and quality requirements of this infrastructure facility, the modeling flow begins:

1. The architect formulates the quality attribute levels that the infrastructure facility as a whole will need to provide.
2. From the required functionality, the architect either finds an existing Pattern Type (PAT) in the DIR, or creates a new one. The PAT is the mold that specifies at the most generic level all elementary infrastructure services that are needed to deliver the final infrastructure functionality.
   For a new PAT, the architect describes the purpose and functionality that infrastructure created after this PAT will deliver. Since this PAT may be used for more than one infrastructure, the architect strives to create a truly generic mold, that encompasses the requirements of the infrastructure at hand, but also caters for other possible infrastructures. For example: when creating a PAT for ArchiSurance Webfarm application hosting, the PAT is not forged tightly around the Webfarm requirements, but as a standard application platform that is usable in the Webfarm, but can also host applications internally for e.g. SAP.
3. If the PAT is newly created, the architect finds all Building Block Types (BBTs) that represent the elementary infrastructure services needed, and includes these in the PAT as mandatory or optional components. Furthermore, a PAT may make use of services of other “adjacent” PATs; these may appear as optional or mandatory adjacent PATs.
   Note that a Pattern Type has relations with adjacent Pattern Variants that are mandatory or optional, and is composed of Building Block Types, whose inclusion in the Pattern is mandatory or optional.
4. From the selected PAT, the architect can now start looking for a suitable Pattern Variant (PAV). If there is no such PAV, or if the PAT was newly created, then a new Pattern Variant needs to be created, based upon the (selected or created) PAT.
   The PAV is a much less generic mold, so its description and purpose will more closely match the infrastructure facility that’s being modeled. Also, the PAVs characteristics and indications for usage can be described. Using this, for every optional adjacent PAT in the Pattern Type on which this PAV is based, it can be determined if this PAV will have relations with corresponding adjacent Pattern Variants or not.
   From the PAT, the functionality and rationale for every optional BBT is considered, and either included in or excluded from the PAV as a Building Block Variant (BBV). Then, the QA levels are determined that the infrastructure is supposed to offer its users.
   Note, then, that a Pattern Variant has relations with adjacent Pattern Variants and is composed of Building Block Variants; there is no "optional" status for either at this level of modeling.
5. Now for each of the Building Block Variants that are needed in the Pattern Variant, either a suitable existing BBV must be found, or a new one created. Since BBVs sit right in the heart of the OIAm model, modeling them takes a few different steps. First step: each new BBV is modeled by starting from the Building Block Type, and further specify the description, purpose, characteristics and indications of usage.
6. Next step in the Building Block Variant modeling: the BBV is placed in a (primary) Environment in which it is supposed to operate (and in additional Environments as well, if the BBV can operate there without adjustments). Furthermore, the BBV is fitted with the necessary instructions from the infrastructure architect to the infrastructure designers, in the form of Elements (EL). Existing Elements can be added to the BBV, either mandatory, optional, or prohibited. This means things like standards, guidelines, configuration settings, and even concrete components (e.g. hardware or software) can be either prescribed, suggested, or declared forbidden by the architect.
   If necessary, the architect can add new Elements to the DIR, if the existing set of Elements does not contain the particular instructions that the architect wants to include.
7. The combination of the BBV description, the Environment(s) in which it can operate, and the Elements that the architect have included, will lead to a set of Quality Attribute levels that this BBV can satisfy.
8. The combination of BBV location in an Environment and the Elements that apply to the BBV (either mandatory, optional or prohibited) will yield a set of QA levels that the BBV will bring to the PAV.
9. To round off the PAV, it can itself now be augmented with Elements (again mandatory, optional, or prohibited) so that an infrastructure design for the required facility will comply with the standards, guidelines et cetera that the infrastructure architect deems applicable.
10. The Quality Attribute levels that all BBVs of the PAV bring to the table, combined with their interrelations within the PAV, will now yield a set of QA levels for the PAV as a whole. These levels must at least match the levels required for the infrastructure functionality in step 1.
11. When the PAV has been completed (including all adjacent PAVs!), it can be handed off to the infrastructure designer, who should now be able to come up with a fitting infrastructure design for the facility. In this step, the designer may consult with the architect for clarification, or perhaps for changes in the requirements, specifications, guidelines et cetera. In the latter case, an iteration of this architecture flow may be initiated.

Modeling with ArchiMate

It is possible to describe an infrastructure architecture in OIAm terms using the ArchiMate architecture modeling language. To help you create ArchiMate drawings of your infrastructure architecture, you can use one or more of these Visio shape stencils:

• stencil containing ArchiMate symbols at the architecture level;
• stencil containing regular shapes at the architecture level;
• stencil containing ArchiMate symbols at the implementation level;
• stencil containing regular shapes at the implementation level;
• and perhaps, if necessary, this stencil with generic OIAm icons.

These files should work with Visio 2003 and higher. The drawings in this wiki are created mostly with the ArchiMate symbols.

When creating an ArchiMate drawing for a OIAm pattern, the following guidelines are currently considered "best practice":

For modeling a Pattern Type:

• No Building Block Type can appear more than once.
• The Pattern Type modeled is drawn in the upper left corner.
• Each Building Block Type is connected to the Pattern Type with an Aggregation relation.
• Each Building Block Type and each adjacent Pattern is connected to the Pattern Type by at least one connection of type "used by" or "flow", either directly, or by connection to another Building Block Type that is connected. This means that each and every BBT and PAT can be "reached" from the Pattern Type by "walking" the connections.
• Connections of the same type can be bundled, so that e.g. three adjacent Pattern Types have a "used by" relation to the Pattern Type that ends at the Pattern Type in a single arrowhead. This may simplify the drawing and thus increase legibility, but should be used sparingly.

• You should avoid using more than 10 Building Block types in a single Pattern Type.

Information Model

Another way to look at the dimensions of decomposition of the Building Blocks Model, their interrelations and their connections to the composition dimensions is by viewing the Information Model (or ontology) below. This is the programmatical way in which the model is represented in this knowledge management system:

Ontology of Decomposition and Composition according to OIAm

Note that relations are defined at the base of the arrow, so you can "read" them in the direction of the arrow: "Environment" "Exists in" "Working Area".

This Information Model is used as the underlying structure of the Infrastructure Architecture Repository and its semantic embedding in this knowledge management system:

• The (de)composition dimensions (contained by the light gray rectangles) are the Categories in this knowledge management system;
• Relations between dimensions are entered as Properties;
• Quality Attribute values are registered as Properties with pre-defined values, and are called attributes in the semantic context as well.