How the TOGAF Standard Serves Enterprise Architecture

Trying to document all the complexity of large enterprise systems can be overwhelming and difficult to know where to begin. Additionally, developing enterprise architectures that meet the strategies of the business, while still carrying good architecture qualities, can be challenging. The guidance and structure provided by TOGAF can help. It is a tried-and-tested framework that offers guidance on many aspects in enterprise architecture. Here, I would like to share with you the benefits of TOGAF, how to get started and additionally how to combine it with other methodologies.

Recently I set out to accomplish the TOGAF 9 Certification with various intentions. After much studying and preparation, I passed the two-part exam. But after the exam was complete, I ended up revering the comprehensiveness of the overall TOGAF standard, more than anticipated.

To demonstrate the value of the TOGAF standard, I will first provide a summary of the standard. I will then outline its contribution to enterprise architecture, provide guidance on applying it in your organization and explain how to adapt it to other methodologies. Because the standard is comprised of seven elaborate parts, only a select few will be highlighted for your benefit. It is encouraged to review the full standard for a better understanding. This summary will encourage you to adopt a mature, in-depth standard rather than organically growing your own.

To provide context, in the past eight years out of a 17-year technology career, I have been more focused on software, systems and solution architecture. Up to this point, I have produced 36 architecture designs within the areas of application, integration, cloud, UI, mobile and CI pipeline. Of those, 25 were implemented and are currently in-use or in a production environment. Although I still produce various types of technology architecture, my work has gradually shifted more towards enterprise architecture.

Much of my current work is centered around designing, overseeing, and governing a suite of transportation-based, online and retail applications, within the supply chain of a major apparel company. In this organization, I also actively participate as a board member on its architecture review board. This board handles architecture reviews, technology standardization, blueprints, and design guidance, as well as enforces security practices and establishes consistency in artifact format and quality.

In this organization’s case, the architecture review board structure and activities are home-grown and have evolved over the brief period since the board’s establishment. With my increasing involvement in enterprise architecture processes, activities and concerns, I wanted to formalize my experience with an enterprise architecture standard recognized by the industry. My goal of obtaining the TOGAF certification was to learn a comprehensive and well-respected enterprise architecture methodology. I wanted to build on my experience in the field, by learning a new discipline. Secondarily, I now hope to encourage organizations to establish and execute a comprehensive enterprise architecture practice.

The Value of Enterprise Architecture

So why is the TOGAF standard important? Or better yet, why is enterprise architecture (EA) important? Businesses thrive off change to deliver new products and services to earn revenue and stay relevant. But throughout a business’s lifetime, new systems are created, mergers require system integration or consolidation, new technologies are adopted for a competitive edge, and more systems need integration to share information. A well-defined and governed EA practice is critically important at an organizational level to confront, handle and manage these technological and computing complexities. Without an EA practice, there could be disconnects between systems, inconsistencies in solutions, miscommunications among product and engineering teams, duplication of engineering efforts and erosion of an organization’s architecture and solution quality.

Let us use a product startup company as an example. This startup could experience surging growth, rapidly advancing from nascent to emergent. The business and technology are experiencing brisk change. Without an EA practice, or at least some level of architecture guidance, the startup may quickly find its systems in disparity and unable to share information. The faster the company’s growth, the more imminent the threat becomes.

Another classic example demonstrating the need for EA is a merger or acquisition. When two companies merge, redundant systems will need to share information or perhaps consolidation will be required. For instance, there may be multiple HR systems for employees, needing to be integrated or consolidated into one. Improper integration will result in inability to share employee data, software bugs, miscommunication, over-communication and additional manual processes to achieve proper business continuity with the additional systems. Additionally, you may need to merge or convert EA frameworks to be under one model such as TOGAF.

In summary, leveraging a mature enterprise architecture standard such as TOGAF provides more efficient and effective IT operations. It offers a better return on investment, a reduced risk for future redundant expenditures and faster/cheaper procurement. All these benefits support more efficient business operations.

TOGAF Summary

The Open Group Architecture Framework, or TOGAF for short, is an enterprise architecture framework standard created by The Open Group organization. The standard is a methodology that includes a set of processes, principles, guidelines, best practices, techniques, roles, and artifacts. It is used for the development and governance of enterprise architectures to adequately address business needs. A well-put definition is stated in the certification study guide:

The purpose of enterprise architecture is to optimize across the enterprise the often-fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy.

To achieve this high-level objective, the standard suggests establishing several tactical elements underneath to support this. These elements include the following - guiding principles, a comprehensive architecture development method (ADM), a living architecture continuum, a living artifact repository, a governance structure, a capability framework and a reference model library. As you may see, some of these facets are structures, such as the continuum and repository. But other facets are processes, such as the iterative ADM architecture development method.

To better understand the components of the framework, below is the structure of the standard.

♦ Part 1: Introduction

• Defines common terms, within the context of the TOGAF standard. Examples include defining an enterprise, enterprise architecture, and architecture framework.
• Provides an overview of core concepts. Examples include the ADM, output types, continuums, repositories, capabilities, and using TOGAF with other architecture frameworks.

♦ Part 2: Architecture Development Method (ADM)

• The ADM is an iterative architecture development method, consisting of nine phases, that guides architects and organizations in the development and delivery of architectures.
  

(1) Section 5.2.2, TOGAF 9.1 standard

• Phases include defined activities/processes, expected inputs and outputs.

• Phases may be tailored to fit an organization’s needs. They may be iterated as a full cycle, adjacently or internally, as-needed.

♦ Part 3: ADM Guidelines and Techniques

▪    Guidelines provide alternatives to adapt the ADM process to deal with varying usage scenarios. An example includes how to apply iteration options to the ADM.

▪    Techniques are specific tactics to support tasks within the ADM cycle. Examples include identifying and applying architecture principles, leveraging architecture patterns, defining business scenarios and performing gap analysis.

♦ Part 4: Architecture Content Framework

• Defines a metamodel that categorizes outputs from architecture efforts. Examples include deliverables, artifacts and building blocks.
• Delineates between deliverables, artifacts and reusable building blocks. Provides specific content examples of each.

♦ Part 5: Enterprise Continuum and Tools

• Provides a method to classify architecture and solution assets to provide consistency and promote reuse. The Enterprise Continuum is comprised of two inner continuums: The Architecture Continuum and Solutions Continuum.
• The inner Architecture Continuum categorizes outputs (deliverables, artifacts, building blocks) with regards to rules, architecture designs, representations, and relationships. This analysis may be more in the abstract or related to principles the solutions need to support. The Architecture Continuum guides the Solutions Continuum.
• The inner Solutions Continuum provides actual methods to implement the assets in the Architecture Continuum, leveraging technologies and frameworks. It supports the Architecture Continuum.
• Both of the continuum architecture classifications are arranged horizontally – moving from the left (more generic or abstract,) to the right (more specific.) The four categories in each are Foundation, Common Systems, Industry and Organizational-Specific.

[Click on the image to enlarge it]

(1) Section 39.3, TOGAF 9.1 standard

♦ Part 6: Reference Models

• Provides very generic or abstract reference models of architecture and technologies that will meet common business objectives.
• An example includes the Technical Reference Model (TRM) architecture that provides generic services and functions as the foundation to more specific architecture.

♦ Part 7: Enterprise Capability Framework

• Provides organization structures, processes, roles, responsibilities and skills to establish and operate an enterprise architecture practice within an organization.
• An architecture capability is established with the support of an architecture board, compliance reviews, contracts, governance, maturity models and employee skills frameworks.

Application of the Standard

Having summarized the benefits of enterprise architecture and TOGAF, let’s discuss how to apply it in your organization. Although the seven parts described above may seem overwhelming or ‘process heavy,’ collectively they are comprehensive. View them as a blueprint to a residence or commercial building.

In TOGAF, these parts of the standard describe classifying your architectures, employing an iterative method to deliver architecture, the supporting organizational constructs, guidelines and techniques, governance, motivating principles, reference models, asset repositories and more. There is no need to reinvent these on your own.

But, you don’t need everything in the standard to be successful. One must be aware of what is offered and how to effectively apply it.

When introducing TOGAF (or any EA practice) a recommendation is to start small. For example, when undergoing implementation efforts, begin with associating the ADM phases with your organization’s project methodology. For each applicable phase, identify the required inputs and the ideal outputs. Execute the processes and activities within the ADM phases to deliver the outputs and expected results. For example, in creating a new target architecture, apply ADM Phases B, C, and D (Business, Information Systems, and Technology Architecture phases) to establish a baseline architecture, then perform a gap analysis to identify pitfalls. Another example of implementing EA is to begin with compiling your existing and net new architecture assets in an Enterprise Continuum. Establish an Architecture Content Framework and begin categorizing your artifacts, deliverables and building blocks.

Socialize the concepts and terminology with the technical, project, and stakeholder teams throughout the effort. Call out the wins that the TOGAF standard has helped deliver. Later, and when appropriate, you may introduce a more formal process. Introduce organizational aspects like an architecture board and governance practice that will need to be formally recognized. For a complete list of activities and considerations, see section 46 (version 9.1) of the TOGAF standard.

Adapting to Other Frameworks and Methods

Lastly, TOGAF acknowledges the occasional need to integrate its standard with other business, project or operation management methods. Every management method is motivated by its own concerns. TOGAF is concerned with quality architecture to meet business strategy. There may be a need to adapt it to other architecture frameworks such as the Zachman Framework. Look to the standard’s section 2.10 (version 9.1) for guidance of blending TOGAF with other frameworks. The methods noted include identifying the deliverables output from an architecture activity and then identifying in what activity or phase the outputs should be produced. Let’s explore two examples.

Example 1: Adapting TOGAF to an Agile Methodology

Agile development methodologies are widely used for developing and delivering technology-based projects in an iterative manner. Agile is development- and project-focused, to ensure products are delivered to meet the stakeholders’ concerns.

In comparison, the TOGAF ADM is more architecture-focused, to ensure the target architecture will support the stakeholder concerns and that it supports the long-term business strategy. The ADM should be employed when target architectures need to be delivered. Not all agile projects require the delivery of a new architecture (e.g. typically with smaller releases/epics) and hence, would not need to employ an ADM cycle. But still, the ADM is an iterative process as well. It is flexible – you may iterate around all eight phases; select only the relevant phases to iterate; iterate repetitively around adjacent phases; or iterate internally within a single phase. It is the best option for delivering a robust target architecture. Remember, the development team is depending on you to deliver a quality architecture product.

How would you employ the ADM as an enterprise architect, in conjunction with an agile development team? Let’s look at an example.

[Click on the image to enlarge it]

Foremost, timing is everything. Much of your introductory work in the Preliminary phase through Phase D needs to be done in advance of the development team receiving it for solutioning and implementation. This includes the following phases: Preliminary, Architecture Vision, Business/Information Systems/Technology architecture designs. Ideally, while the enterprise architect is working on his/her analysis, design and deliverables, the agile team is working on completing a prior release. Ideal timing is to deliver the last enterprise architecture outputs in Phase D just before the development team begins its solution and implementation entering their next agile release. Then, to follow through, the enterprise architect should provide oversight in the solutions phase to determine if a transition architecture is necessary. The architect should follow with the Migration Planning tasks (Phase F) and Implementation Governance tasks (Phase G) in the background, while the agile team is developing the solution. Agile team delivery should be supported by the ADM Phase H Architecture Change Management tasks.

Example 2: Adapting TOGAF to The Zachman Framework

It is unlikely for an organization to employ multiple enterprise architecture frameworks simultaneously, though one possible scenario is when a merger is underway. As an example, two merged organizations could be using different frameworks – the TOGAF standard and the Zachman Framework. In the long term, these might be reduced to one framework, but the two may need to coexist while merging is underway.

To clarify, the Zachman Framework is not a methodology, it is an ontology describing the enterprise structure applicable to architecture. TOGAF is a methodology that has the ADM as a process to deliver enterprise architectures, in addition to several of its other capabilities. However, adapting TOGAF to Zachman will demonstrate the flexibility of TOGAF. Additionally, this will prove a way for an organization to transition from Zachman to TOGAF, as TOGAF provides a more comprehensive solution than provided by Zachman.

First, assess the dimensions of the Zachman table model. Although it has evolved over time, a summary is as follows. Going across the table columns, you have interrogatives that pose a question for each What, How, When, Who, Where and Why. You may interpret these as cues or prompts as to what needs to be acted upon or delivered. Going down the table rows, you have the phase concepts for each Contextual, Conceptual, Logical, Physical and Detailed. You may interpret these as different perspectives requiring different outputs. Essentially the framework is involving all participants in a project and specifies what outputs they should produce to build a satisfying target solution. One might debate that the Zachman Framework is outside the realm of an architecture framework and is more of a project framework.

Having summarized the Zachman Framework, we may now adapt it to the TOGAF standard. Let’s look at an example.

[Click on the image to enlarge it]

To begin, you could interpret the Zachman table row concepts (contextual, conceptual, logical, physical, detailed) to phases of the project, rather than only perspectives. The Zachman Contextual row would align to the ADM Preliminary Phase and Phase A - Architecture Vision. The next Zachman row, the Conceptual, would have some overlap in the ADM Architecture Vision (Phase A) and the Business Architecture (Phase B.) The pattern would continue, with an occasional, slight misalignment needing interpretation.

Conclusion

Hopefully now you understand the value of the TOGAF standard and how it serves enterprise architecture. Indeed, it is an in-depth comprehensive, yet adaptable method to apply enterprise architecture to serve business needs. Please feel free to provide your feedback and experiences in the comments.  

About the Author

Will Stevens is a technology architect and consultant with several years of industry experience across many types of architecture, software engineering, cloud, UI, mobile. He has an M.S. in Computer Software Security, B.S. in Computer Science, several industry certifications, provides independent consulting and has independently launched 2 self-made products, Valloc.com and  SocialIntuition.co.