What makes an
architecture framework?
This page is published under the terms of the licence summarized in the footnote.
Abstract
A comprehensive
architecture framework offers guidance to architects on processes, products and
people
There are many
processes, techniques, documentation schemes, modelling languages and reference
models that architects can find useful.
This paper lists
some, with a little commentary.
Processes for the design,
planning and delivery of change
What turns a change management process into an
architecture framework?
Domain/industry-specific architecture reference
models
People – architect roles and organisation models
Managers use processes to facilitate the planning
and delivery of change.
There are processes for programme,
project and service managers such as:
·
MSP
for programme managers (note that portfolio management
is different)
·
PRINCE
2 for project managers
·
ITIL
for IT service managers (which now includes strategy and planning guidance).
Changes to the systemisation
of a business need architects to shape the changes and the migration path
For this, there are more architect-oriented
processes such as:
·
Business
Systems Planning (IBM)
·
EA
Planning (Stephen Spewak)
·
FEAF
supposedly for federal US government, but much like TOGAF
·
TOGAF’s
Architecture Development Method (ADM) for enterprise architects and related
roles
·
Countless
variations on the above.
There are similarities and overlaps between
management and architecture-oriented processes.
To use two of them together, efficiently, you’ll
need to collate and de-duplicate the processes and their products.
TOGAF recommends you integrate it with your
preferred methods for business change, software development, PMO and IT
operations.
PRINCE 2 could be used by a manager of a TOGAF ADM
cycle, as well as any implementation project that emerges from it.
ITIL can be tailored so as to include all of
TOGAF.
A different kind of process for establishing
enterprise architecture is outlined in “EA as Strategy” by Ross, Weill and
Robertson.
And it could be argued that an architect should
know about agile development methods like SCRUM and lean supply chain processes
like Kanban.
Enterprise architecture focuses on business roles and processes that are enabled and supported by digital information systems.
In 1986, the famous PRISM paper divided architecture into four primary domains: business, data, information systems and platform technologies.
If you take out the information system-related elements out of TOGAF, you don't have an architecture framework any longer.
So, while an architecture framework may feature the general techniques and products of any business change management process, such as:
· business case
· stakeholder management
· requirements management
· risk management
· project initiation document (statement of architecture work).
An architecture framework must also have features - techniques and products – that are more specific to architects, such as:
· business scenario-driven design
· structured analysis, functional decomposition
· data models and data dissemination views
· application integration design patterns and communication diagrams
· platform technology design patterns and documentation.
Today, TOGAF says enterprise architecture
documentation is considerably more abstract than solution architecture
documentation.
At the risk of over simplification, there can be a
three-level abstraction hierarchy.
·
A
software architect documents the structure and behaviour
of a software system - the products are used by software developers and
maintainers.
·
A
solution architect documents the structure and behaviour
of the wider business and IT system – for use by all with concerns about the
proposed system.
·
An
enterprise architect documents the business system portfolio for an additional
reason – for use by those who do governance and change impact analysis on the
whole portfolio.
Documentation schemes include templates for
documents and artefacts (catalogues, matrices and diagrams).
The artefacts show inter-related architectural
entities, and should be based on a coherent meta model
that shows how entities are related.
There are many similarities and overlaps between
documentation schemes such as:
·
TOGAF
part 4 - Content Framework - see TOGAF distilled at avancier.website.
·
DoDAF
- see DoDAF distilled at avancier.website.
·
The
Zachman Framework - see commentary at avancier.website.
·
See
also modelling languages below.
To use two of these together, efficiently, you’ll
need to collate and de-duplicate their elements.
TOGAF’s meta model is OK
as a starting point, though its artefact definitions are slight.
I doubt anybody would use the DoDAF meta model if they were not required to do so.
The Zachman Framework is attractive for appearing
simple; but simplistic might be a better word.
(Columns with two meanings might work, but rows
with three meanings is overloading too far.)
Avancier Methods were created to fill the gaps in the industry-recognised frameworks mentioned above.
Modelling languages give you symbols for
representing and relating architectural entities in diagrams.
Three modelling languages are referred to in
Avancier training courses:
·
IDEF
·
UML
·
ArchiMate
- see ArchiMate distilled at avancier.website.
IDEF is OK, but appears to have been overwhelmed
by UML and ArchiMate.
The fact that ArchiMate and UML share some symbols, and differ in
others, seems unwise.
ArchiMate is
considered more architect-friendly.
UML is a monster, but more thoroughly worked out than ArchiMate.
The Avancier web site includes a proposal for merging UML and ArchiMate.
In practice, people often abuse these modelling languages – perhaps more often than they use them.
Avancier papers explore ambiguities surrounding how symbols for “interfaces”, “services” and “functions” are used.
Reference models outlined in Avancier’s architect
training courses include:
·
APQC
for a generic commercial organisation
·
BIAN
for banking (one of many banking reference models)
·
TMF for
telecoms
o eTOM – Business Architecture
o SID – Data Architecture
o TAM – Applications Architecture
·
SCOR
for supply-chain businesses
·
ProAct for retailers
·
FEA
for US federal government
·
A
long list of industry-specific canonical data models
You might find a reference model that suits your
business.
You’ll have to tailor it to your needs, and budget
for maintenance thereafter.
TOGAF part 6 - “Reference models” - offers two
generic reference models.
Avancier Methods include more.
Enterprises out there are very differently organised, and it is hard to be prescriptive about where
architects fit.
Nevertheless, some architecture frameworks do
provide guidance.
TOGAF part 7 - “Capability Framework” - offers
guidance on architect roles and organisation models.
Avancier Methods include lengthy explorations of
the same.
You can merge different frameworks, languages and
reference models.
It is not difficult to do; some consultants and
systems integrators make their own methodologies this way.
However, the effort to educate a community in your merged product and maintain
that merged product is beyond many enterprises.
Avancier Methods form a comprehensive architecture
framework for enterprise and solution architects.
They were initially created to fill gaps in
industry-recognised frameworks of the kind mentioned
above.
So you will find Avancier Methods are easy to use along with whatever other frameworks you use.
The PRISM
paper’s division of architecture into four primary domains has stood
the test of time.
But its discussion of architecture scoping and levelling is weak.
Scoping (breadth, depth, time, cost, resources
etc.) of designs and plans is a big issue.
Levelling means describing enterprise,
solution and software architectures at different levels of detail.
The PRISM paper looked at things from an enterprise/executive level view.
It encouraged setting enterprise-wide principles and standards, to facilitate integration, reuse and agility.
(At the same time, Zachman was encouraging enterprise-wide system description.)
Enterprise architects define long-term targets for an enterprise's business processes, applications, and platform technologies.
The define enterprise-level road maps to reach these targets.
But there is a fact about such “road maps”
that is obscure in the PRISM paper.
It is in the nature of business that tactical solutions and silo systems must be developed and deployed.
The fact is: enterprise-level road maps can and often do cut across solution-level road maps.
The challenge is to progress the former while many solution architects are working to shape and steer specific systems and projects.
A solution to be designed and deployed needs a solution
architect - with or without any overarching EA.
Compliance of a solution with EA standards and
road maps can add to the time, cost or resources needed.
So even where EA standards and road maps are in place, some SA may occur outside of, or conflict with, the EA.
Both EA and SA should span the four domains; and their scope tends to differ in other ways explored elsewhere at avancier.website.
Copyright conditions
Creative Commons Attribution-No
Derivative Works Licence 2.0 28/10/2014 20:22
Attribution: You may copy, distribute and display this copyrighted work
only if you clearly credit “Avancier Limited: http://avancier.website”
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