TOGAF 10 and enterprise architecture

TOGAF 10 and enterprise architecture

The idea of ​​creating a model of ideal enterprise architecture has existed for quite some time. There are different methodologies, standards, templates that describe different options for creating architecture. The TOGAF platform (The Open Group Architecture Framework) is a widely used solution for building an enterprise architecture that provides a common language, methodology and tools for designing, planning and implementing an organization’s IT infrastructure. One of the key components of TOGAF is the Architecture Development Method (ADM), which describes a step-by-step process for creating and managing an enterprise architecture. Within ADM, there are various methods that can be used to develop an organization architecture. In the framework of this article, we will consider some of them.

The TOGAF standard is the basis of enterprise architecture. It is free to use by any organization that wishes to develop an enterprise architecture for internal use.

Freedom of change

Although all TOGAF documentation is unified, it is accepted that organizations will change it during the implementation process and deliberately choose some elements, customize, exclude unnecessary ones and create their own. For example, an organization may want to implement the TOGAF metamodel, but forgo any internal technology architecture development guide because it is an active consumer of cloud services.

Before starting work with TOGAF, it is worth answering some fundamental questions, for example, why do you need an enterprise architecture or why use the TOGAF standard as a basis for architecture.

The term “Enterprise” in the context of “Enterprise Architecture” can be applied either to the entire enterprise as a whole, covering all its activities, information and technologies that make up the entire infrastructure and management of the enterprise, or to one or more specific areas of activity within the enterprise. An enterprise may include partners, suppliers, and customers, as well as internal business units. In all cases, the architecture encompasses multiple systems and functional groups within the enterprise.

Many organizations may include multiple businesses and may develop and maintain a number of independent enterprise architectures to address each. These enterprises often share much in common, including processes, functions and their information systems, and there is often great potential for greater use of a common architecture. For example, a common framework can provide a framework for developing common elements and solutions, as well as a shared architecture repository for the integration and reuse of business models, projects, information, and data.

Main goals

The goal of enterprise architecture is to optimize enterprise-wide, often fragmented legacy processes (both manual and automated) into an integrated environment that responds to change and supports the implementation of business strategy.

Effective management and use of information, as well as digital transformation, are key success factors in business and necessary means of achieving competitive advantages. Enterprise architecture meets this need by providing a strategic context for the development and expansion of digital technology capabilities in response to the needs of an ever-changing business environment.

In addition, good enterprise architecture allows for the right balance between business transformation and ongoing operational efficiency. It enables individual business units to safely innovate in pursuit of changing business goals and competitive advantages. At the same time, the enterprise architecture allows meeting the needs of the organization with the help of an integrated strategy that provides the maximum possible synergy both inside the enterprise and outside it.

Finally, data protection law requires that processes related to personal data are fully documented in a way that can be easily understood by untrained readers such as data subjects, judges and lawyers. It is clear that the creation of this basic documentation stems from fundamental considerations that have changed, and this is now crucial.

Application of the TOGAF architecture

Consider the main areas of the architecture, which are usually considered subsets of the overall enterprise architecture and are supported by the TOGAF standard.

  • First of all, it is the business architecture (Business Architecture), which defines the business strategy, management, organization and key business processes used in the organization.

  • Data Architecture is used to describe the structure of the organization’s logical and physical resources, and even data management resources.

  • The application architecture (Application Architecture) provides a scheme for the deployment of individual applications, their interaction and interconnection with the main business processes of the organization.

  • And finally, the technology architecture (Technology Architecture) describes the digital architecture and logical capabilities of the software and hardware infrastructure, as well as the standards needed to support the deployment of business services, data services, and applications. This section includes digital services, Internet of Things (IoT), social network infrastructure, cloud services, IT infrastructure, middleware, networks, communications, data processing, standards, etc.

There are also many other areas that could be defined by bringing together relevant business, data, application and technology insights.

ADM method

The ADM architecture development method, already mentioned at the beginning of the article, provides a proven and reproducible architecture development process. This method includes the creation of an architectural framework, the development of architectural content, the transition and management of the implementation of various enterprise architectures.

The architecture development and implementation process is a continuous cycle in which enterprises transform the current architecture according to current business goals and objectives.

Next, we will consider the stages of ADM presented in the figure. At the preliminary stage (Preliminary), the measures necessary for the operation of the TOGAF platform and the definition of the principles of the architecture are described.

In the initial step A, we need to identify the current problems, sketch out the solution and define the overall strategy for the transition to change.

In phase B, we describe the development of the business architecture to support the agreed architectural vision presented in phase A. Phase C describes the development of the information systems architecture to support the agreed architectural vision. The technology architecture in step D describes the development of the technology architecture supporting the agreed architectural vision.

Stages A-E are some understanding of the problem and development of the necessary architectural vision.

Next, at stage E, the initial planning of the interaction of those architectural solutions, which we defined in the previous stages, is carried out. Phase F defines how to move from the base architecture to the target architecture by completing the development of a detailed implementation and migration plan.

In phase G, we provide architectural oversight of the implementation of the plan developed in step F. And the final phase H establishes procedures for managing changes to the new architecture, such as ensuring proper planning, structuring, and obtaining expected business values.

All these stages are managed by Requirement Management, which manages the architecture requirements within ADM.

In general, the description of the ADM stages in TOGAF focuses on recommendations about what can be done to define and deploy an enterprise architecture.

Artifacts and building blocks

The results of using ADM are technological processes, architectural requirements, project plans, assessment of project compliance with requirements, etc.

The Architecture Content Framework uses the following three categories to describe the type of work product in a context of use:

The end result is the work product that is stipulated in the contract and, in turn, formally reviewed, approved and signed by the interested parties

Final deliverables are the raw data of projects, and what is represented as documentation is usually archived after the project is completed or transferred to an architectural repository as a reference model, standard, or snapshot of the architectural landscape at a point in time.

The next type is artifact. This is a work product that describes one aspect of the architecture. Artifacts are usually classified as catalogs (lists of items), matrices (showing relationships between items), and diagrams (images of items). Examples include a requirements catalog, an application interaction matrix, and a value chain diagram. An architecture deliverable may contain one or more artifacts, and the artifacts will form the contents of the architecture repository. An artifact may or may not be considered a deliverable depending on the contract specification.

Structural block is a component that can be combined with other building blocks to create architectures and solutions. Building blocks can be reused.

Structural blocks can be defined at different levels of detail, depending on the stage of architecture development. For example, at an early stage, a building block may simply consist of a title or a general description. Later, the building block can be broken down into several supporting building blocks and can be accompanied by a complete specification. Building blocks can belong to “architectures” or “solutions”. And then there are two more abbreviations that are often used in TOGAF.

Architecture Building Blocks (ABB) usually describe the required capabilities and form a solution building block (SBB) specification; for example, an enterprise may need customer service capabilities supported by multiple SBBs, such as processes, data, and application software

Solution Building Blocks (SBB) are the components that will be used to implement the required capabilities. For example, a network is a building block that can be described with additional artifacts and then used to implement enterprise solutions.

Below is the interaction between artifacts and building blocks.

For example, an architecture definition document is the end result that documents the architecture description. This document will contain a number of additional artifacts representing the building blocks of architecture. A block diagram of the process (artifact) can be created to describe the process of processing the target call (structural block). This artifact can also describe other building blocks, such as process participants (for example, a customer service representative).

Below is an example of such a relationship:

Conclusion

In this article, we have considered some of the main points related to the use of the TOGAF 10 platform to build an enterprise architecture.

Assessing business readiness for TOGAF transformation is important for understanding the current state of the company and successfully implementing changes. It allows you to identify weaknesses and risks that can hinder the transformation, as well as to determine the necessary resources and set priorities. Helps create a realistic roadmap aligned with the business objective. We will talk about evaluation and transformation at a free webinar that will be held today.

And on the course page, you can view recordings of previous webinars.

Related posts