Terminology Wars: Coming to Terms with our Terms

Where Did We Go Wrong?  Business Architecture initiatives can be quickly derailed by a failure to align on vocabulary. A seemingly minor verbiage problem can hinder adoption, cause confusion, and alienate your audience. Let’s examine the role of terminology, the current state of business architecture terminology, and how to prevent terminology from impeding your initiatives. 

Let’s assume that we are working with a new business unit and are creating a “capability model”.  We ask the team to jot down ideas and come together to discuss the organization’s “capabilities”.  The team has extensive conversation, but little resolution.  Much of the conversation comes back to if a particular item is or isn’t a “capability”. Someone suggests “policy manual management”, arguing that it something that includes process, people, and technology. Someone else argues that it is too specific and is actually a support process, not a capability. Definitions are referenced, but they don’t bring the team closer to agreement. Frustration sets in and team members begin to disengage. Eventually, some agreements are reached, but there is little insight or enthusiasm.  Suddenly, our initiative has been overshadowed by a “term war” and we are far from our intended objective. How did we get hung up on words? Where did we go wrong? And how can we prevent it from happening again? To understand what went wrong, let’s start with understanding the role terminology plays in the organization.

Why is Terminology Important?   In Marie Teresa Cabre’s book, “Terminology: theory, methods, and applications”, she explains the meaning of terminology: “For subject field specialists, terminology is the formal reflection of the conceptual organization of a special subject and a necessary medium of expression and professional communication.”(11) To paraphrase, our terminology represents the fundamental concepts of business architecture and is a requirement for effective communication. Terms provide a way to reference our complex ideas with a single word.  Therefore, without agreed upon terms, we cannot succinctly discuss what it is we do. 

When we suggested creating a “capability model”, we attempted to reference a set of specialized concepts and activities we perform. While the term “capability model” provides an expedient way to reference this set of concepts, it lacks usefulness if the concepts referenced were not understood by all team members the same way.  This leads us to our next question.

Why is Business Architecture Terminology Misunderstood?  Business Architecture is a relatively new discipline.  As business architecture matures, governing bodies, professional standards, and certifications are being formed. The process is not easy. To align on terminology, we must align on the underlying concepts they represent. As a community of practice, we are moving swiftly towards a common nomenclature, but in the meantime, we do not have a long established, globally accepted set of artifacts and terms. This means that in your experience, most people will not be aware of the context in which you intend to use a business architecture term – they may not even be aware of the term “business architecture” at all. Until standardization is achieved and widely syndicated, we must assume our teams do not have a common understanding of business architecture terminology.

In the absence of common understanding, people draw upon their personal frame of reference.  This may result in alternate definitions for a term or drawing upon similar concepts.  Related concepts are abundant because business architecture has connections to many fields, such as information technology, continuous improvement, organizational change management, and business strategy.  Each field comes with its own core concepts and terms. Business architecture draws upon these fields and is tightly coupled with them; however, they are far from identical.  

Most likely, our team has a variety of backgrounds, which may include an IT specialist, who is imagining a UML class diagram, a Lean practitioner, who is drawing parallels to value stream mapping, and a MBA graduate, who is thinking of a balanced scorecard. While all are strongly related to our capability model, it’s not surprising that this has caused confusion on our team.

How Do We Negotiate a Terminology Peace Treaty?  Now that we understand the source of confusion, as well as its significance, it’s our responsibility to keep “term wars” from diverting attention from architecture objectives. Let’s look at some ways to keep the dialogue focused.

First of all, know your organizational context. Seek to understand existing strategies and programs, their core concepts, and key terms.  By understanding the organization’s paradigm, we can more skillfully explain concepts and how they fit in with the paradigm. When explaining concepts, reference related concepts and address the similarities and differences.   Any existing shared concepts are an asset.  By showing a clear relationship to an agreed upon idea, you increase your chances of a common understanding of the new idea.

Secondly, use terminology mindfully. As Einstein said, “Make everything as simple as possible, but no simpler”.  When introducing terms, clearly articulate what they mean in an architecture context, how their relationship to well-known terms, and what purpose the term serves. If you use certain terms interchangeably, select one and stick with it.  Be especially aware of terms you intend to use that have pre-existing definitions in the organization.  These will cause the most confusion. You may choose to use the term or select an alternate term. If you choose to use the term, address the verbiage conflict and explain your reasoning. Readily acknowledge that the same word can carry different meanings in different contexts.

How Do We End the Terminology Wars for Good?   Lastly, help to address the root cause of the conflict. Participate in and support the activities of professional and standards organizations seeking to create bodies of knowledge and commonality between practitioners. Part of the excitement of business architecture is participating in the formalization of a new field.   These activities will bring standardization between business architects and form a single, recognized language.  As business architecture increases its visibility and standardization, acceptance of associated terminology will follow. Engagement from a wide community of business architect practitioners, such as you, will ensure standards are field tested and consider a variety of applications.

Let’s assume we reconvene the business unit and apply these strategies. After understanding the team’s frame of reference, we explain how capabilities are related to, but not the same as, classes, value streams, and balanced scorecards.  We provide definitions and examples. (See Bill Ulrich’s article “Defining the Business Capability – A Cheat Sheet” for definitions and examples). We acknowledge that our working definition of “capability” is specific to business architecture and is not in conflict with the term’s use in other fields.  Now, the team is aligned and able to successfully focus the dialogue on their objectives. 

Coming to Terms  By understanding the underlying conceptual struggles that terminology represents, we address the issue more productively.  We must recognize that based on a person’s frame of reference, terms may have different connotations, especially because business architecture is an emerging field and is still forming its standards.  However, we can’t allow the “term war” to inhibit our initiatives. By understanding our organizational context, explaining relationships to other fields, supporting industry standardization and delivering clear, simple messages, we can forge ahead. Ultimately, with your help, business architecture will reach a level of recognition and maturity, that we can finally call an end to the terminology wars.