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

1 Introduction. 1

2 Process. 2

3 Process guidelines and techniques. 2

4 Architecture products. 3

5 Architecture product repository. 4

6 Architecture product reference models and patterns. 5

7 People: the architecting organisation. 5

 

1 Introduction

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

 

2 Process

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.

3 Process guidelines and techniques

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

Define architecture processes

Applying AM at Different Enterprise Levels

Define architecture processes

Using AM to Define & Govern SOAs

AM licence holders only

Architecture Principles (inc. 80 principles)

AM licence holders only

Stakeholder Management

Manage stakeholders

Architecture Patterns

AM licence holders only

Business Scenarios

Design business solution

Migration Planning Techniques

Plan phase overview

Business Transformation Readiness Assessment

Manage readiness and risks

Risk Management

Manage readiness and risks

Capability-Based Planning

Capability based planning

 

4 Architecture products

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.

AM Products and Techniques.

5 Architecture product repository

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

 

 

 

 

 

 

 

 

6 Architecture product reference models and patterns

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

7 People: the architecting organisation

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