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 12/11/2018 18:00

 

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...” [now two articles]

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

Decades of EA as business system planning. 6

Enterprise architecture challenges. 7

Concluding remarks on what architects do not do. 7

References. 8

 

Enterprise and solution architecture

Business planning may involve predicting demand, setting product/service prices and changing products/services.

It might involve opening/closing outlets, on/off shoring operations, planning mergers, acquisitions and divestments,

It might involve restructuring the organisation's management, or in-sourcing/outsourcing (say) the HR department.

 

Enterprise architects may stimulate or contribute to business planning of that kind.

But their primary concern is to support and enable business operations.

Enterprise and solution architects design, plan and govern changes to business capabilities/systems.

Partly to optimise and enhance current operations, and partly to support goals/strategies/plans that directors declare.

 

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

Enterprise and solution architects study systems, and design and plan changes to systems.

Which is to say, their concern is “business system planning”.

However, there are misunderstandings of what this means.

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

Architects may find some systems overlap, duplicate or even conflict with each other.

Architects apply some change control to large-scale, generational, system change.

(For more on these underpinning concepts, read papers 5 and 6 on this system theory page.)

 

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

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

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

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

·         products: products and services, sales and service channels

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

·         resources: people, machines, locations/buildings and other physical asset types

 

EAs may contribute to business planning.

I have never met an EA asked or expected to do business planning per se (only read people promoting that idea).

 

Business system planning is concerned with regular business operations that use information.

It looks to optimise and extend how business roles and processes create and use business data.

It is given direction by business planning, and also informs business planning.

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

 

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.

 

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 is the meaning “EA” had to all those gurus and their followers.

That EA takes a cross-organisational view of business processes and data can be seen in:

·         The first two columns of the Zachman framework (1982 and 1987)

·         The focus of Stephen Spewak’s process for EA (1993)

·         The top level of James Martin’s pyramid for Information Engineering (1995).

·         The focus of "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.

Decades ago, US OBM Memoranda 97-16 guidance on enterprise architecture said this:

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

 

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.

Agile development and agile systems (two different things) are discussed in the next paper.

 

The remainder of this paper (formerly here) has been moved into a separate paper.

Read Enterprise Architecture Challenges for discussion of:

 

·         Governance of solution architects by enterprise architects  2

·         Populating your Strategy and Architecture team   3

·         Guerilla EA   4

·         Architecture methodology  5

·         Agility in its various guises  7

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.

 

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.

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

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.