Is Enterprise Architecture a data problem?

My previous article explored the definition of what is Enterprise Architecture (EA)?? Across all the various definitions that could surface of what an Enterprise Architect is or does, there would be some synergies and similarities between those definitions.? One of those similarities, that I believe is fundamental to any good EA practice, is the ability to draw conclusions from the information created during the delivery of architecture.? In this article I want to share with you a particular viewpoint around the concept of data that should be considered as you mature your EA capabilities.? Data plays a huge role in the support of insights that help to make fundamental decisions, accurately and efficiently!

Sometimes when trying to answer that key question of “What is Enterprise Architecture?”, I try and simplify the topic of architecture modelling.? The response I often receive is "oh so you draw pictures?".? Architecture models are a key component of architecture delivery.? I like to drive the distinction and comparison, that no we are architects not artists, we create models not pictures.? Like that of an architect within the construction industry, his schematics are more than just a pretty picture.?

Artists think about colour, light, shadow, texture, tone, proportion etc.? Architects think about requirements, cost, flow, location, compliance, integrity and integration to name but a few.? Those lists of considerations are very different and therefore the results are very different.? The comparison of a construction architect to an enterprise architect was first prominently made by John Zachman in the 1980s and has been repeated numerous times since, however very few understand the reasons why.

He expressed these views to address the complexity of managing large scale information systems.? He observed that just as construction projects required detailed planning and a structured approach, so too do enterprises.

The TOGAF architecture framework furthers this mindset and does a good job of recommending the creation of an Enterprise Metamodel.? However, the skill as always is in the implementation of the metamodel, the processes that support it and the insights from the data inside of it.? Within time I will produce several further articles that demonstrate how we can use the data within the enterprise metamodel to answer specific business questions and help transform the way many organisations operate (with a lack of visibility across the holistic Enterprise Architecture), but first let's explore how we build one.

Architecture modelling (drawing pictures) is a foundational skillset in the world of Enterprise Architecture and a mechanism to produce an enterprise metamodel.? There are a wide number of EA tools on the market that help provide the ability to produce these metamodels taking their inspiration from either TOGAF or ArchiMate.? The tools provide the ability to visualise and manage complex structures of an organisation using a series of components and relationships connecting these components together.? In their simplest form they can help to ensure alignment from the organisational strategy through to the physical execution and implementation.

Finding a natural starting point when starting to build the metamodel can be difficult as it should be driven by the problem that you are trying to solve.? However, there are some core components that should be part of the foundations to help solve a wide range of common problems.? Below is an example of the TOGAF Enterprise Metamodel with a few custom relationships and simplification around the Data Entity and Application components for illustrative purposes.

People (Actors) - these are integral to the metamodel as they help drive ownership and responsibility to the other components that exist within the metamodel.? Without ownership things generally fall flat and things fail.? People data is generally widely available within most organisations.? Common sources are identity and access management solutions (e.g. Entra ID on Azure) or HR platforms that are used to master people data.

Organisation Unit – People naturally don’t float around your organisation but exist within teams, groups or organisation units to be more specific which refers to a self-contained unit of resources.? This information naturally would be sourced from any existing HR platforms.?

Applications – Another source of generally available information is applications, these will either exist in spreadsheets or a CMDB, neither are generally kept up to date very well however act as a good starting point.? As you model Applications or take them into your EA repository, it creates a great opportunity to decommission those spreadsheets and enrich the application data set with additional attributes linked to applications (e.g. lifecycle, RPO, RTO, criticality, business and technical fit, etc).

Data – Data in this context refers to business data.? Most organisations have realised the importance of data and have teams responsible for helping to curate and organise data making it available to a wide range of stakeholders through core data management and analytical platforms (e.g. data mesh or fabric)

Business Capabilities – Lastly business capabilities the linchpin to the metamodel that brings some of these components above together and is a representation of what your organisation does to achieve a specific purpose or outcome, supported by applications and data, that are delivered by an organisation unit and people.

These components are a good starting point to help drive further conversations and to further enhance the metamodel as new challenges arise.

I like to think of architecture modelling a bit like a jigsaw puzzle, with the components being the pieces and the relationships being how they fit together.? Everyone knows you start with the pieces around the edge first and as you make your way to the middle of the picture, it becomes clearer and more complete.? The same is true with architecture, in some instances having the bits around the edge modelled accurately, enables you to draw a possible conclusion.? However, you might be missing a key piece of the puzzle that would help you to either answer it more accurately or at speed.?? Once all the pieces fit together you can clearly see what you are looking at.?

In this analogy the EA tool is the box containing all these pieces but in a more organised and methodical structure.? Could this be done in everyone's favourite tool … Excel?? Well not really, modern tools typically use graph databases as a powerful tool to traverse the relationships between the data components and explore synergies between data points using sophisticated visualisations.? Very quickly Excel becomes difficult to use when joining those different components together from the Enterprise metamodel.

This isn't to say as architects you must model every single piece of your organisation.? However, as your organisation evolves and you create processes and drive adoption of the Enterprise metamodel, the questions become far easier to assess.? This is where the value of an Enterprise Architect lives, in the quality and maturity of the data, to inform decisions and answer complex business questions.? The other responsibilities of designing, planning, implementation and governance are table stakes and impossible to do without the former.

Therefore, is Enterprise Architecture merely a data problem?? I hear my data friends shouting at the screen "everything is a data problem". Clearly this is an oversimplification of the role we play as an EA; however, data does play a huge role.

The opinions expressed here belong solely to myself, and do not reflect the views of my current or previous employers