What makes an architecture framework?
This page is published under the terms of the licence summarized in the footnote.
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.
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:
· 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.
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.
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