The Open Group is a global consortium that enables the achievement of business objectives through technology standards. With more than 870 member organizations, we have a diverse membership that spans all sectors of the technology community – customers, systems and solutions suppliers, tool vendors, integrators and consultants, as well as academics and researchers.

The mission of The Open Group is to drive the creation of Boundaryless Information Flow™ achieved by:

Further information on The Open Group is available at www.opengroup.org.

The Open Group publishes a wide range of technical documentation, most of which is focused on development of Standards and Guides, but which also includes white papers, technical studies, certification and testing documentation, and business titles. Full details and a catalog are available at www.opengroup.org/library.

The TOGAF Standard is a proven enterprise methodology and framework used by the world’s leading organizations to improve business efficiency.

This document is a TOGAF^® Series Guide to Using the TOGAF^® Standard in the Digital Enterprise. It has been developed and approved by The Open Group. This document sets out to answer two overarching questions:

The high-level structure of this document is as follows:

The audience for this document is those undertaking the roles of both Enterprise Architects and Digital Practitioners. For Digital Practitioners it communicates what architecture practices would help to grow their digital enterprise, and how to interact with the Enterprise Architecture community to get them. For those undertaking an Enterprise Architect role it provides guidance on supporting the digital enterprise.

A side benefit, therefore, of addressing two audiences, each with different cultures and approaches, is sharing information about each community to facilitate cooperation and productive engagements.

The TOGAF^® Series Guides contain guidance on how to use the TOGAF Standard and how to adapt it to fulfill specific needs.

The TOGAF^® Series Guides are expected to be the most rapidly developing part of the TOGAF Standard and are positioned as the guidance part of the standard. While the TOGAF Fundamental Content is expected to be long-lived and stable, guidance on the use of the TOGAF Standard can be industry, architectural style, purpose, and problem-specific. For example, the stakeholders, concerns, views, and supporting models required to support the transformation of an extended enterprise may be significantly different than those used to support the transition of an in-house IT environment to the cloud; both will use the Architecture Development Method (ADM), start with an Architecture Vision, and develop a Target Architecture on the way to an Implementation and Migration Plan. The TOGAF Fundamental Content remains the essential scaffolding across industry, domain, and style.

This document does not contain any normative references at the time of publication. These may be added in a future release.

This document describes how and when Enterprise Architecture, using the approach defined in the TOGAF Standard, can be used to enable a digital enterprise. The experience and knowledge collected and cataloged in the TOGAF Standard has come from years of experience by people around the globe who have built and run the IT portions of companies around the world. The lessons learnt can be used to minimize the growing pains from which maturing digital enterprises will likely suffer.

The structure of this document uses the four contexts and descriptions from the DPBoK Standard to describe the different stages or maturity levels through which a digital product and digitally-based company might transition.

Chapter 1, Introduction provides an introduction to the Enterprise Architect and the Digital Practitioner along with their perspectives and the strategy to connect them. The document presents guidance using a “peek-ahead” approach so a digital enterprise maturing from one context to the next can appropriately apply the TOGAF Standard and Enterprise Architecture to “look ahead” in preparation for transitioning from context to context. It also describes the importance of delivering Enterprise Architecture through a service delivery model – the Enterprise Architecture as a service strategy.

Chapter 2, Why the TOGAF Standard Supports the Digital Enterprise describes why Enterprise Architecture using the TOGAF Standard should be applied in a digital enterprise, and describes using each to reactively and proactively manage and avoid technical debt. It also describes how, as digital products mature and operational excellence is needed, both can be used to mature a product and a company.

Chapter 3, Terminology Alignment provides clarity for the terminology used by the TOGAF Standard and the DPBoK Standard. It also points out definitions commonly used by The Open Group for any terms used in the document that the reader might want to review.

Chapter 4, How the TOGAF Standard Supports the Digital Enterprise comprises the bulk of the content as it reviews the four contexts used by the DPBoK Standard and describes what Enterprise Architecture can contribute during each context. It also describes the Enterprise Architecture principles, capabilities, and services that support each context. Finally, the chapter describes which parts of the TOGAF ADM and TOGAF Series Guides apply to each context to assist with further guidance.

The DPBoK Standard describes the skills needed to operate a successful digital enterprise, including digital product delivery.

New business models resulting from a combination of digital technology, combined with digital ways of working, are transforming economies and societies worldwide. Digital investments are critical for modern organizations. Participating in their delivery (i.e., working to create and manage them for value) can provide prosperity for individuals, communities, and public and private enterprises. Learning programs worldwide are under pressure to produce an increasing number of qualified professionals to meet voracious workforce demands. Skill requirements have undergone a seismic shift over the past 20 years; Digital Practitioners require a wide variety of skills and competencies, including cloud architecture and operations, continuous delivery and deployment, collaboration, Agile and Lean methods, product management, and more.

The DPBoK Standard is intended to support the development of the Digital Practitioner. It seeks to provide guidance for both new entrants into the digital workforce as well as experienced practitioners seeking to update their understanding on how all the various themes and components of digital and IT management fit together in the new world. The Enterprise Architect can use the DPBoK Standard to understand culture, leadership practices, and product development. They can use that information to create a rapport with product teams and discover where they can provide an architectural service to product teams. They can also use this standard to better understand what artifacts are created and how to harvest them in the context of the emergence model from the DPBoK Standard.

Every Digital Practitioner wants and expects their company to be a wild success and to grow exponentially from a founder state to an enduring enterprise as described in the DPBoK Standard emergence model. But what happens when, as it grows, they are faced with the complexity of coordination across multiple teams and potentially across multiple lines of business? What happens when every contract with every business or customer needs a legal review, when they face compliance and regulatory concerns, or when they are the target of litigation?

The Digital Practitioner can use this document and the pointers to specific methods defined in the TOGAF Standard as a sort of “peek-ahead” tool. This document provides guidance that helps the Digital Practitioner complete the Enterprise Architecture tasks that are defined in the DPBoK Standard. It indicates/suggests current best practices so that decisions with long-term consequences are well-informed and set for success as they mature to a large enterprise with several hundred or thousand employees. As the company and teams grow and make decisions that impact their product, they can leverage the hard-earned lessons from the generations of practitioners that came before them. By reviewing where the TOGAF Standard has tools, templates, and processes to complete the tasks discussed in the DPBoK Standard, they will have tools necessary to grow successfully through well-informed decisions.

In looking at the DPBoK Standard, the subject of building a digital enterprise, and how Enterprise Architecture and the TOGAF Standard specifically support the digital enterprise, it became obvious that a shift in focus would be useful. This resulted in spelling out two specific Enterprise Architecture strategies that are used throughout this document:

These two strategies along with the guidance contained in this document will improve the probability of success for the digital enterprise in any organization.

The TOGAF Standard began to evolve at a time when server hardware and networking equipment needed to be purchased; data center space, power, and cooling needed to be planned for, and product licenses negotiated and purchased. Technology infrastructure had to be well-planned and in place in the early stages of a project to allow for adequate lead time. Now, there are alternatives to purchasing and staging hardware and networking, and many product licenses are open-source licensing.

While the environment has changed, the business functions needed to deliver an IT capability still exist. These functions still require an understanding of the concepts behind the business process, and an approach or methodology to accomplish their associated tasks. The TOGAF Standard and Enterprise Architecture are relevant to understand business functions and the tasks that must be completed by people in order to enable the business functions.

The need for companies to evolve into digital enterprises can be linked to a variety of drivers, least of which is the rapid change in technologies that lend themselves to new ways of working, socializing, and entertaining. The Enterprise Architecture capability and the TOGAF Standard support Agile software delivery environments. An Enterprise Architecture should be seen as supporting and enabling the Agile environment in delivering and enhancing digital products and services quicker and easier by providing insight into various areas; including:

Having an Agile culture and using Agile delivery methods does not necessarily lead to products with Agile characteristics. Agile delivery must balance the business value of early delivery to market ^[2] with the future value of leveraging and connecting to other components in the ecosystem that would add value to the product. As a result, a more appropriate approach to developing an Agile backbone may be one that looks at the enterprise, particularly in the Team of Teams and Enduring Enterprise contexts of the DPBoK Standard. In other words, the TOGAF Core Concepts and ADM. For more information on Enterprise Architecture supporting Agile delivery using the TOGAF Standard; see the TOGAF^® Series Guide: Enabling Enterprise Agility (see Referenced Documents). Often the quickest delivery involves solutions that are not easily adaptable with other features and difficult to connect to other components in the ecosystem that would add value to the product.

It is important to consider that for organizations to become digital they must improve their digital offerings with products and services that offer additional value not considered by competitors. To achieve this, experimentation is important, using iterative test-and-learn approaches to identify new digital products. Enterprise Architecture is well-suited to support this experimentation, providing the alignment of business objectives to the digital vision; for example, by applying techniques like design thinking. The use of architecture alternatives to select different potential implementation roadmaps is also a plus. More details on how to handle architecture alternatives can be found in the TOGAF Standard – ADM Techniques (see Referenced Documents), Chapter 10, “Architecture Alternatives and Trade-Off”.

One area of Agile development that can be helped by an Enterprise Architecture approach is the management of technical and architectural debt. Technical debt is not bad, but a debt may bring a short-term benefit at the cost of future delay and inflexibility in bringing new features to market.^[3]

Once you incur technical debt, you have to do something with it. This can be considered as reactively managing technical debt. Many technical debt issues can be dealt with in the product backlog by having the principle that technical debt is tracked and continually paid down as part of items in the sprints. However, there are other forms of technical debt that are better dealt with from an enterprise perspective because of their extremely complex or cross-cutting nature, which may be better managed using Enterprise Architecture and/or following the approaches in the TOGAF Standard. Other forms of technical debt that do not require Enterprise Architecture or approaches from the TOGAF Standard are technical debts that can be mitigated by following software or middleware patterns. This approach might be preferred to simplify maintainability. Technical debt of this nature can also appear in the technology domain.

An approach based on the TOGAF Standard is also well-suited to identifying technical debt incurred due to redundancy. As all products are based in the same digital ecosystem, multiple Scrum teams may have run into the same “architecture roadblocks”. Using the TOGAF ADM as an Enterprise Architecture approach should uncover these overlaps and not only address the issues specific to particular product architectures, but also gain insight into fundamental and systematic deficiencies in the digital ecosystem itself. This can enable teams to develop or acquire solutions to address issues from which multiple products might suffer.

In principle, technical debt is avoidable, but in practice it is incurred. However, the amount of debt that an organization takes on can be proactively managed. The TOGAF Standard has a number of features that, when applied at the enterprise level, can help in the proactive management of the infrastructure. In Digital Transformation Strategy to Implementation using The Open Group Standards (see Referenced Documents), debt is described as:

“The gap between desired state and current state is a liability – a debt incurred by the enterprise. When trade-off decisions result in adding to the backlog of work, the architect and the enterprise are wilfully increasing the chasm between current and target state – an increase in debt. Using assessments from maturity and service design, the practitioner constrains and guides the enterprise from tripping up during trade-off decisions. It also provides insights and compels the enterprise to involve all skill verticals – Human Resources, Finance, Product and Service lines, Strategy, etc.”

When creating a strategy to proactively manage technical debt by using the TOGAF Standard, consider the following:

Digital products and services have a lifecycle from inception to retirement. The length of the lifecycle is dependent on its viability to its ecosystem. The strength of Agile processes lies in the evidence-based testing of features, which means that some experiments will be a success. For the products that fail for one reason or another the long-term consequence of their viability is not relevant. It is the product that has proven its viability without necessarily being engineered for sustainability or deeply embedded integration, which may require rework to address integration into the larger ecosystem.

A new digital product triggers a chain of events. Products that incorporate any sort of technology are constantly evolving. If they are not evolving, they are becoming obsolete. The evolution of products and services is driven by ever-increasing value to the customer. Value can be measured from many perspectives, but one common perspective is the capability of the product or service to connect to other things.

The TOGAF Standard can be used to manage and mature digital products, and to help deliver operational excellence. However, at times it can feel like quite a challenge as Agile processes focus on delivering code over documentation and the TOGAF Standard centers much of its methodology around artifact collection and management.

Although there can be a feeling amongst agilists that there is no need for architecture, the authors of this document assert that there is. It may be that the architecture is not understood, or written down, or it may be a poorly designed architecture; but as long as there is a system, there is an architecture. Without suggesting a best practice for architecture documentation, each architecture description can be plotted on the matrix described in Figure 1, “Example of Documentation Matrix”.

A system, whether large, small, simple, complex, just invented yesterday, or as old as the punch card mainframes, has an architecture. And that architecture has a description; we can describe it visually, verbally, or in a written form.

The job of the architect is to do just enough architecture, just in time. The TOGAF Standard describes what the architecture description should contain, such as information about stakeholders, concerns, views (for example, the views of stakeholders – to address their concerns), and viewpoints. Separate and apart from the evolutionary state of the architecture is the form of architecture measured by its formality, which is a separate measurement of its completeness, soundness, and robustness. Obvious problem areas are the extremes, when:

The architect should have the experience to be able to apply a format of architecture that achieves the best result within the context of the architectural environment.

Digital products must adapt to their evolving ecosystem or they will lose their value. The digital products might become inefficient, obsolete, or too expensive to maintain. A well-constructed ecosystem that is adaptable, scalable, and flexible is the purpose of an architecture.

The TOGAF ADM provides guidance for understanding and describing the larger digital ecosystem in the form of Enterprise Architecture. The TOGAF Standard can also be used to partition the ecosystem into segment architectures, while digital products can be described as solution architectures.

As digital products and services increase in complexity, more rigorous forms of architecture can and should be applied to maintain the “Agile” aspects of digital products. The question becomes how much rigor to apply? Using guidance available in the TOGAF Standard, the Digital Practitioner can mitigate slow-downs in continuous delivery caused by complexity; for example, by evangelizing the rigorous and structured development of reusable components that are relatively easy to integrate. Conversely, the architect can select TOGAF components that help to address complexity and deselect components that are over-engineered for the context in which they are operating. The TOGAF Standard states that it should be adapted and “right-sized” for smaller or less complex environments.

Most importantly, the TOGAF Standard focuses on business outcomes described as valuable to the customer or end user. This aligns with how the value of digital products and services are measured. However, the Agile approach of “you build it, you operate it” may not be operationally efficient, especially when the digital product begins to embed itself into the core operational model of the technology infrastructure. The TOGAF Standard provides the framework that accommodates not only product architectures but entire capabilities in which the product participates.

This chapter provides a detailed overview of the four contexts of organizational evolution per the DPBoK Standard and their relationship to Enterprise Architecture and the TOGAF Standard. This chapter answers the questions:

The strategy for answering this last question is to present a set of Enterprise Architecture services that package the right set of activities within the TOGAF Standard to deliver value to the digital enterprise as needed per context of the emergence model. What is listed is a minimal set of Enterprise Architecture services that deliver Enterprise Architecture capabilities for decision-making in each context to ensure risk is understood, and to “peek-ahead” in preparation for going to the next context.

The DPBoK Standard identifies four contexts of organizational evolution toward a digital enterprise:

The DPBoK Standard presents these contexts as levels, where the enterprise moves from an earlier context to the next level of success. This is described as an emergence model where only the knowledge and activity essential to the level is presented, with enough foreshadowing, to prepare for the transition to the next level of emergence. It is our strategy to support this emergence model with Enterprise Architecture through our peek-ahead strategy. So, not only does the Enterprise Architect support the specific context, but also considers the next level and informs the Digital Practitioners of ways to position themselves to evolve. At the higher levels of the emergence model, the Enterprise Architect can play an essential primary role in enabling cross-team communication without adding to the cognitive load of the individual teams. In addition, the Enterprise Architects can ensure that the risks are clearly identified and communicated so that decisions can be made with an appropriate understanding of potential problems and difficulties.

Each of these contexts is described below in separate sections and for each the role of Enterprise Architecture is summarized along with a list of candidate Enterprise Architect services which might be leveraged by the Digital Practitioner to support their efforts.

This section answers the questions:

The following subsection identifies the TOGAF principles that directly support the intent of the DPBoK Standard and, in general, how and where they are applied in various emergence levels (contexts) of a digital enterprise. This is called the “principles aspect” of looking at the digital enterprise and the TOGAF Standard. Consideration was given to each of the principles from the TOGAF Standard, as listed in Appendix B, Principles from the TOGAF Standard.

Figure 2, “TOGAF Principles Mapped to DPBoK Standard Contexts” identifies which of the TOGAF principles are most applicable to each of the contexts of the DPBoK Standard. Descriptions of the principles and how they apply to the DPBoK contexts follow the matrix. If a principle is assessed as applicable to an earlier context it applies to all other later contexts.

The following principles from the TOGAF Standard that support the DPBoK Standard are presented per digital enterprise context.

Enterprise Architecture capabilities can be described as the ability to realize something within certain constraints and under certain conditions. Enterprise Architecture services are the delivery mechanism for Enterprise Architecture capabilities. In this section, we list the Enterprise Architecture capabilities supported by the TOGAF Standard that could be of use in each of the contexts of the DPBoK Standard, and then describe the Enterprise Architecture services that deliver those capabilities. The capabilities identified here were honed by analyzing both the implications of the principles in the prior section and the content from the DPBoK Standard – fundamentally by asking the question: “What Enterprise Architecture capabilities would be useful here?”.

Enterprise Architecture capabilities can be written in a manner such as: the Enterprise Architecting ability (skilled people, repeatable process, and material) to {do x} under circumstances {y} within time window {z}. Of course an Enterprise Architecture service can be engaged to deliver an Enterprise Architecture capability in any of the contexts, however it is understood that the emergence model does not need all services in all contexts.

Figure 3, “Enterprise Architecture Services to DPBoK Standard Emergence Model” summarizes the Enterprise Architecture services that should be considered per context to deliver Enterprise Architecture capabilities. The following sections elaborate on the Enterprise Architecture services and Enterprise Architecture capabilities most pertinent for each context. The Digital Practitioner would be wise to consider using the Enterprise Architecture services listed per context. The Enterprise Architecture service provider must consider the context and deliver in a timely manner, in line with the operation tempo of the given context.

This service category contains candidate services that enable requirements understanding – taking a step beyond requirements management, these services help get closer to real needs, which will deliver greater business value.

This service category contains candidate services that enable well-planned and executed architecture projects in support of organization change. These services would typically be provided in the beginning of a “project”, whether large or small, waterfall, or Agile.

This service category contains candidate services that enable good design decisions in support of organization change. These services would typically be provided after a project has been funded, whether large or small, waterfall, or Agile. These services include the development of MVAs and associated analysis to support the design decisions.

This service category contains candidate services that enable good development decisions in support of organization change. These services would typically be provided during the development phase of a project, whether large or small, waterfall, or Agile. These services focus on answering questions and providing enterprise analysis in support of development decisions.

This service category contains services that enable good enterprise decisions in support of organization change. These services could be provided independent of any individual project. These services focus on answering questions and providing enterprise analysis in support of more strategic decisions.

This service category contains candidate services that enable the development and management of an Enterprise Architecture practice. These services are focused on improving the Enterprise Architecture capability.

Each of the following aspects lists benefits and proposed Enterprise Architecture services that support the DPBoK Standard alignment area.