Enterprise and Solution Architecture (Mainstream EA)

One of about 300 papers at http://avancier.website. Copyright Graham Berrisford. Last updated 30/01/2017 12:34

And one of several papers on the home page about the terms and concepts used in architecture frameworks.


This paper is pre-course reading for Enterprise and Solution Architecture (ESA) certification courses in this Training Calendar.


Preface. 1

Solution architecture. 2

Mainstream enterprise architecture. 3

Definition of EA and SA roles in SFIA.. 4

Aims of EA and SA roles. 5

Road maps and politics. 5

Populating a Strategy and Architecture team.. 6

Some EA challenges. 8

Concluding remarks. 10

Footnotes: Things related to or confused with EA.. 10



Unlike a building architect, our kind of architect designs activity systems.

Business activity systems evolved by formalising the messages, memories and rules of social activity systems.

For ever and a day:

·         people performing activities in business roles and processes have depended on

·         business information systems (IS), which have used some kind of

·         information technology (IT), from clay tablets through pen and paper to computers.


Today’s “information age” started with the digitisation of business information.

Businesses discovered that digitising business systems, and changing them, required new disciplines.

The term “enterprise architecture” did not come of out of thinking about information technologies.

It was first used in connection with cross-organisational analysis of business processes and the data they use.

The history in “EA and the Digital Enterprise” includes a list of references from 1970 onwards.


Enterprise architecture (EA) optimises and extends business activities that create and use data.

Enterprise architects respond to business plans, align changes with them, and sometimes influence them.

They draw up high-level designs and plans for changes to the three architecture domains in the table below.


Business Planning

Business mission, vision, drivers, strategies and goals.

Mergers, acquisitions, divestments, internal organisation restructurings and rationalisations.

Enterprise Architecture 

(Business Systems Planning)



Business functions/capabilities, roles, processes/value streams and their interrelationships.

The services they provide to each and to entities in the business environment.

Information System


Applications and their interrelationships

The services applications provide to each other and to business activities.

Data stores and data flows, the data structures they contain and the qualities of that data.



Platform technologies and their interrelationships

The services technologies provide to each other and to business applications.


Enterprise architects take a cross-organisational and strategic perspective of the three architecture domains.

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


So don’t think of EA as being to computer resources what HR is to human resources.

Rather, think of EA as being about the optimisation and extension of human and computer activity systems.

The paper below positions mainstream EA in relation to solution architecture.

It is written to reflect the history of architecture frameworks and the reality of modern architect job descriptions.

Solution architecture

Since the Information Age started, businesses have looked to support and enable roles and processes that create and use digital business data.

Business managers have recognised problems, requirements and opportunities relating to such roles and processes.

·         1970s We can increase the speed and accuracy of our accounting systems.

·         1990s We can help sales and marketing by capturing and analysing information about customers’ interests.

·         2010s We can grow our market share by developing a new delivery channel facilitated by social media.


In the 1980s, various “business system planning” and “information system planning” methods were established, covering.

·         Organisation or business architecture - roles and processes shaped by the needs of the business to serve customers.

·         Information system architecture - shaped by the needs of business roles and processes to create and use business data.

·         Infrastructure technology architecture – shaped by needs of information systems to move, store and process business data.


By the 1990s, medium-to-large enterprises hired service providers to shape and steer solution delivery projects.

Solution architects were/are employed to capture visions, analyse problems and requirements and outline solutions.

They work to join up analysts, designers, builders and technical specialists.

They document solution outlines both for approval by clients and for use by specialists.

Solution outlines typically span business, information system and technology domains.


Information systems

Infrastructure technology



Business roles

and processes

Data structures in

data flows and stores

Use cases and business

apps that enable them

Platform technology

apps, nodes and networks


Solution architects sometimes work on strategic and cross-organisational projects; that does not turn them into enterprise architects.

See below for more on solution architect roles and aims.

Mainstream enterprise architecture

If solution architects shape and steer changes to business systems in response to particular problems, requirements and opportunities.

Then, what is or should be the role of an enterprise architect? There are widely different interpretations.

You may find network architects, software architects and business analysts who call themselves enterprise architect.

Some focus on the technologies that enable digital information systems; others focus on business strategy or organisation design.

The original aims and nature of enterprise architecture are obscured by such diverse uses of the term.


“The purpose of EA is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment.” TOGAF 9.1

Business processes are integrated through the exchange of information in messages and sharing of memories.

EA is about the why, when, where and how of business processes that create, store and use information.

It is about the design and planning of changes to those business activities, and/or to the capture and provision of that information.

A general aim of EA is to optimise, standardise and integrate business roles and processes (2006 reference).


In the 1980s, people recognised a problem with their existing approach to designing business systems that create and use business data.

Solutions architects acted independently of each other – under the influence of competing information technology vendors.

The result was an estate of non-standard, non-integrated, difficult-to-change systems.


The issues and diseconomies created by this mess of “silo solutions” became increasingly apparent.

·         Data locked into silo data stores, difficulties exchanging data between applications/business roles.

·         Business roles dependent on vendor-specific technologies - technology vendor dependence.

·         The cost and quality issues of maintaining the same data in different formats and places

·         The cost of resources and licences to maintain duplicate and overlapping business applications.

·         The cost of resources and licences to maintain duplicate and overlapping platform technologies.


Business managers (only indirectly aware of the technology mess) felt pains at the business level:

·         Weak business coordination: silo information systems make it harder to integrate business roles and processes.

·         Inflexible business systems: digitising and codifying can make it harder to change business roles and processes.


“Enterprise architecture” emerged as a response the pains – to help people stop the mess getting worse, and tidy it up.

The aim was to take a higher, portfolio level, view of “business system planning” and “information system planning”.

Zachman’s vision was to integrate business systems - their roles, processes and data – into one coordinated business system.

“The cost and the success of the business, depending increasingly on its information systems, require a disciplined approach to the management of those systems.” Zachman


Zachman's vision of the single, integrated, enterprise-wide business system may never be realised.

However that remains a target vision that helps to explain what EA teams aim for.

If there is no cross-organizational view of business processes and data, then there is no EA.

If there is no architect using that view to steer the portfolio of business systems, then there is no enterprise architect.


Today, mainstream enterprise architecture takes a holistic, systemic view of business roles and processes that create used business data.

Enterprise architects govern the portfolio of business systems, striving to optimise it by standardisation and integration.

Definition of EA and SA roles in SFIA

The Skills Framework for the Information Age (SFIA) is an international standard.

It defines roles for people involved in designing or changing business systems that use information and communication technologies.

This table shows how SFIA maps a small selection of its many roles to 7 levels of responsibility.


Responsibility level

Enterprise architecture








Solution architecture








Project management








Business analysis








Business modelling








Requirements definition and management








System design








Database design








Software development








Database admin









SFIA defines the roles as being concerned with changing business structures, processes, systems and infrastructure to a target state.

Enterprise architects are concerned with setting strategies, policies, standards and practices.

Solution architects guide the design and development of integrated solutions to meet current and future business needs.

Solution architects coordinate design activities, produce logical models of components and interfaces, and more detailed designs.


The “Architect roles and realities” page on the web site includes real and generalised role definitions for enterprise and solution architects.

Both kinds of architect are concerned with business systems that feature actors performing recognised roles in regular processes that create and use information.

Aims of EA and SA roles

Both enterprise and solution architects (along with business analysts and technical specialists) are concerned to:

·         start from the business and human context

·         design and plan changes to business systems under change control.

·         support and enable roles and processes that create and use business data.

·         improve the efficiency and effectiveness of business processes.

·         extend and improve the gathering of business data, its quality and exploitation.

·         make cost effective use of modern technologies to capture, store, transmit and exploit business data.


Enterprise architects are concerned also to:

·         take a cross-organisational portfolio-level perspective of business systems, roles and processes

·         optimise business systems landscape by reducing duplication and increasing integration

·         shape the portfolio of applications that capture business data and make it available for use.

·         define the target IT landscape (whatever that means locally) in the light of requirements and constraints

·         maintain enterprise-wide documentation to assist in the above

·         support, guide and govern solution architects in addressing specific business problems, requirements and opportunities

·         define cross-organisational standards, principles and “road maps”.

·         look to where systems can take advantage of innovations in business practices or technologies.

·         contribute to business strategies.


Both roles require communication skills, leadership, and holistic understanding of business & technology.

Road maps and politics

A road map is a document that sets out a baseline-to-target migration path.

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.

Populating a Strategy and Architecture team

You are unlikely to find an enterprise in which every cell of the table below below maps to one role or person.

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











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 an EA or 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.


A large and diverse enterprise may be divided into functions/capabilities/segments, each with its own Strategy and Architecture team.

A large Strategy and Architecture team may divide roles according the rows of the table.

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

Some (large banks for example) insert a row called “segment architect” between the enterprise and solution levels.


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

Elsewhere, the enterprise needs people to address also the aims and activities in top row of the table.

However, “the enterprise architect" is not far from a myth; since there is rarely one and only one person architecting business systems.

A Strategy and Architecture team might employ an enterprise architect in charge of each architecture domain.


By contrast, solution architects are often expected span all domains, and join up the perspectives of specialists in each domain.

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


In a small to medium company, the CIO may double as the enterprise architect.

The CIO may ask solution architects to work with an EA mindset (“guerrilla EA”).

And expect software architects or business analysts to act as solution architects.


The organisation in the table below has no enterprise architect, and only one solution architect.

A university


c50 people in business system change


c100 people in IT services management


Campus data centres


Solution architect (TDA with EA mind set)


Groupware / mailing list


Schools (fiefdoms)


Supplier relationship managers (licences)


Desk top apps, OS and printers


Buildings (25m)


Data integration specialists


Senior management




Application development team


Clerical administration




PMO (programme/project managers, back office)


Data centre / hardware / operations



User engagement and requirements specialists


Service desk


IS/IT projects per year


File store / directory / identity management


Business applications


OS / databases / networks





Hardware – desk tops, projectors etc.



There being no EA function, the solution architect sent two others, not called “architect”, to attend our architect training.

An education in enterprise and solution architecture can be relevant and useful to people with no EA function. 


EA work can be difficult and political; there are limits to its scope and what it can achieve.

Not every business has an EA team dedicated to EA (as the organisation structure above shows).

There is often some kind “Strategy and Architecture” team that supplies solution architects to projects.

These solution architects work can be encouraged to work with an EA mind set, and step up when needed to do EA level work.

This is called “guerrilla EA” here.

Some EA challenges

Mainstream EA is about cross-organisational planning and governance of business systems that use information.

EA-minded architects look for opportunities to digitise roles and processes, or capture new and useful data.

Naturally, much of what people do in a business is ad hoc, irregular, intuitive or unrepeatable

It is impossible to digitise roles and processes that are changed by actors on the fly, or use unknowable heuristics.

That is OK; some things are best left to human judgement and informal processes.


US OBM Memoranda 97-16 says this:

The documentation of the Enterprise Architecture should include a discussion of principles and goals.

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

Different businesses have different balances between centralization and decentralization, and different paces of change


Centralization and decentralization

EA-minded architects look for opportunities to standardise and integrate business systems.

What if nobody sees a need for any of many current “silo systems” to interact?

Suppose the only business-wide view required is financial summary information collected from disparate business units?

Such a highly diversified business presents a challenge to the notion that “the enterprise is a system”.


Still, a Strategy and Architecture team has a role to play in governance of solution architects working on discrete business systems.

Aims include: mitigate risks, standardise, integrate and optimize systems to the benefit to the enterprise as a whole.

The team can maintain EA-level standards, principles, reference models , best practices and road maps.

It can govern solution architects with reference to that collateral.

It can give waiver for an innovative and/or agile project to proceed outside of normal governance.


Pace of change: EA and Agile

Strategic level planning can give rise to transformation projects that last years and cost millions.

(An architect in a global business told me in Dec 2016 of a recent project that cost $200 million.)

EA-minded architects should playing leading role in major transformations or digitisations of enterprise business systems, roles and processes.

EA methods like TOGAF are designed to ensure there are agreed objectives, models of baseline and target systems, and governance of system delivery.

There is a down side - the necessary bureaucracy – including impact analysis of change requests against documented system descriptions.


The need to change business systems quickly is a challenge to any strategic planning or change management process.

“In the 1980s we would assume a transformation/convergence agenda across the enterprise would take a few years and $100 millions.

Today such projects are rare… we [engineer] systems even down to three month windows.
What I don’t see in [mainstream EA references] is how to make good choices in an evolving global-competitive information-based, revenue-earning business.” Alan Lloyd in discussion.


Not all are “global-competitive, information-based, revenue-earning businesses”.

And even in those businesses, not all systems are needed at three months notice.

But an EA function does have to address the pace of change.


Enterprise architects use portfolio management techniques to prioritise system developments and guide them.

They cannot maintain detailed documentation of business systems that change frequently.

But they should maintain just enough documentation to govern their portfolio effectively.

Enough to be able to trade off the benefits of contrasting approaches.


EA (as in TOGAF) is a management framework for changing business systems to a target that may well be a year or more away.

Agile (as in SCRUM) is a framework for continual improvement of software systems.

It usually implies changing and re-testing software systems on a daily basis, often with releases every couple of weeks.

The two are different, but not incompatible.


Agile development methods can give faster delivery.

And architects may encourage agile software development within the confines of a higher-level architecture.

However, taken to the extremes, EA bureaucracy and agile development both lead to difficulties.

Architects have to understand the extremes and strike a balance between them.


Not all systems and projects suit agile development.

Systems that require a large/complex database structure and/or data migration usually take a long time.

Some projects that process money or legislation cannot be partially implemented – they must be right first time.

Architects need a score chart to define the suitability of a system and project for agile development.

And might well recommend setting aside extra time and money for projects that are not suitable.


Some encourage division of an application into separately deliverable “microservices”.

This means more than connecting components using asynchronous messaging.

Read this Microservices paper for more.

In short, architects should divide a coherent data structure with care, and consider the downside of doing so.

Concluding remarks

The history in “EA and the Digital Enterprise” includes a list of references from 1970 onwards.

There is a common theme – a focus on business processes and data.

EA is about making substantial changes to business processes and/or business data.


EAs work to support business planning..

They optimise and extend business roles and processes that create and use business data.

They attend to the digital technologies required for that.

They govern more detailed solution architecture/design work.


EAs are not sociologists: they are not socio-cultural systems thinkers who promote a "participatory democracy".

They are not general-purpose business management consultants, advising, say, on how to make a matrix management system work.

They are not technology engineers: they don’t design a new car, new car production line or new database management system.


EA can touch any process that can be optimised or extended by creating and use business data.

That doesn’t make EAs responsible for every business process.

They may optimise how the road gang leader gets job instructions and delivers job a completion report.

But they are not out there studying how gang leaders motivate their gangs.

They do not direct road gangs in how to better dig holes in roads

That is the role of operational researchers or specialist business consultants.


EA applies a general system theory principle called "primacy of behavior".

It focuses on changes to value streams/scenarios/processes and roles in them.

It builds and maintains one more logical capability/functional decomposition structures, to which much else can be mapped.

It is not only cross-organisational but organisation neutral.

It analyses the organisation's management structure, and maps functions/capabilities to nodes in it.

But it does not assume responsibility for the design of the management structure.

Footnotes: Things related to or confused with EA


TOGAF was designed with reference to "information-intensive” businesses such as government, banking, finance and retail.

It is a management framework, designed to clarify and cement the roles of business, IS and IT architects in changing business systems

1990s TOGAF was born to help people tidy up a messy IT platform, using a Technical Reference Model.

2000s TOGAF joined mainstream EA by adding phases to define target business processes and data.

2010s TOGAF became more a solution architecture project management method with side bar references to EA.


TOGAF still reads in some places as though it is written with a multi-year time scale in mind.

“Preparation for business transformation needs or for radical infrastructure changes initiates an EA review or development.”

"First, develop Target Architecture Descriptions for the overall (largescale) system, demonstrating a response to stakeholder objectives and concerns for a relatively distant timeframe (for example, a six-year period)."

But many scale it down and tailor the ADM for use as a management framework for a smallish/shortish solution delivery project.

That is OK, but calling it “EA” obscures the meaning of the term as defined above.

EA and Six Sigma or Lean?

Mainstream EA is about the optimisation and extension of business roles and processes that create and use business data - and the technologies required.

It was designed with reference to "information-intensive” businesses such as government, banking, finance and retail.

Their business transactions continually consume, process and produce business data.

They rely heavily on technologies that “manufacture” the information needed by customers, suppliers and employees.


Six Sigma and Lean were designed with reference to processes in physical product manufacturing.

Six Sigma features two approaches to a project.

·         DMAIC (Define, Measure, Analyze, Improve and Control) used to improve existing processes.

·         DMEDI (Define, Measure, Explore, Develop, Integrate and Validate) used to develop new products and processes.


Six Sigma emphasises data capture and employs concepts like:

·         Voice of Customer, Critical to Quality Requirements, Measurement System Analysis, root cause analysis methods.

·         Hypothesis Testing, ANOVA, Design of Experiments, Risk and Change management tools, Control Charts.


Lean is a set of principles derived from work on the Toyota Production System.

It is primarily concerned with the elimination of waste, which is classified into eight types:

·         Inventory, Unused Creativity, Waiting, Excess Motion

·         Transportation, Overprocessing, Defects, Overproduction.


One strand of EA is to apply Lean principles to information-intensive roles, processes, data, and enabling technologies.

Further, Lean and Six Sigma can be useful in examination of whatever business scenarios/processes are relevant to the "request for architecture work".

Socio-cultural EA?

Mainstream EA is what it has been since Walker (reputedly) coined the term in the 1960s and Zachman followed his lead.

It is about the optimisation and extension of business roles and processes that create and use business data - and the technologies required.

There is a trend to use it as a label for all manner of business management consulting and socio-cultural systems thinking.

This leads to inconsistency, and then to disintegration into the babble and nonsense one finds in systems thinking discussion.

Instead of becoming a respectable profession, the term EA becomes meaningless and useless.

Read the “Socio-cultural EA” paper for discussion of a "novel taxonomy” that radically deconstructed EA.