Say What? Misconceptions about Architecture and Communication

As an enterprise-architecture professional you are able to create models that perfectly describe any reality. However, if you want people to actually understand you, a simple model that might not be 100% correct is probably a better idea. Here’s why.

Enterprise Architecture and Communication

An important aspect of enterprise architecture is communication. Ensuring that people understand the current and future situation of the organization requires a common language in which architecture models and information can be expressed.

In the past, organizations have used their own language and those of consulting organizations for expressing their enterprise architecture. More recently, enterprise architecture standards such as TOGAF and ArchiMate have provided organizations with a more standardized language. Recently, a new version of the ArchiMate standard has been published which contains all sorts of new terms. In this blog, I discuss how enterprise architecture and architecture standards relate to communication.

Who’s the Target Audience?

Communication, in general, depends on the target audience and communication goals. Standards such as TOGAF and ArchiMate are primarily focused on target audiences who have at least some understanding of enterprise architecture, models and the standards themselves. In practice, architects are the main target audience, followed directly by IT-related staff such as analysts, designers, developers and project managers.

Legends Anyone?

When architecture models use multiple concepts and/or relations they get harder to read. A legend and/or textual explanation becomes necessary for understanding these models. You can imagine that with more complex models, using more difficult concepts or relations, quite an elaborate explanation is needed. Without this elaborate legend, many by people who are not up to speed with enterprise architecture, models or the standards will be lost.

Although elaborate explanations may help people in understanding architecture models, a lot of people in the organization just do not have the time, patience, capability or desire to understand them.

Often, more than 90% of the organization falls into this category.

Communicating information to a broad audience requires a different approach. Models need to be made simpler, using the least notation that is required. Most people can easily understand simple diagrams, especially when the terms used within these simple diagrams are part of their business vocabulary. Simple diagrams use only one or two concepts/symbols and preferably only one type of relationship. Also, they shouldn’t look technical. They should avoid specific symbols that require explanation. This requires architects to carefully think about the information and message that they want to convey, which is a good thing.

Using Business Vocabulary

As mentioned before, using simple business vocabulary is really important if you really want to address a large part of the organization. A pitfall for architects is that they abstract from things that people recognize, and define abstractions. An example of such an abstraction is the concept involved party that abstracts from things such as a person, organization, customer and supplier. Although it is perfectly reasonable to use such a concept in designs of IT-systems, you cannot expect an average employee to understand what it means. This means that you need to be very careful in your communication.

Your vocabulary as an enterprise architect contains all sorts of abstract concepts that are not part of the business vocabulary. Try to avoid these in broader communication.

This can also put you in difficult modeling situations, in which you may have to choose between terms that are part of business vocabulary and abstract terms that are probably more correct but that people probably do not understand (such as an involved party). Try to leave out superclasses in object models and only show the concrete classes that inherit from them. For example, in an information model in the higher education domain, the term educational product was not understood. Instead the concrete instances education, minor, and course were used.

Standards Or Not?

It is important that you do not let standards get in the way of communication. People have built a specific vocabulary in their lifetime and business experience. They understand all sorts of intricacies in terms that can not be abstracted into generalized concepts. It is often hard enough to let a group of people come to a common understanding of a set of terms. It sounds great if we can just adopt standard definitions for terms. For example, a standard definition of a customer could be someone that buys something from the organization.

In practice, these standard definitions just do not express the specifics that we want to address. Meaning is always specific to the context and to the person receiving the communication. What the term customer or the term order means for your specific business process in your specific organization cannot be expressed in a useful standard definition. Maybe in your context, you only want to call people that have current contract customers.

I have given up on standard definitions that can provide valuable meaning in all contexts. In a lot of situations, it is even better to let different definitions co-exist. They can provide you with alternative perspectives that highlight important aspects. Do you believe in an ultimate definition of the term enterprise architecture?

Diagrams Versus Text

I want to end this item with a personal insight on communication. The insight is that in a lot of situations, natural language, for example in the form of a story, can provide a much better means of communication than a model. It is well-known that lawyers rather read a text than understand a model. People are used to telling and reading stories. Natural language is something that is very close to our senses and the way our brain structures our knowledge. A good text or story can provide a very concise way of expressing information. Any model can be translated into a text that contains the same information. You can draw a diagram that shows customer and order entities with a relationship, or you can just write a customer can place one or more orders.

Happy storytelling!

PS – Check out my other posts, see how you can get started with TOGAF, or browse the catalog.