Infrastructure Architect : TOGAF, what is in it for me?

TOGAF Vision
What’s TOGAF?

“The Open Group Architecture Framework (TOGAF®) is a framework for enterprise architecture which provides a comprehensive approach for designing, planning, implementation, and governance of an enterprise information architecture.” Source

Why use TOGAF? It’s currently the most adopted and accepted methodology for Enterprise Architecture. So by using the concepts given by TOGAF, integration with other parties will (in time) become more standarized.

Basically it’s a high level framework of the process and model needed to fulfil enterprise architecture. Be aware that the concept of “Enterprise” is seen as a mere scope. So your own department can be seen as an enterprise, which would impose that multiple enterprise architectures are used within your company. The abstraction is really high level where the focus is to achieve a “Boundaryless Information Flow”. This means that the objective of TOGAF is to be able to easily share information across businesses. So the enterprise scope defines the boundaries to which you want your interfaces to become “available”. How does TOGAF look to achieve this goal? By using the following building blocks to help you in the process…

Architecture Development Method
The “ADM” (Architecture Development Method) is the core of TOGAF indicating the process flow for enterprise architecture. The steps used in this process can be viewed as common sense and are probably used by most companies in one way or another.

The prelim & phase A provide the context & vision for the process, phase B/C/D define the architecture, phase E/F define the transition and G/H define the governance.
(Source)

Architecture Content Metamodel

The content metamodel provides a definition of all the types of building blocks that may exist within an architecture, showing how these building blocks can be described and related to one another. For example, when creating an architecture, an architect will identify applications, “data entities” held within applications, and technologies that implement those applications. (Source)

The “Architecture Content Metamodel” has to goal to drive a greater consistency in the way designs are made. So by using the same concepts, communication and integration between different parties should become less complex/difficult. Archimate has been adopted by the Open Group as the language to describe this content framework.

The keen eye will have noticed that the “Technology Architecture” is only a small part of the entire metamodel. In my opinion, Infrastructure Architecture is responsible for the “Technology Architecture” and a part of the “Information Systems Architecture”. The hybrid situation is due to the fact that most Infrastructure Architects are also responsible for “Infrastructure Applications”. Most “Application Architects” will not care too much about (for instance) email systems…

Architecture Continiuum

The Enterprise Continuum is intended to represent the classification of all assets that are available to an enterprise. It classifies assets that exist within the enterprise along with other assets in the wider environment that are relevant to the enterprise, such as products, research, market factors, commercial factors, business strategies, and legislation. … The enterprise needs and business requirements are addressed in increasing detail from left to right. The architect will typically look to find re-usable architectural elements toward the left of the continuum. When elements are not found, the requirements for the missing elements are passed to the left of the continuum for incorporation. Those implementing architectures within their own organizations can use the same continuum models specialized for their business. (source)

Basically TOFAF indicates that the objective should be to create reusable models; kinda like patterns with applications… and to have various drilldown viewpoints towards the architecture. The more you go down, the more specific you can become. Where the objective is only to differentiate when it’s a true advantage to your business. Otherwise it would make more sense to follow the industry standard, as this will make the integration between different parties less complex, as the (near) same structure has been used.

Architecture Repository
Just like any kind of repository, TOGAF identifies that there is an architecture repository which stores the “baseline” (current situation) and all reference models. Even if there is no physical/agreed location, then this repository will already be present in the architect’s mind. Yet as always, this is not good thing to do from a business side, as the architect will become a critical resource within your organization.

A clear business motivation for the repository is to get a standardized way of documenting the (entire) information flow and all its components. We’re currently in a time period where a lot of our colleagues are nearing retirement. This could pose as a knowledge drain to a lot of companies…

Reference Models

This chapter describes the Technical Reference Model (TRM), including core taxonomy, graphical representation, and the detailed platform taxonomy. (source)

Architecture Capability Framework

In order to successfully operate an architecture function within an enterprise, it is necessary to put in place appropriate organization structures, processes, roles, responsibilities, and skills to realize the Architecture Capability. (source)

Basically, this boils down to the fact of getting the right skills on the job. Where this might seem as dead obvious, it’s something where a lot of companies fail…

So in practice?
And to get back to the initial question ; “As an Infrastructure Architect, what’s in it for me?”
Personally I find the following items to be interesting ;
– Use the same language as all other architects (from different domains) : For modelling that would be ArchiMate, but also the concepts used to determine certain facets
– Use an integrated modeling tool to be able to get all connections documented and reuse system components for different viewpoints
– “Know your position within the flow” and that most concepts do not differ too much from what you’ve already been doing