This page is published under the terms of the licence summarized in the footnote.
This paper discusses the processes of TOGAF, divided into two groups – the development half and the management half.
The table below shows the
clockwise cycle of ADM in shape that separates the first development half of
the cycle from the second management half.
|
Management phases |
Continuous phase |
Development phases |
|
|
|
Preliminary phase: Architecture
framework and principles |
|
H Architecture Change Management |
Requirements Management |
A Architecture Vision |
|
G Implementation Governance |
B Business Architecture |
|
|
F Migration Planning |
C Information System Architecture |
|
|
E Opportunities and Solutions |
D Technology Architecture |
Q) Can we use TOGAF for solution architecture as well as enterprise architecture?
A) Yes, but doing solution architecture for an enterprise differs from doing enterprise architecture. See the final section of this paper for discussion of this.
The first two TOGAF phases are about initiating an enterprise architecture development cycle.
Inputs: ADM and Other architecture framework(s), Business strategy, business principles, business goals, and business drivers, IT governance strategy, Architecture principles, Principles that are being subscribed to, arising from other, federated architectures
Outputs: Framework definition: process and tools, Architecture principles. Restatement of, or reference to, business principles, business goals, and business drivers and governance structures
Your customized version of TOGAF
You’ll have good reasons to customise TOGAF. You’ll have to align TOGAF with methods for IT governance (COBIT), IT service management (ITIL) and programme/project management. You’ll have to align methods used by enterprise and suppliers. Remember that essential for engaging management are phase A: Vision and phase B: Business architecture.
Your agreed principles
Architecture principles usually relate to goals of the business and/or IT function. They can be regarded as requirements for or constraints on architecture development. A principle should be simple, brief, stable guidance. It should be choice reducer/simplifier and conflict reducer/resolver. Conflicts between principles must be made explicit and the trade offs explained. An enterprise’s architecture typically has around 20 principles, and mostly shared by many enterprises. TOGAF doesn't prescribe your architecture principles. It gives you 20 (ex USAF) principles to start from. It gives you a template for defining principles (Name, Description, Rationale, Implications).
Your governance structure
Governance requires three things:
TOGAF points put that governance can be subdivided into three areas:
The aim of phase A is to clarify scope and engage stakeholders.
Inputs: Request for Architecture Work, Enterprise Continuum (models and building blocks), Business strategy, business goals, and business drivers, Architecture principles, Existing architectural documentation (framework description, architectural descriptions, existing baseline descriptions, etc.)
Outputs: Refined statements of inputs, Architecture Vision, Business Scenarios, Approved Statement of Architecture Work.
Phase A starts with a request for work and ends with an approved statement of work. This statement of architecture work contains or refers to an architecture vision, aka architecture v0.1, aka conceptual framework. TOGAF recommends the architecture vision is described using business scenarios.
Q) Why does TOGAF devote so much space to Business Scenarios?
A) Remember the driver is Business-IT alignment. TOGAF 7 authors employed "Business Scenarios" as a means of capturing business requirements and relating IT to it.
Q) Why aren't other analysis and design techniques (e.g. requirements cataloguing, data modelling) described?
A) Other techniques are taken for granted. Perhaps there was less industry recognition of Business Scenarios, so it had to be described within TOGAF itself?
Q) Why are there no true Business Scenarios among the Open Group examples on the CD?
A) Partly because nobody will submit real examples for publication. And partly because the examples do successfully illustrate how the Business Scenarios template provides a good structure for presenting generic technology architecture descriptions.
Q) Surely Business Scenarios is problem/solution-specific analysis and design technique?
A) True. However, some businesses are based on a single end-to-end business process. And see previous Q and A.
Q) Should procurement specialists be engaged in phase A?
A) Yes, they are stakeholders and their policies may constrain technology choice. Note however that a raison d’être of the Open Group and TOGAF is to promote vendor/technology-neutral specifications and decisions. And ADM promotes three sequences: Business before Technology; Logical before Physical; High-level before Detail. So procurement decisions are postponed until a complete logical rationale has been documented.
The next three phases of ADM are about documenting the baseline architecture, and developing a target enterprise architecture. These three phases repeat what is essentially the same process for each of the four architecture domains. This table summarises the generic architecture description process used in phases B, C and D.
|
Generalised Architecture Development
Process |
Notes |
|
1. Develop Baseline Architecture
Description |
|
|
Develop a Baseline Architecture Description, to the extent necessary to support the Target Architecture. |
|
|
Identify and document candidate Architecture Building Blocks (potential re-usable assets). |
Reuse |
|
2. Review and select assets from the |
|
|
i. Select relevant resources (principles, reference models, patterns) from the Architecture Continuum, on the basis of the requirements, stakeholders and their concerns. |
Reuse |
|
ii. Select architecture viewpoints (e.g., Operations, Management, Financial) that enable the architect to demonstrate how stakeholder concerns are being addressed. |
Reuse |
|
iii. Identify tools and techniques for capture, modeling, and analysis, in association with the selected viewpoints. These may comprise simple documents or spreadsheets, or more sophisticated modeling tools and techniques such as activity models, business process models, use-case models, etc. |
Reuse |
|
3. Create Architecture Model(s) |
Start the models that will be completed in the following steps. |
|
i. For each viewpoint, create the specific view required, using the selected tool or method. |
|
|
ii. Assure all stakeholder concerns are covered. If not, create new models or augment existing models. |
Validate completeness |
|
iii. Ensure all information requirements in the Architecture are met. |
Validate availability of data for each function/application/technology. |
|
iv. Perform trade-off analysis to resolve conflicts (if any) among the different views. |
The SEI technique compares options, not views |
|
v. Validate the models support the principles, objectives, and constraints. |
Validate fitness |
|
vi. Note changes to the viewpoint represented in the selected models from the Architecture Continuum, and document. |
Reuse |
|
vii. Test architecture models for completeness against requirements. |
Validate completeness |
|
4. |
|
|
i. Identify required building blocks and check against existing library of building blocks, re-using as appropriate. |
Reuse |
|
ii. Where necessary, define new Architecture Building Blocks. |
An ABB ‘encapsulate’ the provision of closely-related required services |
|
5. Conduct Formal Checkpoint Review of
Architecture Model and Building Blocks with Stakeholders |
|
|
Conduct a formal checkpoint review of the architecture model and building blocks with stakeholders, validating that business goals are met. |
Validate fitness |
|
6. Review Non-Functional (Qualitative)
Criteria |
|
|
Review the qualitative criteria (NFRs), providing as many measurable criteria as possible. |
E.g. throughput, availability, costs |
|
Use to specify required service, perhaps via formal Service Level Agreements (SLAs)). |
|
|
7. Complete Architecture |
|
|
i. Select standards for each of the Architecture Building Blocks, re-using as much as possible from the reference models selected from the Architecture Continuum. |
Reuse |
|
ii. Fully document each Architecture Building Block. |
|
|
iii. Final cross-check of overall architecture against business goals. Document rationale for building block decisions in the architecture document. |
Validate fitness |
|
iv. Document final requirements traceability report. |
|
|
v. Document final mapping of the architecture within the Architecture Continuum. From the selected Architecture Building Blocks, identify those that might be re-used (working practices, roles, business relationships, job descriptions, etc.), and publish via the architecture repository. |
Reuse |
|
vi. Document rationale for building block decisions in the Architecture description document. |
|
|
vii. Prepare the Architecture Report, comprising some or all of the views and models. |
|
|
viii. Checkpoint: check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Architecture, asking if it is fit for the purpose of supporting subsequent work in the other architecture domains. Refine the proposed Architecture only if necessary. |
Validate fitness. Also define any impacts of your target architecture on work already done and to be done. |
|
8. Perform Gap Analysis and Create
Report |
|
|
i. Create gap matrix |
Document baseline v target |
|
ii. Identify building blocks to be carried over, classifying as either changed or unchanged. |
To be reused |
|
iii. Identify eliminated building blocks. |
To be decommissioned |
|
iv. Identify new building blocks. |
|
|
v. Identify gaps and classify as those that should be developed and those that should be procured. |
To be built or bought |
|
|
|
|
Statement of Architecture Work, updated if necessary |
|
|
Validated Architecture Principles, business goals, and strategic drivers |
|
|
Target Architecture, Version 1.0 (detailed) |
|
|
Baseline Architecture, Version 1.0 (detailed), if appropriate |
|
|
Gap analysis results |
|
|
Architecture Report |
|
|
Updated business requirements |
|
|
Updated technical requirements |
|
Inputs: everything produced so far.
Outputs: refined versions of the inputs plus business architecture models and report.
Process: as generic process above.
Q) Who does the work to define business goals, organisations, functions, processes, roles?
A) Usually people called systems analysts, business analysts, business management consultants or business architects. These people must be engaged closely with the enterprise architects, and ideally work in the same team.
Inputs: everything produced so far.
Outputs: refined versions of the inputs plus data architecture models and report.
Process: as generic process above.
Inputs: everything produced so far.
Outputs: refined versions of the inputs plus applications architecture models and report.
Process: as generic process above.
Q) How detailed should an applications architecture description be?
A) TOGAF is for enterprise architects. The principal building blocks are business functions, applications and technologies. The TOGAF illustration of application Building Blocks is coarse-grained. TOGAF provides templates for applications and technologies, but not for software components and services. It is possible to use TOGAF at lower levels of granularity and detail, but you'll have to adapt it, because TOGAF is not written for software architects or infrastructure configurers. Other approaches (like RM-ODP) are designed for detailed software design.
Inputs: everything produced so far.
Outputs: refined versions of the inputs plus technology architecture models and report.
Process: mostly as the generic process above.
Of all TOGAF phases, this one is the most idealised and difficult to understand. One reason is that the essence of TOGAF 7 appears - largely unchanged - as phase D in TOGAF 8. TOGAF 7 focused on technology architecture – mapped directly to business goals and strategy. Phase D was not rewritten as far as it might have been in the light of an Applications Architecture and/or service-oriented architecture.
Step 1 to create a Baseline Description in the TOGAF
format.
You might have started in phase A by populating the Enterprise Continuums’ Foundation Architecture with TOGAF TRM and Open Group SIB. The TOGAF TRM defines services provided by a typical application platform rather than yours. So in step 1, you “Begin by converting the description of the existing environment into the terms of your organization's Foundation Architecture (e.g. the TOGAF TRM).” This process of reverse engineering from the baseline technology SBBs must modify the TOGAF TRM to become our own organisation’s baseline TRM. This baseline TRM is a logical/idealised/rationalised/normalised definition of the services provided by our current application platform. (You can now discard TOGAF TRM headings and entries not used in the baseline TRM.)
You also engage here in “conceptualization of target ABBs” unencumbered by the irrational choice and structure of baseline SBBs, except for where you are obliged to carry some forward. It is however foolish to name some target ABBs without consideration of services our target applications require, which comes next.
Step 2 to identify
reusable stuff
Step 3 to create an architectural model of building
blocks.
“Changes and amendments to the TOGAF TRM should be made to create an organization-specific TRM” Thus, the TRM changes again, to define the services required from our new application platform, our target technology SBBs. You can proceed with a TRM that spans both baseline and target architectures.
Step 4 to select the services portfolio required per
building block.
The assumption here is one ABB has only one service portfolio and vice-versa.
Q). What do the words "function", "service" and "interface" mean?
A) The description of phase D suffers from the fact that words function, system function, business function, functionality, service, service portfolio, interface are used (as throughout the IT industry) in overlapping ways that confuse readers. In TOGAF7, and phase D of TOGAF 8, the words seem to be used thus:
Steps 5 and 6 are review and validation steps
Step 7 to complete the architecture definition
You iteratively manipulate the ABBs to become SBBs, which are classified as to be “developed, re-used, and procured”, in the light of:
These ABBs and SBBs include the Application BBs as well as the Technology BBs.
Q) Does the specification of a newly-required SBB become a vendor-product-version-specific in phase D?
A) ADM encourages vendor-product-version-specific decisions to be made at the latest reasonable point – in phase D or E. Though it also allows that technology choices may be constrained, made or standardised much earlier, perhaps even in a previous cycle of ADM. Remember The Clinger-Cohen act and the like guided IT directors and CIOs to:
Q) Is a newly-required SBB purchased in phase D?
A) No, because a) different SBBs (opportunities) may be identified and selected during phase E. And b) SBB acquisition is best timed to occur in the sequence required by the migration path defined in phase F. The procurement department are best engaged to procure SBBs in phase G.
We turn now to the
second, management, half of ADM.
|
Management phases |
Continuous phase |
Development
phases |
|
|
|
Preliminary
phase: Architecture framework and principles |
|
H Architecture Change Management |
Requirements Management |
A Architecture
Vision |
|
G Implementation Governance |
B Business
Architecture |
|
|
F Migration Planning |
C Information
System Architecture |
|
|
E Opportunities and Solutions |
D Technology
Architecture |
TOGAF is wisely slight in these phases. It says enough that you know what needs to be done by way if planning, governance, change and requirements management. It does not set out to compete with established management methods. It expects your PMO and ITSM organisations to be using MSP, PRINCE2 , PMI, ITIL or whatever. It expects you to integrate the activities of phases E to H into those methods.
TOGAF phases E and F are about planning the work to implement a target enterprise architecture. Phase D concludes with a report of the gap between the baseline architecture and the target architecture. Phases E and F plan the work to migrate from baseline to target. The architect’s role in planning is to:
“The objective is to evaluate and select among the implementation options identified in the development of the various Target Architectures (for example, build versus buy versus re-use options, and sub-options within those major options)”
The process involves:
The process is to plan projects to move the enterprise from the baseline architecture to the target architecture:
Note that the next phase, more project details are defined, including: name, objectives, measures of effectiveness, acceptance criteria, risks and issues.
TOGAF features governance at two levels.
Governance processes must be based on-going compliance reviews to
Remember that governance, change management and requirements management processes are closely related.
Q) Why is this called Implementation Governance rather than Implementation?
A) Because phase G describes only the role the enterprise architect plays in implementation. Implementation itself is composed of projects led by the PMO.
The last two TOGAF phases are about identifying and managing the requirements that drive an enterprise architecture development cycle.
What is presented in TOGAF as the last phase, may in fact be the origin of the request to start up an enterprise architecture development. This usually emerges from a significant change in the business or its management structure. In any case change management must be in place from day 1, otherwise the enterprise architecture development team may be kept in the dark about significant business or technical changes affecting the enterprise (this has been known).
Business, political and technology changes are inevitable. Change management is necessary, and it requires three things:
The change management process should include,
TOGAF speaks of change management at two levels.
There must be an Architecture Board (or other governing council) to decide on handling technology and business changes.
In phase H, TOGAF tells you to establish a process for the management of changes to the new enterprise architecture baseline that is achieved with completion of phase G. And it gives you some pointers to remember.
Remember that governance, change management and requirements management processes are closely related. TOGAF is not a quality management system contained detailed management processes, and phase H is not about managing all changes to everything – only those changes affecting the enterprise architecture.
Q) Why is the objective to establish a change management process? rather than execute one?
A) Phase H addresses changes to the system(s) implemented by
phase G. All implemented systems should be placed under change management. But
enterprise architects are rarely in charge of systems change management.
Systems change management comes under IT service management, and is in the
This implies that the ITSM organisation reports changes which require enterprise architecture Change Management to the architecture governance board. (Another plausible answer is to completely merge architecture governance into IT governance and the architecture board into the IT board.)
Q) How do we correct past irrational and costly technology procurement decisions?
A) Establish a change management process. Establish the authority of the architecture board. Identify a better technology or solution and treat it as an event triggering a change request.
The requirements management phase in TOGAF is ongoing throughout the ADM cycle. It can be viewed as the change management process for architecture description, whereas phase H is the change management process for the implemented systems.
TOGAF is not a quality management system containing detailed requirements capture and management processes. The requirements management process is not about managing all application-level requirements – only those for the enterprise architecture.
enterprise architecture must be done in response to requirements.
Requirements management is necessary, and it requires three things:
TOGAF tells you to establish a process for the capture and management of requirements. The process must
TOGAF outlines a ten step process for requirements management..
Requirements go through iterations until the final version includes the full implications of the requirements (e.g., costs, timescales, business metrics) on the architecture development.
Remember that governance, change management and requirements management processes are closely related.
FAQS
Q) Does this record all requirements, and process all change requests?
A) No, only those which relate to the enterprise architecture.
Q) Why is the RM process so convoluted?
A) Because it spans three time periods
And two levels of impact analysis:
Q) Do Business requirements include Business goals and objectives?
A) Yes.
Q) How can we revisit a phase that has been completed and signed off?
A) We can't. Read that as meaning you revisit the deliverables of the phase.
Yes, but doing solution architecture for an enterprise
differs from doing enterprise architecture.
ADM is the process defined in TOFAF for one enterprise
architecture cycle. ADM can also be used as a process for a very narrow solution
architecture. So the ADM cycle can be separated from the enterprise
architecture cycle, and one enterprise may find itself conduct many ADM cycles
in parallel. In short:
1) The organisation scope for an enterprise architecture
cycle is limited by sponsorship
An enterprise architecture cycle should help an organisation
to rationalise its systems and coordinate its projects, through compliance to a
single coherent enterprise architecture. The aim is to help an organisation to develop
and implement a cross-organisational strategy. This effort requires sponsorship and support from
the top-level “directors” of the organisation. Director-level sponsorship is so
important that the scope is best limited to that level of organisation in which
top-level sponsorship can be established.
Using ADM for an enterprise architecture cycle, the preliminary
phase is where you define the scope of the organisation for which a cycle will
be completed, and an enterprise architecture description will be maintained.
2) One enterprise architecture cycle should end before
the next starts
An organisation’s architecture board should manage one enterprise architecture cycle at a time. It cannot realistically govern several enterprise architecture visions, boards, principle lists, requirement catalogues and architecture repositories.
Using ADM for an enterprise architecture cycle, phase A
defines the focus and timescales of the next cycle. One enterprise architecture
cycle should reach the end of phase F (or be aborted) before you start on the
next phase A.
3) One enterprise architecture cycle may involve parallel
phases and threads.
After phase A of ADM, phases B to F may overlap, and one enterprise
architecture cycle may divide into parallel threads that proceed from phase B
to phase F at different speeds.
4) At a higher-level, an organisation can set only
overarching guidance
You cannot realistically hope to complete an enterprise
architecture cycle for the whole of the large government department, or global
petro-chemical company. The most you can do at the top level is set some generic
principles and standards, maintain some reference models and encourage compliance
to those. You will have to maintain these generalisations on a continuous
basis, rather than follow successive enterprise architecture cycles.
5) At a lower-level, an organisation can execute parallel
solution architecture cycles
An enterprise architecture cycle relates more programme management than project management. But you may adapt ADM to tackle a single problem, and use it in each of several overlapping solution development projects. So ADM can be used as a project management framework as well. And service providers may use ADM in developing a solution architecture for an organisation. That’s fine, provided you realise that these solution architecture cycles should be subordinate to a more strategic enterprise architecture cycle (or else ruled out of its scope).
Ref 1: other papers at http://avancier.co.uk
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