This document discusses how to tailor the TOGAF enterprise architecture framework to align with Scaled Agile (SAFe) delivery methods. It recommends: 1. Adopting key SAFe principles like system thinking and preserving options as architecture principles. 2. "Shifting right" some architecture work to the delivery organization to allow for more incremental feedback. 3. Integrating TOGAF phases like architecture definition and migration planning with SAFe elements like release planning and architecture runways. 4. Adapting architecture capabilities to have skills in agile methods and SAFe, use agile techniques like estimating in story points, and take a lighter governance approach.

1. 2018
Dinesh Singh Panwar
Westpac Group
7/8/2018
White Paper – TOGAF tailoring
for Scaled Agile delivery
Version 1.0

2. Introduction
TOGAF has been a very successful architecture methodology that has been directly or indirectly
adopted by many IT organisations across the world. The primary reason for TOGAF’s success is the
flexibility to tailor the framework as per local situation. With this flexibility, TOGAF is suitable for
both large scale and small scale projects and can work with variety of delivery methodology – Agile,
Waterfall and Hybrid.
TOGAF recommends engagement and feedback with delivery organization in the Opportunity &
solutions and Implementation governance phases.
With the immense popularity of Agile and related delivery methods, various old school
methodologies are either no longer relevant or have been tailored significantly. For instance,
traditional testing phases have been merged into the Build with the so called Shift left approach,
requirement gathering is expected to be part of delivery itself.
One of the agile frameworks called Scaled Agile Framework – SAFe has gone to the next level by
recommending agile approach and overhaul of all aspects of project delivery from Business case to
value realization. This essentially means impact to the way Architecture work is done.
This White paper discusses how TOGAF can be tailored to align with SAFe delivery framework.
Tailoring key SAFe principles as Architecture Principles
For SAFe tailoring of TOGAF, below architecture principles shall be defaulted to the tailored
framework:
1. Apply System Thinking(SAFe#2)
Statement Think of solution as a System and develop architecture to optimize the flow
instead of individual component
Rationale Value of a solution is in working of interconnected components. Focus on
individual component can drain resources and funds and leave less technical and
financial room to adapt, should a change be required
Implications Implication to architecture work is to design the solution with working solution in
mind. If solution is too large to delivery, then focus would be on building working
transition architecture instead of sequencing building of complex non-working
components
2. Assume Variability and preserve options (SAFe#3) – Shift Right
Statement Change of requirement is a default assumption and options should be chosen at
latest possible moment
Rationale With ever changing technology and market landscape, it is always likely that
either requirement will change due to changing market situation or better
technology option would be available. Therefore prescribing detailed
architecture upfront impedes the project from taking tactical and change
directions without going through lengthy governance process

3. Implications Direct implication is on the versioning of Architecture works and depth of details
in the architecture.
To allow changes, architecture needs to scope out the boundaries definitions for
the purposes of versioning and keep the in-depth detailing and choices for the
delivery organization (SAFe Trains) .
Content sharing tools like Confluence provide technology capability for un-
versioned extension of content
Another indirect implication is on the Architecture governance. Since details and
options are left for during the delivery, formal architecture governance is
lightweight and part of architecture team is involved during the delivery within
Release Train
3. Decentralize Decision Making (SAFe#9)
Statement Centralize Strategic decisions and decentralize everything else
Rationale Majority of technology decisions are frequent, time-critical and require local
information. Such decisions are best left to the Scrum teams working on the
features.
Only strategic decisions that may provide economies of scale should be
centralized
Implications The content of Architecture Definition documents shall only prescribe strategic
decisions and low level tools, technology decision shall be purposely left to the
Scrum teams delivering the features.

4. Shift Right of Architecture
Agile has been a development movement that has revolutionized how we look at different aspects
of Software delivery.
In all agile frameworks, Shift left approach of all downstream activities like testing and operations
and folding them into delivery construct results in short feedback loop and ability to respond to
market and change direction even during the delivery
Build Test Operations
Architecture
Work
Customer
Feedback Loop
TIME
Build-Test-
Deploy-
Operate
Architecture
Work
Customer
Incremental Feedback
Long Term Feedback
TIME
Traditional Delivery Model
Typical Agile Delivery Model
As we can visualize, there are 2 kinds of feedbacks in Agile vis-à-vis architecture, one that can be
incorporated by delivery framework without impacting architecture and other where architecture
work is required. Clearly, in order to minimize the average cycle time, majority of feedback should
be managed by delivery organization.
This means that Enterprise architecture shall “shift” some architecture works to delivery
organization. This is “Shift Right” of Architecture. Needless to say, this has to be balancing act of
speed & depth. What activities can be shifted right largely depends on ownership and exact
methodology of the delivery organisation.
Here are 2 scenarios:

5.  Scenario 1: Silo agile teams for individual application engineering team
In this case, there are limits to what can be shifted right. Any feedback that requires change
to Enterprise integrations to the application or Solution Building block (SBB) will require
architecture work. Existing integrations can be left to the Agile team (Principle#3) and only
new integration of changes that fundamentally changes the strategy and intent of the
application should require architecture work
 Scenario 2: Scaled Agile teams or Cross-functional teams
In this case where a delivery construct of multiple agile teams own more than one
applications or SBB, naturally are better placed to absorb more architecture work. In this
case, Architecture governance could be very lean. Moreover, technology architecture can be
part of the delivery framework.
Scaled agile framework (SAFe) provides a mature framework for managing transition
architecture within the delivery. Next section describes how rest of the architecture can be
integrated to SAFe.

6. ADM and SAFe integration
SAFe provides a detailed method of how Architecture work itself can be part of the delivery
construct. There are various flavours or levels of SAFe implementation depending on scale or scope
of the delivery construct. It recommends incremental architecture called Architecture runway
enablers to allow quick changes to Technology and solution architecture as complete architecture is
delayed (Principle #1 and #2).
Whilst the actual implementation of SAFe is driven by organization’s appetite to incorporate agile at
scale, the impact to Architecture is largely limited to Information System and Technology
architecture phases of full ADM.
ADM itself is generally tailored to short cycles to architecture changes on existing Infrastructure,
reducing the cycle time. This topped with SAFe recommended Architecture runway instead of fully
defined Solution building block, greatly makes the organization responsive to demands for change.
SAFe is integrated here.
Instead of clearly defining SBB (Solution
Building Block), architecture defines high level
boundaries and exact definition is left to SAFe
delivery construct

7. TOGAF and SAFe Integration | Solution Building Block = Architecture Runway
SAFePortfolio/
Solution
=TOGAF
Opportunityand
Solution
Technology
Architecture
SAFeReleaseTrainPlanning=TOGAFMigrationPlanning Phase
Gap Analysis
Transition
Architecture as
Enabler and
Capabilities
Capability and
Epic
breakdown
Business EPICS
Features
Enablers
Example: To illustrate this, let’s assume a hypothetical situation:
There are 2 companies – A and B – both having online systems for customer interaction maintained
and changed by SAFe agile release trains. These 2 companies are merged and as a result EA is given
the tasks of technology reconciliation.
For Online systems, EA may recommend solution train to merge the 2 Release Trains and manage
them as 1 solution train. During Technology Architecture – Phase D, Target architecture is created to
gradually move to single system. In Phase E, High level Solution Building blocks are envisioned but
exact details are left to the solution train as branding will be gradually altered allowing for market
feedbacks. SAFe solution train itself envisions the Transition architecture as Architecture Runway
enablers over a period of time, thus bypassing TOGAF-ADM phase E and F for this works-tream
For various impacted backend systems, that may be operating in Scrum or Waterfall methods,
separate Work package are created in Phase E and F or the ADM.
Adaptation of Architecture capability
TOGAF prescribes a relatively generic capability framework that organization can tailor to meet their
tailored ADM. For SAFe integrated ADM, below are the key points that shall be considered

8.  Skills and Knowledge:
o Enterprise architects should have understanding of both Waterfall and agile delivery
methods as some various work packages undertaken by EA may be delivered by
different methodologies
o Solution and Domain architects should have Agile Product Owner skills. In SAFe, PO
is responsible of scope and priority of features. For architecture runway,
Solution/Domain architects defines the enablers and hence acts as direct or pseudo
Product owner.
o Agile estimations is another skill that architects should be proficient in. Unlike
traditional methods, SAFe allows for Epics and capabilities (TOGAF-SBB) to be
estimated in story points instead of hard dollars and time. Therefore, architecture
should be abreast of such estimation techniques and continually update their
“conversion logic”
 Architecture Governance:
o Agile methodologies (including SAFe) prefer light governance to achieve maximum
velocity. Therefore, following Principle #3 the Architecture governance board should
limit themselves to strategic decision making only. All short term decision making
paradigm should be delegated to delivery constructs as design guidelines.
o Cadence – governance meeting frequency and entry criterion can also be tailored to
align to SAFe cadences like PI Planning and Sprint cycles.