Togaf Simplified
If you read the Togaf 9.2 standard it is easy to realize that a lot of information is there. Start with something simple, at least for me, helps me to improve my understanding. So, I decided to share with you a simplified vision of Togaf to give you an introductory vision of Togaf Enterprise Architecture Development Method (ADM).
I will use 2 approaches to describe a personal and simplified vision of Togaf. The first approach is related to the way the phases can be grouped, according picture below.
Togaf can be grouped in 4 main categories where Scope determines what needs to be created regarding the company and business goals. Architecture Work uses the selected domains and phases to creates all architecture work. Delivery planning try to answer the question: what is the best approach to implement the architecture documented? Control category focus on how to control the implementation of architecture and changes needed to achieve company goals.
The second approach is based on a simplified view of main inputs and outputs according picture below.
In the Preliminary phase the Organization Model for Enterprise Architecture includes Maturity assessment, gaps, resolution approach, Roles and responsibilities for architecture team(s), Constraints on architecture work, Budget requirements, Governance and support strategy that brings general information to establish a good architecture governance that will need to use an enterprise repository. Optionally a Request for Architecture Work can be sumitted at this phase.
Request for Architecture Work is a non-architectural deliverable sent from sponsoring organization to trigger the start of an architecture development cycle (Phase A - Architecture Vision). Phase A creates a high-level aspirational vision of what will be delivered and produces the Statement for Architecture Work approved which has an overview of Architecture Vision. Now with all scope defined, budget approved, architecture framework adjusted and team assembled, let’s start the architecture work.
Phases B, C and D use the architecture domains (Business, Application, Data and Technology — Yes, Business and Technology uses the same name for the domain and phase) to produce the Architecture Definition Document(ADD) and Architecture Requirements Specification(ARS). If you need a qualitative information about architecture, you will use the ADD. For quantitative information (think about metrics in this case or criteria that must be met during the implementation of the architecture), refers to the ARS. These two documents encompass the gap analysis results and the details of the baseline and target architectures.
Opportunities and Solutions will refer to the ADD and ARS to create an Architecture Roadmap and introduce the concept of Transition Architecture which goal is to deliver on a specific part of the time the partial benefit of architecture.
Migration Planning focuses on the stakeholder envolviment to get a final Migration and Implementation Plan. I said final because a draft of Migration and Implementation Plan is created in Phase E. At this point the analysis of cost x benefit, gathering of values and return of investment are considered. The architecture team will give the strategic direction to all planners to conceive the detailed plan.
Solution Building Block (SBB) effectively appears firstly in Phase E but SBB is the main goal of Implementation Governance. An architecture contract will be celebrated on phase G and the work of development partner will be inspected through compliance assessments according and criteria established initially in ARS.
Adjusts to the process and other changes can appear during project execution. Request for Architecture Work will be raised to fix the problems and initiate a new cycle of architecture. From now on the completeness of Togaf 9.2 Standard will give all contexts for future iterations.
If you are curious about Requirements Management and why I didn’t write something about it, you can read my article The Logic Behind a Togaf Repository.
In summary, this article removes a lot of “pollution” that appears in the Togaf 9.2 Standard due to much information available. See that this is not a critic because a complete documentation is good for reference. However, when you are introduced to a subject, it is important to evolute according the knowledge accrued.
I hope this article helped you and I wish you a nice week :)