Effective Digital Transformation Depends on a Shared Language

Companies all over the world are embracing digital transformation — the use of new (or already existing) technological capabilities — as the means to better work with their customers, distance themselves from (or keep up with) their competitors, and connect various aspects of their businesses. But to succeed in this endeavor — or even to simply get the most from their current tech — they must rid themselves of a heavy burden: technical debt. Put simply, technical debt occurs when you choose an imperfect short-term solution that will require a more substantial fix later, and includes disparate systems, added software to accommodate them, and added effort to work around them.

Because technical debt is the result of shortcuts — choosing quick fixes over a long-term investment — it causes plenty of problems in the here and now. It adds enormous friction any time people need to coordinate work together across silos. There’s also the ongoing expense to exchange data between systems; the unquantifiable costs associated with being slowed down by your systems, whether you’re in the midst of digital transformation or responding to a competitor’s move; and the price you must eventually pay to redesign and simplify systems. And technical debt and its costs compound over time.

At first blush, executives may dismiss technical debt as the province of their IT departments. That conclusion camouflages the root cause of the issue, however. In truth, technical debt stems from the way the businesses are structured, and how departments develop their own systems and languages for getting their work done.

Technical debt grows as departments adopt increasingly disparate business language and embed that language in their systems. To reduce it, companies must first establish, and rigorously adhere to, a small, well-thought-out common language.

An Insidious Dynamic

Technical debt grows in three simple steps. First, the seeds of technical debt are sown as businesses grow, change, and innovate, naturally leading teams and departments to develop and adopt new, increasingly specialized business language to help them do their work efficiently. This may not have presented much of an issue when the company was small — or when communication between departments was a person-to-person affair — but over time, a language barrier grew, making data sharing between departments extremely difficult. To illustrate this point, 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.” Note that in the context of the entire company, customer has three different legitimate roles, while each department focuses on only one.

Of course, these efforts help each department do its work. Over time, though, it becomes increasingly difficult for departments to work together.

Second, to automate their work, departments use databases, computer systems, and applications, which employ data models and databases to capture and lock in the business language of their users. While automation can help each department boost efficiency, it can also mean that the company winds up with multiple, disparate, department-level databases that don’t speak to each other very well. In particular, each department uses the role it sees for “customer” into their departmental databases. One visible result of this problem is that management can’t get a clear answer to “how many customers do we have?”

Third, people do a lot of work to accommodate the disparate systems: Business departments develop work-arounds and IT crafts custom interfaces to connect these systems. These measures add complexity; though without them, systems simply would not work.

The totality of this technical debt — the disparate systems, added software to accommodate them, and added work performed to work around them — will continue to grow until companies erect some guardrails to prevent the unfettered growth of disparate language.

The Resolution Lies in Common Language

The only proven way to fix this problem is to intervene at step one, via common language. This may seem like a daunting task — after all companies have thousands of terms in their vocabularies. The good news is that focusing first on a small subset of terms that align with the key concepts that bind the company together makes the task manageable. Our experience shows that no more than 150 such concepts are sufficient to transform the entire company. A smaller transformation project, such as adding a customer-facing app, may require as few as half a dozen.

Recall the example above, where “customer” meant different things to different people. The secret to resolving the conflict lies in recognizing and clarifying the underlying concepts:

• First, treat “prospects,” “signers” and “responsible payers” not as tangible things, but as roles played by one or more persons or groups of persons (e.g., organizations).
• Abstract a bit further, defining a “party” as “a person or organization of interest to the enterprise.”
• Take advantage of the flexibility this permits, assigning as many roles to parties as befits the business.

With this approach, a single, shared database can support marketing, sales, finance, and anyone else across the entire enterprise who deals with “parties.” For example, a party important to both marketing and finance is both a prospect and a responsible payer. This allows the company to retire departmental systems, minimize work-arounds, and eliminate the need for customer interfaces, in turn reducing technical debt. Within their departments, marketing, sales, and finance teams see no differences. Separating parties and the roles they play will make it far easier to communicate when working across departmental lines.

Note too that the resulting data collection is far richer, because it describes the full suite of relationships between parties and the company. And rich datasets set the stage for advanced data science and further digital transformation.

Don’t Underestimate the Effort Required

As Len Silverston, consultant at Universal Mindful and a leader in helping companies develop shared language, told me, “Common language and data models provide an architecture that guides further technological development.” But developing these underlying concepts, gaining agreement on them, and using them going forward is hard work. It requires committed leadership and a powerful coalition of people with diverse skills. In particular, a very senior business manager — one with the authority, gravitas, and level to call out the need for common language, sell the business case, set direction, provide resources, align others and enlist them to contribute — is essential.

To underscore this point, those heading up any given transformation effort may be tempted to repeat the mistakes cited above, arguing that investing in common language will slow their work. Possibly, but failure to do so will slow later transformations even further. It takes a very senior leader to evaluate the tradeoffs.

To develop the needed common language, that senior leader must also assemble and manage a diverse team to get the work done, including:

• Conceptual thinkers who can uncover the key concepts cited above.
• Skilled, business-savvy writers who can put those concepts into easily-understood, precise language.
• Negotiators who can resolve differences among various groups.
• Agents of change who convince others to adopt the common language.
• Architects and technicians who can instantiate the resulting language into systems.

Perhaps the role model for using common language to reduce technical debt is Aera Energy LLC, a U.S.-based energy company in California. Formed from a merger, Aera found itself saddled with hundreds of non-integrated legacy systems and inconsistent information management practices. A major acquisition a year after the merger further compounded the problem. A few years later, Aera implemented an enterprise resource planning (ERP) system, which provided some integration and new functionality. But the company still had hundreds of legacy systems.

Aera leadership recognized the situation was growing increasingly untenable and that common language was needed to resolve the underlying issues. In took Aera only 53 core concepts to capture the essence of its business. These formed the heart of long-term data, application, and technology architectures, allowing Aera to replace hundreds of systems over a several years and to add new capabilities. (Full disclosure: Hay, Yonke, and Zachman contributed to the effort.)

A well-thought-out and well-deployed common language will is a sound investment. Aera’s 53 terms served as the foundation for transforming transaction systems, building a comprehensive enterprise data warehouse to support new reporting and analytics and other capabilities, bringing newly-acquired oil and gas fields on board, dealing with new regulations, redesigning business processes, and making reorganizations happen — all without adding technical debt.

When planning your company’s digital transformation, it’s easy to get distracted by the new tech you’ll need. But don’t forget that the goal is to do more with the data you have — and that can’t happen unless your data is all speaking the same language.