Other enterprise architecture challenges


Copyright Graham Berrisford. One of several hundred papers at http://avancier.website. Last updated 22/06/2020 13:11


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

To read the first, click here enterprise and solution architecture: things to know.

Read on for some challenges people face.


Populating your Strategy and Architecture team.. 1

Governance of solution architects by enterprise architects. 1

A few notes on architecture methodology. 1

Conclusions. 1


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 challenges

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.


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

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

They may sanction point solutions and/or duplication of data storage, contrary to a holistic enterprise architecture, enterprise.

Architecture methodology challenges

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..

The enterprise as a system

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

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

It is important to distinguish:

·       a social entity or network in which people communicate

·       an activity system in which people play role and follow rules.


An enterprise is a social entity that employs many distinct socio-technical activity systems.

Those systems may overlap, duplicate or even conflict with each other.

Enterprise architects strive to standardise and integrate systems, but complete integration is impossible.

The more systems are commoditised or industrialised - the more enterprise architect oversight is needed.

Customised and bespoke systems may benefit initially from an agile development approach.

Architecture processes

EA frameworks like TOGAF are abstract management frameworks for design thinking.

TOGAF can help you organise work to change business systems; it does not teach you how to do the work.

Achitects need more concrete training in architectural design principles and patterns.

Architecture documentation

How far to populate an EA repository with documentation?

Enterprise architects are interested in portfolio-level documentation

Solution architects are interested in system/solution-specific documentation

A few ideas:

·       At any level of system decomposition, a context diagram showing inputs and outputs, or an interface definition.

·       At a high level: business processes/value streams/scenarios.

·       At a high level: business function/capability hierarchies and application catalogues.

·       At a middle level: use cases/epics, sagas, kernel entities, components, microservices.

·       At low level: user stories, atomic transactions, data entities and objects/classes.


Any of these may usefully be documented to assist the design process.

How much documentation need be retained? I don’t know. It depends.

And I haven’t mentioned the deployment to infrastructure.

Terminology torture

Unfortunately, the many standards architects refer to (like TOGAF, ArchiMate, BizBOK and UML) are terminology torture on their own - let alone in combination.

Because authors use ordinary words (like service, process, function, capability, actor, interface and process) with a variety of meanings.


Meaning in standards from The Open Group


Meaning in Fowler’s writings for programmers

A structural building block that offers multiple services 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.

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 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 “overegg” what EA can achieve.


EA is political: there are always trade offs and compromises to be made; and

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


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, where are some articles 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 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..

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.