I frequently get asked whether it’s practical to use TOGAF “out-of-the-box” – without any customization. Architects and clients are looking for a turnkey approach that they can easily plug into their enterprise with the hope of quick results – they don’t want something that requires too much effort.

The simple and practical answer is – no: you can’t get the best out of TOGAF if you use it without adapting it to your needs! But this answer ignores the fact that much of TOGAF can be used without any customization. And it also fails to explain why you need to adapt TOGAF, or how you go about doing so.

In this blog post I’m going to briefly overview the arguments for using TOGAF out-of-the-box, and the reasons for customization.

Why can’t you get the best out of TOGAF without adaptation? Because every enterprise is unique. Within its architectures there will be some common components – for example, things that are true for all companies in the same line of business, such as all banks or all airlines. There will also be some systems that are common for pretty much any enterprise, such as the links and interfaces to web technologies.

TOGAF of course recognizes this distinction, between generic and enterprise-specific, in the Enterprise Continuum. The Enterprise Continuum makes an explicit distinction between:

  • Foundation Architectures that define the almost universal fundamentals,
  • Common Systems Architectures that define architectures that are widely reused across many domains,
  • And Industry Architectures that recognize commonality across an industry sector.
  • But that still leaves the Organization-Specific Architectures that are – well, “organization-specific”!

Using the Enterprise Continuum we might find that an Organization-Specific Architecture actually uses 25% foundation, 15% common systems, and 20% industry components, leaving only 40% that is truly organization-specific.

Adapting TOGAF to your needs follows a similar continuum.

Parts of TOGAF can be considered a generic Foundation. This covers any “universal truths” about EA. TOGAF is weak here.

  • For example, good enterprise architects frequently use the idea of a continuum[i]. But TOGAF only includes the Enterprise Continuum that I mentioned above, and it fails to explain the underlying conventions on which it is based.
  • Other parts of TOGAF work better if you are using what might be considered a particular architectural style or approach.

For example, there is a strong leaning in TOGAF towards Service-Oriented Architecture (SOA), while there are less obvious references to Object-Oriented Architecture.

Another example is the TOGAF use of views, viewpoints and stakeholders – which is formally defined in an international standard[ii]. While this is an excellent approach that works very well for some organizations, there are many others that don’t follow this approach.

Then there are the parts of TOGAF that are “TOGAF-specific”. By this I mean that, like other EA approaches, TOGAF has its own peculiarities and language.

For example, this is evident in TOGAF certification questions that begin with the phrase, “according to TOGAF…” The answer to these questions depends more on memorizing the specific way in which TOGAF documentation describes something than on understanding what a trained architect would do in the field!

Now if you have gone to a lot of trouble to learn about TOGAF, I hope you are not thinking that this time has been wasted. I must emphasize that TOGAF does a great job at documenting architectural practice. The TOGAF documentation fills a huge gap – for example, before TOGAF it was hard to find a well-defined process for developing architecture; now this is provided by the ADM. Similarly TOGAF has done a great job of standardizing things like architectural language and meta-models.

But I also need to point out that there is a lot that TOGAF doesn’t yet cover. It doesn’t cover a lot of architectural fundamentals. It covers certain architectural styles, but not others. And some of the TOGAF peculiarities and language will differ from that in your enterprise. So it is unlikely that your enterprise will use, or be able to use, TOGAF without some customization.

So let me leave you with these thoughts:

  • As you use TOGAF, use it with as little customization as possible. Try in the first instance to use TOGAF without adaptation.
  • At the same time, think about what you are trying to achieve. And if TOGAF doesn’t cover it out-of-the-box, then make the necessary customizations to ensure your success!

[1] a continuous sequence in which adjacent elements are not perceptibly different from each other, although the extremes are quite distinct.

[1] http://en.wikipedia.org/wiki/ISO/IEC_42010

TOGAF Online Training

SHARE
Previous articleCommon BPMN Modeling Mistakes – Activities
Next articleCommon BPMN Modeling Mistakes and Best-Practices: Basic Events
Roger has been working as an Enterprise Architect since 1984, and over the years has been in involved in some of the most advanced, innovative and challenging Enterprise Architecture projects. He has extensive experience in applying all of the key EA approaches, including Zachman, TOGAF and Information FrameWork (IFW) and has been involved in establishing and embedding Enterprise Architecture Programmes that delivered strategic business results in organisations all around the world. Roger now works as a trainer, mentor and coach, specialising in developing individual and organisational capability in using Enterprise Architecture techniques and tools.