Other enterprise architecture challenges


Copyright Graham Berrisford. One of several hundred papers at http://avancier.website. Last updated 05/04/2019 22:48


The paper is the second of two that positions mainstream enterprise architecture in relation to solution architecture.


Preface. 1

Populating your Strategy and Architecture team.. 2

Governance of solution architects by enterprise architects. 3

On architecture methodology. 3

References. 5



This paper follows an earlier paper on enterprise and solution architecture which covered:

·        Architect roles in SFIA

·        Architect roles in the TOGAF standard

·        Architect roles in advertised role definitions

·        Decades of solution architecture

·        Decades of point solution proliferation

·        Decades of EA as business system planning.


There is a reasonable understanding out there of why Solution Architects are needed. 

EA has always been challenging, both technically and politically..

·        Defining the monetary business case for any strategic or cross-organisational activity is difficult.

·        The variety of business contexts makes it impossible to prescribe, generically, where EA fits.

·        Some “big up” EA too far.


Decades ago, US OBM Memoranda 97-16 guidance on enterprise architecture said this:

the balance between centralization and decentralization and the pace of change within the agency, should be clearly understood.”


Regarding the pace of change, read our several papers on agile architecture:

1.      On the beginnings of agile

2.      On agile software development

3.      On agile businesses and systems

4.      On systems thinking ideas used in agile

5.      What is agile architecture?

6.      EA in the world of agile architecture


Read on for discussion of further challenges.

Populating your Strategy and Architecture team

The number of roles called “architect” varies widely between organisations.

Some enterprises have never set up an EA practice; some have done so and struggled to make an impact.

However, many do have a team called “strategy and architecture” or the like.

Every enterprise has to work out for itself how its roles cover the cells of the table below.







Infrastructure technology



Business roles & processes,

standardisation, integration

and road maps

Business data

standardisation, integration

and road maps

Business application portfolio

standardisation, integration

and road maps

Platform technology portfolio

standardisation, integration

and road maps



Outline design of a solution’s

required processes

Outline design of a solution’s

data architecture

Outline design of a solution’s

application(s) architecture

Outline design of a solution’s

IT production environment



Detailed design of

processes & use cases

Detailed design of

data stores and flows

Detailed design of

software architecture

Detailed design of

IT production environment


First, there must be a manager (CIO or other) who appreciates and wants to sponsor enterprise and/or solution architect roles.

That manager may create a Strategy and Architecture team – covering some or all of the table above.

How the activities in the table are mapped to roles and people depends on the manager, and the size and nature of the enterprise.

And by the way, it is normal to engage security specialists in each architecture domain.


Division of roles by scope

A large and diverse enterprise may be divided into “segments”, each with its own Strategy and Architecture team.

The segments likely correspond to distinct business functions/capabilities.

E.g. a bank might have retail banking, wealth management and investment segments.


Division of roles by level

A Strategy and Architecture team may divide its roles according the three rows of the table above.

So there is a hierarchy of enterprise, solution and software/technical specialist architects

Some insert a “segment” level between the enterprise and solution levels.

Where an enterprise is happy with silo solutions that duplicate and don’t integrate – the focus may be on solution architecture in the second row of the table.


Division of roles by domain

A Strategy and Architecture team may divide its roles according the columns of the table above.

“The enterprise architect" is rare, since it is difficult for one person to manage portfolios in all four domains.

A Strategy and Architecture team might employ an enterprise architect in charge of each architecture domain (the columns of the table).

By contrast, a solution architect is often expected span all domains, and join up the perspectives of specialists working in each domain on a project.

This makes broadly educated solution architects the lynch pin of an architecture function.

Governance of solution architects by enterprise architects

A solution architect’s vision usually has a relatively short time frame and narrow scope.

In the 1980s, the need to take more strategic and cross-organisational view of business processes and business data became clear.

The cost and quality issues caused by “silo systems” led many to call for higher-level “enterprise architecture”.

Enterprise architects take the broadest possible view, look to standardise, integrate and coordinate business systems across an enterprise.

They respond to the outputs of business planning, align system changes with them, and may influence them.


EA is challenging politically as well as technically.

The idea is to take a cross-organisational and strategic perspective of business systems and changes to them. 

Enterprise architects need not only appropriate knowledge, skills and resources, but also cross-organisational authority.

They act as a central design authority and risk management function.

They guide and govern lower level solution and technical architects working on specific programmes and projects.


The aims of EA include the rationalisation and optimisation of business systems, the de-duplication and integration of systems.

But enterprise architects can and do give waivers from enterprise-level standards and principles.

Although point solutions are contrary to a holistic enterprise architecture, enterprise architects may sanction them

Architects should assess trade offs and make a decisions as to whether to allow a point solutions or not.

Similarly, duplication of data storage by different applications is contrary to holistic enterprise architecture.

But architecture governance may allow some duplicate data to continue, or even to be created.

On architecture methodology

Architecture is high level design and planning of systems that must be designed, tested, integrated and replaced.

How to build a coherent architecture method that makes enterprise transformation quicker, cheaper, better or less risky?

One has to draw many ideas from many sources.

And then direct each method user to decide which ideas best suit their particular transformation challenge.

The enterprise as a system

Some use the terms system, component, process and service interchangeably.

Some use them with different (and sometimes contradictory) meanings.


In some standards from The Open Group

In Fowler’s writings for programmers

A structural building block that offers multiple services (a service portfolio) to its clients


A unit of software that is independently replaceable and upgradeable.

A behavior composed of process steps in a sequence that leads to a result.


An instance of a component executed on a computer.

A discretely requestable behaviour that encapsulates one or more processes.


An out-of-process component, typically reached by a web service request or RPC.


It is commonly said that “enterprise architecture views the enterprise as a system, or system of systems”.

But there are profound misunderstandings of what this means.

To call every problem, situation or business “a system” is unhelpful.

It is important to distinguish:

·        a social network in which people communicate

·        a social system in which people realise role and rules.


An enterprise is one social network that realises many social and technological systems.

Architects may find some systems overlap, duplicate or even conflict with each other.

Enterprise architects apply some change control to large-scale, generational, system change.

For more on these underpinning concepts, read papers 5 and 6 on this system theory page.

Management of system design

EA frameworks like TOGAF are not primarily design methods,

They are abstract management frameworks for design thinking.

TOGAF is intended to help people manage the time, cost and risk of work to change business systems.

It does not teach architects how to do architecture.

Solution architects need more concrete training in architectural design principles and patterns.

System integration design patterns

Architecture methods should include not only system definition, but also patterns for system integration.

Systems can be integrated by users, messaging or database consolidation, online or off line, and in ACID or BASE styles.

System lifecycles and technical debt

Architecture methods have to address the life cycle of a system, and when to replace old systems.

Many applications are badly made, they have poorly structured databases and/or give poor user experiences.

Many are over-engineered: too many layers, vacuous abstractions, facades on facades, needlessly rich domain models and needless use of middleware.

Even well-engineered application – after they have been amended in various ways – can become badly engineered.

But if an application works, and doesn’t cost much, it may not be a concern to enterprise architects.


Technical debt isn’t a measure a poor software design, and refactoring all poor design would be impossible.

Technical debt is a measure of the technical insurance premium worth paying to increase system longevity.

First you have to assess the size and likelihood of the risk.

·        How important is the application? Does it work well enough now?

·        How long will the application be needed? Will it work for the foreseeable future?

·        How likely will it have to be changed much, or re-platformed, in future? What will be the cost of doing that?

·        What is the cost of refactoring now to make the application easier, quicker and cheaper to change in the future?

·        Would it be better simply to replace the application by another?

System road maps

Architects produce road maps that set out how one or more baseline systems are replaced by one or more target systems..

A solution architect drew the following simple road map for replacing an old accounting system by a new one.

System element

Baseline  state

Transition state 1

Transition state 2

Target state


Old system

New system

New system

New system

Purchase to Pay (PtP)

Old system

Old system

New system

New system

Order to Cash (OtC)

Old system

Old system

Old system

New system

Temporary data flows

Old-to-new PtP & OtC

Old-to-new OtC


EA involves coordinating several road maps, strategic and tactical, that cut across each other.

The road map for replacement of the accounting system may have to be shaped in the light of other road maps for

·        replacing the CRM application used to capture orders

·        making all core business data accessible via interfaces conforming to the OData standard

·        reorganising the business from product-focused to customer-focused (or vice-versa).


There are always trade offs and compromises to be made; so EA is political.

Who has authority to make decisions depends on the enterprise’s management and governance structures and processes.


Read 50 years of digitisation and EA for a more extensive EA history, and ends with a link to a long list of references from 1970 onwards.

There is a common theme in the referenced sources – a focus on business roles and processes that create and use business data.

Read EA and TOGAF: how do they differ? for discussion of EA with reference to TOGAF.


All free-to-read materials at http://avancier.website are paid for out of income from Avancier’s training courses and methods licences.

If you find the web site helpful, please spread the word and link to avancier.website in whichever social media you use.