Enterprise and Solution Architecture: How do they differ?

One of about 300 papers at http://avancier.website. Copyright Graham Berrisford. Last updated 09/09/2017 17:18

 

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

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

It is sometimes suggested as pre-course reading for Enterprise and Solution Architecture (ESA) certification courses in this Training Calendar.

 

When posted in an international TOGAF discussion group, this paper prompted 93 likes and these 5 comments

(RK “All in one article...” VE “Thanks for sharing.” SW “This is good reading. Thank you for sharing.” TRB “Good read.” SG “Very much insightful. Thanks a ton.”)

Contents

Introducing enterprise and solution architect roles. 1

50 years of solution architecture. 3

50 years of enterprise architecture. 4

Populating your Strategy and Architecture team.. 5

Road maps and politics. 7

Challenges facing mainstream enterprise architecture today. 8

The balance between centralisation and decentralization?. 8

Agility in response to the pace of change?. 8

Is the EA vision achievable?. 10

Concluding remarks. 11

 

Introducing enterprise and solution architect roles

The “solution architect” is a reasonably common animal.

The “enterprise architect” is a rarer beast, since the duties of the role are often distributed.

This paper distinguishes the roles; noting that these roles overlap and may in some cases be played by either by one person or by several.

 

SFIA roles

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.

Role

Responsibility level

Enterprise architecture

 

 

 

 

5

6

7

Solution architecture

 

 

 

 

5

6

 

Project management

 

 

 

4

5

6

7

Business analysis

 

 

3

4

5

6

 

Business modelling

 

2

3

4

5

6

 

Requirements definition and management

 

2

3

4

5

6

 

System design

 

2

3

4

5

6

 

Database design

 

2

3

4

5

6

 

Software development

 

2

3

4

5

 

 

Database admin

 

2

3

4

5

 

 

 

The table shows that SFIA positions EA and SA as senior, leading roles.

Briefly, SFIA role definitions indicate that both roles are concerned with changing business processes, systems and infrastructure to a target state.

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

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

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

 

Advertised roles

Research into real architect roles (see “more detail” below) shows a wide variety of role definitions.

It is clear that soft skills are important, both EA and SA roles require communication and leadership skills.

In addition, they are expected to have a holistic understanding of a business and the technologies it uses.

 

Advertised role definitions suggest both roles are concerned to:

·         start from the business context and human activities

·         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 have some more strategic aims:

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

·         optimise the business systems landscape by reducing duplication and increasing integration

·         shape the application and platform technology landscape in the light of business requirements and constraints

·         maintain enterprise-wide documentation to assist in the above, including cross-organisational standards, principles and “road maps”.

·         contribute to business strategy with advice on where innovations in business system and technologies can help

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

 

For more detailed research into real architect role definitions, look down the middle column of this “Enterprise architecture roles and realities” page
Below the introductory slide show, you'll see papers on architect roles by level and by domain, and a slide show on the EA manager role.

This paper goes on to say more about the emergence of solution architect and enterprise architect roles, and challenges facing EA today.

 

TOGAF’s three-level architect roles

Read this paper for discussion TOGAF, including its levelling of architect roles and the architecture landscape.

TOGAF (being used in large organisations) inserts a segment level between EA and SA; below is a summary interpretation.

 

Enterprise architects work at the cross-organisational and strategic level:

·         are concerned to optimise, standardise and integrate business systems,

·         maintain a summary description of the enterprise and its system,

·         maintain standards, principles, reference models and patterns,

·         develop roadmaps for change at a strategic, executive-level,

·         govern architects working at lower levels.

 

Segment architects work for a division or domain of an organization:

·         act as enterprise architects for the portfolio of solutions/systems in their business area,

·         maintain a description of their division or domain and its systems,

·         develop roadmaps for change at a portfolio or program or level,

·         govern architects working at lower levels.

 

Solution architects shape a solution and join up the technical specialists who work on it:

·         address the problems and requirements of a particular business operation,

·         work to deliver a new or changed system using particular information technologies,

·         guide projects managers as to the time, cost and risks of project-level work,

·         maintain descriptions at the solution outline or high-level design level,

·         develop roadmaps for change at a project or release level,

·         govern project workers (designers, technical specialists, developers, builders and configurers).

50 years of solution architecture

Business systems evolved over millennia by formalising the roles and rules, messages and memories, of social systems.

Every business depends on sending and receiving messages, and remembering what has been done to date.

Business roles and processes have always required technologies for information storage and communication.

Since the modern Information Age dawned, those technologies have increasingly been “digital”.

And business managers have recognised opportunities to “digitise” more and more human activities.

·         1960s 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.

 

Many “business system planning” and “systems analysis and design” methods were developed in the 1970s and 80s.

Typically, they progressed from business analysis, through requirements for information systems, to the platform technologies they need.

This table indicates how the PRISM report (1986) divided architecture into four domains/layers (or three if you combine the middle two).

Architecture domain/layer

Essential elements

Shaped by the needs of

Business organisation

Business roles and processes

the business to serve customers.

Data/information

Data structures in data stores and flows

business roles to remember and communicate facts and directions

Applications

Use cases and business apps that enable them

business roles to capture, report, move, store and process data

Infrastructure/platform technology

Platform technology apps, nodes and networks

business applications to perform generic computing tasks

 

The UK government’s systems analysis and design method (SSADM) reflected the presumptions of methodologists in the 1980s.

·         Business before technology

·         Logical design before physical design

·         External view (system inputs and outputs) before internal view (system structures and behaviors).

 

SSADM progressed from business options through logical information system modelling to physical technology options and implementation.

In practice, people complained that SSADM was too idealistic, it left physical and technology considerations too late.

Before committing to project work, stakeholders wanted to see a top-to-bottom view of all four architecture domains/layers in the table above.

 

The solution architect role emerged to capture this top-to-bottom view of a system in some kind of “outline solution” document.

A solution outline is documented for two purposes - for approval by stakeholders – and for use by those working in detailed design and development.

First, solution architects respond to particular problems, requirements and opportunities by shaping proposals for changes to business systems.

They can and should play an active role in the following project(s), to steer and join up analysts, designers, builders and technical specialists.

So what is or should be the role of an enterprise architect?

50 years of enterprise architecture

Many have appropriated "enterprise architecture" to mean whatever they want it to mean.

EA emerged in the 1980s out of business system planning rather than business planning, to which it has always been subordinate.

The purpose of mainstream EA has always been to optimise and improve core business processes.

“An EA establishes the Agency-wide roadmap to achieve an Agency’s mission through optimal performance of its core business processes within an efficient IT environment.” (FEAF, 1999 reference).

“Companies excel because they've [decided] which processes they must execute well, and have implemented the IT systems to digitise those processes." (Ross, Weill and Robertson, 2006 reference).

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, 2009 reference)

 

The Information Age brought new opportunities, but also new difficulties.

It turned out that designing, building, testing and rolling out a digital business system is exacting work.

And changing those systems can be just as difficult.

People worked to support/enable, speed/scale up, optimise/extend particular business systems.

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

Thus, the enterprise acquired an estate of systems that were not standardised, not integrated and did not share common services.

Some systems stored different version of the same data, some did not interoperate, and many were tied to particular technologies.

This led to problems in coordinating the business roles and processes that relied on these information systems.

For example, sales and billing systems, or social and health care systems, might be inconsistent and uncoordinated.

 

So how does EA differ from solution architecture?

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

The need to take more strategic and cross-organisational view of business processes and business data became clear.

The origins of EA can be traced back to IBM’s Business System Planning method, which Duane Walker reputedly started c1970.

By the 1980s, 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.

 

Business Planning

Business mission, vision, drivers, strategies, goals and top-level business plans.

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

Enterprise Architecture 

(Business Systems Planning)

Business

Architecture

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

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

Information System

Architecture

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.

Technology

Architecture

Platform technologies and their interrelationships

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

 

EA is challenging politically as well as technically.

The idea is to take a cross-organisational and strategic perspective of the architecture domains in the table above. 

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

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

 

Some enterprise architects work in a team called “strategy and architecture” or the like.

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.

Populating your Strategy and Architecture team

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

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

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

 

Domain

Level

Business

Data/Information

Applications

Infrastructure technology

Enterprise

architecture

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

Solution

architecture

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

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.

 

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.

 

Working without dedicated enterprise architects

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

The CIO may ask solution architects to work with an enterprise architect mindset.

Solution architects may be socialised into a group that cooperates by aligning solutions in the direction of a shared EA vision.

This “guerrilla EA” does what it can, when and where it can, to move the enterprise towards the EA vision.

 

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

2

Solution architect (TDA with EA mind set)

1

Groupware / mailing list

4

Schools (fiefdoms)

30

Supplier relationship managers (licences)

3

Desk top apps, OS and printers

5

Buildings (25m)

300

Data integration specialists

5

Senior management

5

Staff

7,000

Application development team

9

Clerical administration

8

Students

30,000

PMO (programme/project managers, back office)

15

Data centre / hardware / operations

9

 

User engagement and requirements specialists

20

Service desk

9

IS/IT projects per year

150

File store / directory / identity management

10

Business applications

450

OS / databases / networks

25

 

 

 

Hardware – desk tops, projectors etc.

15

 

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.

 

Guerilla EA

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

Still, 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 enterprise architect mind set, and step up when needed to do EA level work.

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

Reporting

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.

Challenges facing mainstream enterprise architecture today

EA has always been challenging, both technically and politically.

Decades ago, US OBM Memoranda 97-16 guidance on enterprise architecture said 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.”

The balance between centralisation and decentralization?

Different businesses and business functions/capabilities have different balances between centralization and decentralization.

What if nobody sees a need for 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 EA team maintains standards, principles, reference models , best practices and road maps for solutions.

It ought to 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.

Agility in response to the pace of change?

Different businesses and business system have different paces of change.

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

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

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

Some new systems are needed at three months notice; some changes are needed faster.

 

There is widespread recognition that initially-stated requirements will change (they are often unclear, inaccurate, incomplete).

Agile usually means early implementation of a partial system, followed by incremental delivery and fast and flexible response to changing requirements.

Agile does not necessarily mean quicker and cheaper delivery of a whole system or system change.

Agile architecture (agile abstract system description)?

Years ago, Scott Ambler called this Agile Model-Driven Development; today it is called evolutionary design, but is it design at all?

Of course you can work iteratively and incrementally, develop your architectural documentation alongside system development and deployment.

Isn’t that agile documentation rather than agile architecture?

Surely, an architect must describe a system's structure and behaviour at a level of abstraction that is as stable as possible?

And if that highest-level architecture is continually changing, doesn’t that undermine the notion of architecture?

 

Architects 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 architecture frameworks and agile software development or deployment practices.

Agile system (agile concrete system reality)?

The notion of an agile system is not a simple or single idea, since a system can be flexible in at least four ways.

A system that is

can

yet might also be

its architecture is likely to be

versatile

do many different things

rigid and hard to change or extend.

large or complex

malleable

be readily changed to a new version

limited and not versatile

slight or simple

extendable

be extended with extra features

not malleable (the Open-Closed principle in OO design).

fixed (must be right first time)

self-directing

change its own roles and rules

reliant on human ability, barely a system at all

slight and simple

 

Addressing the need to change a complex business system quickly is a challenge.

Generally, building flexibility into a system makes a system more complex – which adds time and cost to development.

Sometimes, it means shifting business rules from procedural instructions into data variables that end users can change – which tends to make the system slower.

Agile software development?

First, four assumptions a manager should be wary of making:

·         Coding boot camps turn out competent programmers

·         Programmers have the knowledge and skill to make optimal architecture decisions

·         People with “architect” in their job title have the knowledge and skill to make optimal architecture decisions

·         Agile development produces agile systems.

 

Architecture methods and agile software development methods are not directly comparable.

The former are about planning major changes business systems, to a target that may be a year, two years or more away.

The latter are about what a team does to continually improve and extend a software system, with release cycle of days or weeks.

 

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

Agile development principles include prioritisation of requirements, time boxing, cash boxing and incremental delivery.

Teams are encouraged to change, rebuild and re-testing a software system on a daily basis.

The outcome should be faster delivery of something useful, though it may not do everything customers want.

 

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

Given a particular initiative, an architecture framework like TOGAF is 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.

 

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

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

 

Of course, silo agile development projects lead to silo system issues; the same issues that let people to set up EA in the first place.

The same can be said of “microservices” as some interpret them.

An inevitable consequence is tightening up of project milestones; solution architects must complete “solution outline” documents and get them approved.

 

(Like SOA, the term “microservices” means different things to different people, and is used by some to promote the use of particular technologies.

It must mean 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.)

 

Of course, mindless completion and approval of document templates is ineffective, but the problem is not the document templates.

It is ill-educated, ill-informed document completion; and similar naivety in document reviewers.

There is no substitute for employing well trained experienced and knowledgeable people at all levels.

 

Not all systems and projects are well-suited to 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 meet legislative requirements 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.

If a system or project is not suitable, then it is probably an inherently difficult project.

So, consider substantially increasing the time and budget for the work.

Is the EA vision achievable?

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

The issues and diseconomies created by a mess of “silo solutions” are 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) feel 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.

 

The original EA vision of the single, integrated, enterprise-wide business system was/is so ambitious it may never be achieved.

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

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

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.

Concluding remarks

References? 50 years of digital transformation and EA contains 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.

 

Our (enterprise and solution) architects work to support business planning by optimising and extending these business roles and processes, and exploiting the use of business data.

They attend to the digital technologies required for that; and govern more detailed design work.

 

Our architects do not shape and steer everything in business.

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.

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

 

Our architects may optimise how a road gang leader gets job instructions and delivers job a completion report.

They don’t advise road gang members on how to wield a spade when digging holes (though operational researchers or specialist consultants might).

They don’t design car production lines, or pharmaceutical research equipment or projects.

They don’t design computing infrastructure technologies or data centres

 

Our architects rarely if ever design an organisation’s management structure.

(Instead, they may maintain a logical functional decomposition structure or capability map.

And map organisation units, as well as data structures and application components, to functions/capabilities.)

 

Finally, our architects are not business managers or business change consultants.

They are not responsible for hiring, firing and motivating people.

They are not managers, human resources specialists, or sociological systems thinkers.

Where employee roles are affected by business system change, they often work alongside a “business change” function.

 

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.