A consulting team reviews the BTEP-TOGAF integration model during a transformation readiness workshop.
Designing a strong Target Architecture alone does not guarantee a successful transformation.
Consider an ERP transformation designed to:
Even if the Target Architecture is sound, the transformation may still fail if executive sponsorship is weak, business teams resist change, critical skills are unavailable, or adequate funding has not been secured.
Enterprise Architecture therefore needs to answer not only:
“Can we design the right Architecture?”
but also:
“Can the organization actually transform itself to achieve that Architecture?”
The TOGAF® Business Transformation Readiness Assessment (BTRA) is a technique designed to address this question.
One of the important foundations behind this concept is the Canadian Government’s Business Transformation Enablement Program (BTEP).
TOGAF® explicitly acknowledges that its Business Transformation Readiness Assessment builds on work undertaken by the Canadian Government through BTEP.
This article explains the relationship through the following progression:
What is BTEP? → Why did TOGAF build on BTEP? → What does BTRA assess? → How can Enterprise Architects apply it in real transformation programs?
BTEP, or the Business Transformation Enablement Program, was developed by the Treasury Board of Canada Secretariat as a structured approach for planning, designing, and executing Business Transformation.
The Government of Canada published Business Transformation Enablement Program: An Executive Overview in 2004.
One of the defining characteristics of BTEP is that it does not treat transformation simply as an IT transformation.
Government transformation requires an integrated view of:
Policy / Strategy
↓
Programs
↓
Services
↓
Business Processes
↓
Information
↓
Organization / People
↓
Technology
In other words, the objective is not to start with Technology and use it to force Business change.
Instead:
Business Transformation drives the change, while Information and Technology enable it.
BTEP provided a structured way to develop the deliverables needed to plan, resource, communicate, and execute the journey from the As-Is state to the To-Be state, ultimately connecting transformation design with the Business Case and Implementation Plan.
Government organizations consist of numerous departments and agencies.
When each organization independently manages its own:
organizational silos naturally emerge.
This can lead to:
Business duplication
↓
Information duplication
↓
System duplication
↓
Fragmented services
BTEP therefore approached Business Transformation not only from the perspective of an individual department, but from a Whole-of-Government perspective.
Another important principle was the recognition that Technology Integration alone is insufficient.
Two systems may be technically integrated through APIs, but if their underlying Business Processes and Information Definitions remain inconsistent, genuine integration has not been achieved.
BTEP therefore emphasizes the progression:
Business Interoperability
↓
Information Interoperability
↓
Technical Interoperability
This principle remains highly relevant to modern Enterprise Architecture.
From a practical Enterprise Architecture perspective, the objectives of BTEP can be understood through five major themes.
Rather than optimizing individual departments in isolation, BTEP seeks alignment across Programs, Services, Processes, and Information at the government-wide level.
Transformation starts from the value and services experienced by citizens and clients, rather than from the internal organizational structure of government agencies.
The objective goes beyond System Integration. BTEP seeks coherent integration from Business through Information to Technology.
Rather than allowing each organization to use a completely different transformation methodology, BTEP promotes common Models, Frameworks, Deliverables, and Planning Methodologies.
Transformation does not stop at converting Strategy into Architecture.
It connects:
Strategy → Target Business Design → Business Case → Transformation Plan → Implementation
This fifth objective is particularly important for understanding the relationship between BTEP and the TOGAF® ADM.
BTEP combines multiple mechanisms to make Business Transformation executable.
Key components include:
Used to understand transformation maturity and the direction in which the organization needs to evolve.
Used to model government business consistently through a common approach.
Provides a structured way to organize the scope and Architecture of the transformation.
Identifies common Business Capabilities and cross-functional Requirements needed to enable the transformation.
Produces the planning, design, and execution deliverables required to move from the As-Is state to the To-Be state.
Within the BTEP Transformation Agenda, modeling results are translated into strategic design and planning deliverables required for the transition from As-Is to To-Be. These deliverables are then progressively connected to the Business Case and Implementation Plan.
This demonstrates an important point:
BTEP is not merely an Architecture Modeling Framework.
It is a framework that connects:
Architecture → Transformation Execution
This is where the connection with TOGAF® becomes particularly important.
TOGAF® describes the Business Transformation Readiness Assessment as a technique for assessing and quantifying how prepared an organization is to undergo change.
TOGAF® explicitly states:
“This chapter builds on work by the Canadian Government and its Business Transformation Enablement Program (BTEP).”
Therefore, to understand TOGAF® BTRA properly, it is useful to ask:
“Why did BTEP recognize that Architecture alone is not enough to achieve transformation?”
Suppose an Enterprise Architect develops an excellent Target Architecture.
The organization plans to move from:
Current State
Country A → Local ERP
Country B → Local ERP
Country C → Local ERP
to:
Target State
Global ERP
From an Architecture perspective, the design may be perfectly reasonable.
But what happens if:
In this situation:
The Target Architecture may be right, but Transformation Readiness is low.
This is precisely why TOGAF® needs Business Transformation Readiness Assessment.
TOGAF® recommends a structured process for Business Transformation Readiness Assessment:
Step 1 – Determine Readiness Factors
↓
Step 2 – Present Readiness Factors Using Maturity Models
↓
Step 3 – Assess Readiness Factors
↓
Step 4 – Assess Risks and Identify Improvement Actions
↓
Step 5 – Incorporate Actions into the Implementation & Migration Plan
TOGAF® recommends identifying and assessing relevant Readiness Factors, determining the Risks associated with them, defining Improvement Actions, and incorporating those actions into the Implementation and Migration Plan.
The critical point is:
The Assessment itself is not the end goal.
The real objective is to create the chain:
Readiness Gap → Risk → Action → Implementation Plan
Examples of Readiness Factors derived from the BTEP work and presented by TOGAF® include:
| # | Readiness Factor | What to Assess |
| 1 | Vision | Is the purpose and future state of the transformation clearly understood? |
| 2 | Desire, Willingness & Resolve | Does the organization genuinely want and intend to change? |
| 3 | Need | Is the need for transformation widely recognized? |
| 4 | Business Case | Are the investment rationale and expected Benefits clear? |
| 5 | Funding | Has sufficient funding been secured? |
| 6 | Sponsorship & Leadership | Does executive leadership actively support the transformation? |
| 7 | Governance | Are appropriate decision-making and control mechanisms in place? |
| 8 | Accountability | Is it clear who is accountable for what? |
| 9 | Workable Approach & Execution Model | Is there a practical Transformation Approach? |
| 10 | IT Capacity to Execute | Does IT have sufficient Capability and Resources? |
| 11 | Enterprise Capacity to Execute | Does the Business have sufficient capacity to execute the transformation? |
| 12 | Ability to Implement & Operate | Can the organization operate the new model after implementation? |
An important point is that these 12 factors should not be treated as a fixed checklist.
TOGAF® recognizes that individual organizations may require their own Factors and Criteria.
Therefore, in a real Enterprise Architecture engagement:
Use the BTEP/TOGAF® factors as a starting point, then add, remove, or modify them to reflect the specific transformation.
The assessment should not simply assign a “Yes” or “No” to each factor.
TOGAF® considers three important dimensions.
Does the issue need to be addressed before the transformation begins?
How prepared is the organization today?
A typical scale is:
Low → Fair → Acceptable → Good → High
How difficult will the issue be to resolve?
A typical scale is:
No Action Needed → Easy → Moderate → Difficult
This allows the team to assess not only whether Readiness is low, but also:
How important is the gap, and how difficult will it be to close?
A BTRA should not be completed by the Enterprise Architect alone.
A multi-disciplinary workshop is the preferred approach.
For a Global ERP Transformation, participants might include:
The Enterprise Architect should not simply ask:
“Is everyone ready for this project?”
Instead, Readiness Factors should be converted into specific, assessable questions.
For Vision:
“Can senior management and each Region describe the Business Outcomes expected from the Global ERP in the same way?”
For Governance:
“When the Global Template conflicts with a Local Requirement, who has final decision authority?”
For Enterprise Capacity:
“Can Business Process Owners allocate sufficient time to Design Workshops, Data Cleansing, UAT, and Training?”
This converts abstract Readiness into something that can actually be assessed.
Suppose a manufacturing company is implementing a Global ERP.
After the workshop, the assessment might look like this:
| Factor | Urgency | Status | Difficulty |
| Vision | High | Good | Easy |
| Business Case | High | Good | Easy |
| Sponsorship | High | Acceptable | Moderate |
| Governance | High | Fair | Moderate |
| Business Capacity | High | Low | Difficult |
| IT Capacity | Medium | Acceptable | Moderate |
| Ability to Operate | High | Fair | Difficult |
This assessment immediately reveals that:
The greatest Transformation Risk may be on the Business side rather than in Technology.
In particular:
Business Capacity = Low / Difficult
is a significant warning signal.
The BTRA should not end with the assessment.
Consider Business Capacity.
Finding
Business teams are expected to participate in the ERP Transformation while continuing to perform their normal operational responsibilities.
↓
Risk
Insufficient Business SMEs may delay Process Design, Data Cleansing, and UAT.
↓
Impact
The Implementation Schedule for the Target Architecture may be delayed.
↓
Mitigation Actions
TOGAF® similarly expects Risks to be assessed for each Factor, Improvement Actions to be identified, and new actions to be formally incorporated into the Implementation and Migration Plan.
This is one of the most important principles for applying BTRA in practice.
Ultimately, each assessment should be converted into:
Readiness Factor
↓
Current State
↓
Target State
↓
Gap
↓
Risk
↓
Mitigation / Improvement Action
↓
Owner
↓
Due Date
↓
Work Package / Project
For example:
| Factor | Gap | Risk | Action | Owner |
| Governance | No Global/Local decision rule | Design delays | Establish Design Authority | CIO |
| Business Capacity | Insufficient SMEs | UAT/Data Migration delays | Provide Backfill Resources | Business VP |
| Sponsorship | Weak Regional support | Local resistance | Establish Regional Steering Committee | Sponsor |
| Ability to Operate | Support Model undefined | Post-Go-Live disruption | Design Target Operating Model | IT/Business |
| Skills | Insufficient new ERP skills | Low adoption | Training/Enablement | HR |
Once the assessment reaches this level:
Architecture Assessment becomes Transformation Execution.
This is important both for TOGAF® practitioners and for real-world Enterprise Architecture programs.
In Phase A, TOGAF® assesses readiness for Business Transformation and adds the findings to the Capability Assessment.
The results can then help determine the Architecture Scope, the activities required for the Architecture Project, and relevant Risk Areas.
A practical way to view the lifecycle is:
Phase A
Initial Readiness Assessment
↓
Phases B / C / D
Refine the Target Architecture
↓
Phase E
Translate Readiness Gaps into Transformation Work Packages
↓
Phase F
Incorporate actions into the Implementation & Migration Plan
↓
Phase G
Monitor Readiness, Risks, and Actions
Readiness Assessment is therefore not a one-time survey.
It should be treated as a:
Living Assessment throughout the Transformation lifecycle.
The relationship between BTEP and TOGAF® becomes clearer when viewed end-to-end.
BTEP recognizes that successful Business Transformation requires more than designing the Target Business.
The organization must also be capable of executing the transformation required to achieve that Target State.
TOGAF® incorporates this principle through BTRA and connects:
Architecture Vision
↓
Target Architecture
↓
Transformation Readiness
↓
Risk & Improvement Actions
↓
Implementation & Migration Plan
↓
Architecture Implementation
BTRA can therefore be understood as:
The bridge between Architecture Design and Transformation Execution.
The role of the Enterprise Architect is not simply to assign Readiness Scores.
The more important objective is:
To identify organizational barriers that could prevent the Target Architecture from being realized — before implementation begins.
For example, if the Target Architecture includes:
Global Process Standardization
ask:
If the Target Architecture requires:
Single Source of Truth
ask:
If the Target Architecture includes:
Shared Service
ask:
The practical approach is therefore:
Apply relevant Readiness Factors to each significant change introduced by the Target Architecture.
That is what makes BTRA operational rather than theoretical.
In an actual Enterprise Architecture engagement, a worksheet such as the following can make the assessment actionable:
| Item | Example |
| Readiness Factor | Governance |
| Target Architecture Impact | Global Process Standardization |
| Assessment Question | Is Decision Authority clear when Global and Local requirements conflict? |
| Current State | Decisions made independently by each Country |
| Target State | Decisions made by Global Process Owner / Design Authority |
| Readiness Status | Fair |
| Urgency | High |
| Difficulty to Fix | Moderate |
| Risk | Local Requirements fragment the Global Template |
| Improvement Action | Establish Global Design Authority |
| Owner | Transformation Sponsor |
| Target Date | Before Phase E begins |
| Related Work Package | Governance Setup |
At this level of detail:
BTRA → Risk Management → Migration Planning
becomes one continuous process.
It would be easy to look at BTEP simply as:
“An old Government Architecture Framework developed in Canada.”
That interpretation misses its broader value.
What matters is the underlying transformation philosophy.
BTEP views transformation through:
Business → Information → Technology
and connects:
As-Is → To-Be → Transformation Agenda → Implementation
TOGAF® BTRA focuses particularly on one critical question within this broader transformation model:
“Is the organization genuinely ready and capable of moving to the To-Be state?”
A useful distinction is therefore:
BTEP = A broader approach for systematically designing and executing Business Transformation
BTRA = A TOGAF® technique for assessing the organizational Readiness required to make that Transformation achievable
Without BTRA, Enterprise Architecture discussions can easily stop at:
“What should the Target Architecture be?”
BTRA introduces an additional question.
Not only:
Can we design it?
but also:
Can we actually transform the enterprise to get there?
For example, the Architecture Question:
“Should we consolidate onto a Global ERP?”
evolves into the Transformation Question:
“Do we have the Governance, Leadership, Business Capacity, Skills, Funding, and Operating Model required to successfully consolidate onto a Global ERP?”
This is the real value of the TOGAF® Business Transformation Readiness Assessment.
BTEP was developed by the Canadian Government as a structured approach for planning, designing, and executing Business Transformation from a business-driven, Whole-of-Government perspective.
The Government of Canada still maintains the 2004 Business Transformation Enablement Program: An Executive Overview, published by the Treasury Board of Canada Secretariat.
TOGAF’s Business Transformation Readiness Assessment builds on work undertaken by the Canadian Government and BTEP.
The essence of BTRA is not simply to assign a Readiness Score.
It is to establish the complete transformation chain:
Target Architecture
↓
Required Transformation
↓
Readiness Factors
↓
Current vs. Target Readiness
↓
Readiness Gaps
↓
Transformation Risks
↓
Improvement Actions
↓
Implementation & Migration Plan
For Enterprise Architects, the responsibility is therefore not limited to:
Designing a good Target Architecture.
It also includes:
Creating the organizational conditions required for the enterprise to successfully realize that Architecture.
In this sense, BTEP and the TOGAF® Business Transformation Readiness Assessment help extend Enterprise Architecture beyond Architecture Design into a management discipline for Business Transformation.
Government of Canada / Treasury Board of Canada Secretariat
Business Transformation Enablement Program: An Executive Overview, 2004.
Business Transformation Enablement Program: An Executive Overview
The Open Group — TOGAF® Standard
Official source for the TOGAF Standard and the Architecture Development Method (ADM).
The TOGAF Standard — The Open Group
Parts of this article were developed with reference to generative AI suggestions and were reviewed, refined, and supplemented based on the author’s professional expertise and judgment.
Every TOGAF ADM phase, from Preliminary through Requirements Management, translated into an input/task/output/outcome checklist you…
Learn how TOGAF Architecture Principles can be applied to global SAP implementation and rollout programs.…
Learn how to apply the TOGAF Stakeholder Map to SAP S/4HANA implementation and global rollout…
TOGAF's Architecture Partitioning is defined in the Preliminary Phase and revisited when triggered from Phase…
A practical breakdown of the official TOGAF-SABSA Integration white paper — covering SABSA's background, purpose,…
Struggling to decide which work package to tackle first in a global SAP S/4HANA rollout?…