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.
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:
Following figure describes relationship between deliverables, artefacts and building blocks.
http://www.opengroup.org/architecture/togaf9-doc/arch/Figures/02_concepts1.png
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
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
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.
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 |
|
|
|
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.
This is the main output (deliverables) of Preliminary Phase, this documents typically includes:
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
Principle catalog (list of architecture principles) is the only artefacts generated in this phase.
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 |
|
|
|
Followings must be known in order to determine overall scope of architecture activities:
Statement of Architecture work is created in response of Request for Architecture work. This document typically includes:
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:
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]
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
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]