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 10/01/2019 18:38

 

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.

 

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

 

The second half of this paper (formerly here) has been moved to our Enterprise Architecture Challenges and Agile Architecture papers.

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

References. 10

 

Enterprise and solution architecture

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

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

It may involve predicting demand, sacking or appointing CxOs and restructuring the organisation's management.

 

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

 

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 a solution?

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.

 

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.

 

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?

What if managers insist a point solution is needed tomorrow?

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

Note that agile development and agile systems are two different things.

 

The rest of this paper (formerly here) has been moved to our Enterprise Architecture Challenges and Agile Architecture papers.

The first of those addresses these topics

·        Governance of solution architects by enterprise architects  2

·        Populating your Strategy and Architecture team   3

·        Guerilla EA   4

·        Digital transformation

·        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: the 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.

 

People often liken enterprise or business architecture to building architecture, airplane engineering or city planning.

Such analogies can mislead people, since the theoretical basis for architecting activity systems is none of those.

"Building" a business system is very different from building any kind of concrete structure.

Any similarities you may point to are far outweighed by the differences.

An education in business process engineering is very different from an education in building architecture.

 

Enterprise and business architects are concerned with activity systems - rather than concrete structures.

The concepts that appear and reappear in business architecture are abstract ones like goals, roles, processes and information.

And the theoretical basis for architecting activity systems is general system theory and classical cybernetics - along with a dash of “design thinking” and social systems thinking.

 

(If those things interest you, then do book a place on the next System Theory for Architects Tutorial in London.)

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.

References

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.