In my TOGAF learning series – Part 1: Introduction to TOGAF of TOGAF learning series I introduced Enterprise Architecture and TOGAF, objective of this blog series is to explain TOGAF concepts in brief and precise manner for beginners. This blog series will give you good overview and concepts of TOGAF and also provides right pointers for further study.
These blogs will not go into too much detail as TOGAF concepts are very well explained in TOGAF documentation which is available online for free. My purpose is to give you good start and then direct you to right resource for in-depth learning.
You can treat these blogs as short notes which help you to revisit topics quickly.
TOGAF Learning series will cover:
- TOGAF learning series – Part 1: Introduction to TOGAF
- Architecture Context (this blog)
- Architecture Development
- Transition Planning
- Architecture Deployment
- Architecture Content Framework
- Reference Models
Key concepts
Before we explore TOGAF further, you must go through TOGAF core concepts and definitions which will be base for further learning.
TOGAF work products are classified into three:
- Deliverables: formally agreed work products, are reviewed and signed off by stakeholders.
- Artefacts: more granular deliverables which represents specific view point (specific viewpoint is key here). Artefacts are further divided into three categories:
- o Catalogs: list of things (i.e. application catalogs)
- o Matrices: relationship of things (i.e. application interaction matrix).
- o Diagram: picture of things (i.e. Process flow diagram, Use case diagram)
- Building blocks: these are reusable architectural components which can be combined together to deliver architecture and solutions, Building blocks are further divided into two categories:
- o Architecture building blocks (ABB): vendor and technology neutral building blocks which represent architectural capability (i.e. Sales Order Management system).
- o Solution building blocks (SBB): represent components which implements specifications of ABB. SBBs are technology and vendor aware (i.e. SAP SD).
- o Relationship between ABB and SBB: ABB guides development of SBB and SBB supports ABB.
Following figure describes relationship between deliverables, artefacts and building blocks.
http://www.opengroup.org/architecture/togaf9-doc/arch/Figures/02_concepts1.png
Architecture Repository
Architecture repository is enterprise wide repository to store architectural output and work products.
http://www.opengroup.org/architecture/togaf9-doc/arch/Figures/02_concepts3.png
Components of Architecture Repository [source TOGAF 9]:
- Architecture Metamodel: tailored architecture framework, including metamodel for architecture content.
- Architecture Landscape: Current state of building blocks that are used in organization today.
- Reference Library: repository of best practices, guidelines, template etc.
- Standard Information Base: standards with which architecture must comply.
- Governance log: record of governance activity
- Architectural capability: define the parameters, structure and processes that support governance of architecture repository.
Enterprise Continuum
Enterprise continuum is a view of repository in different timelines during the evolution of Architecture, it represent development of architecture from generic to specific view.
http://www.opengroup.org/architecture/togaf9-doc/arch/Figures/39_entcon_oview.png
Core concepts in detail are available here: http://www.opengroup.org/architecture/togaf9-doc/arch/chap02.htm
Phases of Architecture Development
For sake of this learning series I divided ADM phases in group as per following:
Group Name | Core Phases |
Architecture Context | Phase Preliminary and Phase A (architecture vision) - Focus of this blog |
Architecture Definition | Phase B->Phase C->Phase D |
Transition Planning | Phase E and F |
Architecture Governance | Phase G and H |
These groups are derived from iteration of ADM. I'll cover iteration in detail in another blog.
In order to simplify learning of these phases I'll only be listing key inputs, key steps and key outputs.
Preliminary Phase:
Key objective of preliminary phase is to prepare to execute Architecture Development Method for first time. In this phase 6 questions are answered: "where, what, why, who, and how we do architecture".
Key Input | Key Steps | Key Output |
|
|
|
Scoping of Organization:
Core: organization directly affected by Architectural activities
Soft: Not directly affected but see changes in operations due to interaction with core enterprise.
Extended: outside the scope of Enterprise and not affected.
Request for Architecture Work
This is the main output (deliverables) of Preliminary Phase, this documents typically includes:
- Organization sponsors
- Organization mission statement
- Business goals
- Strategic plans of the business
- Organizational and business constraints
- Budget and financial constraints
- Current business system description
- Current architecture/IT system description
- Description of developing organization
- Availability of resources
Guidelines and Techniques
Architecture Principles:
TOGAF defined principles as "Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission".
Architecture principles typically defined by Enterprise Architect with support from CIO, Architecture Board and key business stakeholders, Architecture principles should be traced back to business objective and they are key drivers for architectural activities. These Principles also represent consensus among the different elements of the enterprise and form the basis for making future IT decisions.
TOGAF recommends following template for defining architecture principles:
Name | Should both represent the essence of the rule as well as be easy to remember. Specific technology platforms should not be mentioned in the name or statement of a principle. Avoid ambiguous words in the Name and in the Statement such as: "support", "open", "consider", and for lack of good measure the word "avoid", itself, be careful with "manage(ment)", and look for unnecessary adjectives and adverbs (fluff). |
Statement | Should succinctly and unambiguously communicate the fundamental rule. For the most part, the principles statements for managing information are similar from one organization to the next. It is vital that the principles statement be unambiguous. |
Rationale | Should highlight the business benefits of adhering to the principle, using business terminology. Point to the similarity of information and technology principles to the principles governing business operations. Also describe the relationship to other principles, and the intentions regarding a balanced interpretation. Describe situations where one principle would be given precedence or carry more weight than another for making a decision. |
Implications | Should highlight the requirements, both for the business and IT, for carrying out the principle - in terms of resources, costs, and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The impact to the business and consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to: "How does this affect me?" It is important not to oversimplify, trivialize, or judge the merit of the impact. Some of the implications will be identified as potential impacts only, and may be speculative rather than fully analyzed |
[Source: TOGAF 9: Architecture Principles]
Detail on Architecture principles and some sample principles are available here: http://www.opengroup.org/architecture/togaf9-doc/arch/chap23.html
Artefacts
Principle catalog (list of architecture principles) is the only artefacts generated in this phase.
Key Learning Points:
- Architecture Principles are developed in this phase.
- Architecture principles are stable.
- Architecture Framework is tailored for this particular iteration of ADM.
- Request for Architecture work is the key output which will trigger next phase (Architecture Vision).
Architecture Vision:
Architecture vision phase is initial phase of ADM and it starts after receiving "Request for Architecture work" from sponsoring organization to Architecture organization. This phase is concerned with defining scope of architectural activities, identifying stakeholders, developing architecture vision and seeking formal approval.
Key Input | Key Steps | Key Output |
|
|
|
Define Scope
Followings must be known in order to determine overall scope of architecture activities:
- Scope of Enterprise covered
- Coverage of Architecture domain: whether to include all domains or restricted to few.
- The level of details: how much vertical depth should be covered in architectural activities.
- Time period available
Statement of Architecture Work
Statement of Architecture work is created in response of Request for Architecture work. This document typically includes:
- Scope and constraints
- Plan for Architecture work
- Roles and responsibilities
- Risks and mitigation activity
- Work product performance assessments
- Business case and KPI metrics.
Architecture Vision
Architecture Vision is the guiding document for development of Business, Information System and Technology architecture, "business scenarios" is technique used to discover and document business requirements.
An architecture vision document typically contains:
- Refined key high-level stakeholder requirements
- Baseline Architecture, version 0.1 (Business, Technology, Data and Technology domain)
- Target Architecture, version 0.1 (Business, Technology, Data and Technology domain)
Guidelines and Techniques
Stakeholder management
Identifying and managing stakeholder contributes significantly in success or failure of projects. Input from stakeholders helps to improve quality of model produced, and successful stakeholder engagement can results more resources, active participation and management of expectations.
It is essential in any initiative to identify the individuals and groups within the organization who will contribute to the development of the architecture, identify those that will gain and those that will lose from its introduction, and then develop a strategy for dealing with them [TOGAF 9: Stakeholder Management]
Steps of stakeholder management:
Identify stakeholders: identify the key stakeholder of the enterprise architecture by asking and exploring series of questions.
Classify stakeholder positions: classify stakeholder and assess power and interest of each stakeholder (use template below).
Determine management approach: using stakeholder power Grid (see figure below)
http://www.opengroup.org/architecture/togaf9-doc/arch/Figures/24_stakeholder_grid.png
Tailor engagement deliverables: see "stakeholder matrix" example in next section (Artefacts).
More on Stakeholder Management http://www.opengroup.org/architecture/togaf9-doc/arch/chap24.html
Artefacts
Architecture vision phase produce 3 artefacts (2 diagrams and 1 matrix):
Solution Concept diagram: high level representation of the solution, a rough pencil sketch of expected solution.
Value Chain diagram: value chain is powerful analysis tool for strategic planning.
Stakeholder matrix:
Stakeholder | Involvement | Class | Relevant Viewpoints |
CxO | This stakeholder group is interested in the high-level drivers, goals, and objectives of the organization, and how these are translated into an effective process and IT architecture to advance the business. | KEEP SATISFIED | Business Footprint Goal/Objective/ Service Model Organization Chart |
Program Management Office | This stakeholder group is interested in prioritizing, funding, and aligning change activity. An understanding of project content and technical dependencies between projects adds a further dimension of richness to portfolio management decision-making. | KEEP SATISFIED | Roadmaps Business Footprint Application Communication Functional Decomposition |
Procurement | Major concerns for these stakeholders are understanding what building blocks of the architecture can be bought, and what constraints (or rules) exist that are relevant to the purchase. The acquirer will shop with multiple vendors looking for the best cost solution while adhering to the constraints (or rules) applied by the architecture, such as standards. The key concern is to make purchasing decisions that fit the architecture, and thereby to reduce the risk of added costs arising from non-compliant components. | KEY PLAYERS | Cost View Standards View |
[Source: TOGAF 9: Stakeholder Management]
Key Learning Points:
- Architecture vision is the key output of this phase which guides development of Business, Application, Data and Technical Architecture.
- Business transformation readiness is key step of Phase A.
- "Business Scenario" is the technique used in this phase to identify business requirements; this technique is also used in Phase B: Business Architecture.
- Stakeholder Management technique is used in Architecture Vision phase.
References:
- TOGAF definitions: http://www.opengroup.org/architecture/togaf9-doc/arch/chap03.html
- TOGAF core concepts: : http://www.opengroup.org/architecture/togaf9-doc/arch/chap02.htm
- Applying Iteration to the ADM : http://www.opengroup.org/architecture/togaf9-doc/arch/chap19.html
- Preliminary Phase: http://www.opengroup.org/architecture/togaf9-doc/arch/chap06.html
- Architecture Principles: http://www.opengroup.org/architecture/togaf9-doc/arch/chap23.html
- Architecture Vision: http://www.opengroup.org/architecture/togaf9-doc/arch/chap07.html
- Stakeholder Management: http://www.opengroup.org/architecture/togaf9-doc/arch/chap24.html
- Architecture deliverables: http://www.opengroup.org/architecture/togaf9-doc/arch/chap36.html
1 Comment
