“Unless and until all members of a team have a common understanding of the problem, attempts to solve the problem are just so much wasted energy.” –Gerald M. Weinberg [1]
In March 2019, one of us (Thomas C. Redman) served as the judge in a mock trial of a data architect (played by Laura Sebastian Coleman) for failing to ensure a common language and leading to an enormous GDPR fine for her company. (Other players included Len Silverston as prosecutor, Danette McGilvray as defense attorney, Katherine O’Keefe as expert witness, and Ron Klein as court reporter.) The trial highlighted the difficulties in developing a common language and building it into computer systems. It was a huge success. Laura was judged innocent by voice acclamation of the audience. Her defense, that she was overmatched and unsupported, resonated with the crowd.
Thomas left the meeting feeling that even though the defense won, its case did not do justice (pun intended) to how difficult establishing common language actually was. He reached out to the other authors of this article and formed a study group, specifically charged with addressing two questions:
- What does it take, from the organizational perspective, to develop and adopt a common language?
- Is doing so worth the trouble?
To conduct this work, we studied both successful and failed attempts to establish common language and we consulted with other experts. Our research led to two reports – Developing and Adopting a Common Language: What’s Required from an Organizational Perspective [2] and The Business Case for a Common Language: Not “If,” but “What and When?” [3] – and a management summary, Effective Digital Transformation Relies on Shared Language [4], that we think will be of considerable interest to all data practitioners. The remainder of this article summarizes the most important points. In particular, we recommend that data professionals:
- Spend far more time focusing on the business benefits of common language and less on the technical benefits.
- Spend far more time building the team needed to successfully define and implement common language and less on the technical aspects of doing the work.
What’s the Problem?
While most of us don’t think about it very often, common language is essential to business. There are standards to ensure that a meter is the same length worldwide and everyone agrees what “payment in U.S. dollars” means no matter what locale you live in. Indeed, common language simplifies the business of doing business, leading to numerous long-term benefits for companies.
Still, it is the exception. The COVID-19 pandemic illustrates the harm in a lack of common language. Good information is our best weapon in fighting coronavirus, yet we still lack common definitions of terms as basic as “death due to coronavirus.” Scattered and siloed data has hindered efforts in the public health crisis and led to unnecessary suffering.
Fortunately, most common language issues within companies are more mundane. Leaders struggle to answer basic questions like “how many customers do we have?” Managers find it tough to work across departmental silos, and technologists spend more time dealing with “systems that don’t talk” than they do implementing new technologies. Most of the added effort needed to accommodate the lack of common language has become so embedded in work life that people don’t even notice it. Even worse, the vast majority of efforts to establish common language, especially those at the enterprise level, fail.
How then, should data practitioners evaluate the high risk versus high rewards trade-off, and what should they do?
Before Jumping In: What Is Common Language?
For purposes of this article, common language refers to nouns, verbs, symbols, syntax, and signals with shared, agreed-upon meanings – that people use to communicate. Such meanings are often reflected in corporate and/or enterprise dictionaries, glossaries, and data models, including those physically implemented in databases and systems. Common language can also refer to codes and protocols that enable machines (especially computers) to communicate. Thus, Internet Protocol (IP) and Universal Product Code (UPC, typically displayed as a barcode) are examples of common language.
The Potential Business Benefits Are Enormous
Data professionals may think about common language in the context of computers, systems, and applications. Without common language, even correctly merging two databases becomes a chore. But the benefits go far beyond that. Our research (described in the aforementioned business case article) confirms that common language makes it easier to pursue all work, goals, and strategies that require coordinated action. Getting trusted answers to basic questions like “how many customers do we have?” is just the start. Other examples: Common language makes it easier for people to work across departments, evaluate business opportunities, respond to threats, and implement change. It saves time and reduces complexity. A common language reduces risk.
For the International Finance Corporation, a sister organization to the World Bank, the motivation to pursue common language stemmed from a desperate need to reconcile operational and financial data. The lack of understanding between various departments had created significant interpersonal friction, adding additional pressure to the business need. For Aera Energy LLC, a California-based oil and gas company, the motivations were three-fold: promoting standard operational processes across the company; building shared, application-independent databases that would be flexible and could scale; and freeing up engineers and geoscientists to spend more time on technical analyses and less on mundane Data Management issues.
In some cases, the motivation for common language crosses company lines. For example, in the telecom industry coordinated intra-industry action is required so two people can talk on their cell phones. In the retail industry, the common desire among companies to make checkout faster and improve logistics and customer service led to the widespread adoption of Universal Product Codes (implemented with graphic barcodes).
This discussion highlights an important lesson: You should spend far more time focusing on the business benefits of common language and less on the technical benefits. For example, while reducing technical debt and departmental in-fighting are both worthy business goals that common language helps achieve, it may be easier to build a broad coalition of people in support of reduced in-fighting.
Organizational Issues Dominate
Benefits aside, there are two major issues. First, implementing a common language is extremely difficult (see the aforementioned article on organizational perspective), especially at the enterprise level. This stands to reason: Absent an immediate problem, the short-term costs of developing a common language may exceed the short-term benefits, making it difficult to sustain development effort. Second, short-term problems that do require a common language are often misdiagnosed within companies: In short, people miss business opportunities.
Our paper on organizational requirements presents 10 criteria, covering the full gamut of long-term vision; sense of urgency; people and process; and adoption, to address these issues. If your organization is seriously considering any sort of common language, digital transformation, or enterprise architecture effort, you should evaluate your status with respect to each. If you can’t satisfy them, you should call a halt until you can meet them. Even better, find a business problem or opportunity for which you can.
Several highlights: First, a senior leader specifically must be charged with seeking, identifying, and pursuing opportunities. Candidates include: chief information officers, chief data officers, enterprise architects, and heads of strategy, who are often best positioned to spot the need for common language and weigh the potential benefits against the possibility that people will not support the effort.
Second, addressing these issues requires some clear-eyed thinking about the core concepts that drive a business, and it requires building those concepts into data models and, later, computer systems. To see why, consider that customer means distinctly different things to different departments: to Marketing, it means “qualified prospect,” to Sales it means “the person with sign-off authority,” and to Finance it is “whoever is responsible for paying the bill.” While each definition helps an individual department do its work, the three make it difficult for departments to work together. Embedding these definitions in individual computer systems exacerbates these difficulties. The PARTY concept recognizes that PEOPLE and ORGANIZATIONS play different roles and helps resolve these issues.
Some concepts, such as PARTY, PRODUCT, and CONTRACT, are shared by many industries. Other core concepts are quite specific. Consider the term “road” at a transportation agency. Does it mean:
- The route from the airport to a hotel (say) to those planning highways (and people wanting to go there),
- The right-of-way for laying out a road to those securing that right-of-way, or
- The volume of material used in constructing a road, to those sorting out how much construction will cost?
Note that routes, rights-of-way, and volumes of material are all essential to the agency, but applying the term “road” to all of them leads to confusion.
The secret to resolving the conflicts lies in discontinuing the use of “road” and defining core concepts, including:
- The network of PATHS, from one NODE to another,
- SITES, that are GEOGRAPHIC AREAS each with designated purposes, and
- PHYSICAL ASSETS, such as a quantity of pavement or a bridge.
These are clearly different and can be defined precisely.
It takes about 100 precise definitions of core concepts to set the foundation for common language across a typical company (a more targeted effort requires fewer). In turn, these definitions form the core of the company’s data models, and should be built into its databases, computer systems, and applications.
Third, enforcement: The steps above don’t present much of a problem when the technology is home-grown. But many off-the-shelf technologies come equipped with their own data models. “Enforcers” must insist that the company’s data models are used instead. Or, at the very least, each vendor must represent its models in terms of the company’s concepts.
Further, in the normal course of business, new terms come up all the time. This is normal and healthy, but left unchecked increasingly less common language means people talk less, silos grow, and it is more difficult to coordinate work. Enforcers strike a balance – allowing local variation to solve specific problems while ensuring the integrity of common language. As in conversations with vendors, localized language at some point must be reconciled with the corporate model.
The fourth key in creating a common language involves assembling the range of diverse talent needed to complete the work. From senior leaders to (abstract) data modelers, to those who can write (expressing complex thoughts clearly), to business managers, to technologists, to enforcers, to communicators (who sell the effort), to process managers (whose job resembles “herding cats” as much as anything else), there is no substitute for getting the right people involved.
Ultimately, only an organization’s most senior management can balance the trade-offs and build the coalition of people needed to develop and implement a common language. This stands to reason – after all, senior leadership bears full responsibility for the ways that business units and departments interact and language is a big part of that. It is a heavy burden.
This discussion highlights the second important point of this article: You should spend far more time building the team needed to successfully define and implement common language and less on the technical aspects of doing the work.
Final Remarks
Too many data practitioners fall into subtle traps. First, we try to define data models when the business language isn’t clear. This makes for models that don’t fully address the business’ issues. Second, we try to compensate for the lack of common language in designing applications. This means we eventually must custom-craft code to connect systems together – making for increasingly complex structures. Finally, we confuse management “support” for leadership. Absent true leadership in promoting the development of systems based on a common language, all of the problems described in this article crop up, and don’t go away soon.
We must avoid these traps. Instead, we must help our business counterparts, our companies, and our leaders see the opportunities and issues for what they really are and build the organizational capabilities to attack them properly. Both we and our companies have much to gain!
[1] Weinberg, Gerald M. 1986. Becoming a Technical Leader: An Organic Problem-Solving Approach. Dorset House.
[2] David C. Hay, Dr. Thomas C. Redman, C. Lwanga Yonke, John A. Zachman. “Developing and Adopting a Common Language: What’s Required from an Organizational Perspective.” The Data Administration Newsletter. April 1, 2020.
[3] David C. Hay, Dr. Thomas C. Redman, C. Lwanga Yonke, John A. Zachman. “The Business Case for a Common Language: Not ‘If,’ but ‘What’ and ‘When?’” The Data Administration Newsletter. December 16, 2020.
[4] David C. Hay, Dr. Thomas C. Redman, C. Lwanga Yonke, John A. Zachman. “Effective Digital Transformation Depends on a Shared Language,” Harvard Business Review, December 14, 2021.