Aligning Agile with TOGAF EA framework

This is a continuation of my series on aligning EA with Agile/Scrum frameworks. The first chapter of this series could be found at Aligning Agile with Zachman EA framework. In the sections below I am trying to showcase one of countless possible ways to align TOGAF with Agile/Scrum - with objective of trying to showcase the flexibility and adaptability of EA frameworks and applicability to the modern enterprises.

Again, as a disclaimer from previous chapter in the series - without getting into religious debate about whether EA should report into CEO or CIO, I would like to focus on a simple objective of having/building an EA practice. In layman terms - Enterprise Architecture is the formal practice/group/team to align the business strategy with the IT spending, and Enterprise Architects achieve this goal by collaborating and working closely with number of stakeholders across the board on business, application, PMO and QA side of the house. In my experience I have partnered with PMO and Portfolio managers to help lay down an iterative SDLC model, with a foundation build upon Agile principles.

Aligning TOGAF with Scrum

TOGAF is the newer of the EA frameworks, however in last decade TOGAF9 has gained a great momentum and very high rate of acceptance throughout IS&T organizations universally - mostly attributed to it's flexibility and adaptability. 

TOGAF is just a guidance, and the user group can actually custom-build it to suit it's business capability model. TOGAF also provides guidance in shapes of ADM, III-RM, TRM et al. Again, a testament of the adaptability and universality of good EA frameworks. 

The view below is representation of the TOGAF Architecture Development Methodology broken in logical demarcations. 

REF-2: The TOGAF ADM

If you study the TOGAF ADM closely you'll notice how ADM provides structure and framework to the whole project and portfolio management. ADM aligns the SDLC in a mature repeatable sequence of events, and sets high level gates (milestones) to help associate each phase with the adjoining phases. 

Let's breakdown the ADM phases in layman terms to establish clearer understanding with regards to objectives from each ADM phase here:-

Phase A - Architecture Vision

Develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed enterprise architecture

Phase B - Business Architecture

Develop the Target Business Architecture describing how the enterprise needs to operate to achieve the business goals,responds to the strategic drivers set out in the Architecture Vision, and addresses the stakeholder concerns

Phase C - Information Systems Architecture

Develop the Target IS Architecture that enables the Business Architecture and the Architecture Vision, while addressing the stakeholder concerns

Phase D - Application Architecture

Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Application Architectures

Phase E - Opportunities & Solutions

Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C,and D

Phase F - Migration Planning

Ensure that the Implementation and Migration Plan is coordinated with the enterprise's approach to managing and implementing change in the enterprise's overall change portfolio

The fact that ADM revolves iteratively around the business requirements, and repeats logically after completion of each iteration is testament of it's alignment with Scrum methodologies and it's close alignment with the business objectives and goals of an enterprise/organization at fundamental level

Laying these phases in sequential order, keeping in mind the high level objectives of each phase and also considering agile/scrum methodologies on the other side of the thought process - one could lay a representation as marked below. In the view below, i.e. FIG.1 - TOGAF aligned with the Scrum methodology for SDLC, I have showcased how TOGAF is aligned with Agile/Scrum in a top-bottom representation. 

FIG.1 - TOGAF aligned with the Scrum methodology for SDLC

Notice how the view above showcases gates/milestones - indicating the handshake opportunities/placeholders for various stakeholders involved in the end-to-end SDLC, moving the project responsibilities between teams/stakeholders. 

The gates could be used to mark out clear demarcation and also in setting protocols and standards for information exchange between stakeholders representing different groups/units.

This same model could be extended, or taken a step further even to the Phase H of the ADM, i.e. Architecture Change Management. This could be applicable in cases when the original architecture solutions could not be applied/conformed to or change in original requirements or in case of lot of defects during UAT leading to re-do or most commonly, taking a backlog of the unfinished used stories and re-prioritizing them in the next sprint.

Aligning Zachman and TOGAF together with Agile/Scrum

Overlapping this TOGAF/Scrum representation above with the Zachman/Scrum model one could easily link the 2 and see the close association between the 2 models.

The output from gate 1 and gate 2, i.e. Corporate Strategy and Technology alignment phases, evidently become inputs for the tactical plans in shape of user stories/epics as answers to - when, who, how, what, where and why, all addressed during the earlier phases. Please see the FIG.2 - SDLC Gates based upon the Zachman, TOGAF and Agile/Scrum Alignment for better clarity.

FIG.2 - SDLC Gates based upon the Zachman, TOGAF and Agile/Scrum Alignment

Summary

Zachman is a true example of an EA framework which has stood the test of time and has been adopted by 1000s of organizations worldwide. Adaptability and universal applicability of Zachman makes it stand atop all EA frameworks, testament to the flexibility of the mature EA framework.

TOGAF on the other hand is inherently flexible since it just guides the EA practitioners with guidelines and methodologies, leaving the implementation details to the EAP. If anything, it just adds to the agility of the practicing organization and provides means of progressive incremental maturity. 

Hopefully, this should help the EA skeptics understand how easily an EA frameworks can align with Scrum/Agile methodologies and enhance productivity and agility of the SDLC. It should help skeptics realize that one can tweak and morph the EA framework to meet the business needs and IT expectations. 

In the end I would like to sum it up by giving an analogy - 

Building a large, complex, enterprise-wide information system for the modern enterprises without an EA framework is like trying to build a modern cosmopolitan city without a city planner or a blueprint. 

Can you build a city without a blueprint? Probably Yes.  

However, would you want to live in such a city? Probably NOT.

Enterprise Architecture is simply indispensable for the modern enterprises. 


----x----x----x----


Disclaimer - The reader is expected to have basic knowledge of TOGAF, ADM and Agile. Also, please note that there are many more EA models/frameworks and the value chain could also be represented potentially in dozens of different ways. That being said, Agile and EA could be aligned in multiple different ways - owing to flexibility offered by both, as long as the using organization knows what it's looking for.


References:

REF-1: The Zachman Model

http://www.zachman.com/about-the-zachman-framework

REF-2: The TOGAF ADM

http://pubs.opengroup.org/architecture/togaf9-doc/m/chap05.html