Enterprise and Solution Architecture Roles: things to know

https://bit.ly/2OlJVqr

Copyright Graham Berrisford. One of several hundred articles at http://avancier.website. Last updated 20/10/2020 18:01

 

This article positions enterprise architecture in relation to business planning and to solution architecture.

It outlines both the historical context for and the reality of modern architect job descriptions.

It has been downloaded getting on for 20,000 times.

 

·       VE “Thanks for sharing.”

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

·       TRB “Good read.”

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

Contents

The business planning context 1

The architecture work space. 1

Enterprise and solution architect roles. 1

How enterprise and solution architecture roles emerged. 1

Further reading. 1

Appendix 1: The emergence of architecture frameworks. 1

Appendix 2: What architects don’t do. 1

 

The business planning context

Enterprise and solution architects may both stimulate and contribute to business planning.

But their primary responsibility is business system planning.

Busines systems are composed of human (people) and computer (technology) actors performing activities to meet aims (goals).

 

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 and directing changes to any of the following.

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

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

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

 

Business system planning

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

The business systems of interest here are activity systems:

·       they feature human and computer actors performing regular activities to meet given aims

·       the activities of interest create and use business data that is or may be digitized

·       they are designed: meaning their elements are ordered and related to achieve desired outcomes

·       they may be integrated with other business systems by the exchange of information

·       they may be changed under change control.

 

The term solution architecture is used at a narrower and more tactical level, often in relation to one particular system, or a process that requires system integration.

Architects often work with:

·       a programme/project management office (PMO)

·       a business change function – when human organisation or roles are significantly impacted

·       an operations management and/or IT services management function.

The architecture work space      

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

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

However, many do have a team called “strategy and architecture” or the like.

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

 

Domain

Level

Business

Data/Information

Applications

Infrastructure technology

Enterprise

architecture

Business services, processes & roles,

standardisation, integration

and road maps

Business data stores and flows

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

 

 Note that software architects complete the internal component structure and APIs of an application, at a detailed level.

And may address also inter-application messaging at a detailed level.

 

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

Enterprise and solution architect roles

Enterprise and solution architects don’t design buildings, cities or other concrete structures.

Their concern is the design of business activity systems in which human and computer actors perform processes to deliver services.

They work to extend and improve business roles and processes that create and use data that is or can be digitized.

They play a role in selecting technologies that are used to support and enable those processes.

 

Solution architects work on specific initiatives.

They respond to requests for architecture work and solution visions.

Their work spans all four primary architecture domains: business, data, applications and technologies (BDAT).

A solution architect:

·       shapes and steers a solution by compiling a Solution Outline or Solution Architecture Definition

·       coordinates the work of specialists working across the BDAT and security domains

·       is responsible for identifying and mitigating technical and non-functional risks

·       defines a baseline to target migration path

·       works alongside a project manager

·       starts with the business context, working with business analysts as need be

·       understands a variety of alternative technologies in the DAT domains

·       understands a variety of alternative design patterns and makes trade-offs between them

·       balances the demands of project managers and enterprise architects.

 

Enterprise architects have a wider remit.

They work at the cross-organisational portfolio and strategic level:

·       are concerned to optimize, standardize and integrate business roles, processes and systems

·       look to constrain the wastefulness and issues caused by point solution proliferation and duplication

·       maintain a summary description of the enterprise and its systems

·       maintain standards, principles, reference models and patterns

·       contribute to business strategy with advice on where changes and innovations can help

·       develop roadmaps for changes and at a strategic, executive-level

·       guide and govern architects working at lower levels.

 

Their scope may be a whole business, or a division or segment of a business; and includes interfaces to systems governed by others.

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

They may support business directors and planners in the design and planning of a major “digital transformation”.

 

In a nutshell, enterprise architecture is portfolio-level thinking.

It is strategic and cross-organisational planning of changes to business systems that are now or will be digitized to some degree.

Whereas solution architecture is project-level thinking - about the design and planning of discrete systems/solutions.

But the roles overlap, and each role may be divided between two or more people.

Architect roles in the SFIA standard

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.

The standard says enterprise architects are concerned with “setting strategies, policies, standards and practices”.

(At least, those related to the design, planning and procurement of systems that support business activities.)                                                                                             

The standard says solution architects

·       “guide the design and development of integrated solutions to meet current and future business needs.”

·       “coordinate design activities, produce logical models of components and interfaces, and more detailed designs.”

Architect roles in the TOGAF standard

TOGAF, to suit large and diversified enterprises, includes a segment level of architecture between EA and SA.

Below is a summary interpretation, based on a thorough reading of the whole standard at versions 8 and 9.

 

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

·       See the definition above.

 

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.

A selection of architect role definitions are posted in the left-hand column of this “Enterprise architecture roles and realities” page.

You'll find articles on architect roles by level and by domain, and a slide show on the EA manager role.

 

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

 

Generally, architects start from the business context and human activities.

They design and plan changes to business systems - under change control.

They aim to support and enable business 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.

How enterprise and solution architecture roles emerged

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, business systems have increasingly been “digitized”.

Many IT departments have taken on the role formerly played by Operational Research departments

From 1960 onwards, people have recognized opportunities to “digitize” more and more business activities.

·       We can increase the speed and accuracy of billing and accounting.

·       We can digitize employment records and tax collection.

·       We can process cash using ATMs and point of sale devices.

·       We can digitize money handling using card readers

·       We can measure resource consumption using digital meters.

·       We can replace snail mail by email

·       We can do market research by capturing and analyzing information about customers.

·       We can digitize our shop window on the internet.

·       We can advertise and deliver services via social media.

·       We can apply machine learning and other kinds of AI to our business data.

The emergence of solution architecture definition

Digitizing data and automating processes is difficult, detailed and yet also abstract work.

People have looked to formalize how the work is best organized. 

 

Three architecture principles

In the 1980s, the UK government’s method (SSADM) was based on these principles:

·       Business options before technology options

·       Logical design before physical design

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

The principles remain sound, but some criticized SSADM for leaving 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

 

Four architecture domains

Most architecture frameworks and modelling languages divide architecture into the architecture domains identified in the PRISM report (1986)

The table below maps the four primary 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

 

The division into domains/layers remains sound.

But there is more attention nowadays to security architecture, which is applicable to each of the domains above.

 

Formalisation of solution architecture definition

A “solution architecture definition” or “solution outline” captures a holistic view of the system(s) to be built or changed.

The document, addressing all domains above, is produced for one or both of two, sometimes incompatible, 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?

The emergence of EA to constrain “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, optimize/extend particular business systems.

They employed architects who defined solutions independently of each other – under the influence of competing technology vendors.

Thus, the enterprise acquired a portfolio of systems that were not standardized, 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.

 

Enterprise architecture was initially a reaction to issues caused by diverse silo solutions.

Note that the same issues may appear today as a result of over-enthusiastic division of applications into “microservices”!

 

The problems created by silo solutions

To begin with, the 4Ds related to data processing:

·       Duplications of data and processes – leading to costs

·       Disintegrities between data in different systems – leading to quality issues

·       Delays in completing processes

·       Difficulties with cross-organizational data analysis.

 

Add issues and diseconomies created by maintaining a mess of disparate applications and technologies:

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

·       Complexity in the use of technologies to move data between applications

·       Complexity in the effort needed to align or transform between different data formats

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

 

The pains are felt 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 digitizing and codifying can make it hard (or impossible) to change business roles and processes.

 

An enterprise architecture as a product

Above, EA is seeing and designing a business as a coordinated collection of human and computer actors performing activities to meet aims.

EA is defined similarly in this article.

“We define enterprise architecture as the holistic design of people, processes, and technology to execute digitally-inspired strategic goals.”

An enterprise architecture is a model or description of an enterprise as collection of systems, at the most abstract level of business system design.

Why define one? The same article says:

“Every negative customer interaction via a company app, website, telephone call, or service provider exposes your architectural inadequacies.

“Left unresolved, these issues will destroy formerly great organizations.

The emergence of EA as business system planning

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

But their primary concern is business system planning.

 

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.

Further reading

 

How does an architecture framework EA relate to SA?

For an EA-SA value stream read the short article number 4 here https://www.linkedin.com/in/grahamberrisford/detail/recent-activity/posts/

 

For detailed research and real architect role definitions.

A selection of architect role definitions are posted in the left-hand column of this “Enterprise architecture roles and realities” page.

You'll find articles on architect roles by level and by domain, and a slide show on the EA manager role.

 

How does EA apply general system theory?

Read this slide show for how TOGAF and ArchiMate embody general system theory principles.

 

For discussion of EA with reference to TOGAF

Read EA and TOGAF: how do they differ?

 

On two big challenge EA faces

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

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 standardize, 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 those things.

 

The pace of change?

Where there is little sponsorship or enthusiasm for following an EA framework, a more agile EA approach might be considered.

There are several articles on agile architecture at http://avancier.website.

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

·       “Guerilla EA”

Appendix 1: The emergence of architecture frameworks

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

For an extensive EA history, and references from 1970 onwards, read 50 years of digitisation and EA

This appendix contains only a few notes on the history.

 

All the gurus below saw/see EA as based on taking a cross-organisational view of business processes and data.

·       1970s Duane Walker’s Business System Planning

·       1980s John Zachman’s tabular framework, and James Martin’s pyramid for Information Engineering

·       1990s Stephen Spewak’s EA planning process

·       2000s "EA as Strategy" by Ross, Weill and Robertson

 

A comprehensive architecture methodology or framework provides guidance on the processes and products of architecture work, and the people involved.

The process is the cross-organisational and strategic planning of changes to business systems, with a view to standardisation and integration of business processes.

The product is the description of an enterprise's business systems, and how they relate to each other.

That description, being multi-dimensional, is best recorded in a repository

 

Meta models for an architecture repository have been around for half a century (long before TOGAF and BizBOK).

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.

Today’s EA frameworks are still concerned with optimizing, 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.

 

Zachman’s vision of the single enterprise-wide business database is not achievable.

However, it remains a vision that helps to explain that EA is about 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.

Appendix 2: What architects don’t do

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

They look to optimize 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.

They look for opportunities to digitize roles and processes, or capture new and useful data.

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

It is impossible to digitize 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 optimize 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 do that.)

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

They don’t design generic IT (platform/infrastructure technologies) or data centres

 

Our architects are not business managers or business change consultants.

They rarely if ever design an organisation’s management structure.

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

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

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

 

 

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.