One of the major selling points for TOGAF is that it provides a standardized, common foundation for the discipline of Enterprise Architecture.
In other words, everything in TOGAF – the ideas and concepts, methods and process, techniques and guidelines, metamodel and reference models – defines the lingua franca for EA.
Speaking the Right Language
A lingua franca is the language, adopted as common, between speakers whose native languages are different. (Historically lingua franca was a mixture of Italian, French, Greek, Arabic, and Spanish that was used in the eastern Mediterranean.) So my question in this blog is: how useful is TOGAF as an Esperanto go-between language for enterprise architects from different backgrounds?
This subject came up recently when I advised a client about recruiting experienced architects. How varied are the backgrounds of EA professionals? And to what extent do architects speak different languages?
Well even the phrase “enterprise architecture” is open to interpretation. As a personal anecdote, this year is my 30th year as an enterprise architect, and throughout these three decades the phrase “enterprise architecture” continues to have different meanings! When I started as an architect the discipline was known as Information Architecture – but not with the same meaning as today!
You’re an Enterprise What?
The phrase was coined by Richard Saul Wurman in 1976 as a response to the growing volumes contemporary information. He argued that we needed a systemic way of managing the fourth resource of information, and saw an analogy with the use of architecture in buildings. It was much later that information architecture gained its more narrow focus, associated with the Internet.
Then EA became known as Information Systems Architecture – a phrase popularized by the publication of John Zachman’s Systems Journal article on the subject, which later became known as the Zachman Framework. Gradually EA evolved to cover more than just its IT origins – expanding to include business and organization. And EA’s scope has expanded now beyond the enterprise boundary to include its environmental and social context.
So it is really not too surprising that EA professionals have very varied backgrounds. This is where TOGAF steps in, by attempting to provide a common foundation for the discipline.
Early versions of TOGAF were focused on information technology, but gradually came to include a stronger business orientation. This is evident in the four TOGAF domains – starting with Business, followed by Data and Application, and ending with Technology – and in the sequence of the ADM which starts from business requirements, architecture vision and business architecture.
Overcoming the Linguistic Barrier
Even within TOGAF, the nature of each of the domains means a difference in subject matter and techniques, which can create linguistic barriers. I had to address this issue recently with a client where the word “application” had several meanings; for business people an “application” was often the complete suite of software that supported their needs; in operations application and system were interchangeable terms; and even within development an application could mean standalone software or a module.
But this was the tip of the iceberg… On one project we found that the same architectural components were referred to variously as a transaction, process, procedure, activity, service or function. Executives, business analysts, product managers, business managers, policy makers, application architects, and process modellers had their own label or different meanings. A further complication is that there are frequently overlaps between the labels and meaning!
Fortunately TOGAF has several resources that can help to solve this jumble, although there are limitations. The language throughout the TOGAF documentation is pretty consistent – one of the reasons for interim releases such as 9.1 is actually to correct any minor deviations in language. The four domains go a step further by providing consistent ways to segment the architecture; this segmentation is based partly on the different subject matter, concepts, and architecture components (and therefore language) in each domain.
The metamodel attempts a standard taxonomy, but this is where providing a lingua franca becomes tricky – providing a single metamodel construct to cover every stakeholder perspective only works for very simple concepts.
In Conclusion…
So here’s the rub. TOGAF is about as good as it gets as a common Esperanto for EA. Everything described in TOGAF uses a consistent language – and that helps enormously. But as architects we need to be aware that we can’t force a common language on stakeholders.
There will always be differences in meaning. And this point is sometimes overlooked when practicing EA: ultimately we need to talk to stakeholders in their own language, while simultaneously translating into TOGAF-ese. Beware of only speaking TOGAF!
