In a long line of enterprise architecture frameworks, TOGAF® is not the first and it’s unlikely to be the last. But it is one that’s endured for nearly two decades, with worldwide usage—an impressive feat in today’s technology landscape.
TOGAF is the acronym for The Open Group Architecture Framework, and it was developed by The Open Group, a not-for-profit technology industry consortium that continues to update and reiterate the TOGAF.
This article will focus on familiarizing beginners with TOGAF.
Understanding enterprise architecture
In a previous article, we deep dived into enterprise architecture frameworks. Enterprise architecture refers to the holistic view and approach of software and other technology across an entire company or enterprise.
Typically, enterprise architecture isn’t just a structure for organizing all sorts of internal infrastructures. Instead, the goal is to provide real solutions to business needs through analyzing, designing, planning, and implementing the right technology in the right ways.
More and more, enterprise architecture also encompasses additional business needs, such as:
The goal of an organized enterprise architecture, then, is to successfully execute business strategy with efficiency, efficacy, agility, and security.
If all this sounds like it can be complicated – designing and implementing a clear, long-term solution to all enterprise software in a way that solves business needs – it’s because it is. That’s why enterprise architecture frameworks (EAFs) started emerging informally and formally, as long as five decades ago.
(Read our explainer on enterprise application software.)
TOGAF history and facts
As a subset of computer architecture, enterprise architecture as a field dates back to the mid-1960s. IBM among other companies and universities spearheaded some explicit ways to build enterprise architecture, knowing that all the pieces involved to run on a network are complicated.
Over the next few decades, technology only became more complicated: today, most companies, regardless of size or product, utilize the internet to make their business processes easier, quicker, and sometimes more transparent. Today, enterprise architecture is a necessary process to make sense of various hardware and software options, on premise and in the cloud, and to ensure security when sharing data across multiple platforms.
(Understand how enterprise networking works.)
The TOGAF was initially developed in 1995. As was common in the field of enterprise architecture by then, newer versions or models offered improved iterations and theories. Likewise, TOGAF took a lot of inspiration from the U.S. Department of Defense’s own EAF, called the Technical Architecture Framework for Information Management (TAFIM). Interestingly, the USDoD stopped using the TAFIM within a couple years of the emergence of TOGAF. Still, TOGAF implementation and success continues worldwide today, more than 20 years later.
The Open Group has updated TOGAF to the current 9.2 version. The Open Group further certifies tools and courses that meet TOGAF standards. Today various organizations have developed 8 tools and 71 courses which are officially certified by the Open Group.
The TOGAF approach to EAFs
The Open Group defines the TOGAF as the “de factor global standard for enterprise architecture”. The framework is intended to help enterprises organize and address all critical business needs through four goals:
- Ensuring all users, from key stakeholders to team members, speak the same language. This helps everyone understand the framework, content, and goals in the same way and gets the entire enterprise on the same page, breaking down any communication barriers.
- Avoiding being “locked in” to proprietary solutions for enterprise architecture. As long as the company is using the TOGAF internally and not towards commercial purposes, the framework is free.
- Saving time and money and utilizing resources more effectively.
- Achieving demonstrable return on investment (ROI).
3 pillars of TOGAF
If the four goals are the theoretical outcome of using TOGAF, then the three pillars are the way to achieve the goals. These pillars help create a systematic process to organize and put software technology to use in a structured way that aligns with governance and business objectives. Because software develop relies on collaboration across various business departments inside and outside of IT, TOGAF’s goal of speaking the same language encourages and assists the various stakeholders to get on the same page, something that may not otherwise happen in business environments.
The TOGAF is divided into three main pillars:
Enterprise architecture domains
Enterprise architecture domains divide the architecture into four key areas (sometimes shortened to ‘BDAT areas’):
- Business architecture, which defines business strategy and organization, key business processes, and governance and standards.
- Data architecture, which documents the structure of logical and physical data assets and any related data management resources.
- Applications architecture, which provides a blueprint for deploying individual systems, including the interactions among application systems as well as their relationships to essential business processes.
- Technical architecture (also known as technology architecture), which describes the hardware, software, and network infrastructure necessary to support the deployment of mission-critical applications.
Architecture Development Model (ADM)
This iterative cycle uses performance engineering to develop an actual enterprise architecture. Importantly, it can be customized to the enterprise’s needs, so it’s not a one-size-fits-all approach. Once an architecture is developed, the enterprise can roll it out to all teams or departments in iterative cycles, ensuring minimal errors and further helping the company communicate cohesively.
Enterprise Continuum
This classification system tracks architecture solutions on a range, starting at generic, industry-standard options and including customized enterprise-specific solutions.
The heart of TOGAF
Proponents say that ADM is the heart of TOGAF: it’s this pillar that makes TOGAF both very effective and a standout from other frameworks. The Architecture Development Method offers eight steps as guidance to figure out where the enterprise currently is and determine where the enterprise wants and needs to be in each of the four enterprise architecture domains.
Once business processes are established through the entire lifecycle, the ADM helps the enterprise to:
- Identify the gaps between current status and long-term goals.
- Collate these gaps into smaller actionable and understandable packages that the team can then implement.
Two other areas are sometimes included in TOGAF’s main pillars:
- TOGAF certified tools
- Qualifications
The Open Group offers two certifications for individuals:
- The first level is known as the Foundation, teaching basic tenets of enterprise architecture and rolling out TOGAF.
- Level 2 Certified involves business analysis and application.
The Open Group also certifies tools that align with TOGAF. For the most recent version, eight tools from eight organization are available.
Benefits of using TOGAF
The benefits of ADM are that it is customizable to organizational need—there’s no need to create a structure that doesn’t serve your business. These smaller packages are also scalable, so if one team rolls it out, it can successfully be rolled out to other teams without much tweaking. This helps the enterprise establish a process with multiple check points, so that there are few errors the wider the architecture is implemented.
There can also be benefits to individuals who certify in TOGAF. A study of industry employees indicates that enterprise architects, software architects, and IT directors, among others, who choose to earn a certification in TOGAF often see an average yearly pay bump of $10,000 to $20,000 over similarly placed colleagues who aren’t certified.
Some experts in enterprise architecture point out that while TOGAF may appear very logical, it’s actually quite a shake up to traditionally educated technology consultants today – but perhaps this will change has TOGAF adoption continues along steadily.
TOGAF vs ITIL: A brief comparison
TOGAF and ITIL® are two of the most popular management frameworks, each describing common interests in managing IT services and operational activities in an IT-driven organization. Yet, both provide a different perspective:
- ITIL is focused on service management.
- TOGAF is focused on developing and managing enterprise architecture.
Both have emerged as an integral component of managing enterprise IT, allowing organizations to anticipate and prepare for change in a fast-evolving enterprise IT landscape. Two main changes facing enterprise IT has encouraged IT professionals and decision makers to view TOGAF and ITIL not as separate and different frameworks, but ones that compete for relative interest in particular application domains:
- IT Service Management has matured such that it is no longer an isolated operational function but a critical segment that drives business value.
- Enterprise Architecture is not only a technical discipline but requires advice at a senior executive level on financial, operational, and business aspects: hybrid and multi-cloud environments are as much a business question as a technical question.
As the professionals and decision makers working with different frameworks are now compelled to collaborate and work across business functions, the comparison between TOGAF and ITIL frameworks has emerged as a relevant debate. In this context, organizations should note the following considerations:
- Both ITIL and TOGAF may describe certain aspects of enterprise IT from different perspectives. These perspectives tend to be conflicting at times.
- Professionals already adopting one of ITIL or TOGAF frameworks may need to completely understand the requirements as well as instructions when adopting the other framework. In reality, both frameworks only provide generic guidelines instead of specific actionable practice items.
- It may require detailed discussions and in-depth experimentations based on trial-and-error to evaluate the effectiveness of ITIL vs TOGAF on specific management matters.
You can develop these discussions by considering some of the key differences between TOGAF and ITIL:
- TOGAF helps develop enterprise architecture. The scope of ITIL in this context is limited only to developing an efficient IT department within that business architecture.
- Managing IT operations and services are well within the scope of ITIL. TOGAF on the other hand does not cover the run-time (IT Service) operations of the business.
- ITIL is focused on policies that help deliver value to end-users through service quality. TOGAF takes a similar approach for the larger enterprise architecture. This is one of the key areas where ITIL and TOGAF converge.
- ITIL Service Design guidelines largely overlap the TOGAF framework. Specifically, collecting and managing requirements in designing business architecture or managing IT services is similar.
- TOGAF guidelines on service transition largely overlap with the ITIL framework. Specifically, developing, testing and migrating of desired systems and activities is extensively covered in ITIL.
- Architecture change management and ITIL continual service improvements greatly resemble: ITIL provides detailed practical guidelines whereas TOGAF provides a big picture overview on the topic.
- TOGAF encourages the use of other frameworks for change management decisions and the 7-step guideline provided by ITIL is applicable to enterprise architecture, albeit to the IT services domain only.
Success & criticism of TOGAF
According to the Open Group, TOGAF is employed in more than 80% of Global 50 companies and more than 60% of Fortune 500 companies. Though criticism of the framework is often that it is too complicated or theoretical to be applicable, it seems that plenty of companies are using the structure.
Companies who have successfully implemented the framework admit that failings do happen, because TOGAF cannot be a cure all for enterprise issues. While the issue can be TOGAF principles or the enterprise architecture itself, others argue that sometimes key stakeholders and C-level management don’t always take the time to set up important factors, such as key performance indicators (KPIs), to make the architecture team successful.
This lack of complete buy-in may sometimes be due to the complicated nature of TOGAF, when looked at in its entirety. Indeed, even when the framework feels overwhelming, the best advice may be to pick what works best for your company. Some technology experts suggest precisely that: skip what seems overdone or unnecessary and implement the pieces that seem most necessary. After all, the key stakeholders are the ones who need to find use in this structure, and they know the company the best.
Many understand that TOGAF is a work in progress—marked by new releases every few years. Even skeptics of TOGAF and enterprise architecture frameworks in general find that the applied use of TOGAF is often successful simply because it is better than doing nothing.
When companies want to jump onboard a new technology, it often requires building out the right tech team from scratch and then tracking down all sorts of data. It gets messy, and the rapid pace that technology shifts and improves, these requests occur a lot more often than they used to. This can explain, in part, the bustling IT and architecture teams that are always busy yet somehow always seem behind.
TOGAF is no miracle tool, but it does provide structure to help these teams—and upper-level management—from having to reinvent the wheel each time the company wants to incorporate new technology. Technology expert Jason Bloomberg underscores why TOGAF is such a conflicting topic in the enterprise architecture industry. When organizations employ TOGAF, they typically “fall into four buckets”:
- Those who apply it incorrectly, and therefore it shows no value.
- Those who achieve some baseline success in handling legacy problems.
- Those who achieve explicit business goals.
- Those who want to handle change better overall.
This final group sees enterprise architecture as a way to become more agile.
As its widespread use indicates, TOGAF can help enterprises of any size and any industry—but those who employ it are probably best served by understanding its pros and cons first, and then applying the parts that make particular sense for their own company.
Related reading
- BMC Business of IT Blog
- BMC IT Operations Blog
- VSEM (Vision, Strategy, Execution, and Metrics) Framework Explained
- Data Architecture Explained: Components, Standards & Changing Architectures
- What’s BPMaaS? Business Process Management as a Service Explained
- Popular IT Service Management (ITSM) Frameworks
