Enterprise and Solution Architecture: things to know

https://bit.ly/2OlJVqr

Copyright Graham Berrisford. One of several hundred papers at http://avancier.website. Last updated 14/10/2019 15:38

 

As a noun, an enterprise architecture (EA) is a product, a description of an enterprise's business systems, coordinated with each other.

As verb, EA is a process, the cross-organisational and strategic oversight of business system innovations, developments and changes, with a view to standardisation and integration.

It is probably true that more enterprises pursue the process than produce the product.

 

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 suggested as pre-course reading for Enterprise and Solution Architecture (ESA) certification courses in this Training Calendar.

 

·       VE “Thanks for sharing.”

·       SW “This is good reading. Thank you for sharing.”

·       TRB “Good read.”

·       SG “Very much insightful. Thanks a ton.”

Contents

Enterprise and solution architecture. 1

Decades of solution architecture. 4

Decades of point solution proliferation. 6

Decades of EA as business system planning. 6

Enterprise architecture challenges. 8

Concluding remarks - on what architects do not do. 8

Footnotes. 9

 

Enterprise and solution architecture

Enterprise and solution architects don’t design buildings or other concrete things.

They are concerned with the services provided by a business.

And with how those services are delivered by processes that refer to and advance the state of the business.

 

Business planning

Business directors are responsible for business planning.

They respond to business drivers by declaring strategic directions and top-level goals/objectives.

Business planning may involve predicting demand.

It addresses changes that have been envisioned to one or more of an enterprises’

·       Constitution: mergers, acquisitions and divestments, opening/closing outlets

·       Market: industry domain/sector/segment, customers and suppliers

·       Products: products and services, sales and service channels, prices

·       Relationships: partners, in-sourcing and out-sourcing of operations

·       Resources: people, wages, machines, locations/buildings and other physical asset types.

·       Management structure: sacking or appointing CxOs and restructuring the organisation.

 

Enterprise and solution architecture

Enterprise and solution architects may stimulate and contribute to business planning of the kind above.

But their primary concern is business system planning.

They study the business systems (human and computer) that support and enable business operations

They design and plan changes, not only to support goals/strategies/plans that directors declare, but also, more generally, to optimise systems.

 

In a nutshell, enterprise architecture is strategic and cross-organisational planning of changes to business systems that are now or will be digitised to some degree.

Solution architecture is the design and planning of discrete systems/solutions.

 

Enterprise and solution architects are concerned with regular business operations that use information.

They look to optimise and extend how business roles and processes create and use business data.

At the same time, they aim to constrain the wastefulness and issues caused by point solution proliferation.

This involves standardisation, integration and innovation.

 

What is an enterprise?

The scope of the systems governed by an enterprise architecture function is whatever its sponsors decide.

It may be a whole business, or a division or segment of a business.

It includes interfaces to systems governed by others.

Architects in different businesses may collaborate in cross-business initiatives (e.g. the Tele Management Forum).

 

What is solution architecture?

The scope of a solution is outlined by sponsors in a request for architecture work

It involves changes to the architecture of one or more business systems within an enterprise.

Solution architects shape and steer solutions, compiling “solution outlines” and “solution architecture definitions”.

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.

 

What is enterprise architecture?

Enterprise architecture (EA) was a reaction to issues caused by diverse silo solutions, including the four Ds: delays, disintegrities and difficulties with data analysis.

EAs map business roles and processes to business data and applications at a cross-organisational and strategic level, and review solution outlines.

Where there is no sponsorship or enthusiasm for employing full-time EAs, you may consider a more Agile EA approach.

 

Related functions

Enterprise and business architects usually work with a “programme/project management office” (PMO)

When human organisation or roles are significantly impacted, they work in cooperation with a "business change" function.

To set a new or changed system live, it is passed to some kind of “operations management” function.

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

 

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

 

 

 

SFIA positions EA and SA as senior, leading roles.

Both roles are concerned with changing business role and 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”.

(SFIA means those related to the design, planning and procurement of information systems that support business roles and processes.)

Architect roles in the TOGAF standard

Below is a summary interpretation, including a segment level between EA and SA.

 

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 [some might call them business domain 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 [some might call them project 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).

Architect roles in advertised role definitions

Research into real architect roles 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.

 

All architects 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, go to our “Enterprise architecture roles and realities” page
You'll find there 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.

Decades 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 dawn of the Information Age, people 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.

 

Architecture domains

Digitising data and automating processes is difficult work, and people have looked to formalise how the work is best organised. 

The PRISM report (1986) identified four architecture domains; these remain the basis of EA frameworks and modelling languages today

The table below maps the four domains to the three architecture layers in TOGAF and ArchiMate.

 

Architecture layer

Architecture domain/view

Essential elements

Shaped by the needs of

Business

Business organisation

Business roles and processes

the business to serve customers.

Information

systems

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

Technology

Infrastructure technology

Platform technology apps, nodes and networks

business applications to perform generic computing tasks

 

Architecture methods

In the 1980s, the UK government’s systems analysis and design method (SSADM) reflected the presumptions of methodologists at that time.

·       Business options before technology options

·       Logical design before physical design

·       External view (system interfaces, 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.

Early architecture frameworks progressed similarly, from business analysis, through requirements for information systems, to the platform technologies they need.

In practice, people complained this approach is too idealistic, it leaves 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.

 

Solution architecture emerged out of efforts 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

·       for use by those working in detailed design and development.

 

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?

Decades of point solution proliferation

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.

 

Business managers had specific requirements to support/enable, speed/scale up, optimise/extend particular business systems.

Architects defined solutions independently of each other – under the influence of competing technology vendors.

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

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

 

IT people are aware of the technical issues and diseconomies created by a mess of “silo solutions”.

·       Technology dependencies - business roles depend on vendor-specific technologies.

·       Difficulties exchanging data between applications - data locked into silo data stores.

·       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 people (only indirectly aware of the technology mess) feel pains at the business level:

·       Business coordination is weak because silo systems make it harder to integrate business roles and processes.

·       For example, sales and billing systems, or social and health care systems, are inconsistent and uncoordinated.

·       Business systems are inflexible, because digitising and codifying can make it hard (or impossible) to change business roles and processes.

Decades of EA as business system planning

Enterprise and solution architects may stimulate and contribute to business planning of the kind mentioned above, at the start of this paper.

But their primary concern is business system planning.

They study current business systems, and design and plan changes to them.

Not only to support goals/strategies/plans that directors declare, but also, more generally, to optimise systems.

 

Enterprise and solution architects are concerned with regular business operations that use information.

They look to optimise and extend how business roles and processes create and use business data.

At the same time, they aim to constrain the wastefulness and issues caused by point solution proliferation.

This involves standardisation, integration and innovation.

 

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.

 

Mainstream EA emerged out of IBM’s Business System Planning method, which Duane Walker reputedly started c1970.

At that time, human activity systems increasingly depended on computers, and Operational Research functions were subsumed into IT departments.

EA can be seen as the digitisation-oriented descendant of Operational Research.

Sometimes, EA supports business directors and planners in the design and planning of a major enterprise transformation, but not always.

 

Taking a cross-organisational view of business processes and data

Starting in the 1980s, gurus devised various EA methods and techniques; including logical functional decomposition, value stream diagrams etc.

The techniques don’t matter here; what matters that “EA” had much the same meaning to all those gurus and their followers.

EA meant then – and still means - taking a cross-organisational view of business processes and data.

That view can be seen in

·       The Zachman framework (1982 and 1987)

·       Stephen Spewak’s process for EA (1993)

·       James Martin’s pyramid for Information Engineering (1995).

·       "EA as Strategy" by Ross, Weill and Robertson (2006)

 

(Read 50 years of digitisation and EA for quotes and references backing up the history above.)

 

Today’s EA frameworks are still concerned with optimising, extending and changing business processes that create and use data.

First, enterprise architects should understand the systems of the business, not necessarily in depth.

Then, they should understand what information technologies do or can do to support and enable the business.

The vision of the single, integrated, enterprise-wide business system is probably not achievable.

However, it remains a target vision that helps to explain what EA is.

Enterprise architects govern the portfolio of business systems.

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 (but see guerilla EA below).

Enterprise architecture challenges

EA has always been challenging, both technically and politically.

In the 1990s, the US OBM Memoranda 97-16 guidance on enterprise architecture declared that.

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

 

The balance between centralisation 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?

A highly diversified business presents a challenge to the notion that the enterprise is a holistic system.

 

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

Suppose your enterprises wishes to standardise, integrate and optimize systems to the benefit to the enterprise as a whole, and mitigate change risks.

Then it needs standards, principles, reference models, best practices and road maps for business system change.

And it ought to govern solution architects with reference to that collateral.

 

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 other EA challenges for discussion of:

·       Populating your Strategy and Architecture team   3

·       Governance of solution architects by enterprise architects  2

·       Architecture methodology  5

Concluding remarks - on what architects do not do

Enterprise and solution architects work to support and contribute to business planning by business system planning.

They look to optimise and extend business roles and processes, and exploit the use of business data.

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

 

Enterprise and solution 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.

 

Enterprise and solution 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

 

Enterprise and solution architects rarely if ever design an organisation’s management structure.

(Though 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, enterprise and solution 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.

Footnotes

Footnote 1: underpinning theory

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

But there are misunderstandings of what a business system is.

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 can be described one social network that realises many social and technological systems.

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

For more on systems theory and thinking, read on systems thinking ideas used in agile.

 

Footnote 2: EA not = ITA

EA and BA are much older than TOGAF and BizBOK and have always been about Process and Data before Technology.

EA meta models have been around for fifty years.

Perhaps the first was that of IBM’s Business System Planning, created by Duane Walker in the 1970s and inherited by John Zachman c1980.

It set the pattern for other EA meta models in the 1980s and 90s.

If I have it right, the Business System Planning meta model features 7 entities and 8 relationships

·       Processes <solve > Problems

·       Processes <are performed by > Organisations

·       Processes <create and use> Data entities

·       Process <are enabled and supported by> Applications

·       Data entities <represent> Business entities

·       Data entities <are maintained in> Data stores

·       Applications <access> Data stores

·       Organisation <use> Applications

 

Again, notice the focus on Process and Data rather than Technology.

Footnote 3: other background reading

Read 50 years of digitisation 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.

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.