Anyone who reads about Enterprise Architecture (EA) will find mention of TOGAF. They’ll see it positioned as the staple EA Framework, a tried-and-tested structure that many companies use to guide their architectural development. It is a good framework, but many factors need to be considered when adopting the process.
This article will provide the information needed to seriously consider TOGAF as an enterprise business tool. It will explain TOGAF in-depth, run through its goals, detail its strengths and limitations, explore its structure, consider alternatives, and offer some implementation tips.
Jump to:
What are the Benefits of TOGAF?
What are the Four Pillars of TOGAF Architecture?
What is the TOGAF Architecture Development Method (ADM)?
What is the Enterprise Continuum?
Implement TOGAF Framework With Ardoq and Prepare Any Organization For a Successful EA Project
What is TOGAF?
TOGAF, meaning The Open Group Architecture Framework, is an EA Framework designed to help large organizations map and efficiently develop their IT infrastructure. It can help an enterprise align its business goals and IT strategy, enabling it to manage its technology infrastructure effectively.
TOGAF comprises a broad set of principles, guidelines, and best practices for developing and maintaining EA, supporting consistency, interoperability, and flexibility in IT systems. The first version was released in 1995 by a software consortium that would become The Open Group, and it’s been built upon in numerous versions made available throughout the years since.
To support and promote TOGAF, the Open Group has developed a comprehensive training and certification program to ensure that TOGAF
practitioners have appropriate expertise and up-to-date knowledge.
What is the Goal of TOGAF in Enterprise Architecture?
Managing the development of an enterprise-level organization is difficult, as numerous operational elements complicate efforts to understand the top-down view needed to select and implement major changes.
Using TOGAF to model and analyze its architecture, an organization can more straightforwardly determine how well its infrastructure serves its business objectives. It can then devise, prioritize and implement architectural changes to help it achieve its targets through improved standardization, efficiency, and productivity.
Additionally, mapping the EA process using TOGAF principles reduces the need for EA resources, including guides and consultants, saving time and money.
Overall, TOGAF's goal is to enable the organization to develop and maintain an Enterprise Architecture that supports business agility, strategic decision-making, and successful IT implementation.
Although it is not the right fit for every operation, it has become the preferred enterprise framework for many organizations.
Is TOGAF a Governance Framework?
TOGAF is a framework intended to address the full breadth of EA mapping and management. Accordingly, although not a governance framework per se, it does cover governance at some length, laying out best practices for aligning objectives, ensuring legal and ethical data management, and defining required roles and departmental structures.
However, a framework entirely about governance will usually touch upon areas outside of TOGAF, such as in-depth HR management and corporate goals, that do not require strict architecture.
Who Uses TOGAF?
The Open Group’s blog asserts that “80% of Global 50 companies and 60% of Fortune 500 companies utilize TOGAF when designing their architectures”, but it’s hard to say how accurate this is as it offers no evidence or citation.
It’s more useful to think instead about the type of organization that benefits, or can benefit, from the standard modules and processes provided within TOGAF and to consider how the people using it engage with the tools they choose to implement.
Which Organizations Suit TOGAF?
TOGAF is sufficiently comprehensive to be workable for any organization, so any organization intent on undergoing digital transformation can find value in applying elements of TOGAF to its EA development. Nevertheless, this doesn’t mean it’s a universal fit, and it isn’t right for every business.
Organizations with complex infrastructures are best suited to using TOGAF, as that complexity can justify the investment required in TOGAF and how best to apply it. A successful application can result in a standardized architectural chart that uses boilerplate terms and formats to mitigate the obscurity borne of an industrial niche.
Vast organizations within sectors such as healthcare, finance, and telecommunications can use TOGAF to produce standardized overviews and use them to reduce the complexity of their systems, leaving them more adaptable and easier to manage.
Of course, there are many reasons why an organization may wish to refrain from using TOGAF. Here are just some to consider:
- It might lack the necessary resources to apply TOGAF without making significant investments in training, time, or external consultants.
- It might use few IT systems, making such a huge framework unnecessary.
- It might exist in such a narrow niche that adapting a generic framework would be counterproductive.
- It might change its infrastructure so often that part of a framework would soon become outdated.
What Professionals Engage With TOGAF?
Not everyone within an enterprise will engage with TOGAF, as it is complicated and can be inaccessible to those without architectural experience. However, those professionals who typically work with the framework include:
Enterprise Architects
Some organizations hire or train full-time EAs to develop their EA practices, while others work with third-party EAs when needed. Either way, EAs are responsible for the adoption of TOGAF and getting other relevant contributors involved. EAs tasked with using TOGAF will generally be TOGAF certified. The Open Group reports that this includes over 100,000 people worldwide.
CIOs (Chief Information Officers)
CIOs of organizations using TOGAF must govern the overall use and management of information technology. They must ensure that IT assets are properly documented, decision-makers are kept apprised of resource allocation, and core business goals are given top priority. The better they understand the elements of TOGAF, the more swiftly they can align IT initiatives with business objectives.
IT Managers
While CIOs oversee IT operations, IT managers ensure smooth day-to-day processes. In organizations using TOGAF, IT managers must turn the meta-level infrastructure analysis into regular actions. They must also justify major changes to their user population. Therefore, they must understand things well enough to see them from both top-down and bottom-up perspectives.
System Architects
Just as EAs design overall business infrastructure, System Architects design organizations’ component systems. They find or develop suitable applications and technologies, ensure that best practices are followed for data storage and protection, clearly document processes, and take charge of resolving any problems that arise. When TOGAF is implemented, System Architects handle the system-level analysis, performance report, and recommendation of optimizations.
Business Analysts
Business analysts can benefit from the structured methodology and framework of TOGAF when designing and managing business processes and IT systems. The standards within TOGAF can help them align their business objectives and IT strategies, document current and planned architecture, and identify methods and technologies worth testing or immediately implementing.
What Are the Benefits of TOGAF?
When applied in the right circumstances, TOGAF can help an organization in a number of ways. Some of the key benefits include:
1. Streamlined IT Operations
Given the scope and depth of modern IT infrastructure, finding ways to get things running more smoothly is hugely important. By clearly framing available processes, roles, and assets, TOGAF can improve the overall understanding of how things work, improving IT efficiency.
Adding insight into system and application use can also drive efforts to reduce redundancy and ensure that every resource is returning optimal value. Wasteful or overly convoluted components can be phased out, leaving room for investment in effective solutions or promising innovations.
2. Better Strategic Alignment
The internal goals of IT departments do not always resemble the business goals of the operations around them, which can cause problems.
TOGAF helps bridge the gap between business and IT by providing a framework for aligning IT strategies and capabilities with business goals and requirements. As a result, the organization can make better-informed decisions, prioritize investments, and achieve a more effective IT-business integration.
3. Improved Interoperability
The gaps between different IT systems can lead to loss. Resources that should be shared can end up siloed, and limited communication can result in redundant or poorly optimized operations. Mapping everything out through TOGAF can show where these gaps are slowing things down and inform the production of interoperability standards and guidelines capable of establishing tight-knit processes.
4. Standardized Architectural Framing
As TOGAF is ubiquitous within Enterprise Architecture, adapting it to map an organization makes it easier to work with third-party consultants and saves time and effort by using established methods designed to suit TOGAF modules.
4. Risk Management and Appliance
TOGAF integrates governance and risk management practices, thereby assisting organizations in identifying and managing the risks associated with IT architecture. Its adoption promotes compliance with industry regulations, security standards, and organizational policies.
What Are the Limitations of TOGAF?
Despite its notable benefits, TOGAF is far from a perfect solution to Enterprise Architecture woes. Here are some of its main limitations:
1. It is complex and costly. Though the sheer breadth of TOGAF can be considered a strength, it’s also a huge problem when trying to justify investment. It is so complicated, including concepts, methodologies, and artifacts, that implementing it will be expensive and time-consuming, no matter the team in charge.
2. It is geared toward standard infrastructure. As TOGAF was developed to be widely applicable, it best fits generic Enterprise Architecture. Any business that operates differently will struggle to make it work, inevitably need to make concessions, and likely require additional investment.
3. It is too big to use as a whole. TOGAF is an enormous framework packed with more tools, methods, and best practices than even a mammoth enterprise organization can accommodate. It also won’t fit any business perfectly. To use it well, an organization must first pore over it and identify the applicable parts.
4. It does not deliver broad accessibility. While TOGAF's standardization is useful for EAs and others with relevant experience, it doesn’t usually mean much to others. Deploying TOGAF likely won’t necessarily make it any easier for stakeholders to understand what’s going on. A framework needs to be readily comprehensible to aid cross-departmental strategy.
What Are the Advantages of Not Using an Enterprise Architecture Framework?
The limitations of TOGAF are such that some organizations don’t stand to gain much from using it. This isn’t entirely specific to TOGAF, however. EA Frameworks, in general, share some issues that make them hard to recommend. Most concerningly, they can focus rigidly on documentation while assuming (or perhaps hoping) that it will ultimately return value. Still, when the deliverables are done, no one knows what to do with them.
Since using a framework isn’t obligatory, then, it’s worth looking at the advantages of going without one. Launching an EA project without a framework can seem intimidating, but two core reasons can make it the right call:
- It facilitates focus on key goals. Leveraging the benefits of Enterprise Architecture is supposed to bring an organization closer to its business objectives, but getting stuck on a framework can impact this. Organizations that go to great lengths to implement frameworks like TOGAF can be left trying to figure out how to make the deliverables return value. This order doesn’t make sense.
If a business instead starts by identifying what it wants to achieve, it can then decide what documentation and modeling will help it achieve its goals. Every facet of the resulting project will serve a clear purpose to all stakeholders, getting everyone on the same page and showing the value of EA optimization. - It requires minimal initial investment. Even the cost of getting a framework like TOGAF approved can be high; it takes time to trawl through case studies and create presentations to win over decision-makers, especially given the noted inaccessibility of EA Frameworks.
Going without such a framework requires far less of an initial investment, making it much easier to sell.
Once the first steps have been taken (namely, analyzing corporate goals and identifying the elements of EA that are most relevant to them), the value of the resulting deliverables can be so clear to everyone involved that getting further commitment is straightforward.
It’s important to note that working without a conventional EA Framework doesn’t mean having no guidance. Using an EA platform such as Ardoq, an organization can quickly begin codifying its infrastructure without needing any set models. It can maintain focus on vital questions concerning digital transformation instead of getting lost in the weeds of strict guidelines.
Regardless of whether it’s using TOGAF (or any EA framework), an organization using Ardoq can soon prove the value of EA by using the following range of solutions:
What Are the Four Pillars of TOGAF Architecture?
TOGAF splits EA into four core pillars. Each pillar represents a key operational perspective, and analysis that omits any of them will miss something important. They can also be combined in various ways to form more niche subdomains which may be worth considering. The four pillars are as follows:
1. Business Architecture
This pillar describes the overall business structure, looking at the overarching strategies for architectural development. It particularly emphasizes governance and process management. Most significantly, it drives alignment between IT and general operations, framing technical elements in ways that communicate their value so decision-makers can work faster and more efficiently.
2. Data Architecture
This pillar documents the storage and handling of data assets, using data models and visualization methods to show how information is managed. Given the legal and reputational implications of mismanaging data, it is extremely important to work with a clear view of Data Architecture. Such a view will help ensure legal compliance, facilitate interoperability, and yield better strategic decisions.
3. Applications Architecture
This pillar lays out all applications in use, detailing what purposes they serve, what value they return, how they interact, how they’re used, who’s responsible for them, and what, if any, optimizations could be rolled out. It also encompasses related documentation, such as user guides and training materials. This architecture is essential for keeping IT costs down and allowing new systems to be tested.
4. Technology Architecture
This pillar outlines the software and hardware systems underpinning operational infrastructure and what those systems must do to deliver consistent performance. If these foundations, which include cloud services, internal networks, and device registration, are not managed and maintained well, they can soon cause widespread issues.
What is the TOGAF Architecture Development Method (ADM)?
The TOGAF Architecture Development Method (ADM) forms the core of the TOGAF Standard and provides a standardized process for developing and maintaining Enterprise Architecture. The ADM offers an iterative cycle that prompts change when desirable, helping any organization using it pursue digital transformation.
To function effectively, the ADM requires the standardized documentation of existing infrastructure. This documentation shows the current status of things and provides the baseline from which work can be done. Importantly, it lays the groundwork for the use of existing industry-standard models and tactics, allowing resource-limited organizations to refine their operations without needing to invest heavily in strategic development.
TOGAF ADM Phases
The TOGAF ADM contains 10 phases. They are loosely ordered, though a core aspect of the ADM is that they can be performed in other sequences. These phases are:
- Preliminary Phase. This phase includes everything that must be done to prepare an operation for EA development. This covers any required adaptation of TOGAF elements and establishing the foundational principles that will govern the resulting projects.
-
Phase A: Architecture Vision. As the first phase of the development cycle, this phase lays out the scope of the overall initiative. In doing so, it lists the stakeholders, explains the reasoning behind the desire for EA, and secures a commitment to proceed from decision-makers.
-
Phase B: Business Architecture. This phase develops the business structure required to support architectural changes. This involves defining specific processes, listing key assets, and noting how things will be run.
-
Phase C: Information Systems Architectures. This stage explores the IT systems that will underpin the EA work. To do this, it’s necessary to define data models and outline application interactions ready to deliver the desired vision.
-
Phase D: Technology Architecture. This phase involves developing the foundation-level technological systems. This mostly consists of reviewing current assets and gauging the need for additional software or hardware.
-
Phase E: Opportunities & Solutions. This stage reviews implementation goals and looks for the most convenient ways to realize them. Wins are good early on, so it makes sense to start by identifying any.
-
Phase F: Migration Planning. This phase outlines the steps to transition from legacy infrastructure to optimized architecture. It needs to be highly detailed to prove effective. The less planned, the more that can go wrong.
-
Phase G: Implementation Governance. This stage oversees the deployment of the migration plans, checking to see that people are fulfilling their roles and processes are being followed correctly.
-
Phase H: Architecture Change Management. This phase establishes clear procedures to govern any tweaks to the new architecture. Since there is no such thing as perfect architecture, iteration will always be necessary, but it needs to be done very carefully.
-
Requirements Management. This stage impacts all other phases, as it governs managing architecture requirements. When needs change, it ensures they’re properly documented, assessed, and integrated.
What is the Enterprise Continuum?
Any organization that uses the TOGAF ADM should create an Architecture Repository. To do that, it can use the Enterprise Continuum, a framework that aids the collection, documentation, and classification of assets used to support the maintenance or development of EA.
An Architecture Repository is simply a vault of meta-elements concerning EA. It should hold all assets relevant to past, present, and planned EA actions, including models and patterns. By ensuring that existing assets are used where convenient and new assets are developed where appropriate, an Architecture Repository, and thus the Enterprise Continuum, supports practical operational improvement.
Other Common EA Frameworks
Though TOGAF is the most widely known EA Framework by some margin, it isn’t the only one around. Popular alternatives include the Zachman Framework and the Federal Enterprise Architecture Framework (FEAF). Here’s more about them:
The Zachman Framework
John Zachman created the Zachman Framework in the early to mid-1980s while working on systems planning at IBM. He was trying to reduce the complexity of framing IT infrastructure and landed on using a matrix to investigate the intersections of perspectives and questions.
The questions are straightforward, starting with What, How, Where, Who, When, and Why. The perspectives are variable but often include categories such as Planner, Owner, Designer, Builder, Programmer, Implementer, and/or User/Worker. These categories can readily be likened to the core domains used within TOGAF.
Unlike the TOGAF model, though, the Zachman Framework doesn’t provide any processes for working on Enterprise Architecture. Instead, it seeks to document the elements within an organization’s infrastructure, making it a good jumping-off point. The Zachman Framework can be applied to an entire organization or used for a specific tool.
The main issue with the Zachman Framework is that it only lists how things are perceived from certain viewpoints. While this may be interesting, it might not drive meaningful action or make digital transformation easier. Even so, its ability to neatly show things from different perspectives allows it to aid communication.
The Federal Enterprise Architecture Framework (FEAF)
Developed by the US government in the 1990s to help federal agencies coordinate more effectively, the Federal Enterprise Architecture Framework is geared toward expansive bureaucracies that struggle with efficiency and cost-cutting.
Though it was intended for use within the public sector, FEAF can be adapted for private organizations with numerous departments to manage. It is particularly suitable for businesses heavily impacted by legal regulations and governmental oversight, such as pharmaceutical or transport companies.
Like TOGAF, FEAF concentrates on some core domains. The six FEAF targets are Performance, Business, Data, Application, Infrastructure, and Security. It emphasizes interoperability and uses the Collaborative Planning Methodology (CMP). This phased process helps ensure the smart use of resources and the sharing of vital information.
FEAF is less flexible than the TOGAF standard, however, and places less focus on IT, which makes sense given its origin. Because it’s rigidly prescriptive, it can be easy enough to apply when it’s completely relevant. However, it is not suited to be reworked for various types of organizations in the way that TOGAF is.
Implement TOGAF Framework With Ardoq and Prepare Any Organization For a Successful EA Project
This article has covered the basics of TOGAF, clarifying its strengths and weaknesses. It should help any business decide whether to use this popular EA Framework. Regardless of the company's decision, Ardoq is recommended for any organization eager to invest in EA projects.
Ardoq can certainly implement any selected elements of TOGAF, but it does not require it to proceed. Instead, Ardoq is framework-agnostic and can be used in whichever methodology or set of methodologies best suits it. It doesn’t require any framework to start making progress.
TOGAF or no TOGAF, schedule a demo today to discover how the power and flexibility of Ardoq can smoothly steer EA optimization at the highest level.
