Business Case – Why Enterprise Architecture Needs to Change – Part I

(Editor’s Note: What follows is Part 1. Part II appears tomorrow.)

By Greg Matthews

Many enterprises operate what is essentially a stone age-based IT lifecycle process.

“Stone age” means that it is stuck at the lowest level of maturity, with no means to improve over time. Symptoms include:

  • There are some modelling/design tools used, but designs are usually built from scratch without any reuse.
  • Designs are all different and don’t share a common structured design language.
  • Since there’s no structured design language, this is a blocker to apply any higher-order analysis or automation tools.
  • It’s difficult to find designs at the Enterprise or project/product level.
  • If you can find a design, it’s difficult to understand.
  • There is no concept of a reusable building block that can be discovered and digitally reused in future designs.

This low level of sophistication incurs a large ongoing cost and applies regardless of the predominant lifecycle methodology used, e.g conventional, SAFe, Agile, etc.

By comparison, other industries have managed to transition to a mostly digital approach and can serve as an example for Enterprise Architecture.

  • In software development, package managers like Maven or Node allow developers to discover, download and integrate software packages into their software projects. In addition, package managers provide the machinery to reuse software building blocks digitally.
  • In civil engineering, project designers can discover, download, and integrate 3D design components into their digital engineering designs.

The solution to moving out of the “stone age” is to use a digital end-to-end approach for Architecture content (whether EA or SA), and provide openness and transparency across EA, project, and reusable component Architectures.

Just like any digital approach to any business problem, the use of structured data is key.

The best-structured data language for Architecture is arguably the ArchiMate notation which has a rich notation covering the depth and breadth of Architecture modelling, and also a rich set of connectors to link elements.

ArchiMate isn’t perfect, but there are no other real contenders.

Also, this article isn’t suggesting that all Architecture diagrams need to be in ArchiMate.

That would probably be a bad outcome.

We still need “artists’ impression” diagrams and concept diagrams.

However, if you do wish to explore avoiding the ongoing costs (detailed below) then there seems no other choice than to adopt a digital end-to-end lifecycle that is reasonably dependent on ArchiMate.

There is also a cost to adopting ArchiMate. However, this shouldn’t be a barrier to begin adopting a digital approach.

Architects should arguably understand global Architecture modelling standards, and to that end, we’ve provided a few resources that will evolve over time.

A more detailed breakdown of the costs (and how to avoid it) of being in the “stone age” follows.

New staff inefficiency cost

When new staff are hired, they typically know very little about the Enterprise IT platform or business processes.

Even if the new hire has significant experience in the given industry, the new organisation’s IT platform and processes will likely vary greatly from the person’s past experience.

It takes several months or longer for new staff to accumulate enough knowledge about how the business and IT platform work to operate effectively without help from other staff and operate effectively.

The cost of this knowledge gap is the new person delivering outcomes slower than other staff and consuming time of other staff unnecessarily by simply asking questions like ‘what systems do we have?’, ‘what does the business do?’, ‘how does system X work?’ and so on.

It would be better if new team members could surf through Architecture models to learn how the business and IT platform work and query this as required when a design decision is needed.

Typical questions that a new person might want to ask include:

  • How does the business work? (value chain, capabilities, processes)
  • Who are the stakeholders, and what are their goals and drivers?
  • What information is used by the business, and what value/outcomes are achieved by different information flows?
  • What application platforms do we have, what do they do, and how is data created, consumed, and exchanged?
  • What are the main reusable components that most solutions are expected to reuse?
  • What projects are planned and in flight, and how do they change the IT platform?
  • What are the partner and supplier ecosystems, and what information do we exchange with them?
  • And so on.

How to implement:

  • Make sure that all Architecture content is loaded into AIM either as a Project or Component, so that new team members can independently discover and understand Architecture content

Lack of reuse cost

When a new project is started, the Architect usually begins their design from scratch.

It is wasteful to create the design from scratch each time rather than reuse Architecture building blocks.

Designs created from scratch will also typically be less mature and accurate than reusing a design that may have been reviewed and verified as accurate and secure over time.

It would be better if Architects only had to create the unique design elements for a project.

Initial project concept designs typically still need to be created from scratch until there is some consensus around scope and approach but then as this becomes clearer the technical design should heavily leverage reusable component design elements. 

Initial project concept designs should also leverage organisational models which include coverage of value chains, capabilities, org charts, and so on.

This saves design time and assurance time as it is clearer which parts of the solution have already been reviewed by CyberSecurity, Infrastructure, EA, and so on.

How to implement:

  • The Architecture and business community should curate reusable Architecture building blocks in AIM covering the full range of Architecture aspects (EA, SA, Tech, Security, etc.). Projects to select and reuse building blocks in designs

Modelling quality and consistency cost

Usually, every Architect has their modelling style.

This modelling diversity is healthy and encouraged.

However, there should be some common core modelling conventions so that it’s easier for Architects and other stakeholders to understand and provide feedback on designs.

For example, do Architects consistently model applications, integration, security, business processes, stakeholder goals and drivers, and so on?

If there is a very low level of design consistency, then it takes more effort for people to review a design.

This likely means that stakeholder expertise cannot be effectively applied to improve a design.

It would be better if a common core of design conventions simplified understanding and led to a higher degree of quality stakeholder review.

Ideally, Architecture designs could be automatically checked for consistency, so that your organisation can move towards modelling conventions that you decide are appropriate and easily understood.

How to implement: Use AIM model validation rules, machine learning, and train your Architects 

  • Use AIM’s rules engine to specify common modelling rules.
  • Use AIM’s machine learning and tell AIM which of your models are “good” models. AIM can then learn how you prefer to model and provide recommendations on other models so that they align with your conventions.
  • Train your Architects in basic modelling conventions, and then develop your Enterprise conventions. Some initial guidance is here: ArchiMate Design Concepts

Project misalignment and duplication risk

In large Enterprises, it can be common to plan and execute 100+ projects each year.

It’s challenging to get this right without duplicated initiatives, initiatives with a poorly defined scope, or initiatives that don’t align with the operating model.

The reason it’s difficult is a lack of access to Architecture models needed to support planning and high-level design.

  • Enterprise models that describe how the business is composed, e.g. value chain, capabilities, processes, and operating model.
  • IT models that define the current state IT platform

This might even be a factor in why many Enterprises only perform annual capital project planning because it’s too complex to do this any more frequently than once per year.

It’d be better if there were an Architecture repository to support more fluid IT investment planning and high-level design.

Such a repository would need to cover project architecture and current state architecture, and contain:

  • Models explaining how the business worked, e.g. value chain, capabilities, processes, and operating model.
  • Models explaining what projects were planned and in-flight, including a mapping of projects to Enterprise.
  • Models explaining the current state of IT platforms, applications functions/integration, and business processes so that we could ensure that projects are correctly shaped.

How to implement:

  • Ensure that you load all relevant Architecture models into AIM, incl. EA and Project Models.
  • Fund teams instead of projects.
  • Monitor project delivery capability and then use AIM to keep the investment pipeline sufficiently full.

Part II appears Tuesday. 

Greg Matthews created the Architecture in Motion (AIM) platform as a result of 16 years in Enterprise Architecture and Solution Architecture in large Enterprises across different industries, and a previous background as a software developer. 

AIM is an open and transparent platform to manage project architectures and reusable component architectures using the ArchiMate modelling notation. It contains a rules engine and machine learning to drive towards model consistency and allows stories to be overlaid atop architecture diagrams so that people can discover and understand architecture content more easily. This is a new and innovative approach to architecture and you can trial AIM for free at You can also find out more about AIM at

1 Trackback / Pingback

  1. Business Case – Why Enterprise Architecture Needs to Change – Part I - Slowhorse Ltd

Comments are closed.