Architect roles by level and domain
(Mapping roles to the architecture
work space)
This page is published under the terms of the licence summarized in the footnote.
All free-to-read materials on the Avancier web site are paid for out of income
from Avancier’s training courses and methods licences.
If you find them helpful, please spread the word and link to the site in
whichever social media you use.
The paper
was published in March 2014 and is still evolving in the light of comments; to
comment further please email here.
So far,
there seems agreement that it is helpful to cut up the architecture work space
into logical chunks.
One
public comment: “You are spot on, I agree with your definitions of
roles by domain/view and by level.”
And there
is agreement that mapping any person or role to one or several chunks is a
decision best made locally
Almost
all reservations expressed so far have been addressed in the paper below.
What is not covered here?
Many
things: authority structures, workflows, artefacts and document templates.
This is
only starter for thinking about the architecture work space.
Abstract
Given a large and complex business system, one
person cannot architect every aspect and detail
The enterprise and solution
architecture work space must be divided up one way or another.
This paper sets out a simple
two-dimensional classification, in accord with references 1 and 2.
It outlines the architecture work space, not (for
example) the management, testing or operations workspace.
The two dimensions are
sub-divided in ways that have emerged over several decades and been widely
adopted.
The four architecture domains
have appeared in every popular architecture framework for the last 30 years.
For example, in “EA Planning”,
TOGAF and IAF (references 3, 4 and 5).
Every large organisation
stratifies planning and design roles from broad/strategic to narrow/tactical.
Three levels are enough for us
here; though the paper does discuss a fourth (segment) level between enterprise
and solution.
|
Architecture Work Space |
||||
|
Domain/view Level |
Business |
Information/Data |
Applications |
Infrastructure/Platform |
|
Enterprise |
|
|
|
|
|
Solution |
|
|
|
|
|
Software |
|
|
|
|
|
Operations |
|
|
|
|
The grid might be used to assign
row/column titles to people, or pigeon-hole them in one cell, but that is not
its purpose.
The purpose is to help in assignment
concerns and activities to people - filling gaps - minimising overlaps.
You can choose which cells you
want any specific “architect" to cover, and give that cell group any title
you like.
Contents
Architecture work
space by level
Architecture work
space by domain/view
Mapping architecture
maturity levels to the grid
Comments and questions
answered
Appendix 2: a
half-baked suggestion for where common roles names may fit
The job
market place has proved incapable of settling the meaning of “enterprise
architect” and other architect role names.
The
Skills Framework for the Information Age (ref. 6) is useful but doesn't grapple
with the multi-dimensional and flexible nature of architect roles.
How to
define a classification scheme that can be easily and widely accepted?
The
classification scheme has to be fitting enough, also simple and flexible.
Simplicity
An aim is
to keep the representation of the architecture work space simple –
not too elaborate for a small-to-medium business.
A 2-dimensional
grid is probably as complex a scheme as we can manage – and the proposal
is below.
|
Domain/view Level |
Business |
Information/Data |
Applications |
Infrastructure/Platform |
|
Enterprise |
Enterprise/Business |
Enterprise/Data |
Enterprise/Apps |
Enterprise/Platform |
|
Solution |
Solution/Business |
Solution/Data |
Solution/Apps |
Solution/Platform |
|
Software |
Software/Business |
Software/Data |
Software/Apps |
Software/Platform |
The grid
is not about assigning row/column titles to people, or pigeon-holing them in
one cell.
It is
about assigning concerns and activities to people - filling gaps and minimising
overlaps.
Flexibility
There is
no universally agreed way of assigning the 12 cells (individually or in groups)
to people.
You can
choose which cells you want any specific “architect" to cover, and give
that cell group any title you like.
The
smaller and simpler the enterprise/system/solution, the more cells might be
covered by one person.
In a
small on-line web business, one multi-skilled “architect” might cover cells.
The grid
helps to demonstrate the breadth and depth of that person's role (and argue for
a salary increase).
Larger
and more complex enterprises tend to define more specialised roles.
I know
banks that add a row or two, and even add a column.
Some
introduce a "segment"
level between enterprise and solution.
You can label the grid and roles
as you see fit
The grid
helps you consider universal architecture concerns and activities and assign
them to roles or actors (people).
You can
group cells so as to create a role, permanent or temporary, and name that role
as you see fit.
The names
of the rows and columns are less important than their definitions.
But we do
have to name the rows and columns of the grid; the names compromise between the
principles of:
Architecture work space by level
Every
large organisation stratifies planning and design roles into levels from
broad/strategic to narrow/tactical.
Bear in
mind that a real architect often works in more than one domain and at more than
one level.
So,
somebody assigned to a role at one level may work in one or several
domain/views.
And note
that a large, diverse and complex enterprise may insert a level between enterprise
and solution, to divide their estate into cohesive and manageable chunks.
TOGAF
suggests three levels:
"Strategic
Architecture: A summary formal description of the enterprise, providing an
organizing framework for operational and change activity, and an
executive-level, long-term view for direction setting."
"Segment
Architecture: A detailed, formal description of areas within an enterprise,
used at the program or portfolio level to organize and align change
activity."
"Solution
Architecture: A description of a discrete and focused business operation or
activity and how IS/IT supports that operation, typically applies to a single
project or project release..."
For us,
the segment level is optional, and there is a level of software architecture
below the solution level, so our summary is this:
|
Enterprise architecture |
A summary formal description of the enterprise,
providing a framework for organising operational and change activity, and an
executive-level, long-term view for direction setting. |
|
Solution architecture |
A description of a discrete business function or
process and how it is supported by data, applications and technologies,
typically applies to a single project or project release. |
|
Software
architecture |
A fine-grained description of an application’s
internal structure and behaviour, or how application components interoperate. |
Higher
level roles operate more widely, with a broader scope.
TOGAF
says: "The
Enterprise Architect has the responsibility for architectural design and
documentation at a landscape and technical reference model level…
This
often means abstracting from detail; though EA roles may address tiny details
(e.g. identifiers) that are widely used across the enterprise.
TOGAF
says: "The
Enterprise Architect .. often
leads a group of the Segment Architects and/or Solution Architects related to a
given program."
Here,
“leads” probably means steering and governing lower roles rather than directly
managing them.
This
table below represents reasonable consensus.
|
Enterprise
Architect |
Solution
Architect |
|
Often
works for an enterprise, is a manager or member of a central EA function,
superintends work done by service providers. Optimises
the enterprise systems by integration or standardisation. Aims
for enterprise-wide integrity and quality. Responsible
for the quality and completeness of strategic road maps. May
specialise in one architecture domain. Looks
to increase business agility and technical agility. |
Often
works for a service provider in the bid and/or delivery phase. Shapes
and steers a solution, usually at a project level. Aims
for delivery quality: focused on critical success factors, esp.
non-functional qualities. Responsible
for the completeness of solution outlines and high-level designs. Understands
all facets of system design well enough to join up a coherent solution
architecture Shares
responsibility for time and cost of solution delivery. |
|
Leadership and governance Engages
with senior executives and their strategies. Acts as
highest-level design authority. May
lead architects in a programme, and guide them on standardisation and
integration opportunities. May
assign other architects to work on discrete developments. Defines
general principles, standards, and reusable components. Governs
that solution architects comply with relevant overarching EA. |
Leadership and governance Joins
up business analysts, software architects and technicians Submits
solution architectures for approval to higher/other authorities. Joins
lower-level technical specialists to each other and the overall architectural
landscape. Identifies
and mitigate technical risks, with delivery time and cost in mind. Adopts
general principles, standards, and reusable components. Governs
solution delivery, may be asked to heed relevant overarching EA. |
|
Planning level and time frame Considers
the whole enterprise as a system. Sets
out strategic cross-organisational road maps Addresses
the politics of cross-organisational concerns and goals, setting strategic
and cross-organisational directions. Governs
diverse programmes over the long term. |
Planning level and time frame Considers
selected business roles and processes. Relatively
tactical: the migration path for a programme or project. Does
what has to be done to address specific problems and requirements, and shape
and steer system changes with an eye on risks and costs. Shapes
specific solutions over a shorter time frame. |
|
Design and documentation Designs
and documents the enterprise system estate (aka landscape) and reference
models. Works
at the highest level with coarse-grained and logical outlines Documents the architecture of the enterprise
enough to enable impact analysis. |
Design and documentation Designs
and documents solutions to specific business problems. Works
at a middle level, elaborates from the abstract to the concrete, selects
physical components. Describes the architecture of a system that is the
outcome of one endeavour, at a level sufficient for detailed design and
building to proceed. |
Enterprise level architecture
A PRISM
paper in 1986 encouraged the setting of enterprise-wide architecture
principles and standards.
To
facilitate integration, reuse and agility, Zachman and others encouraged
enterprise-wide system description, at an abstract level.
TOGAF says: "The Enterprise
Architect has the responsibility for architectural design and documentation at
a landscape and technical reference model level."
Enterprise
and solution architecture are both about systemisation of business roles and
processes.
Where
systemisation efforts are local and/or tactical, they are more accurately
called solution architecture.
Uncoordinated
solution architectures result in a fragmented, duplicated and incoherent
enterprise – disparate processes, applications and infrastructure.
So,
enterprise architects are supposed to take the cross-organisational and
strategic perspective – to integrate and standardise.
TOGAF says: "The Enterprise
Architect often leads a group of the Segment Architects and/or Solution
Architects related to a given program."
(See
comments and questions below for more discussion of the enterprise level.)
Segment (or portfolio) level
architecture
A large,
diverse and complex enterprise may insert a level between EA and SA, to divide
their estate into cohesive and manageable chunks.
Looked at
from below, this segment level may be seen as the EA level.
“In our bank, the segments are
business domains (cards, payments, core banking, channels, business
intelligence domain...).
But each could be seen as a
portfolio. Besides that [the 3 by 4 grid in this paper] is perfect.
Solution level architecture
Solution
architects may concern themselves with anything and everything to do with a
solution.
Software level architecture
“I like the introduction of
"software" - which is missing today in our company.”
Software
architects play only one of various specialist roles below the solution
architect,
They
address the modularisation and integration of software components.
They
describe the internal structure and behaviour of a software application.
They may
follow principles and patterns for modularisation and integration.
An
enterprise architect is not likely to engage in detailed software architecture.
However
its principles and patterns (e.g. encapsulation, coupling/decoupling) are
useful at higher levels.
All
architects should be familiar with such principles and able to apply them
appropriately.
And
solution architects have to talk to software architects about such matters.
Architecture work space by domain/view
The four
architecture domain/views below were established in “EA Planning” (Stephen Spewak, 1993) and are now the basis of countless EA
frameworks, including TOGAF.
Bear in
mind that a real architect often works in more than one domain and at more than
one level.
So,
somebody assigned to a role in one domain/view may work at any or all levels.
Every architecture view and
architect
|
Assigning processes and products to the work space
– an example for you to extend or modify |
|||
|
Business view |
Information/Data view |
Applications view |
Infrastructure/Platform view |
|
Enterprise/Business Standardisation &
integration of business roles &
processes Business function/capability
hierarchy Business products &
services catalogue Business processes and
roles Etc. |
Enterprise/Data Data standardisation
& integration Data store & data
flow catalogues Maps data to business
functions Business data model &
views of it Canonical data model(s) Core business data entity
life cycles Etc. |
Enterprise/Apps Business app
standardisation & integration Business app
portfolio/catalogue Maps business apps to
business functions Business app life cycles
and road maps Etc. |
Enterprise/Platform Platform standardisation
& integration Platform technology
portfolio/catalogue Platform services
portfolio/catalogue (TRM) Platform technology life
cycles and road maps Etc. |
|
Solution/Business For a required
system/solution: Business services Business processes and
roles Mappings to goals
& locations Requirements catalogues Use case diagrams and
definitions Outline UI (or other I/O)
designs Etc. |
Solution/Data For a required
system/solution: Maps data to processes
and roles Logical data models CIA requirements Data qualities/meta data Etc. |
Solution/Apps For a required
system/solution: Maps use cases to
processes and roles Maps business apps to use
cases Design for NFRs Coarse-grained app
components Coarse-grained sequence diagrams Etc. |
Solution/Platform For a required
system/solution: Maps platform to business
apps Platform technology
definitions Client & server node
definitions Design for NFRs Outline deployment
diagrams Outline network diagrams Etc. |
|
Software/Business Detailed use case
definitions Detailed UI designs Governs UI implementation Etc. |
Software/Data Detailed database design Detailed message design Governs database
administration Etc. |
Software/Apps Detailed (fine-grained)
software design Governs software
development Etc. |
Software/Platform Detailed deployment
diagrams Detailed network
diagrams. Governs platform and
network configuration Etc. |
Note that
the distribution of concerns and activities to roles is a matter for local role
definition.
Remember
that this is the architecture work
space, not (for example) the management, testing or operations workspace.
Mapping architecture maturity levels to the
grid
Four EA maturity
levels are defined in “EA as Strategy” (ref. 7). This paper adds one lower
level of maturity.
Maturity level 1: JDI: local apps and infrastructure are built and deployed with
little planning or governance.
Maturity level 2: Business silos: local apps and infrastructure are built and
deployed under solution level planning and governance.
Maturity level 3: Standardised technology: shared infrastructure, technology
standards, fewer platforms.
Maturity level 4: Optimised core: enterprise systems, shared apps and data, no data
redundancy.
Maturity level 5: Business modularity: reusable business components and processes.
This
table maps the five maturity levels to the cells of the architecture working
space grid.
|
Business |
Information/Data |
Applications |
Infrastructure/Platform |
|
|
Enterprise |
5: Business modularity: reusable business components and
processes. |
4: Optimised core: enterprise systems, shared apps and data,
no data redundancy. |
3: Standardised technology: shared
infrastructure, technology standards, fewer platforms |
|
|
Solution |
2: Business
silos: local
apps and infrastructure are built and deployed under solution level planning
and governance. |
|||
|
Software |
1: JDI: local apps and infrastructure
are built and deployed with little planning or governance. |
|||
Comments and questions answered
Q) Are all business roles and processes in scope?
Some business roles
and processes are ad hoc, informal, infrequent, creative or manual and do not
require information systems.
Such roles and
processes are not good candidates for systemisation (though work to define or
change them might be placed in the Solution/Business cell of the grid).
EA is
much more about business roles and processes that require information systems
to monitor and direct the processes, which in turn require platform
technologies.
Q) Where does the IT architect
fit?
Traditionally,
EA has been focused on how business roles and processes are enabled, monitored
and directed by business information systems.
The
attention given to the IT infrastructure or platform technologies has been
slight. Read more at “IT architect roles”
Q) Where does the security
architect fit?
Security
concerns can appear anywhere – can attach to every cell of the tabular
classification.
“A
security architect defines standards and design features attached to other
architectures.
A
security architect may define a standard security risk assessment framework,
define a standard set of controls and risk mitigation, in all architecture
domains.
A
security architect should work with enterprise and solution architects to
ensure that risk framework and standard solution options are fit for purpose
and easy to consume.
And work
with operational service lines to stand up shared-services for the most common
requirements.”
Q) What is a business
application?
There
seems to be no universally agreed answer.
Many
business applications take the form of a stack running from user interface at
the top to a database at the bottom.
Batch
(serial data processing) load and report programs may also be considered as
business applications.
In a
world of distributed systems, what a business application is – how big it is -
where it starts and stops – is challenging.
Inter-application
messages may be considered as inputs and outputs of applications at either end.
The
processing of messages in transit may be considered as business applications.
Q) Where does enterprise
application integration fit?
Deciding
and governing the use of an enterprise-wide standard for application
integration is a role in the enterprise/applications cell of the grid.
Deciding
a solution-specific application integration style or pattern is a role in the
solution/applications cell.
It might
be done in compliance with an EA level standard, or not.
If this is
what you call a middleware architect role, then it might be placed in the grid
as below.
|
Domain/view Level |
Business |
Information/data |
Applications |
Infrastructure Platform |
|
Enterprise
|
|
Enterprise-wide
canonical data model |
EAI standards |
|
|
Solution |
|
Narrow use
canonical data model |
Middleware
Architect |
Middleware
architect |
|
Software |
|
|
|
|
Building
and governing the use of an enterprise-wide canonical data model is a role in the
enterprise/data architecture cell.
Building
a solution-wide canonical data model is a role in the data architecture domain
at the solution/data cell.
It might
be done in compliance with an EA level canonical data model, or not.
Q) How does this relate to
building architecture?
The word
architect comes from the Greek, meaning “master builder”.
Architectural
drawings are not buildings, they are specifications
that abstract (hugely) from built systems.
But the
IT domain is very peculiar, because human and activity systems are infinitely
malleable.
And even
bottom level code and configuration details are only abstract specifications
for required behaviour.
Q) What is the difference between
requirements analysis and architecture?
Requirements
are what the architect (or somebody) captures from one or more customers.
Given
requirements, the job of the architect is to specify the form/structure and
functions/behaviour of the building.
The
architect must be responsible for this high-level design.
Without
that, there is no architecting, only what might be called a requirements
analyst role.
Q) What is the difference between
requirements definition and architecture definition?
There is
no universal agreement about the dividing line.
Simply speaking,
inside a system, components/roles cooperate to execute processes.
Looked at
from the outside, services encapsulate processes, and interfaces encapsulate
components/roles and make services available.
Some say
a use case definition (which documents a process encapsulated in a service) is
requirements specification, others say architecture definition.
TOGAF
places services in the requirements specification, the rest (components/roles,
processes and interfaces) in the architecture definition.
Q) What is the difference between
architecture and design?
There is
no agreed distinction between architecture and design.
Dictionary definitions of architecture include the word design, and position
the architect as a chief designer.
(I once worked through a standard on architecture definition replacing all
"architecture" by "design" and couldn't detect any
difference in the meaning.)
However, in IT circles, architects often produce what are called "high
level design" documents.
By
implication, there is "detailed design" below the level of the
architecture.
So this paper uses the word design only at the lower levels.
Q) Where does one role let go and
another pick up?
The
hand-over of artefacts from one level to another is always a challenge.
For any
architect, a big and generally unanswerable question is: How much detail is
enough or too much?
Much
depends on:
A common
question is: What details should a Solution Architecture document contain?
If you
rephrase the question as: What do analysts and designers need to pick up and
follow through to solution delivery?
Then
clearly, the answer must be influenced by local role divisions, and the
abilities of the people involved.
(However,
I do sell a general answer to that question in Avancier Methods in the form of
a comprehensive Solution Outline document template.)
Does EA have to attend to tiny
details?
EA
addresses what is most abstract. Sometimes abstract by composition - broad
brush. Other times abstract by generalisation to have the broadest application.
The most generalisable components and processes may be small. E.g. identity management in a single-sign-on application. E.g. a single item (say a customer address format) in an
enterprise-wide canonical data model. To impose small generic things
enterprise-wide is a big project.
Does EA seek to remove all redundancy?
No, but
it is an EA role to detect redundancy, and remove it where that is beneficial.
Without
the broad EA view you don't know where the redundancy is and can’t plan how to
remove it.
Ross etc.
define levels of EA maturity in terms of redundancy removal.
Do EA and SA address business system changes that do not involve
information system change?
Enterprise
and solution architects do not address every business role and process.
They do
not define how professional footballers play football, or actors act in a play,
or miners mine for coal.
They
model business processes that are repeated and deterministic enough to be
systemised - and
create or use business data.
The more
repeated and complex the process, the more likely the business needs it to be
monitored, supported or directed by structured data.
The EA
team catalogues all significant information systems and monitors or directs
changes to them. Business roles and processes that do not involve information
systems are relatively peripheral to the main thrust of EA.
Can every enterprise be
systemised? Does every enterprise have a definable architecture?
Not all
enterprises are stable enough in scope, standardised or repeated enough in
processes, to be systemisable to a significant
degree.
Many
processes are ad hoc, informal or manual.
Parts of
an enterprise that are not systemisable are
peripheral to EA.
In a
small business, what is repeated and deterministic enough to be worthy of
systemisation (e.g. accounting, email communication) is often outsourced or
commoditised.
Is it easy to engage executives
with enterprise architecture?
No. It is
not easy to engage business managers with architecture disciplines in general,
cross-organisational redundancy and long-term planning.
That is
what makes EA so difficult, requiring attention to power, politics and
stakeholder management.
How to engage executives?
Ross etc.
address that in their book. (Avancier Methods for EA also address it.)
Where does an EA team manager
draw the line as to what EA members address?
Relevant
questions include: Is the change cross organisational? strategic?
mission-critical?
How much
is needed by way of time, money and resources? Having said that, the EA team
may include pool of solution architects who can be assigned to direct or
support more local, more tactical, less mission-critical and low cost changes.
Appendix 2: a half-baked suggestion for where
common roles names may fit
March 2014,
I ran a 5 day enterprise and solution architecture course for 5 people.
I asked
them to place themselves in 4 by 3 architecture work space grid at
avancier.co.uk.
To
simplify a little, results were:
The grid
helped them to articulate their focus, understand the others’ roles, and feel
comfortable about the differences.
And having
established that understanding, they worked together well.
Nobody likes being pigeon-holed, but might it be possible and helpful to
place specialist roles names in the cells?
The grid
below has been hastily completed with some possible role names – but really –
this is up to local decision making.
|
Domain/view Level |
Business |
Information/Data |
Applications |
Infrastructure/Platform |
|
Enterprise
|
Business architect Business
consultant |
Information
architect |
Application
portfolio manager |
Technology portfolio manager Operations
architect |
|
Solution |
Business consultant Business analyst Systems
analyst |
Data
architect |
Applications architect Middleware
architect |
Platform architect Middleware
architect |
|
Software |
Requirements analyst User
interface designer |
Database
designer |
Software
designer |
Platform designer Network
designer |
References
Ref. 1:
“The British Computer Society’s reference model for enterprise and solution
architecture” downloadable from www.BCS.org.
Ref.
2: Avancier Methods at http://avancier.co.uk.
Ref. 3:
“EA Planning” Stephen Spewak 1993
Ref. 4:
“TOGAF” free to read at opengroup.org 2009
Ref.
5: “Integrated Architecture Framework
(IAF) Cap Gemini
Ref. 6:
"Skills Framework for the Information Age"
Ref. 7:
“EA as Strategy” Ross, Weill and Robertson 2006
Footnote: Creative Commons Attribution-No
Derivative Works Licence 2.0
04/12/2015
12:48
Attribution: You may copy, distribute and
display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and include this
footnote at the end.
No
Derivative Works: You may
copy, distribute, display only complete and verbatim copies of this page, not
derivative works based upon it.
For more
information about the licence, see http://creativecommons.org