TOGAF 10 and enterprise architecture
The idea of creating a model of an ideal enterprise architecture has been around for quite some time. There are various methodologies, standards, and templates that describe different options for creating architecture. TOGAF (The Open Group Architecture Framework) is a widely used enterprise architecture solution 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's architecture. In this article we will look at some of them.
The TOGAF standard is the basis for enterprise architecture. It can be freely used by any organization wishing to develop an enterprise architecture for internal use.
Freedom to change
Although all TOGAF documentation is a cohesive whole, it is acceptable that organizations will change it during the implementation process and intentionally select some elements, customize them, eliminate unnecessary ones, and create their own. For example, an organization may want to implement the TOGAF metamodel but not use any guidance for developing its internal technology architecture because it is an active consumer of cloud services.
Before you start working with TOGAF, it's worth answering some fundamental questions, such as why enterprise architecture is needed 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, encompassing all of its activities, information and technologies that make up the entire infrastructure and management of the enterprise, or to one or more specific activities within the enterprise. An enterprise can include partners, suppliers and customers, as well as internal business units. In all cases, the architecture spans multiple systems and functional groups within the enterprise.
Many organizations may include multiple enterprises and may develop and maintain a number of independent enterprise architectures to address each of them. These businesses often have much in common with each other, 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 integrating and reusing business models, designs, information, and data.
Main goals
The goal of enterprise architecture is to streamline often fragmented legacy processes (both manual and automated) across the enterprise into an integrated environment that responds to change and supports the execution of business strategy.
Effective management and use of information, as well as digital transformation, are key factors for business success and essential means of achieving competitive advantage. Enterprise architecture addresses this need by providing a strategic context for developing and expanding digital capabilities in response to the ever-changing needs of the business environment.
In addition, good enterprise architecture achieves 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 advantage. At the same time, enterprise architecture allows you to meet the needs of the organization with an integrated strategy that creates the greatest possible synergy both within and outside the enterprise.
Finally, personal data protection law requires that processes related to personal data be 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 arises from changed fundamental considerations, and this is now critical.
Application of TOGAF architecture
Let's look at the major architecture areas that are typically considered subsets of the overall enterprise architecture, all of which are supported by the TOGAF standard.
First of all, this is the Business Architecture, which determines the business strategy, management, organization and key business processes used in the organization.
Data Architecture is used to describe the structure of an organization's logical and physical resources, as well as data management resources.
Application Architecture provides a blueprint for how individual applications are deployed, how they interact, and how they relate to the organization's core business processes.
Finally, the 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, data, and application services. This section includes digital services, Internet of Things (IoT), social networking infrastructure, cloud services, IT infrastructure, middleware, networks, communications, data processing, standards, etc.
There are also many other areas that could be defined by combining relevant insights from business, data, applications and technology.
ADM method
The ADM architecture development method, which was already mentioned at the beginning of the article, provides a proven and repeatable process for developing architectures. This method includes creating the architectural framework, developing architectural content, transitioning, and managing the implementation of various enterprise architectures.
The architecture design and implementation process is a continuous cycle in which enterprises transform their current architecture to meet current business goals and objectives.
Next we will look at the stages of ADM presented in the figure. The Preliminary stage describes the activities required to operate the TOGAF platform and defines the architectural principles.
In the initial step A, we must identify the current problems, sketch a solution, and define an overall strategy for transitioning to change.
In Phase B, we describe the development of the business architecture to support the agreed upon architectural vision presented in Step A. Phase C describes the development of the information systems architecture to support the agreed upon architectural vision. The technology architecture in step D describes the development of the technology architecture to support the agreed upon architectural vision.
Stages A-E represent some understanding of the problem and the development of the necessary architectural vision.
Next, Stage E carries out initial interaction planning for the architectural solutions that we identified in the previous stages. Phase F determines how to move from the base architecture to the target architecture by completing 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 delivery of expected business values.
All these stages are managed by Requirement Management, which manages the architectural requirements within ADM.
In general, TOGAF's description of the ADM phases focuses on recommendations for what can be done to define and deploy an enterprise architecture.
Artifacts and building blocks
The outputs of ADM are workflows, architectural requirements, design plans, design compliance assessments, etc. The TOGAF architectural content framework provides a structural model of architectural content that allows core work products to be consistently defined, structured, and presented.
The architectural content framework uses the following three categories to describe the type of work product in the context of use:
End result is the work product that is specified in the contract and, in turn, formally reviewed, approved and signed by the interested parties
The deliverables are the outputs of projects, and what is presented as documentation is typically archived upon completion of the project or submitted to an architectural repository as a reference model, standard, or snapshot of the architectural landscape at a specific point in time.
The next type is artifact. This is a work product that describes one aspect of the architecture. Artifacts are typically classified as catalogs (lists of elements), matrices (showing relationships between elements), and diagrams (representations of elements). Examples include a requirements catalog, an application interaction matrix, and a value chain diagram. An architectural deliverable may contain one or more artifacts, and the artifacts will form the contents of the architectural 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.
Building blocks can be defined at different levels of detail, depending on what stage the architecture is in development. For example, at an early stage, a building block may simply consist of a title or a general description. The building block may later be broken down into several supporting building blocks and may be accompanied by a complete specification. Building blocks can refer to “architectures” or “solutions”. And then there are two more abbreviations that are often used in TOGAF.
Architecture Building Blocks (ABB) typically describe the required capabilities and formulate a solution building block (SBB) specification; for example, an enterprise may require customer service capabilities supported by many SBBs such as process, data, and application software
Solution Building Blocks (SBB) represent the components that will be used to implement the required capabilities. For example, a network is a building block that can be described using 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 an end result that documents a description of the architecture. This document will contain a number of additional artifacts that are representations of building blocks related to architecture. A process flow diagram (artifact) can be created to describe the process of processing a target call (structural block). This artifact may 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 examined some of the main points related to the use of the TOGAF 10 platform for building enterprise architecture.
Assessing the readiness of a business for transformation according to TOGAF is important for understanding the current state of the company and successfully implementing changes. It allows you to identify weaknesses and risks that may hinder the transformation, as well as identify the necessary resources and set priorities. Helps create a realistic roadmap aligned with business goals. About assessment and transformation Let's talk in a free webinarwhich will take place today.
And on the course page you can look recordings of previous webinars.
