Consistency, one might argue, is the hobgoblin of little minds. But in reality, what it comes to sharing ideas between teams scattered over the globe and articulating designs for someone to build stuff on - consistency of expression is your best friend. Sab Saini MBCS and Gagan Gandhi CITP look at the need of standardisation of architecture description in the IT space in general and the challenges that the infrastructure architecture domain faces in achieving that.

Whether it’s a naval engineer designing an aircraft carrier or an IT architect designing a financial system for an Investment bank - the architecture community as a whole has realised the value of standardisation and uniformity of representation of information for a long time now.

Standardisation enables model driven architecture; and helps create different views from the same information based on stakeholder needs. One of the key pain areas of architecture teams today is representation of information - which gives rise to unruly and huge architecture description documents, time spent in understanding current state and validating (and re-validating) what the document meant to say. Architects spend more time trying to unearth the current state in large enterprises; or doing the archaeology; than they spend creating new designs.

Architecture description process - maturity model

The architecture description process maturity model shows the typical journey an organisation would take moving from a non-standardised and chaotic state to a state where teams can seamlessly collaborate with each other and static Word documents for architecture description become history.

Architecture description process - maturity model

The standardisation phase - as the name states - is all about bringing in consistency of notations and processes. It promotes common language of communication, reduces communication barriers and encourages reuse of assets. The key to standardisation is to agree on a meta-model to represent architecture concepts; industry standard languages like UML and ArchiMate® have become the de-facto choice for business and application domains.

Standardisation by itself does not require a change in the modelling tool. MS Visio and PowerPoint are as powerful and effective as any EA tool to bring in consistency.

The collaboration phase - depends on the use of an enterprise architecture tool. This is a development phase in which organisations would implement a shared asset repository; and automate the production of word document to describe architecture. It is essential to establish the methods and standards before the tool selection - the standards govern the choice of tool and not the other way around.

Many organisations deal with architecture description maturity as a one-step process instead of the highlighted two-phase approach. Doing it all in a single phase is a leap too far where the value realisation does not happen till at least a few months after the journey has ended. It creates resistance among teams that are asked to adopt two changes at the same time - change in standards and change of tool.

When it comes to industry support for defining and implementing standard notations and practices, Archimate® and UML are the de-facto choice for much of the IT architecture community. While they provide considerable power and flexibility to the business and application architecture domains, its support for infrastructure architecture is flaky at best.

Having realised this gap in capability of Archimate®, we have developed an extension for infrastructure modelling to be used along with the rest of Archimate® concepts. The extension provides additional concepts and attributes, defines specific views, and enables articulation of infrastructure architecture and design through a limited set of views created from models.