Architectural thinking and ArchiMate Modelling

Connecting the Architectural world to the Operational World

We can all agree that ArchiMate is a mechanism to model the architecture of an organisation. In this we mean we model the “types” of things in the organisation rather than actual instances of things. Our world is one of standard patterns and designs which can be implemented again and again. For instance, if we use construction as our example, we might hold a pattern library of standard design constructs. A door will be 37 inches wide and 6 feet and 8 inches high with 3 hinges at 10 inches from either end and one in the centre with a handle and catch placed 42 inches from the top. We can use this standard pattern in all our designs. We can have a standard pattern for a bathroom stating it must have a bath, shower, sink and lavatory, a door (to our standard pattern stated elsewhere), and any principles that govern this room such as electrical safety or min and max distances and any requirements we might place on the components. We can then build designs using these patterns. Our bathroom will have these components of these make and model, placed in these positions, connected in this way etc. We are not modelling instances of the bathroom traditionally.

There is, however, an obvious connection between architecture and the physical world. Every instance of an object in the physical world can be assigned to a “type” held within our architectural models.  If we can link our understanding of the Architectural and Operational worlds there are a series of benefits:


We can see where there are deviations from our designs and standard patterns. For example, we made a decision that a Windows Application Server would run an Antivirus product and a backup solution and that the make and models of these products should be Windows Server 2008 R2 64 bit with Symantec Backup Exec 2012 and Symantec Endpoint Protection 12 (other products also available). We could then see that server ABC123 with IP address 123.456.123.456 is deviating from this standard and potentially requires an upgrade.  We can then assess the potential cost to update actual servers and produce an accurate picture of overall Technical Debt.

We can also get a clear understanding of how different business units or geographies implement a solution differently; our US implementation of SAP is different to our UK implementation.

Impact Upon the Business

Traditionally in the operational world especially with ITSM IT Service Management) techniques such as ITIL we would be focusing on our assets and understanding their links to a list of services we have established. This list of services is often confused. In our architectural world where we use service orientated thinking using languages such as ArchiMate we are comfortable understanding services using languages like ArchiMate at the level of Application and Technology. The architectural world can provide clearer guidance on the services that ITSM programmes should manage together with an understanding of requirements. In addition the linkage into the larger enterprise wide architecture means that there is a clearer understanding of how IT services are depended upon by the business. We can potentially understand which business processes are supported by which server. Which people performing which roles will be affected if a server were to go offline. This makes the process of planning maintenance much easier. If we take this server offline we will affect these business critical processes. However these processes do not occur on the weekend so we can perform the upgrades then.

Problem Analysis

This aspect of ITSM is a challenge without any kind of documented architecture. Tracking the source of a problem reported by a user without any understanding of the dependencies between the application used and the rest of the estate is tough. Many CMDB (configuration Management Database Base) products through their auto discovery capabilities offer a packet sniffing mechanism which can observe traffic between servers and guess the applications concerned based on the type of data and the ports they hit. This is not reliable and no substitute for a clearly documented architecture connected to the operational landscape. In our joined up world we are able to see that this application has dependencies upon these other applications which are deployed upon these servers, one of these is connected via this router which is displaying a fault.

Planning and Assessing the Impact of Change

With a well defined as-is architecture we have a good chance of being able to understand and asses the impact of change in principle but being able to define actual impact and therefore the effort and cost is harder. Again in our joined up world we have a much better chance. In our architectural world we could assess that changing our Customer Reference Number affects a range of asset types.  This piece of data is used in these data flows between a series of applications and is held in a series of schema in a series of data stores, resides in a collection of business data objects (documents, reports etc.). These applications support a collection of business processes in which a collection of roles and thus actors participate. The applications reside on a series of platforms. This information can give us estimations on effort and cost to redevelop software, database schema, business documents, inform people etc. If we are connected to our operational world we can see exactly where this software and database schema are deployed and give us a feel for deployment costs.

A well recognised common problem noted over the last 15 years which has a surprising impact is miscommunication between teams. Business people use different names for things to the application teams who then use different terms to the infrastructure. In our joined up world even if we don’t use the same terms we can see the relationships between these terms. In the CMDB we call the application X but in our architecture we call it Y.

ArchiMate example diagram

With modelling metamodels we can connect architectural tools to asset management tools such as CMDBs, document management tools etc.

Architectural modelling tools  can connect  to asset management tools such as CMDBs, document management tools etc. to help us chive visbility of the assets, their composition and their value to the business.

EA Dynamics Uk offer training and consultancy for modelling practice and metamodels such as Archmiate Accredited courses.  Please feel free to contact us to learn more.


Benefits of Modelling

  • Ability to articulate strategic view of landscape Optimise data use
  • Reduce infrastructure duplication and optimise non-functional aspects
  • More effective decision making due to up front options analysis with simulation of key requirements
  • Ability to communicate conflicting goals and drivers and facilitate conflict resolution
  • Highlight misalignment of priorities
  • Show competing demands for business services allowing compromise service levels to be defined
  • Improve oversight and Architectural Governance

Open Group Certification logo is a trademark and TOGAF is a registered trademark of The Open Group in the United States and other countries. TOGAF® 9 Practitioner Certification Training Level 1 and 2 is an Accredited TOGAF 9 Training Course and complies with the accreditation requirements for The Open Group TOGAF Certification for People program

TOGAF Certification and  Enterprise Architecture Consulting Services