Bridging TOGAF's architecture domains

Figure 1

The Open Group Architecture Framework, like other frameworks, has several standards for enterprise architecture at its core, including TOGAF (a diagramming and notational standard) and ArchiMate (a standard for modeling tools). TOGAF provides a process for developing and implementing enterprise architectures, which is called the Architecture Development Method (ADM). TOGAF also provides viewpoints, techniques, and reference models drawn from a content framework which demonstrates using each building blocks that are expected to be employed in documenting an enterprise architecture definition.

While the Open Group reports that TOGAF is being used by 80% of Global 50 businesses, skeptics have questioned what level of benefits can actually be achieved by adopting such a framework out of the box. Because of the subjective nature of TOGAF's guidance, it can be difficult to isolate issues which are intrinsic to the framework itself from problems which are common to those applying this framework for developing a specific instance of an architecture definition.

TOGAF's architecture domains themselves are not the problem, as they are made up of Enterprise Architecture viewpoints that are typical of the information needed to orchestrate major IT transformation projects:

  • Business Architectures, which communicate the motivation for the architecture objectives, demonstrate alignment of tactical demands to those objectives. This motivation is intended to provide a bridge from the enterprise's as-is business models to the to-be capabilities, products, and services that are to be provided by the business's future state organizations.
  • Data Architectures, which describe the standards for data integration between separate information systems and locations so that the data flows essential to data processing operations can be managed and controlled, while meeting the non-functional requirements of the systems of interest
  • Applications architectures, which define the elements, design patterns and planned evolution of features and functions required by users for the transformational results to be achieved
  • Information technology architectures, which must be expressed using the notations and conventions necessary for defining the service delivery infrastructure required in initial deployments and full-scale operations. 

Figure 2

These viewpoints are called 'pillars' in the TOGAF framework literature, highlighting one of the differences between the TOGAF framework and the international standard for systems and software architecture that describes best practices for architecture definitions themselves - ISO/IEC 42010. While guidance on the  key architectural elements of ISO 42010 is widely available (from books which providing credible catalogs of stakeholders, viewpoints, and perspectives), TOGAF remains largely silent about such basics of architecture definition, and how such artifacts are to be integrated across TOGAF's domains. Indeed, one of the weaknesses of TOGAF is that it fails to provide sufficient guidance on the integration of architectural elements to achieve some particular purpose. While it does offer some guidance on critical issues such as interoperability, and on potential sources of patterns to adopt as starting points, you won't find any guidance whatsoever on how to provide assurance that the costs of implementation do not exceed the available benefits from that implementation.

In their book Architecture as Strategy: Creating a Foundation for Business Execution,  J. Ross, P. Weill, and D. Robertson describe a classic example of this challenge, citing an IT architect's frustration:

So we started working on understanding the business strategy, and what we discovered in that process is, they really didn't have a business strategy. What they had were a lot of promises. We are going to grow. We are going to use branding. We are going to run our plants more effectively. We are going to increase our volume, but they hadn't figured out exactly how they were going to do it. And what I said was: it is very difficult for me to write an IT strategy to support your business strategy when you don't have that defined.

In other words, if a business's strategy is dominated by  suitcase words, i.e. language that is vague and subjective, that business's IT strategy will probably have similar ambiguity. The problems arising from this lack of specificity will take many forms, but will likely first arise as challenges as the business attempts to align the elements of the business layer in Figure 2, and pin down exactly which work will need to change in the as-is state, or how that work will need to be transitioned to a to-be state that will credibly deliver on concrete value propositions. But the incidence of these problems doesn't stop with these challenges. One of the most important characteristics of any architecture lies in its ability to localize change; when a new architecture is deployed, changes in that new architecture should be less likely to ripple into the other parts, by design. Unless TOGAF's content specifications are necessary and sufficient to communicate the mechanisms that will achieve this separation of concerns, and assure that these mechanisms can be implemented properly, the framework's robustness should be questioned, even though competent and motivated architects have done their best in the time they were given.

Unfortunately, when any framework's viewpoints are populated by poorly defined concepts, they prove difficult to rework over time. Their relationships to other suitcase words may prove equally nebulous:

  • Architecture Principles, Requirements, and Roadmap, in which capabilities are delivered by combinations of principles, constraints, assumptions, requirements, gaps, and work packages.. or not of these at all.
  • Organization Units, providing the policies and expectations of actors as they perform roles, and access functions to support processes. Yet organizations are often more complicated than depicted in models, especially as supply chains get involved. Unless an organization is accurately modeled, the ramifications on flow, security, affordability, and scale may be completely misunderstood. 

These elements populate the TOGAF core elements, and offer opportunities for creating new business services, and assuring that they remain integrated with data, application, and technology architectures. Yet each of these architectures may themselves just be notionally defined, obsolete, or isolated from their underlying business purposes. This often occurs through the use of fuzzy language such as 'informed', 'leveraged', or 'enhanced', instead of 'enforced', 'assured', or 'validated'.' Often the language is even more pliable. For example, in TOGAF (unlike in traditional systems engineering) 'functions' are a construct of organizations, rather than behaviors of systems, and are primarily of concern because someone must 'own' them. Unfortunately, the obligations of this ownership may never explicitly be called out, but can implicitly expand as any change to models are incorporated. Processes may orchestrate functions, and may be decomposed from them, but do not directly implement them. Concepts of transformation across a cascade of functions rarely are required to achieve functional integration or coherence.

Business capability maps have been useful as classifiers of processes and tool assets so that opportunities for reuse and consolidations can be identified. However, unless the definitions of such assets adequately define all viewpoints of stakeholders relevant to these capabilities (which they rarely do), the information in the models will tend to greatly oversimplify the underlying work necessary to deliver or integrate these capabilities in actual practice. Finally, for an IT structure that is intended to specifically support its businesses, the absence of cost accounting may not fully represent the full costs necessary for designing, supporting, or operating those capabilities under different business scenarios.

Figure 3

With that in mind, let's examine TOGAF's content metamodel, which is graphically represented in Figure 2 below. The extensions of TOGAF are summarized in its color-coded legend; these extensions can be thought of as metamodel enhancements that expand considerably on what is included in the core model 'out of the box'. However, as these core elements themselves are all optional, each definition must choose a mix of these constructs, and develop the mechanisms to enforce their consistent capture, and to measure the ultimate value of managing the quality of the underlying information over its lifecycle. When used, these extensions effectively serve as viewpoints into the enterprise, capturing the:

  • motivation - the goals, objectives, enablers, and drivers of change
  • infrastructure consolidation - the logical, technology, component, and physical taxonomy of assets, applications, and support
  • process modeling - the events and controls of processes necessary for producing a product
  • data modeling - the structure, attributes, and relationships of information
  • service modeling - such as by using the colors shown at the bottom of the figure.

TOGAF has quite a few proponents. Its sponsor, The Open Group does their part in marketing TOGAF to IT and Business Executives. However, since 2014, a number of articles have begun to appear in business magazines with titles like Is Enterprise Architecture Completely BrokenEnterprise Architecture: Don't Be a Fool with a Tool, Why Open Group and TOGAF may hold back EA, Enterprise Architecture is not TOGAF, Gartner's Top 10 EA Pitfalls, and The Top 8 Enterprise Architecture Risks. A sampling of remarks from these sources highlights these concerns:

  • Researcher Svyatoslav Kotusev reports that "most TOGAF recommendations are usually found inapplicable" and are not even consistently followed in organizations The Open Group lists as major users, stating instead that "the core parts of TOGAF were found to largely be useless". Commenting on TOGAF's flexibility, he notes "TOGAF is indeed flexible, i.e. does not prescribe anything in particular. As a result, TOGAF-certified EA practitioners are free to do whatever they find reasonable and praise TOGAF for its flexibility since TOGAF generously allows them to adapt (actually ignore) its own unreasonable advice. Unreasonableness of TOGAF’s advice is compensated by optionality of its execution."
  • Angelo Andreeto, of the Zurich Insurance Group, cautions frameworks such as TOGAF "tend to become self-referential', absorbing all of the EA's efforts, and taking them away from "solving real problems". TOGAF should really be considered as a "a toolkit of random EA-related recommendations" and "‘using TOGAF’ can be best explained as "studying TOGAF and then doing something else instead"
  • Jason Bloomberg, Forbes contributor, argues that "for many organizations, TOGAF has gained traction simply because it’s better than doing nothing". He bemoans "the practice of EA has become all about documentation rather than effecting business change".
  • EA practitioners report that TOGAF can hardly be followed step-by-step. "Our initial assumptions about TOGAF were that it would be a sort of 'methodology' that we could follow to produce our EA, however this turned out not to be the case"
  • TOGAF's prescriptions for compliance are vague and inarticulate; for example, the guidance "only states that the ADM should be adapted without specifying how"
  • Real world, in depth examples demonstrating the actual practical usage of TOGAF's recommendations are missing: "There is a pressing need for some detailed worked examples and use cases. Although these were requested, they were not forthcoming from TOGAF trainers or The Open Group"

Ken Griesi thinks he has identified the common failure mode that spans these issues: "EA fails when enterprises are treated as discrete systems that can be reduced into smaller problem sets, as traditional engineering approaches would have us believe." As an alternative, Greise suggests examining enterprises as living organisms, rather than falling back on metaphors from mechanical systems or building construction. Unfortunately, these examples do not reflect the complexity that confronts large enterprises. Unfortunately, these are exactly the places where robust methods and patterns are most needed to aid in shaping enterprise architectures.