TOGAF® ADM Phase D – Develop the Technology Architecture

We develop the technology architecture in TOGAF ADM Phase D. A good technology architecture has the critical constraints on technology and infrastructure that enable your application and data architecture. Constraints that enable the choices of purchasing, integrating, and developing software. Constraints that drive you on premise, to a private cloud, our public cloud PaaS. Without these top-level constraints, detail inside any specific technology is of little practical value.

The TOGAF Standard is clear about two things. First, the technology architecture to directly supports the information systems architecture (application and data) to enable the business architecture. Second, we do not develop domain architectures sequentially.

Digital transformation requires the right IT Architecture. A good technology architecture is required because every architecture domain enables, delivers, or blocks outcomes in other domains.

TOGAF ADM Phase D – Develop the Technology Architecture

At a Glance

TOGAF ADM Overview

Use the TOGAF ADM to develop the knowledge needed for the best technology architecture. Every ADM Phase provides the inputs and activity required to develop knowledge on a specific topic. The TOGAF ADM stands at the centre of the TOGAF Standard. It is the only scalable universal method to develop enterprise architecture. It is appropriate for every level of detail. Like all logical models, it needs to be expanded to cover different levels of detail - strategy, portfolio, project, and solution delivery.

If you need an overview of the TOGAF ADM, please read the TOGAF ADM Phases Explained.

What is TOGAF Phase D?

In TOGAF Phase D, Technology architects lead the development of the technology architecture. They do this by looking to enable the information systems architecture – not by taking orders and fulfilling hopes. Technology architects understand long-lived infrastructure delivers their environment. They must look ahead and be ready. They have to ensure that short-term hopes do not create long-term pain.

When we are developing enterprise architecture teams, we tell the architects two central facts about TOGAF Phase D - Technology Architecture. First, until you have an Application Development Model, you cannot proceed. Developing details of your infrastructure before you understand what your application architecture needs is pointless. Second, if they are diving an IT, or infrastructure agenda, they will always develop a low-quality technology architecture. The infrastructure designers and operators should feel constrained by the technology architecture.

In a modern digitally transformed enterprise, all architecture domains interact. Choices in one domain enable, deliver, or block outcomes in another domain. Most business objectives depend upon right IT Architecture. We can only develop the right technology architecture if we have a solid Application Architecture.

The true difficulty of technology architecture is the long-lived nature of infrastructure. Without a technology architecture providing constraints, tactical infrastructure choices will always create worse enterprise outcomes.

There is a direct alignment between good technology architecture and modern PaaS, or most Cloud Architecture. Both identify infrastructure services. Both provide constrain and enable data and application choices. Both isolate applications from the underpinning infrastructure.

What is the Objective of TOGAF ADM Phase D?

The TOGAF ADM starts with Phase A. It delivers a simplified target architecture - the Architecture Vision. The Architecture Vision had better include business, application, data, and technology domains. Too often, we see people pretend to develop an Architecture Vision. They show up with a business operations fantasy and treat Phase D as an exercise in delivering fantasy. Real enterprise architecture has developed a simplified target architecture. Activity in Phase D develops the technology architecture domains further. Success requires:

  • You address the problem of how the current infrastructure does not meet the preferences of the stakeholders
  • You learn what must change to enable the infrastructure to meet the preferences of the stakeholders? (Gaps)
  • You have a sufficient understanding of the work is necessary to deliver changes (Work Package)
  • You understand the interaction between changes and constraints in other architecture domains to protect the value expected (Architecture Requirements Specifications)

The central outcome of Phase D is the candidate technology architecture. Technology architects work with the other domain architects. Expect to pass hopes and constraints back and forth. All architecture development requires getting to the best answer for the enterprise. The best answer understands limitations and work in all domains.

The point of the TOGAF ADM is to explore possible changes. Changes are balanced in terms of work, value, and risk. Changes that are selected or dropped. The set of changes creates the target architecture and the architecture roadmap.

Technology architects work with infrastructure. Infrastructure is the hardest part of an organization to change. Technology architects must second-guess every potential change and keep their eyes open to an off-ramp. The least expensive off-ramp is during architecture development. Stop bad ideas soon. Eliminating bad ideas saves money and enables successful change. The need to think further ahead with infrastructure requires the technology architects to constrain infrastructure designers and implementers.

Interaction with TOGAF Phase B, Phase C, and Phase E

The business’ is the enterprise. It always has been. Modern digital enterprises cannot use hard-working people to overcome limitations in applications and infrastructure. Limitations in applications and infrastructure eliminate enterprise agility and kill digital transformations.

They designed the TOGAF ADM around the challenge of breaking work-up and the requirement to work together. Unfortunately, the classic TOGAF ADM diagram shows the flow of necessary information. They have interpreted it as a waterfall.

Anyone who suggests enterprise architecture can be developed sequentially is wrong. Anyone who tells you to run out an architect the enterprise is also wrong. The complexity and skill specialization requires domains. Their development starts and proceeds together. You must follow an agile approach of just enough to test the cascading constraints. TOGAF calls this iteration.

What is Technology Architecture?

Technology architecture is one of the four foundational enterprise architecture domains. A technology architecture is a description of your complete infrastructure portfolio that tells you when to buy infrastructure, when to use PaaS, and when to invent infrastructure. It tells you where to put boundaries between systems. It tells you how you will approach your infrastructure lifecycle.

We can guarantee that your current technology architecture is not aligned. We are confident that you will start from a position where infrastructure planning did not have a solid application architecture or business architecture.

When you have a technology architecture, you have the set of infrastructure services required by your applications. You have a set of guidelines and constraints for designing and operating your infrastructure. You have a technology roadmap that your stakeholder understands.

To develop the technology architecture, its services, guidelines and constraints, the technology architect must work with her peers and the stakeholders. They must explore how different infrastructure choices enable or block business and software choices. They must get to how the set of choices enables and constrains the organization’s objectives. Drop potential changes that deliver too little, require too much work, or have too much uncertainty. Good architecture roadmaps contain necessary changes and are de-risked.

What is a Technology Architecture Used For?

The technology architecture will help answer the following questions:

Technology Architecture vs Cloud Architecture

We see almost no different between good PaaS, or good Private Cloud Architecture, and good Technology Architecture. The core work products, a System Model and Service Model, are the same. The difference is when you use PaaS or Public Cloud, you do not need to worry about the underpinning infrastructure.

Ironically, if you have been doing good Technology Architecture since TOGAF 8, you have been providing a clear set of infrastructure services. You will have been specifying the interfaces and standards to those services. We suspect your work is easily transferred to a Public Cloud PaaS service catalog.

TOGAF 8 called for technology services to abstract detailed infrastructure to allow portability, manage the ‘ilities’, and enable infrastructure lifecycles. The same reason that all the Public Cloud PaaS providers have their customers use services. If we all had only done good technology architecture, we would have avoided the dead end of immobile applications, undelivered ‘ilities,’ and technical-debt.

>>> Jump to The Basics of Private Cloud Architecture

Do we call it Technology Architecture, Infrastructure Architecture, or IT Architecture?

The TOGAF Standard calls it Technology Architecture. Our enterprise architecture consulting practice usually uses infrastructure. Many others call for an IT Architecture. Efforts to develop a crisp universal definition routinely fail. Our strong advice is to focus on the purpose, rather than the definition.

The line between architecture domains helps us bring the right skill and right conversations together. Thinking about this purpose keeps the focus on developing a useful architecture.

Thinking about the definition will routinely walk you into a pointless discussion. Is the AI Chat-bot Application, AI, or Business? Is email an application or infrastructure? What about facial recognition used for Access Control? The permutations are endless.

All enterprise architecture domains bleed into each other. Together, domains cover the complete enterprise architecture. We create a domain so a specialist architect can use techniques and skills. New enterprise architecture domains continually arise. Most get absorbed into a classic enterprise architecture domain as they become mainstream.

Our advice is don’t worry about what is right. Instead, make sure you understand what someone else means when they are speaking. Always know what your listeners assume you mean. Take accountability for understanding and adjust your terms.

What is the difference between an Enterprise Architect and an IT Architect?

Many people assume they should focus an enterprise architect on IT Infrastructure. On several consulting engagements, we have relabeled our enterprise architects to avoid this problem. The Enterprise Architecture profession is clear. IT Architecture is a subset of enterprise architecture. Technology is a subset of IT architecture.

We focus enterprise architects on the interplay of all architecture domains. On many teams, there will be data architects, application architects, security architects, business architects, and technology architects. They might be called by their role, or by the general title enterprise architect.

TOGAF ADM Phase D Technology Architecture

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.

Technology Architecture

Technology Architecture Models, Tools, and Techniques

The TOGAF ADM Phase D is delivers the Information Systems Architecture. This Phase exists to develop the technology architecture and data architecture that comprise the information systems. In TOGAF, the first step is to determine the views required, and the models required.

Stakeholder Concerns will identify the views. There are seven central technology architecture models.

  • Infrastructure Provider Model specifies how infrastructure will be provided
  • Infrastructure System Model captures the large systems your infrastructure portfolio
  • Infrastructure Service Model breaks the infrastructure portfolio into black boxes and focuses on outcome and attributes of the Service
  • Interface Model describes how you connect to, or use, infrastructure
  • Lifecycle Model identifies the required lifecycle attributes of your infrastructure portfolio
  • Standards Catalog identifies the acquisition standards for your infrastructure portfolio
  • Infrastructure Physical Model explains what real infrastructure exists in the infrastructure portfolio

Technology Architecture Models

Develop a useful technology architecture requires several enterprise architecture models. Each model kind explains a different aspect of the infrastructure portfolio. TOGAF Phase D technology architecture explains the broad steps to develop the Target Architecture. Different model kinds let you look at the infrastructure portfolio in different ways.

Using the minimum number of linkages these models describe the technology architecture. With a minimum set of linkages to other domains a complete enterprise architecture is described.

Infrastructure Provider Model

The Infrastructure Provider Model describes how infrastructure will be provided. This model requires an Infrastructure Service or Infrastructure System Model.

There are four basic provider types:

  • Public Cloud PaaS, can be assembled as point infrastructure services. Restrictions and limitations of interoperability require selecting in provider bundles
  • Enterprise systems, mainstream common use infrastructure. Typically, it is provided in broad systems that embed a range of features. Enterprise systems require work to assemble into Infrastructure Services.
  • Specialist systems excel at different niches. Typically, specialist systems support unique use cases. Examples include aviation certified infrastructure, or extended shock and temperature ranges, or quantum computing
  • Custom infrastructure, you have built for your organization. Typically, custom meets unique requirements in your business or application architecture.

Infrastructure System Model

The system model abstracts infrastructure required to deliver a feature. Most Technical Reference Architectures are based on a system model. They identify the different features of infrastructure.

Think about an application environment, with application servers, load balancers, and storage. The design of your system model will constrain your ability to identify duplication, rigidity, and complexity.

System models allow you to direct thinking to areas in your infrastructure where operational cost, rigidity, and duplication need to be addressed. They move the conversation from specific variants of the system to the trade-off between impact to other domains, agility, cost, and operations.

FEAF, OPAS, and IndEA all provide Infrastructure System Models. Required to perform Infrastructure Portfolio Planning. Duplication and specialization drive complexity and cost into the Infrastructure Portfolio.

Infrastructure Service Model

An Infrastructure Service Model is a specialized version of an Infrastructure System Model. It collapses everything into a black box with known attributes and interfaces. You cannot perform Public Cloud PaaS, or Private Cloud PaaS architecture without a Service Model.

An Infrastructure Service Model is invaluable in developing the Infrastructure Provider Model and validating the Target in an Infrastructure System Model. The interfaces in your Service Model should all be well identified in your Interface Model.

Enterprise agility requires a good Infrastructure Service Model. You need to be able to find and remove the barriers to change.

Interface Model

An Interface Model identifies how you connect different components of your infrastructure tother, and how applications and data access the infrastructure. You cannot develop a Private Cloud PaaS architecture without an interface model. Now will you be able to connect services from more than one Public Cloud PaaS provider.

You are chasing boundaries between systems. You must specify whether and how a boundary can be crossed. Too often technology architects fail to specify boundaries that cannot be crossed. Most rigid and unchangeable infrastructure results from this failure.

The Interface Model is critical in enabling enterprise agility, managing the infrastructure portfolio, and lowering IT cost.

Lifecycle Model

A Lifecycle Model identifies the requires driving into infrastructure design, and reality coming out of physical infrastructure. We use the lifecycle model to identify the lifecycle we have, and need. Years ago, we developed a communication architecture in a mountainous area filled with protected wilderness. This architecture had a range of unique lifecycle requirements that drove the design. It also drove operational requirements.

Standards Catalog

Too often architects we work with assume a Technology Standards Catalog will drive infrastructure operations preferences into the architecture. They assume the other domains will be told the technology standards. This is true only after the stakeholders approve the technology architecture. Until your stakeholders approve the architecture, you cannot perform architecture governance.

The first use of an architecture developed standards catalog is to identify the non-compliant infrastructure. Infrastructure that injects rigidity, cost, complexity, and deficiency into the baseline technology architecture and every other domain.

Your standards catalog will drive infrastructure procurement. When there is no effective Infrastructure Service Model or Infrastructure Interface models it will provide guidance and constraint to other domains and implementers.

Infrastructure Physical Model

A Physical Model describes the actual infrastructure portfolio. Always use the terms used by commercial infrastructure vendors. You will need to associate this to the other technology architecture models to transition the Target into the real-world.

The Physical Model identifies many gaps in the more abstract technology architecture models. It also forms the basis of the Implementation and Migration Plan developed through Phase F.

Technology Architecture Techniques

We use a broad set of techniques to develop and communicate our business architecture.

  • Technical reference Architectures
  • UML is ubiquitous in good model-driven-development. When you are working in Architecture to support Solution Development, a System Model and Interface model should be developed following UML practices.
  • 4+1 Views are useful in identifying the implication of the Target for different communities. Developing 4+1 models helps ensure you are considering all relevant changes.

Technology Architecture Models Aligned to Enterprise Architecture Purpose

The level of question you are answering with your business architecture will drive use of different business architecture models. For example, Architecture to support Portfolio often won’t develop a Value Chain model. Instead, a Value Chain will usually be superior architecture and constrain your freedom.

Architecture to Support Strategy Architecture to Support Portfolio Architecture to Support Project Architecture to Support Solution Delivery
Application Development Model Key Deliverable Key Deliverable Superior Architecture Superior Architecture
System Model Regular Deliverable Key Deliverable Superior Architecture Superior Architecture
Functional Model Regular Deliverable Key Deliverable Key Deliverable & Superior Architecture Key Deliverable & Superior Architecture
Product Model Occasional Deliverable

Appropriate level of detail often diminishes value

Regular Deliverable

Appropriate level of detail often diminishes value

Key Deliverable Key Deliverable
Integration Model Occasional Deliverable

Appropriate level of detail often diminishes value

Regular Deliverable

Appropriate level of detail often diminishes value

Key Deliverable Key Deliverable & Superior Architecture
Service Model Occasional Deliverable

Appropriate level of detail often diminishes value

Regular Deliverable Key Deliverable & Superior Architecture Key Deliverable & Superior Architecture

Business Architecture Models Influence on Technology Architecture Models

Business Model Operating Model Value Chain Capability Model Process Model Functional Model Information Model Organization Model
Application Development Model Major input

Requires a System or Functional Model

Major input

Requires a System or Functional Model

Major input

Requires a System or Functional Model

Major input

Requires a System or Functional Model

Major input

Requires a System or Functional Model

Major input

Requires a System or Functional Model

Limited Input Limited Input
System Model Limited Input Limited Input Limited Input Limited Input Limited Input Major Input Limited Input Major Input
Product Model Major Input Major Input Major Input Limited Input Limited Input Limited Input Limited Input
Integration Model Very Limited Input Major Input on core design

Requires a System or Functional Model

Major Input on core design

Requires a System or Functional Model

Best Input

A direct link is difficult to see. It is worth doing the work.

Major Input on core design

Requires a System or Functional Model

Limited Input

Use only if other models are not available

Major Input on core design

Requires a System or Functional Model

Major Input on core design

Requires a System or Functional Model

Service Model Limited Input

The linkages are important, but a direct link is difficult to see

Limited Input

The linkages are important, but a direct link is difficult to see

Limited Input

The linkages are important, but a direct link is difficult to see

Best Input

A direct link is difficult to see. It is worth doing the work.

Used as a completeness test Major Input

A direct link is difficult to see. It is worth doing the work.

Major Input

Technology Architecture Models for Enterprise Architecture Use Cases

Every enterprise architecture use case is about enabling effective change. There are many kinds of change. Our enterprise architecture use cases help address common questions.

It doesn’t matter what the use case is. The Technology architects has the same goal – helping their stakeholders make better decisions and lead successful change initiatives.

Strategic Change Incremental Change Improve Cost Improve Quality Improve Enterprise Agility Mitigating Technology Risk IT Modernization Digital Transformation Application Portfolio Rationalization Acquisition Integration
Infrastructure Provider Model Very useful Key constraints Key guidelines Critical constraints Critical gaps and constraints Critical gaps and constraints Critical gaps and constraints Critical gaps and constraints Critical gaps and constraints Critical gaps and constraints
Infrastructure System Model Very useful

Critical gaps and constraints

Critical gaps and constraints Critical gaps and constraints  Critical gaps and constraints Critical gaps and constraints Critical gaps and constraints
Infrastructure Service Model Very useful

Critical gaps and constraints

 Very useful

Critical gaps and constraints

 Very useful

Critical gaps and constraints

 Very useful

Critical gaps and constraints

Very useful

Critical gaps and constraints

Very useful

Critical gaps and constraints

Very useful

Critical gaps and constraints

Very useful

Critical gaps and constraints

Very useful

Critical gaps and constraints

Very useful

Critical gaps and constraints

Lifecycle Model Very useful

Critical gaps and constraints

Critical gaps and constraints Very useful

Critical gaps and constraints

Very useful

Critical gaps and constraints

Critical gaps and constraints Critical gaps and constraints Very useful

Critical gaps and constraints

Critical gaps and constraints Critical gaps and constraints Critical gaps and constraints
Standards Catalog Model Very useful for gaps and constraints Very useful

Critical constraints

Very useful

Critical constraints

Very useful

Critical constraints

Constraints Gaps and constraints Gaps and constraints Very useful for gaps and constraints

Applying Enterprise Architecture Principles to Technology Architecture

There are 7 Architecture Principles every enterprise architect should know. Principles are superior architecture and constrain your freedom when developing architecture. Each one of your architecture principles will constrain the development of your technology architecture. Always test your candidate architecture, don’t find an alignment statement. Prove you are following the letter and the spirit. You know the principle is correct. In TOGAF ADM Phase D, you need to prove the technology architecture conforms.

Technology Architecture Implication
Don’t Mess With Success Look to eliminate change. Yes, eliminate all change that is not explicitly justified
Focus On Excellence Leverage the Capability Model and the Application Development Model to ensure the technology enables enterprise excellence.

Align with the Digital Product Model. Product and Service are direct to the customer and have very difference minimum standards.

Why Not One? Leverage the Application Development Model and Infrastructure Service Model to find where duplication is prohibited. Then eliminate it.
Data is an Asset Ensure the Infrastructure meets the requirements of asset management and asset use.
Systems Work Where We Work Work location and work style drive infrastructure.
Painless User Experience Differentiation, transformation, and efficiency programs require cost models deliver productivity. Most of the time you are eliminating productivity degradation, not improving it.
Self Service Infrastructure administrative activities & deployment are high cost when they are not self-service. Anything that blocks self-service degrades productivity and chane.

How does TOGAF Phase D align with Agile Development?

Infrastructure either enables or drains potential value from agile development. If your organization needs a strong agile development capability, you need to architect your infrastructure around the agile development capability. The Application Development Model will identify the scope, and whether agile development is helpful or critical.

Lean on your Infrastructure Provider Model and Infrastructure Service Model to align the technology architecture to your Agile needs.

None of the four areas enterprise architecture intersects with agile development always align with technology architecture. Direct alignment comes from the Product Model. Apart from direct alignment always look at Infrastructure Services.

How does TOGAF Phase D enable Enterprise Agility?

As we know, enterprise agility has nothing to do with how you write software. Enterprise agility your enterprise’s ability to react to unexpected threats and opportunities. It is that simple. Can you react to the unexpected?

The enterprise agility model has five points:

  1. Alertness – Can you detect opportunities and threats?
  2. Accessibility – Can you access relevant information in time to respond?
  3. Decisiveness – Can you decide using the available information?
  4. Swiftness – Can you implement your decisions in the time available?
  5. Flexibility – What are you doing to reduce the barriers to action?

Most of the time enterprise architecture is working on #5 - Flexibility. Look for every area that creates rigidity and remove it. In our infrastructure lifecycle planning, we discount every benefit that is not received within 2 years. This is a significant burden on technology architecture, and highlights why Public Cloud PaaS is so attractive.

TOGAF ADM Phase D Technology Architecture Models

Final Thoughts on TOGAF ADM Phase D

Successful enterprise architecture teams do not waste their technology architects designing and guiding the implementation of infrastructure. That confuses a technology architect with a solution architect. It damages the enterprise architecture.

Technology architects need to develop the guidelines and guardrails for the people who solution architect, design, implement, and potentially invent the enterprise’s infrastructure portfolio. In short, the enterprise technology architect is not a solution architect nor a technology specialist called a technology architect. While those roles are important, they do not contribute to an EA Team.

In TOGAF ADM Phase D you develop of the four foundational enterprise architecture domains. TOGAF is clear you develop this architecture with the other domains. The distinction is that the technology architecture often drives changes outside most change initiatives. Infrastructure you own are long-lived capital assets and evolve at a very different pace. Infrastructure needs to be there before the need. Infrastructure needs to be updated on its cycle.

Successful technology architects guide and constrain:

  • The enterprise architect domain architects to the art of the possible
  • Infrastructure planners on the criteria of success
  • Solution architects and specialist technology architects on criteria to judge, criteria to succeed and priority

Great technology architects enable enterprise agility and agile software development. They have focused on the balance between efficiency and agility.

TOGAF ADM Phase D develops the technology architecture. Technology architecture is the foundation of all modern digital enterprises. Use TOGAF Phase D to focus scarce change resources on efficiency and agility. Doing that delivers sustainable enterprise value from infrastructure investments.

Scroll to Top