TOGAF ADM Phase D Technology Architecture Deliverables

One central outcome of Phase D is a technology architecture. This is one part of the complete enterprise architecture. So, in a roundabout way, there are five useful deliverables for TOGAF ADM Phase D:

1. Models that comprise the Technology Architecture
2. Gaps between the current & target technology architecture
3. Candidate work packages that will fill the gaps
4. Candidate architecture specifications that will let you govern future architecture development and implementation
5. Influence into the business architecture, application architecture, data architecture, and security architecture

Always keep in mind that you are seeking to improve the organization. Improvement requires change. The change delivers value. Value and cost of change can be measured. Uncertainty always decreases potential value. When the success is uncertain cost increases geometrically. Very little uncertainty will eliminate anticipated.

Most of the time when we speak about the Technology Architecture, we are referring to the models and architecture specifications. Different models will explain different aspects of the complete infrastructure. Together the models and the needed changes form the technology architecture.

When looking at different model kinds, keep in mind there are many uses of the same terms. We cannot stress enough that you should relax about the model’s label. What you call a functional decomposition model someone else will call a service. Our enterprise architecture consulting focuses on purpose, not what the model is called. You can call it a functional decomposition, or a system model, or a service model. We only care about the purpose of the model – what are you trying to learn, and does your model effectively explain how that aspect of the real-work works?

Completion of Phase D Technology Architecture

All TOGAF ADM Phases have the information inputs and activity to develop the knowledge you need. The outcome of Phase D is the development of a candidate technology architecture.

Output & Outcome

Essential Knowledge

The technology domain architecture approved by the stakeholders for the problem being addressed, with a set of gaps, and work to clear the gaps understood by the stakeholders.

How the current technology portfolio fails to meet the preferences of the stakeholders? What must change to enable the software portfolio to meet the preferences of the stakeholders? (Gaps) What work is necessary to realize the changes that are consistent with the additional value being created? (Work Package) How stakeholder priority and preference adjust in response to value, effort, and risk of change. (Stakeholder Requirements)

Table from TOGAF 10 TOGAF Series Guide: Enterprise Architect’s Guide to Developing Architecture

Phase D Bare Bones

In Phase D, the work of a technology architect is determining what needs to change in the technology to enable the information systems to enable the enterprise. Sounds simple. All you need to do is understand what the organization is trying to improve, where it is falling short, and what must change.

The bare bones of Phase D are:

• Knowing how the infrastructure portfolio enables capturing value

Organizations create value when they do something that a customer will pay more for. Value is typically generated when a material is changed, when a service is rendered, or information is used. Iron ore to steel, weather warning delivered, or parts, orders, and manufacturing capacity to create a production order.

Technology usually has a supporting role. It enables people and applications to generate the value. As a supporting function, we optimize for efficiency. The critical question is answered by knowing the minimum services required.

• Knowing how infrastructure will be delivered

We used to need to own and operate our technology. With Public Cloud PaaS providers, we can operate global scalable organizations owning no technology. Most organizations will have a mixture of infrastructure they own and operate, infrastructure they select others operate, and a set of infrastructure services.

• Knowing the source of cost, complexity, and rigidity

Every infrastructure portfolio suffers from rigidity. Infrastructure is hard to change. Complexity and rigidity create cost and complexity. Your infrastructure looks like a complex watch-works. One that was assembled out of almost random parts. Changing one thing usually creates cascading changes through the entire portfolio.

Technology architecture must reduce rigidity to enable enterprise agility. You must optimize your core infrastructure portfolio to drive out sustained cost and complexity. The race to Public Cloud PaaS is simply an effort to buy some agility.

• Knowing how to select infrastructure

There are four infrastructure models: PaaS, enterprise systems, specialist systems, and custom development. Each has a different cost and optimization model. You need to apply the right infrastructure acquisition model in the right places.

• Knowing the expectations of infrastructure

Sometimes we need a generic infrastructure service. Sometimes we need specialist hardware. Most of the time we need something without too much overhead. We leverage the concepts and attributes in capability models to guide choices about our technology architecture. Our Business Architecture Capability Assessment Guide has a set of attributes that can be readily adapted.

• Know how to use the infrastructure

What is the selected interface? Do you choose to use an industry standard or go further with a specialist interface? Do you mask the interface with abstraction?

Then there is operating the infrastructure. What are the operating expectations? What about up-time, or the ability to absorb component failure? What are the requirements for being able to change the infrastructure?

• What must change to deliver the best infrastructure portfolio?

We develop technology architecture to improve an organization. The pace and reality of infrastructure changes mean that most changes deliver out of cycle. Current business changes must use the existing infrastructure. As a technology architect, you are often working on the fifth aspect of the enterprise agility model - Flexibility. Without pre-emptive work on reducing the barriers to action, your organization has constraints on unexpected change.

Most changes people want to make are only tinkering. In terms of Six Sigma, it is local optimization. Making one small part of the system better, even at a cost to the entire system. As a technology architect, use the guidance in TOGAF ADM Phase D to focus on material changes that drive meaningful enterprise agility, cost improvement, or value creation.

The three completion essentials of Phase D:

• First, what must change? Change in service, performer, interface, operation, outsourcing, in-sourcing, or automating. These are all changes. We do them to improve an organization. Look to improve your infrastructure portfolio.
• Second, when must it change? Are there dependencies? How about pre-conditions? Are you changing set-the-stage for a later change?
• Third, how will you know if the change succeeded? What is your governance test for success? How will you guard value?

Stakeholders’ own approval of all architecture changes. The technology architect is accountable for describing the change in terms they understand. In terms that address their concerns. As well as providing the governance tests so the stakeholders can direct the change project.

TOGAF Phase D Technology Architecture Deliverables and Enterprise Architecture Purposes

There are four core purposes for developing enterprise architecture. Different Phase D deliverables have different importance in each purpose.

	Architecture to Support Strategy	Architecture to Support Portfolio	Architecture to Support Project	Architecture to Support Solution Delivery
Phase D Work Product: Candidate Technology Architecture	Key deliverable Primary use is stakeholder understanding of target and work. Secondary use is the creation of Architecture Requirements Specification for Architects	Key deliverable Primary use is stakeholder understanding of target and work. Secondary use is the creation of Architecture Requirements Specification for Architects	Before project initiation and finalization of business case Primary use is the creation of Architecture Requirements Specification for Implementers	Before engagement of execution partners (including internal providers) Primary use is the creation of Architecture Requirements Specification for Implementers
Phase D Work Product: Candidate Roadmap Items	Key deliverable Primary use is stakeholder understanding of work. Secondary use is the creation of constraints for Architects	Key deliverable Primary use is stakeholder understanding of work and dependency. Secondary use is the creation of constraints for Architects	Limited use Can be used as an input to projects with multiple interactive changes	Before engagement of execution partners (including internal providers). Primary use is identification of required change, and preferences of how to execute change, to manage solution delivery partner selection and engagement
Phase D Work Product: Architecture Requirements Specification	Limited use Usually Architects can infer constraints from superior architecture.	Limited use Usually Architects can infer constraints from superior architecture.	Key deliverable Before completion of project initiation	Key deliverable Before engagement and contracting

Table from TOGAF 10 TOGAF Series Guide: Enterprise Architect’s Guide to Developing Architecture

Candidate Technology Architecture

There are four core purposes for developing enterprise architecture. Different models have different importance in each purpose.

>>> Jump to the common Technology Architecture Models

Candidate Technology Architecture Roadmap Components

What are the minimum changes? If you are evaluating changing an infrastructure vendor, it is unlikely a material change. If you are changing from a generic enterprise system to specialist infrastructure, then the component and specification change in the Infrastructure Provider Model, is the Roadmap Candidate. Never forget all the cascading changes. Switching to specialist infrastructure will require changes throughout the business and application architecture. Even, if it is just changes in the team that operates the specialist hardware.

We often use an Infrastructure System Model to summarize changes. System Models provide enough abstraction for planning and execution conversations. We recommend using scores and work packages to explain changes. For more information on using scores, see the Business Architecture Capability Assessment Guide.

We use all Architecture Roadmap components in TOGAF Phase E - Architecture Roadmap.

Candidate Technology Architecture Requirements Specification

Explain the constraints on infrastructure designers, buyers, and implementers. Explain how you will assess the improvement.

We often use scores and simplified statements to describe requirements. Requirement can be a measure of automation, or a statement that this infrastructure will be Public Cloud PaaS, or specialist hardware. These requirements are used to direct and control a change project in TOGAF Phase G.

What is the role of the Technology Architect in Phase D?

We expect the technology architect to lead TOGAF Phase D and deliver the domain architecture. They must develop the models that show the source of the deficiency. They must exercise their models to show how a change overcomes the deficiency. We expect them to lead stakeholders, subject matter experts, and other domain architects through trade-off analysis.

Technology architects must engage closely with business architects and application architects. The technology architecture often causes deficiencies in their domain. As well, removing complexity and rigidity in the technology architecture usually requires changes there.

We expect the technology architect to key off the business architecture. They must understand the Operating Model and the Competency and Automation attributes of the Capability Model. We also expect that they will understand the Application Development Model, the Competency and Automation attributes of any Application System Model, and the Digital Product Model.

>>> Jump to the common Business Architecture Models and common Application Architecture Models

>>> Jump to common Technology Architecture Models

Enterprise architecture teams cannot succeed without technology architects. Modern digital enterprises only look like they run on software. They run on infrastructure. Nothing happens in without infrastructure. Weak technology choices will cripple business agility and value creation. Technology architects specialize in the technology domain. They cannot do their job without effectively working with business architects, data, technology, and security architects.

What is the role of the Enterprise Architect in Phase D?

The enterprise architect has the same role in TOGAF Phase D. An enterprise architect needs to fill-in where any domain architect needs help. Either developing the technology architecture, interpreting other domains, or guarding value. Many technology architects will not see the impact coming from, or going to, the business architecture. Or they may not articulate a requirement in terms the security architect can act on.

The most important role of the enterprise architect is crossing boundaries. Whether they are domain, skill, or authority boundaries, the enterprise architect needs to cross them.