Free FLOWing Information for the Enterprise

A bridge is needed between the Language of Leadership and the Language of Management

I was recently re-reading the seminal FLOW® methodology book by Ted & Andy Kallman and was reminded of one of the most powerful concepts they put forward, that is “The Language of Leadership vs The Language of Management”, and how I’ve seen that disconnect dramatically hinder efforts to implement Enterprise Information over the decades.

FLOW® is aimed at broader enterprise efficiency and profitability and unifies “…Traditional management and Agile methodologies enabling successful results…” [From the back cover of the book].  I had the privilege of working with Ted twenty years ago while some of the early concepts were being formalized and I was astounded at the difference between teams following his guidance and teams trying to barrel forward and produce “brute force” results.

The common ground between Ted and Andy’s approach and my approach centered around establishing clear communications between team members, leadership and the rest of the organization.  My focus was, is, and always will be getting clear, unambiguous, and exhaustive plain business language descriptions for every data element (at the attribute/field level)  that has value to the broader organization because it has been my experience that the lack of these descriptions has been the single biggest hindrance to development projects moving quickly (Agile), while delivering results that have both tactical (project scope) and strategic (enterprise scope) value.  A lengthy discussion of how that manifests itself is beyond the scope of this, but I’ll be happy to go into it later if there is any interest.

This distinction between “tactical value” and “strategic value” is key, for it is at the heart of why “technical debt” accumulates in enterprise data systems as the years and projects pass.  Project teams (software development, software package implementation, etc…) are rarely (approaching “never”) measured against the “quality” to the Enterprise of the data that they capture, manipulate and present.  The priority, invariably, is “Do the screens come up?”, does the application seem to perform the specific functionality that the sponsoring business unit desires?  If so, victory is declared, cake is eaten, awards are handed out, promotions given and everyone moves on.  The problem is that since expanding the discussion of the data elements in the scope of the project that might have a broader usefulness to other business units or even Enterprise-level reusability will take more time and delay the declaration of victory they are enthusiastically resisted by the project teams.  They are operating at the level of “The Language of Management” which is very functionally specific (tactical in scope) to the business unit sponsoring the project.

Fast forward to Executive Leadership wanting to have a “Quote to Cash” dashboard.  Now they are thinking in terms of the “Language of Leadership”.  While the concepts in which they think are broader, they are made up of collections of finer-grained concepts that have all been formalized in un-integrated and typically poorly defined siloed “tactical” implementations.  The process of properly identifying compatible/equivalent finer-grained data elements is excruciatingly slow and error prone.  When external data sources/clients are thrown in as well as external systems needing to be integrated due to acquisition the mountain of technical debt becomes terrifying.

Again, a detailed discussion of the path out of this quagmire is outside the scope of this piece, but at a high-level what must be done is the establishment of a “canonical” business glossary at the Language of Leadership level and then incrementally a “mapping” of those concepts to the underlying physical instantiations/representation (“Language of Management” terms).  This “mapping” and the underlying definitions work that must be done is of immeasurable value to data scientists, business analysts, development teams (new development, new implementations, integrations, etc…), compliance folks and executive leadership. The challenge is that this isn’t some “silver bullet” piece of software that can be bought and turned on.  It takes organizational understanding and executive leadership buy-in and sponsorship to create a culture of shared understanding and strategic priorities versus siloed victories.

“Culling the Herd”

This article was well written and contained this gem, which was re-quoted by Daniel Roth [Executive Editor @ LinkedIn] on LinkedIn:

…when you have those high performers in place, cutting those who aren’t working out becomes easier. “High performers hate working with mediocre performers,” she says. “Not just low performers. Mediocre performers. So you’re devaluating your best team players by not addressing people who aren’t really cutting it for the brand.”

Data Quality and Integration rarely dies a dramatic death… it is usually a “death of a thousand cuts”

There is rarely a moment in time when the forces of anarchy rise up and commit to a full-frontal assault on the concept of integrated, high-quality data.

No, the far more likely path to ruin is paved with short-sighted expediencies, misguided priorities, poorly planned performance metrics and weak-willed governance.

Most real data quality advocates are outnumbered a hundred or more to one in any given organization and the slightest loss of conviction by executive leadership when tempted with “quicker” screen delivery will excite the pitchforks-and-torches crowd to a frenzy that will soon overwhelm the voice of reason and lead to decisions that are more quickly gratifying while strategically devastating.

As the integrated environment is incrementally polluted with data feeds of ever-diminishing quality or bypassed entirely in search of a “quick win”, the prophets of doom who never really wanted to go to all that extra effort swoop in to capitalize on each and every tidbit of negative feedback like vultures picking at a slowly decaying carcass.

Eventually, when the data can no longer be considered comprehensive, accurate or timely the verdict is rendered that “integration” is a quixotic idea and faster, easier and [immediately] cheaper is the way to go.  The potential real benefits of organizational agility, informational stability and architectural flexibility are dismissed with a snort.