Business Case – Why Enterprise Architecture needs to change

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.

Subject matter expert (SME) over-utilisation

Most Enterprises have application owners that oversee and approve any changes to their allotted application(s).

What happens is that those SMEs typically get invited to meetings to explain what the application does and how it is integrated into other systems.

This is not the best use of the SME’s time, and the SME would be better off spending time on their actual job rather than in meetings explaining how systems work.

Typically, the SME is a functional expert on their allotted application(s) but sometimes doesn’t have a deep understanding of its Architecture, so there can be a lot of unintended misinformation on the architecture that needs to be worked through and verified.

It’d be better if the application architecture were documented and available for people to review and understand.

Ideally, it would provide all of the necessary details around application functions, integration, and information management. There would also be story-based documentation that answered key questions about the application platform – since story-based content is typically easier to understand than the content presented in other forms.

How to implement:

  • Switch from an ‘application owners’ to ‘component owners’ approach (since an application owner approach generates silos).
  • Ensure that components (which might cover 1 or more applications) have their Architecture design loaded into AIM.
  • Ensure that designs cover application functions, data, integration, security, and link to business functions/processes, and the EA capability model.
  • Create ‘Stories’ in AIM, being overlays of Architecture models, to provide a level of documentation enabling people to self-discover and understand how components (1 or more collaborating applications) work.

Change management cost

In a large Enterprise, there can be a lot of changes to applications, technology, and business processes throughout the year.

It takes a fair amount of energy to curate release notes and for staff to review and absorb this information.

This constant change means that there is a half-life to whatever facts someone thinks they know about how an Enterprise works.

It’d be better if there were a way to share Architecture changes. This might be changes to EA reference models, projects, or reusable components.

A centralised place to review Architecture changes allows people to more easily absorb summary information but then dive deeper if required.

How to implement:

  • Create a Story in AIM for each significant element of change.
  • Use a common story tag to identify those stories which were created to communicate change, e.g. ‘EA Update’, ‘Project Update’, etc.
  • Inform your teams how to filter the AIM Stories page to see when change has occurred, and how to drill into Architecture content if they wish to explore further.

Misalignment to strategy cost

Most Enterprises have a Strategy function that charts the high-level direction of the Enterprise and set priorities for allocating resources.

It seems that staff commonly do not know where this strategy content can be found.

Sometimes, this is because it’s not even written down or published.

Then, well-meaning staff propose projects that optimise a department or aspect of the IT platform that isn’t explicitly aligned with strategy.

This can lead to the IT budget containing an unnecessarily high level of projects that do not align with strategic direction.

It’d be better if a strategy were published so that a higher proportion of project proposals were strategically aligned in the first instance.

How to implement:

  • Ensure that views supporting strategic analysis are published in AIM
  • Ensure that project proposals explain strategic alignment against strategy views before being funded. 

Lack of scope clarification and project cost blowouts

It can be quite common for a project to be initiated off the back of a vital driver or objective that has been identified.

This might be a completely valid driver, but not represent a holistic view of the problem space.

Then, the requirements are written.

The requirements can then sometimes not really be requirements but instead a quasi-solution architecture document that specifies the solution and does not capture the current state, target state, or the changes to information lifecycle management.

Then the project ramps up, and an Architect is assigned at some point.

During project delivery, a range of discoveries are made, and there is a variation to project shaping and goals. For example, discoveries about unknown integrations, dependencies, or functionality.

All of this tends to require a readjustment to project activities, and therefore either an increase to the project cost or a descoping of the project to fit into the allotted budget/schedule.

It’d be better if the project scope were more fully discovered upfront.

This relies on being able to perform discovery on the current state in an Architecture repository to understand applications, functions, integration, and dependencies generally.

The main question being answered here is whether the proposed set of high-level work packages (scope) for a project makes sense.

If the project proceeds with the set of proposed work packages, will the Architecture (business, IT) be left in a working state, or will there be further remediation required? 

How to implement:

  • Take a ‘do the Architecture first‘ approach.
  • Ensure that an Architect is one of the first people assigned to a project. i.e. do not just initially assign BAs to projects.
  • Develop a high-level architecture approach that is intended to provide very clear project scope definitions, based on current state Architecture information. It should provide evidence that the proposed project scope will not require any further remediation work to leave the IT platform in a working state.
  • Provide guidance around ensuring that “Business Requirements” documents do not morph into quasi Solution Architecture documents.

Ineffective governance cost

It can be quite common in large Enterprises that a project is launched, and then it disappears for some extended period to perform discovery and create designs.

The project is then told that it must pass through Architecture governance, so it prepares a slide deck that provides a project overview and explanation of the now locked-in target architecture.

The project then presents this deck at a governance meeting, and most of the time, because the project must meet a deadline, usually based on funding, there is little change that can be made. It’s too little, too late.

It’d be better if there was continuous access to project architectures as they evolved. This would allow for early feedback and meaningful project shaping.

Important feedback to projects can include guidance around:

  • The use of applications and integration
  • The lifecycle of information both within the Enterprise and with customers and partners.
  • Functions provided
  • Security
  • Use of standards
  • The general approach taken, i.e. tactical or strategic.

How to implement:

  • Require that projects publish their project architectures into AIM, as early as possible, and also update when any meaningful change has occurred.
  • Develop a collaborative approach whereby there is a continuous conversation across project stakeholders to ensure that appropriate project feedback is received, e.g. EA, Security, Applications, Infra, Procurement, Commercial, etc. can provide feedback as required through the project lifecycle.
  • Modify Governance/Assurance processes to be more of a lightweight activity since the high-value project shaping and technical feedback have already occurred out-of-band of Governance processes.

Lack of ability to manage technical debt cost

It can be quite common in large Enterprises that Governance sessions make a point of capturing technical debt.

This list of technical debt gets captured in detail and then never referred to again.

This is partially due to the lack of structure available against which to tag technical debt.

It’d be better if the technical debt could be captured in a way that enabled it to be considered in IT investment planning.

One way to do this is to capture the current state IT platform as a series of components (1 or more apps and/or technologies that together provide a building block), and then tag technical debt against the relevant component.

How to implement:

  • Define reusable Architecture building blocks as ‘Components’ in AIM. A ‘Component’ is 1 or more applications and/or technologies that work together as a building block. We apply object-oriented principles here, and seek to achieve high cohesion (do 1 thing well) and low coupling (minimal interdependencies with other components).
  • In each Component, define one story for each element of technical debt. Tag each story with a meta-tag, e.g. type = ‘Technical Debt’, so that you can find and review technical debt across your entire portfolio of reusable components.