Avancier Methods (AM): an introduction
This page is published under the terms of the licence summarized in the footnote.
“I have never seen such a thorough,
all encompassing, accessible and SENSIBLE statement of what it's about and how
to do it.” “Great content and methods.”
This paper introduces AM with links to pages that contain more detail.
The introduction is divided into 7 parts so as to match the document structure of TOGAF (though the content is different.)
AM is probably the most cohesive and coherent architecture framework in the public domain.
AM is comprehensive, approaching 100 papers and slide shows.
Most of AM is freely available for viewing by individuals online without a licence.
About 20% of AM is made available only to licence holders: read Why/how use AM? and Access and usage rights for more information.
Contents
3 Process guidelines and techniques
5 Architecture product repository
6 Architecture product reference models and patterns
7 People: the architecting organisation
An architecture describes the structure and behaviour of a system.
An enterprise is an organisation that shares goals and a budget; it is a business or part of a business that enterprise architects are sponsored to address.
AM for EA helps enterprise architects to treat the whole enterprise as a system, and manage changes to that system.
A solution is one or more systems designed in response to a declaration of specific problems and/or requirements.
AM for SA helps solution architects to design a solution, and govern its implementation.
AM divides architecture into broad views or domains, called business, information systems (data and applications) and technology.
These domains can be represented as hierarchical layers in which the components in a lower layer provide services to the components in the layer above.
Architecture
Domain |
Core Architectural Entities |
Business |
Business Services |
Business Functions, Roles, Actors |
|
Information Systems |
Use Cases, Automated Services |
Applications, Data Stores, Data Entities |
|
Infrastructure Technology |
Platform Services |
Platform Technologies |
AM promotes architect-led planning and governance.
You can use AM to record a baseline architecture, develop a target architecture to address problems and meet requirements for change.
Then plan and govern the transformation of systems from the baseline to the target.
The core of AM is the five-phase process outlined here AM process framework.
This is a generic method that can be adapted for any kind of transformation or change programme that involves information systems.
AM contains more by way of guidelines and techniques than other architecture frameworks.
Click on AM Product & Techniques for more documentation and modelling techniques.
The table below lists where you can find guidelines and techniques corresponding to those in TOGAF.
Guidelines and Techniques |
Find advice in |
Applying Iteration to AM |
|
Applying AM at Different Enterprise Levels |
|
Using AM to Define & Govern SOAs |
AM licence holders only |
Architecture Principles (inc. 80 principles) |
AM licence holders only |
Stakeholder Management |
|
Architecture Patterns |
AM licence holders only |
Business Scenarios |
|
Migration Planning Techniques |
|
Business Transformation Readiness Assessment |
|
Risk Management |
|
Capability-Based Planning |
AM encourages architects to document architectural assets and maintain this documentation.
It defines products (content or documentation) that architects may produce and maintain.
· Deliverables: contents lists for documents, which often contain
· Artefacts: tables and diagrams, which describe and relate
· Entities: discrete architectural entities such as business role, application and technology.
One architectural entity may appear in several artefacts. One artefact may appear in several architecture descriptions.
Meta model for an
architecture repository
AM is underpinned by two ideas:
These two ideas can be used to classify architectural entities in a grid, a kind of meta model, below.
Context |
Force
(Driver,
Mission, Vision) Directive
(Principle,
Policy, Rule) |
||
Requirements
and behaviour |
Logical
structure |
Physical
structure |
|
Business |
Aim (Goal,
Objective, Requirement) |
|
Location |
Business
Service |
Business
Function |
Organization
Unit |
|
Business
Process |
Role |
Actor |
|
Applications |
IS
Service (Use Case, Automated
Service) |
Application |
|
Data |
Data Entity |
Data
Store |
|
Technology |
Platform
Service |
Technology |
The grid suggests some horizontal and vertical relationships, and other relationships can be found in AM artefacts.
But you have to choose which entities, relationships and artefacts you believe to be worth recording in your situation..
It is wise to start with the simplest useful meta model; don’t elaborate it until you
· understand what it takes to maintain the minimal useful content,
· know what the data volumes will be, and
· have resources to maintain the model.
An enterprise architect may start with an Application Portfolio Catalogue, then map the Applications to other entities of interest.
Such as Business Functions/Capabilities, Platform Technologies, Data Stores and/or Data Entities.
A solution architect, when modelling one solution or a handful of applications, may well be more ambitious, for example:
· record finer-grained entities such as Use cases, Data Flows, Data Entities and Platform Services
· map Roles (and/or Business Process steps) to Use Cases (and/or Data Flows) to Applications
· map Applications to Platform Services to Technologies.
Note that Functions, Processes, Roles are different ways to group elementary activities.
People rarely model all three views to the same level of detail.
Architects are expected to store architecture documentation in a repository - using the enterprise’s knowledge management systems, tools and file stores.
Architects are expected to structure and index the repository for ease of access. The structure is divisible into sections.
Heading |
Repository
content |
Methodology |
Definition of processes, products, including a meta model |
Products |
Architecture model - architecture entities and artefacts Architecture deliverables |
Reference |
Reference models: common structures and patterns Standards: open standards, local standards etc. |
People |
Organisation: roles, skills, training needs etc. |
Work |
Projects, assignments, assessments, decisions, calendar |
An architecture repository contains many architecture deliverables, artefacts and entities. How to find an artefact or architectural entity you are looking for? There are many ways to classify artefacts and entities. Two-dimensional classification schemes like the ones below suggest some indexes for filing elements of documentation.
Indexes to TOGAF’s
Enterprise Continuum |
|
Indexes to the Zachman
Framework |
|
Change Planning
Framework |
||||||||||||||||||
Generalisation Idealisation |
Universal |
Common |
Shared |
Unique |
x x
|
Question Idealisation |
What |
How |
Where |
Who |
When |
Why |
x |
Time Level of detail |
Baseline |
Year 1 |
Year 2 |
Target |
||||
Contextual |
|
|
|
|
|
Contextual |
|
|
|
|
|
|
|
Strategy |
|
|||||||
Conceptual/logical |
|
|
|
|
|
Conceptual/logical |
|
|
|
|
|
|
|
Programme |
|
|
||||||
Physical |
|
|
|
|
|
Physical |
|
|
|
|
|
|
|
Project |
|
|
|
|
||||
Real |
|
|
|
|
|
Real |
|
|
|
|
|
|
|
Work package |
|
|
|
|
|
|
|
|
A reference model is a generalized structure (of components, data entities, processes or services) that can be used as starter or template for more specific models.
AM mentions a variety of industry reference models. AM itself offers some generic design patterns.
Domain |
Example Reference Models and
Patterns |
Business |
APQC, SCOR, ProAct, etc. |
Data |
Various industry data models |
Applications |
Database consolidation Physical master data management Virtual master data management Etc. |
Technology |
2,3,4 tier architecture patterns Disaster recovery patterns |
Avancier Products
and Techniques includes advice on the organisation and roles of the
enterprise architecture team.
Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0
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