After adding Archimate, and rather failing to digest it, TOGAF9.2 adds now an approach to Business Architecture (BA) proposed by the BA Guild. It all begins with the dear term of Business Capability. Yet, the usual definition, What a business does rather than How it does it, sounds smart but adds little clarity. Just try to define some capabilities and you realize what you are up against. To start with, capabilities are too general to be of practical use. Yet, imagine explaining to your top business your capability map that exhibits the usual Partner, Customer, Sales, Marketing, Sales, Risk... Management capabilities. By taking the term “management” out of the capability naming, the whole lot becomes an ordinary list of key business as usual words such as Customer, Partner, Sales, Accounts, Order... While this seems like a great achievement for TOGAFers, they do look so obvious to the business that it may sound like IT-splaining.

TOGAF9.2 stuff is though another incremental addition not quite integrated into the current TOGAF. In fact, TOGAF, Archimate and BA do not have a common metamodel yet. Perhaps because they come from different organisations.

TOGAF appears again to re-invent the wheel with regards to business capability maps and value streams vis-a-vis the existing process frameworks. But then, what's new, when ADM is just another development process while TOGAF’s risks, requirements, security management have been in existence in business practice and academia since long.

Besides, both TOGAF and EA do step in other enterprise fields as if they were virgin territories, attempting to re-define them from scratch as if no specialisation dealt with them so far. TOGAF adds long existing business pre-occupations and the associated practices to the TOGAF stack , as if they were "terra nulla".

Historically, TOGAF grew to this barely manageable size at a slow pace and in small fractions. Imagine studying TOGAF alone, without the benefit of a training course. Trying to make sense of this disparate chapters, guides, mapping papers and, in general, additions of all kind, is it even possible? With its many additions and papers, what is its size now? Are concepts and notions consistent along the whole tome? But the situation makes us increasingly dependent on the ever growing series of expensive training courses, certifications and consultants. Yet, with its dimension and this extensive and increasing program of certifications, re-certifications and badges now, TOGAF may effectively block your entrance to the EA arena or, at least, it may make it too expensive for many.

Given the approach, TOGAF transforms us, the EA architects, in TOGAF Sisyphus-es who keep pushing the boulder of EA against the mountain of TOGAF trainings, certifications, and badges now, paying all along for the privilege to be up-to-date. Not surprisingly, "Sisyphus was punished for his self-aggrandizing craftiness and deceitfulness by being forced to roll an immense boulder up a hill only for it to roll down when it nears the top, repeating this action for eternity" (Wikipedia). By covering all these lateral fields, TOGAF looks more like a compelling business training for IT. Perhaps this is the true value of TOGAF rather than the claim that it represents an EA framework. Yet, TOGAF has not been sanctioned by the business, not so far.

Imagine now we keep adding parts to our Enterprise Architecture, as TOGAF does, without really integrating them in the EA whole. This is what we do today in the absence of a modelling framework. But the reason we need an Enterprise Architecture (EA) framework is to ensure the smooth integration of parts into the navigable EA. TOGAF should use itself such a framework with placeholders for parts so that we know from the beginning what are the parts and where do they fit in. This framework would ensure that the entire TOGAF employs the same components and definitions without contradictions, overlaps or divergence. The frame would constitute the skeleton of TOGAF. It would ensure a hierarchical, modular and layered TOGAF, employing own architecture principles. In fact, this is how work is done by architects. The standard would become as such easy to understand, use and roadmap.

Still, today, TOGAF is like political correctness. To play, one has to pay lip service and the never ending training bill.

Some name

Adrian is a recognized Executive Consultant in Enterprise Strategy & Architecture. He has over 20 years experience working in digital media, telecoms, health insurance, airlines, utilities and government developing new EA practices and managing teams in an international environment. He's published several
books and runs a prominent website
EA Matters.