Lingo Explained : From Baseline to Target

The definitions according to Togaf ;
Baseline : “A specification that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development or change and that can be changed only through formal change control procedures or a type of procedure such as configuration management.”
Target Architecture : “The description of a future state of the architecture being developed for an organization. There may be several future states developed as a roadmap to show the evolution of the architecture to a target state.”
Gap : “A statement of difference between two states. Used in the context of gap analysis, where the difference between the Baseline and Target Architecture is identified.”
Transition Architecture : “A formal description of one state of the architecture at an architecturally significant point in time. One or more Transition Architectures may be used to describe the progression in time from the Baseline to the Target Architecture.”

kvaes-baseline-target-interim-architectures

So to translate this to the terms that are already being used in “the real world” too;
Baseline : The baseline is the “AS IS” situation. This is something you should already be aware of, as this is your operational baseline for your configuration management, and thus the basis for all change requests (as probably generated from an architecture change).
Target : This is the “TO BE” situation, your “flag in the distance” to indicate where you want to be.
Transition Architecture : These are your waypoints to get to your goal (being the target). Sometimes these are called “Interim Targets”, where they are called “Plateau” according to the “Implementation & Migration” extension of Archimate.
Gap : The “diff” between your starting point (“AS IS”) and your destination (“TO BE”).

Advertisements

Lingo Explained : Am I compliant?

Intro
Ever wondered what the difference is between compliant, conformant & consistent? has some nice definitions about it that will guide you in these statements.

Irrelevant
Irrelevant
When the targetted specification and the actual implementation do not have anything in common, then this is called “Irrelevant”.

Consistent
Consistent
Once the specification and implementation share common grounds. Yet not all specifications are met and features that were not covered by the specification are provided, then this is called “Consistent”.

Compliant
Compliant
Once not all features of the specification are implemented, yet all things that are implemented are according to the specifications, then this is called “Compliant”.

Conformant
Conformant
If all the features of the specification are implemented according to the specs, yet some features are implemented that are not in accordance to the specification, then this is called “Conformant”.

Fully Conformant
Fully Conformant
If there is a full match between specifications and implementation, then this is called “Fully Conformant”. You can probably guess how rare this one is… 😉

Non-Conformant
Non-Conformant
Any of the above situations, yet some features that are implemented are not in accordance to the specification.

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