Developing and Adopting a Common Language

Executive Summary

It seems obvious enough that companies, government agencies and non-profits would benefit from a common language.  Without it, coordinating work is more difficult, computers “don’t talk,” and basic questions such as “how many customers do we have?” yield differing answers, making it more difficult to run the business.

It is observably true that most organizations do not have a common language and experience many such problems.  Furthermore, efforts to put all the data in one place have not yielded a common language.  Nor has the latest generation of technologies, such as cloud-based data lakes. 

These points led us to ask the following:

• What does it take, from an organization perspective, to develop and adopt a common language?
• Is doing so worth the trouble (i.e., what is the compelling business case for a common language)?

This report deals with the first question.  Specifically, we’ve identified ten criteria, grouped into four broad areas (1.  Sense of Urgency; 2.  Long-Term Thinking; 3.  People, Process, and Structure; and 4.  Adoption and Growth) that we consider necessary if an organization is to have much chance with a common language.   Each is tough on its own and, taken together, the range of coordinated effort is staggering.

We do not yet know if a common vocabulary is always worth the trouble.  Indeed, we suspect that answer will depend on the individual company’s business circumstances.  And it may well be possible that a company could develop, adopt, and benefit from a very restricted common vocabulary.  We aim to explore these topics in a later paper when we report on question 2, above.

As a standalone, this document aims to both:

• Educate those contemplating a common language, and
• Serve as a “checklist.” Do not go forward with a common vocabulary effort unless and until you can meet these criteria.

One final note: Our work was guided by one unqualified success, a few partial successes, and many failures.  The unqualified success was Aera Energy LLC, the Bakersfield, CA (USA)-based oil and gas company.  Herein we use “bullets” to explore how some of these criteria were/are implemented at Aera.

The Ten Requirements

1. Sense of Urgency

Employees at all levels of the organization can explain why the organization should develop and implement the common language (and not do something else instead), and why it should do it now (and not some other time).  As a result, they make time on their schedules to contribute, as required.  For some, the required time is significant. 

Long-Term Thinking 

2. Vision 

• A clear statement/picture of the intended reality once a common language is adopted, and how it will differ from current state.

3. Clarity of Purpose/Shared Business Objective

Sufficient long-term objectives incorporating overall company integration are important.  Unless the CEO advances the view that key terms must mean the same things across the enterprise, a common language effort faces long odds.  Further, large numbers of people must actively buy-in.   

In Aera:

• The purpose was to replace obsolete and redundant IT systems and improve data quality, specifically to “integrate people, process and technology to deliver quality information to business customers.”     

People, Process, and Structure

To coordinate and complete the work:

4. A Very Senior Responsible Manager

With the authority, gravitas, and level to articulate/sell the business case, set direction, remove obstacles, provide resources, align others, and enlist others to contribute.  Note:  This person does not need to have great depth with respect to data architecture per se. They just must be willing and able to actively provide support and exert credible influence to steer the effort to its successful completion.  A wide variety of people, in various positions on the organization chart, can play this essential role.  For the purposes of this document, this person is called the sponsor.

In Aera:

The CIO assumed the role of sponsor, helping to secure the sustained support of the CEO and aligning the IT Department to the effort.

5. Relentless Change Leaders

Who introduce the need for common language, persistently advocate and fight for it, define the business case and the vision, convert others, build a strong partnership between all involved, provide a means to implement common language, and deliver the business benefits promised.

In Aera:

• Several employees worked together as a team to help drive the change. The process owner for one of Aera’s core business processes was the champion who articulated the need for common language and the Zachman Framework for Enterprise Architecture (EA).  He also served as the primary spokesperson for the effort.  Three other early adopters, all from business teams at Aera, served as change agents.  They helped to drive across the organization the adoption of a common language and of the changes required to achieve it.  Underscoring the vital importance of business and IT partnership in this type of endeavors, these four individuals transferred to IT from business roles in engineering and management.  One of them in particular, switched from a senior business role to IT, bringing tremendous business acumen and lending immeasurable credibility to the EA effort.  He later became the chief architect when that position was created.

6. A Well-Defined Process

To get the right people involved (those who have a stake in the outcome and/or are needed to complete the work).  These people:

• Identify the underlying concepts,
• Define the appropriate language (key terms) for each concept,
• Resolve disagreements on definitions across the enterprise,
• Train everyone on the resulting unified language of the business, and
•  Build it into computer systems.

See the end of the article for a high-level process flowchart.

In Aera:

• Developing and instantiating the common language was achieved through three sequential efforts:
  • Aera enlisted the help of Steve Spewak and used his Enterprise Architecture Planning (EAP) methodology to implement rows 1 and 2 of the Zachman Framework, producing among other things, architectures for data, applications and technology, and a plan to implement these architectures. One data architecture deliverable was a list of 53 key business concepts along with their interrelationships and definitions. These terms were the foundation of common language at Aera.

Note:  The Zachman Framework for Enterprise Architecture is a matrix for classifying elements of the “body of knowledge” that describes an enterprise’s nature and structure.  It is organized in terms of rows that represent the different perspectives for viewing the architecture:

1. Executive
2. Manager
3. Architect
4. Engineer
5. Technician
6. The enterprise as a whole

The framework also features “What”, “How”, “Where” “Who”, “When” and “Why” columns.  Each cell then describes one aspect of how the enterprise works.  For a more complete description, see Zachman’s web site.[1]

• EAP was followed by a transition phase, during which Aera completed several improvement projects to put in place new processes and structures to position itself for the EA implementation phase.  Paraphrasing the popular saying, Aera knew it could not solve the problems it had with the same level of thinking that had created them.  Three of these projects were essential to its common language aspirations:
  • Aera defined and implemented a standard and rigorous System Development Life Cycle (SDLC) methodology. It required the articulated development of data models (Zachman Framework “What” column, rows 3 to 6), in a way that ensured that models developed for a given row successfully reflect the intent and requirements embedded in the models developed for the preceding row. Data quality and migration best practices were also built into the SDLC.

• Aera also established a data governance structure with two major components:
  • Information and process owners (IPO) were business managers from across the enterprise who have oversight responsibilities in several areas including process standardization and management, IT demand management and prioritization, and selection of business information stewards.
    • Business information stewards (BIS) were identified for each of the 53 key concepts identified during EAP, and they were charged with developing enterprise definitions and business rules as new data elements were defined.  The BIS came from business teams and were selected for their business knowledge and ability to build consensus.
  • Thirdly, Aera created and formalized the three roles of data, application and technology architects, entrusted with managing and maintaining the architectural models and artifacts developed during EAP, and responsible for overseeing their transformations into implemented structures during enterprise architecture implementation.
  • Enterprise architecture implementation (EAI) then followed, consisting of implementing the remaining four rows of the Zachman Framework through a series of applications development, iterative data warehouse implementation and technology projects, over a five-year period.  Throughout this implementation phase, the BIS carried forward the case for common language, identified and prioritized the additional terms that needed to be defined, and provided the definitions and business rules.  In rare occasions, issues were escalated up to the IPO group for resolution. The IT staff then instantiated the common language in computer systems (databases, applications, reports etc.), as per the SDLC.

7. Skilled Staff

A small team of people with the creativity and ability needed to do this at the right level of abstraction.  Importantly, some 100 concepts typically would underpin a common language, and these must be identified and understood in rich detail.   With such a foundation, the number of terms defined may gradually grow to thousands of terms (and included in a “data dictionary”).  However, skipping the identification of the underlying concepts and attempting to define terms straightaway, as some do, appears ill-fated.   Roles involved include:

• Data modelers.  In terms of the Zachman Framework, they are responsible for the description and formal representation of the “What” column, rows 1, 2, and 3.
• Data definers, who can write clear definitions.
• Responsible managers, who represent the interests of their departments AND are also able to collaborate to achieve win-win to meet the needs of the enterprise.
• Process managers, who are responsible for coordinating the work. 
• Enforcers, who ensure that the common vocabulary is adhered to, particularly in databases, computer systems, and applications.
• Communicators, who can communicate the concepts to the rest of the organization, to vendors, etc.

In Aera:

During the planning (EAP) phase, the Aera data architect and three of the business leaders who had transferred to IT were the data modelers and definers, coached by Steve Spewak, and pulling others from business teams as needed.

During the implementation (EAI) phase:

• The Aera data architect and David Hay (brought in as a consultant) were the primary data modelers.
• The business information stewards were the data definers.
• The data architect, who had played a key role in the development of the Aera SDLC, became one of its crucial enforcers. The data architect was supported by the application architect, the technology architect, and the chief architect.
• The information and process owners were the responsible managers.  They also helped enforce the common language by role modeling its use.
• Different people assumed different process manager roles:
  • The business leader who was the champion at initiation became the EAI program manager, responsible for the delivery of all the EAI projects.
  • One of the change agents became the data architecture manager, leading the data architects and the data quality staff who were embedded in the EAI projects teams.
• A team of two people handled change management and communication, as well as training.
• The eventual success of the common language effort was enabled by the fact that a critical mass of hundreds of people in IT and in the business departments embraced the new expectations and became skilled contributors. 

8. IT and All the Business Departments Must Contribute

Each must name a responsible manager, who has the authority to speak for and represent the needs of his/her department. These people serve as change agents and help drive the adoption of the common language in their respective departments.  In addition, a critical mass of business and IT staff at all levels of the organization must adopt new ways of thinking and working.

9. Adoption

The common language must be built into the day-to-day vocabulary of the organization and into the processes used to describe the work the organization performs. It also forms the basis of the data architecture which is deployed and adhered to in the development and purchase of new systems (database designs and implementation, application user interfaces, standards to assess commercial off the shelf (COTS) systems, etc.)

10. Growth

The organization must have the capacity to include new concepts and/or terms, as the business grows and changes, and to eliminate those that no longer matter. 

In Aera:  No new concepts have been added in fifteen plus years.  There are now close to 1,500 terms defined in the Zachman Framework row 3 data models.

A Long Journey

It is trite to observe all human activity, and especially commerce, depends on common language.  Thus it is no surprise that people all over the world are learning English—doing so improves their employability.

To conduct their businesses effectively and efficiently, companies and government agencies need greater precision than “English” alone provides.  Still, developing and adopting common languages have proven difficult.  We set out, if only for ourselves, to clarify what exactly is required from an organizational perspective.  While we expected that we would compile a demanding list, we were surprised just how much consistent, long-term effort is required, up and down the organization chart.  So demanding that, as we worked together, we often remarked in frustration, “No current company could muster these resources.  This will never happen!”

Thus we appear to have a bit of a paradox:

The apparent need for a common language vs. The difficulties in defining and adopting one

Of course, there is no true paradox.  Companies do amazing things—when they are sufficiently motivated.  This point underscores the importance of the second question we’ve asked ourselves, “What is the business case for a common language?”  We’ll report on that as soon as we are able.  And we encourage input.

In the meantime, we are making this report available–the need for a common language comes up frequently, often disguised as a data warehouse project, master data management or enterprise data architecture. We urge those promoting such ventures to study this document carefully, lest they underestimate what is required.

(c) Copyright 2020 Hay, Redman, Yonke and Zachman
All rights reserved

---

[1] See https://www.zachman.com/about-the-zachman-framework

Author’s Biographies

David C. Hay

David Hay has been producing data models to support strategic and requirements planning for more than thirty years. As President of Essential Strategies International, Mr. Hay has worked in a variety of industries and government agencies. These include banking, clinical pharmaceutical research, and all aspects of oil production and processing. Projects entailed defining corporate information architecture, identifying requirements, and planning strategies for the implementation of new systems.

Mr. Hay’s most recent book,  “Achieving Buzzword Compliance: Data Architecture Language and Vocabulary” applies the concepts of consistent vocabulary to the data architecture field itself.

Previously, Mr. Hay wrote, “Enterprise Model Patterns: Describing the World”, an “upper ontology” consisting of a comprehensive model of any enterprise. It is the successor to his ground-breaking 1995 book, “Data Model Patterns: Conventions of Thought”–the original book describing standard data model configurations for standard business situations.

In addition, Mr. Hay has written other books on metadata, requirements analysis, and UML. He has spoken at numerous international and local data architecture, semantics, user group, and other conferences.

Dr. Thomas C. Redman,

Dr. Thomas Redman (“the  Data Doc”), is the President of Data Quality Solutions.  

Dr. Redman helps companies attack data quality head-on, using new approaches, managerial responsibilities, and techniques.   His book, Getting In Front on Data: The Who Does What (Technics Publications, 2016), and “Data’s Credibility Problem” (Harvard Business Review, December 2013) are the indispensable references.  

Dr. Redman helps them see the big picture and get the right focus, leadership, structure, and people in place.  The Real Work of Data Science (w/Kenett, Wiley, 2019) summarizes.  Finally, his  book, Data Driven (Harvard Business School Press, 2008) explores what it takes to manage data as assets.  He has written dozens of articles for Harvard Business Review, The Wall Street Journal and MIT Sloan Management Review. 

C. Lwanga Yonke

A seasoned information quality practitioner at Aera Energy LLC, C. Lwanga Yonke has successfully led teams in multiple areas including data architecture, data warehousing, business intelligence, information quality and data governance. His initial experience is in petroleum engineering and operations.  He is a founding member of IQ International (prev. IAIDQ) and served as a volunteer and advisor to its Board for Directors for many years.

John A. Zachman

John Zachman is the originator of the “Framework for Enterprise Architecture” (The Zachman Framework™) which has received broad acceptance around the world as an integrative framework, an ontology for descriptive representations of Enterprises. Mr. Zachman is not only known for this work on Enterprise Architecture, but is also known for his early contributions to IBM’s Information Strategy methodology (Business Systems Planning) as well as to their Executive team planning techniques (Intensive Planning).

Mr. Zachman retired from IBM in 1990, having served them for 26 years. He is Chief Executive Officer of his own education and consulting business, Zachman International® and Owner and Executive Director of the Federated Enterprise Architecture Certification Institute in Washington, D.C.

Mr. Zachman has been focusing on Enterprise Architecture since 1970 and has written extensively on the subject. He has directed innumerable executive team planning sessions. He travels nationally and internationally, teaching and consulting, and is a popular conference speaker, known for his motivating messages on Enterprise Architecture issues. He has spoken to many thousands of enterprise managers and information professionals on every continent.