Enterprise Architecture is an abstract discipline – because it deals in information about its subject matter, and uses information-based artefacts to describe and make changes to the architecture. It is as important to manage this information as it is to manage the things that are described. In this respect, enterprise architecture is an information management discipline.
And as with other information-based disciplines, language and its use is a key factor in how well we manage this information, in our case for effectively managing architectural change and complexity.
Language is a very powerful architectural tool. But our use of language is open to interpretation, and it may also cause confusion and misunderstanding! (This is why language is the heart of the first factor in my 8 factor approach to enterprise architecture.)
As enterprise architects, what is the most effective way to make language work for us, rather than against us?
Adopting one of the basic EA techniques, I would start by simply listing words and phrases that were key to architectural discussions, and then add some structure by defining them and putting them in a glossary.
If I needed more structure I would consider a thesaurus, classification schemes, and taxonomies. And I would certainly draw upon that old friend – the meta model, to show how key terms were related to each other. (tim – the Information Model, which has been called the intelligent meta model, improves on a traditional meta model by adding additional knowledge, advice and guidance on the use of architectural information.)
This approach results in a controlled vocabulary, or a standard set of words and phrases, as a fundamental artefact. This language will be used again and again in every subsequent artefact – be it model, pattern, policy, standard, principle, etc.
The main criticism of controlled vocabularies is their perceived artificiality. What is the best way of gaining the benefits from a standard language without forcing its use? The simple answer is: always use the natural language of your stakeholders, but map it to the controlled vocabulary whenever it serves a valuable architectural purpose. That way architects get the benefits of a structured language, but this is transparent to non-architects.
The interesting thing is that whenever there is genuine value from using clearly defined terminology and well structured information models, then that language is quickly adopted by everyone!