Here’s How TOGAF Can Help to Develop Your Enterprise Architecture

In the exhaustive list of enterprise architecture frameworks, TOGAF® is not the first and certainly not the last. But 80% of the Global 50 and over 60% of the Fortune 500 companies have been using it for almost two decades.

As this widespread use shows, TOGAF provides enterprises with a clear architectural framework on their path to success. But even TOGAF is not applicable in all situations. Those considering it needs to understand the structure’s fundamentals and possible trade-offs. This article will discuss who will benefit from TOGAF and who should avoid it. Let’s dive into TOGAF peculiarities.

Briefly about Enterprise Architecture

Enterprise architecture took shape in the 1960s through the IBM initiative. Then all the elements needed to work on the network were very complex. But even after a few decades, they have not become easier.

Therefore, regardless of their size or the product, most companies are trying to optimize their corporate performance. It’s not just about modeling business processes with rules and guidelines. It should also analyze the goals and indicators of their achievement, organizational structures (project and functional), the line of products/services created that generate income, and the infrastructure (hardware, software, and hardware) used for work.

All this forms a single system – the enterprise architecture, for the design of which many special approaches (frameworks) are used.

What is TOGAF®?

As mentioned above, the most popular today is TOGAF – meaning The Open Group Architecture Framework. It was created in 1991 by an international organization Open Group, with over 600 members from various industries, including Lockheed Martin, Nissan Motors, ExxonMobil, Microsoft, Oracle, and Amazon Web Services.

The Open Group defines the TOGAF model as “the de facto global standard for enterprise architecture.” TOGAF helps businesses align their IT goals with global business goals and orchestrate cross-departmental IT efforts like other IT management systems. The framework helps define and organize the requirements before the start of the project, ensuring the rapid progress of the process with minimal friction.

What is TOGAF used for?

This tried-and-tested framework helps businesses organize and meet their immediate needs by ensuring:

• That all key stakeholders will speak the same language. It means a common understanding of structure, content, and purpose and allows the entire enterprise to negotiate without communication barriers.
• There will be no “binding” to proprietary solutions for corporate architecture. For internal, non-commercial purposes, the platform is usually free.
• More efficient use of resources will be ensured, including savings in time and money.
• The company achieves a verifiable return on investment (ROI).

TOGAF Enterprise Architecture Principles

Architecture principles are rules and guidelines used at different enterprise levels to keep things running smoothly. Enterprises need them to manage their information management systems and other IT tools. TOGAF sets out a set of examples of 21 principles of high-quality architecture. It divides them into four parts and has:

• Name  – which is clear and easy to remember.
• Statement – defining what a principle is.
• Rationale – why principles are important and how they will benefit the business.
• Consequences – what is required to implement this principle and how it might affect the business.

In general, 10-20 corporate architecture guidelines are enough for an organization. We will return to them at the end of the article and consider the most useful ones from the enterprise’s point of view.

Four Architectural Pillars of TOGAF

Enterprise architecture is “the fundamental organization of a system, embodied in its components, relationships, environments, and the principles that govern its design and development.” But TOGAF not only covers but also expands this definition. Depending on the context, “architecture” in TOGAF can have two meanings:

• A formal description or a detailed system plan at the component level to guide architecture implementation.
• The structure and relationship of components and the principles and guidelines that govern their design and evolution.

The framework proposes to describe the enterprise architecture in terms of the following main domains:

1. Business: the corporate strategy, management structure, and key business processes
2. Data: the logical and physical structure of an organization’s data, including corporate resources to manage it;
3. Applications: a list of all used corporate information systems and software applications with a description of their participation in the company’s business processes, as well as interaction with each other and external services;
4. Technologies: the structure and logic of the software and hardware environments necessary for the operation of business applications and data access. It includes a description of the entire supporting infrastructure: networks, servers, processing, etc.

TOGAF is unique in architectural design because it places business needs at the center of all project activities. It guides organizations through the business processes, data and information, and technology changes required to implement their strategies. TOGAF methodology can help in business planning, implementation, and support:

• Massive technological shifts;
• Business transformation projects;
• Creation of new divisions;
• New compliance initiatives;
• Attempts to enter new markets;
• Development of new products or services;
• Restructuring of divisions within the business;
• Integration of key technologies and cultural elements and processes, and capabilities.

What are TOGAF components?

• The Architecture Development Method (ADM)

Aim: How to manage enterprise architecture?

• ADM Guidelines and Techniques

Aim: How to apply the ADM?

• Architecture Content Framework: deliverables, artifacts, building blocks

Aim: How to map out all the information?

• The Enterprise Continuum: the architecture repository

Aim: How to maximize the recycling of existing architectures?

• TOGAF Reference Models

Aim: How to create industry-practice models?

• The Architecture Capability Framework: Establishing an EA Capability

Aim: How to design enterprise architecture?

TOGAF Architecture Design Model

TOGAF defines not only the purpose of the four architectural domains but also how the company should create architecture. This specification is called the Architecture Development Method (ADM).

The ADM is an eight-step sequential process, as shown below. The method is extensible and can develop the company’s architecture for a specific IT solution. You can also apply it with other, more specialized methods for particular tasks and industry methods and standards.

• The Preliminary Phase is to identify persons interested in the implementation process and discuss the functions of the EA with them. During this phase, Architecture Guiding Principles are being developed based on the organization’s business principles which describe the processes and criteria for overseeing the AP implementation process.
• Phase A is for expressing the AP’s vision. Architecture Vision uses the business drivers to define the purpose of the EA activities and create first-cut descriptions for the base and target environment. If the business objectives are not obvious, then part of this phase is to help the company identify its major goals and the corresponding processes that the EA must support. In this phase, a special document called the Statement of Architectural Work is created, outlining the scope and conditions of the AP.
• Phase B is for the detailed development of the business domain architecture. It provides details of the base and target architectures outlined in the Architecture Vision document to provide useful input for technical analysis. This phase uses various business modeling techniques and notations.
• Phase C is associated with the creation of the architecture of the subject areas “Application” and “Data (Information).” This phase describes the current and development of the target architecture of information systems. It also uses special techniques, approaches, and notations associated with data and applications.
• Phase D focuses on describing and developing the technological architecture (networks, nodes, computing devices, technological interfaces, etc.).
• The goal of Phase E is to figure out the capabilities offered by the target architecture and sketch out a potential solution. Work in this phase centers on the applicability and practicality of implementation alternatives. A realization and implementation plan is created in this phase, and major projects are identified.
• In phase F, detailed planning is carried out, implementation projects are prioritized, and the migration process gap analysis is performed. This task includes assessing dependencies between projects and minimizing their net impact on enterprise functions. Also, the list of projects is updated at this stage, and the “Implementation and Implementation Plan” is detailed.
• Once the project specification is approved, the focus shifts to planning more specific conditions and recommendations for each implementation project. During phase G, a link is established between the governing architecture (TOGAF) and the development organization (which can be configured using RUP and the Project Management Body of Knowledge (PMBOK), for example, or any other project management methodologies). The selected projects are implemented under the control of traditional architecture. At the end of this phase, we have “Architectural Contracts” approved by the developer organization. The final output of Phase G is architecture-compatible solutions.
• In phase H, the emphasis shifts to managing architecture change, achieved by delivering implemented solutions. In this phase, an “Architectural Task Requirement” can be created, setting goals for subsequent iterations of implementing the AP.

These steps or activities are performed iteratively in a loop as the enterprise architecture is defined and implemented. Since the business is constantly changing, the architecture must change with it. Wherever there is a change in the business strategy or vision statement, it should be a cue to look at what needs to be changed in the architecture. Even if the business follows the same strategy, you should review applications and technology architectures to keep up with new hardware and software releases and other changing conditions.

What is Good about TOGAF?

TOGAF is suitable for implementing very large systems in very large companies. It is indispensable when creating architectures designed to work across the enterprise.

TOGAF structure comprises 52 chapters and is divided into two groups, including the main content of TOGAF and the advanced manual. The entire range contains the fundamentals and best practices of TOGAF, which provide the basis for its structure. The extended portion of the TOGAF guide includes guidance on specific topics such as Agile, Business Architecture, Data and Information Architecture, and Security Architecture.

TOGAF is not prescriptive and does not require the use of certain technologies and practices. It stays at a high level of abstraction. However, it can work with other methodologies, such as Agile and DevOps, as it supports versatility and adopts an iterative model, an important component of Agile.

With TOGAF, you can use any approach that makes sense from an architectural perspective, as long as it is well-defined and well-known. TOGAF understands that this is best for companies that are well-structured organizations but also understands that no two companies are the same. TOGAF also demands that the risks inherent in a technical solution be identified and mitigation plans activated.

TOGAF is large, detailed, and abstract, and these qualities allow it to be used in a wide variety of companies. However, even with such versatility, TOGAF is not a perfect fit for everyone. It has certain limitations.

TOGAF Limitations

As noted previously, TOGAF is for large companies who want to implement large enterprise architectures with a million-dollar budget and thousands of employees. So, the key limitations are size and price. The company must be large and wealthy enough to cover the costs. If your starting capital is $100,000, TOGAF is not for you.

Another limitation of TOGAF is that it is designed for companies with a hierarchical structure and divisions. But if you have a flat management hierarchy and an independent workforce like other small companies present in the open-source landscape, TOGAF is probably not for you.

The final limitation is that it takes a long time to learn the details of the specification. The TOGAF specification is over 800 pages long. That’s a lot of information to consume and remember.

What is TOGAF Certification?

Although detractors say that TOGAF is good in theory but rarely applied, it still holds a prominent place in the enterprise architecture landscape. Typically, companies intending to use TOGAF want their enterprise architects to be TOGAF certified because it:

• Confirms their ability to simplify complex technical processes and allows them to flash up the career ladder.
• Is used by the world’s leading enterprises to certify a common body of core knowledge of methodology and structure.
• Is valuable for demonstrating to employers and colleagues your commitment to enterprise architecture as a discipline.

PayScale research shows that 77,000 TOGAF-certified enterprise architects, software architects, and CIOs have higher annual earnings than their non-certified counterparts.

Candidates must complete a course and pass an exam. Part 1 is a 40-question test that tests your basic knowledge of the TOGAF structure. Part 2 is a scenario-based test that describes different situations.

As you can see, experience is necessary for competent work with TOGAF. If you want to work for a large company that will benefit from it, then TOGAF is for you. Otherwise, its professional value is limited.

TOGAF vs. ITIL

TOGAF and ITIL® are the two most famous governance frameworks, each describing a common interest in managing IT services and operations in an IT-driven organization.

However, the difference between them is that:

• ITIL is focused on service management.
• TOGAF is concentrated on the development and management of the enterprise architecture.

ITIL and TOGAF are more often used to achieve better organizational fit, security, and overall digital resilience. In short, if you want to build your IT system and then run it, then TOGAF will tell you how solution architects make IT, and ITIL will tell you how to create a set of processes to support IT.

How many TOGAF architecture principles does an enterprise need?

Of all the TOGAF architecture principles, here are a few that your organization may find useful.

1. Benefit to the enterprise must be maximized

All information management decisions MUST be made for the benefit of the enterprise. That means that sometimes what seems best for one organization within an enterprise may not be the best for the enterprise.

2. Information management is everyone’s business

This TOGAF principle states that “all parts of the enterprise should be involved in all aspects of the information environment.” In fact, this is another principle of the importance of collaboration in the enterprise. Everyone must contribute to information management and participation in important decision-making.

3. Business continuity first

This principle states that “equipment failure, natural disasters, and data corruption should not disrupt or stop the operation of the enterprise.” Even though we depend on technology systems to do our jobs, it must also prepare you to keep the business running even if those systems fail.

4. Data is a valuable asset

All data is a concrete and valuable asset for the enterprise. That is a real, measurable resource. Everyone in the enterprise needs to know that their information is reliable and accurate and to have access to relevant data when needed. Since all decisions in the enterprise are based on data, all this data must be carefully organized and managed.

5. Data must be transferred

This principle states that data should be stored in one application and shared across the enterprise. It is much cheaper and simpler to store all the data in one application than keep it in different applications. This is important to ensure that all enterprise employees access the data they need to work.

6. Data must be available

One of the “implications” of that principle is that there must be some flexibility to ensure that all people in the enterprise can conveniently access the data. It means that everyone in the enterprise should have easy access to all the data in that enterprise to do their job.

7. All enterprise technologies should be easy to use

To ensure that everyone can do their job effectively and efficiently, keep technology simple. The more time and resources you spend figuring out how to use technology, the less time you have to tackle the real problem. It means lower productivity and concentration, which is never good.

8. Control Technological Diversity

While there are bound to be some different technical requirements for various applications in an enterprise, this principle declares that you should try to keep the multiple technologies to a minimum. The more different technologies you use, the more expensive and problematic it becomes for your enterprise.

Conclusion

TOGAF is not a miracle tool, but it provides a framework to help teams and senior management avoid reinventing the wheel every time a company wants to implement new technology.

It is especially important if the company is growing rapidly because then it will be difficult to catch up on the go. In addition, the right technical team is needed, which can skillfully manipulate the structure and behavior of the enterprise in a complex environment.

Contact us if you want to keep up with new technologies and trends and do great things with TOGAF. We will provide you with the people and tools to help you adopt, produce, use, and maintain your enterprise architecture.