Tacit knowledge and lightening-speed communication make very poor bedfellows. In the Knowledge Age, the central issue is effective communication. It's time to architect what we know and how we express it on a much larger scale. The foundation? A structured business vocabulary – what we call a concept model. That's the human side. Then the opportunities on the technology side are boundless. First, we need to rethink what this space is really all about.
We recently coordinated the development of an enterprise-wide concept model – think structured business glossary – for a large sovereign wealth fund. It included over 1,700 business terms and definitions, along with 65 graphic diagrams ('neighborhoods') showing visually how the underlying concepts relate. The fund's motivation? The creation of a sophisticated (and expensive) new data lake for the business. They understood clearly that without a common business vocabulary, an integrated and useful solution would elude them.
The project shone a spotlight on where a business vocabulary actually originates in the organization and who needs to be involved in its standardization. It also sharpened the necessary distinction between vocabulary vs. data ownership.
After feeling our way forward, we zeroed in on the organization's policy documents, which had official glossaries. What better place to go for authoritative vocabulary? Of course, each document had its own glossary, and none took a completely enterprise view, but those were problems they could recognize and address.
What better starting point for terms and definitions than business policy documents?! When you work on vocabulary from a truly top-down, business point of view, you see how ineffective an IT-up or data-out approach will likely prove.
The Formal Business Messaging Pyramid
Policy documents lie at the apex of different forms of formal messaging or communication in the business. The Formal Business Messaging Space in your organization takes the form of a pyramid, as illustrated in Figure 1. Business vocabulary and natural language is a central component of each layer. You find that words and sentences (roughly 'messages') are literally everywhere.
Think how dis-integrated this pyramid is in most organizations. Where is any knowledge blueprint to work by?
We've been saying for years that data is central to your organization. But formal messages are even more basic. Before words can properly label your data, those words must play a central role in command, execution, and knowledge transfer. The point is so obvious, we often take it for granted.
And that's becoming the source of great pain for many organizations. As an IT professional or business analyst, you may think this 'business-side' stuff is not your concern. You're wrong. The result of such thinking is data and systems that don't 'message' effectively, ones that never seem really plugged into business knowledge.
Knowledge Alignment
A central challenge up and down the Formal Business Messaging Pyramid is alignment, which needs to be coordinated in two main ways. The first is obvious. The second, less so.
- First and foremost is strategy alignment. Messaging that is misaligned with strategy and policy will always be counterproductive. But of course, we've known that for years (even if not always practiced).
- Second, and not far behind, is knowledge alignment. Except perhaps in the limited sense of knowledge retention, the need for a deliberate, engineered focus on this kind of alignment is new.
What is the basis for knowledge alignment in the organization? Words and sentences (and ultimately labels for data). A fundamental principle for the Formal Business Message Space is that all forms of messaging should be based on and coordinated with the prime knowledge sources in the business – those of the second highest tier in the pyramid (legal, science and engineering documents).
About Requirements
You've probably noticed that requirements are missing in the pyramid. Aren't they 'messaging' too?
Yes, but requirements lie in a different dimension. They are specifications for something that needs to be built, not messaging between and among business players for directing and operating the day-to-day business.
A major failing of most requirements approach is that they are not plugged directly into prime business knowledge sources. For example:
- Many requirement documents don't even bother with a business glossary. Even when they do, it's not coordinated with the authoritative knowledge sources.
- A great many business analysts still know little or nothing about the how-to of interpreting (and questioning) policy and knowledge sources – even though this activity should be central to dialog about requirements with business stakeholders.
Does this know-how exist? Yes, we've been developing, practicing and teaching it for years.1
What About Informal Messaging?
The Formal Business Messaging Pyramid focuses on formal messaging (documents of all kinds), not informal messaging such as face-to-face conversations, virtual meetings, emails, etc.
Aren't informal communications important? Of course, but let's look at the bigger picture. Going forward, what percentage of the total messaging in a knowledge-rich, digitally-oriented organization can be informal? We're already swamped. Even if we can maintain the status quo in the increasingly digital world, we're swimming against the tide. And it's only going to get worse over time.
We're quite aware that this new holistic view of the messaging-based organization needs to reach and penetrate the business side. The larger solution is only indirectly an IT or business analyst problem. But who are the agents of real change in organizations these days? If you're reading this article, it's probably you!
Can the responsibilities for vocabulary ownership and data ownership by business stakeholders be separate? Should they be? I have listened to many presentations and read many articles about data governance (or data stewardship if you prefer), but I have never come across anyone saying they can and should be. So, I'm going to say it. If you are involved with data governance in any way, you'll want to read this piece. Chances are it will surprise and maybe even shock you.
Ownership of Vocabulary vs. Ownership of Data:
A Fresh Look from the Business Messaging Perspective
A client recently posed the following questions to us: Should the business owner of a business term and the owner of related data be one and the same? Are the responsibilities inseparable? Should they, and can they, be distinguished? By 'term' the client meant business term and business definition.
The answer is of course they can be separated!
As proof, consider this. Let's suppose you are a strong or even moderate believer in data privacy. You think the consumer (or citizen) should own or control their personal data, not the organization with which they interact. To me, it's nonetheless pretty obvious that the organization does not need to, and in fact cannot, cede control of the names of concepts (terms) and their definitions to the consumer. The result would simply be anarchy. Clearly, the ownership of business vocabulary can be separate from ownership of data.
In cases that do not involve questions of data privacy, do the responsibilities need to be separate? I have listened to many presentations and read many articles about data governance (or data stewardship if you prefer), but I have never come across anyone saying that yes, they do.
It's possible of course that I've simply missed hearing it, or that the data governance coordinators weren't being entirely clear about the matter. I'm simply saying I've never come across a program where separation of the responsibilities is evident.
It's hardly surprising, of course, since most data governance initiatives are spawned by IT (in one way or another). But I think it's fundamentally wrong.
I view lack of separation as the root cause of a host of problems, not least of which is massive loss of productivity right across organization. It's also a symptom of the underlying failure to understand and embrace what I've come to call the true Messaging Space of the business.2
In any case, it's time to take a hard look at the respective responsibilities of vocabulary ownership vs. data ownership.
Ownership of Vocabulary. Ownership of business terms and definitions implies exercise of high-level authority.
- Well-crafted business definitions should seldom change.3 When they do, however, broad implications for the business can result. For example, consider the potential implications of changing the definition of 'product'. Such change should be viewed as a matter of executive strategy and/or of deep subject matter expertise.
- Changing business definitions is actually a matter of changing business policy. The impact can be far greater than just on data; all other forms of policy and corporate communications depend on the meaning they express. In other words, business vocabulary is the foundation of the entire Business Messaging Space.
Ownership of Data. Ownership of data implies performance of operational responsibility.
- Adjustments to data specifications are often on-going. The (business) rules for consistency and correctness need continual adjustment and re-evaluation, especially as special cases, exceptions, and new channels arise. Code schemes need to be managed, and mapping regimens need to be regulated. Lack of proper attention can have overall impact (e.g., diminished precision in KPIs), though immediate results are usually localized (e.g., specific transactions in error).
Given that the responsibilities for vocabulary vs. data can and often should be distinct, who is the ideal business owner of a business term and the related definition? We offer the following criteria, more or less in the given order of priority.4
- The business unit that creates the concept. Such business units are often responsible for governance or enabling functions, rather than line functions. The unit has frequently produced authoritative policy documents that can serve as key reference points. In financial investment, for example, a policy document addressing delegation of authority might introduce the concepts of 'allocated capital' and 'committed capital'. The business unit responsible for producing that policy document should be the owner of those terms.
- The business unit that has the broadest knowledge of the concept and use of the designated term. Business units often create concepts and terms for their own needs, even when those same concepts are more widely applicable across the organization. The owner should be the business unit that has the deepest understanding and widest view.
- The business unit most impacted if the meaning of the term changes.
- The business unit most upstream in the value chain (generally the one where data is first created under the term).
Is your requirements approach friendly to vocabulary, policies and messages? I mean directly. Wouldn't it be of great help to your organization in achieving its goals if they were? In our experience, policy sources almost always need interpretation and disambiguation to achieve an effective practicable form. As this column discusses, the rule message 'Reserved for Green Car' provides an excellent case in point.
What Does It Take to Message Effectively?
The 'Reserved for Green Car' Case Study
Suppose you were a cop and you came across the situation in this photo. Would you issue a citation for a parking violation? If the case went to court, and you were the judge, would you rule for or against the defendant?
I'm not a lawyer, but common sense suggests that the driver almost certainly violated the intent of the rule. Maybe because drivers are licensed, they are expected to correctly intuit the proper interpretations of traffic signs. But turning to business, how many of your end customers and workers are licensed to do what they do?
Let me make these important points:
- Messaging matters. Mess up the communication about guidance, and transactions (let's say that in the present context the act of parking a vehicle is a transaction) can easily go astray.
- Message makers (in this case the sign designer) should not be left on their own when it comes to creating guideposts for operational activity. Those of you who are business analysts and IT professionals are sign makers in more ways than one. So yes, if you're reading this, that probably means you.
- It's not enough to simply establish rules. Messaging about the rules is also part of the equation. And it's true whether or not the rule can be automated.
Let's be clear about what kind of messaging I mean. All the following are involved:
- Selection of Term. Clearly the term 'green vehicle' could be ambiguous. Did the business people (state highway or local traffic officials) foresee that? Should they have thought through its usage in the constrained real estate of likely communication channels (here the size of the sign) more thoroughly? Should business analysts or other professionals have given them a heads-up about this potential problem in advance? I'd say the answer to all these questions is yes.
- Definition of Concept. What is the meaning of 'green vehicle'? Is the concept defined clearly? Is it defined somewhere that is accessible for people who need it (e.g., the driver of this vehicle)? Let's assume the driver of the pick-up truck is a righteous citizen. Could they find the definition in real time? For example, would it work to post the definition on the back of the sign? What's the feasibility of an app for that?
- Short-Handing the Rule. Apart from the problem with 'green vehicle', does “Reserved for Green Vehicles” best support the messaging? Would 'Green Vehicles Only' be better?5 A before-implementation-time conversation about the best form of the message should directly involve business stakeholders.
- Expressing the Policy. If you unravel this ball of yarn completely, ultimately you get to the long-hand expression of the parking law or regulation in an authoritative source. That's the ultimate source of the truth. Without ever considering that source text directly, it's hardly surprising you'd go astray in implementation.
A little backstory: I put this photo out on social media and posed essentially the same questions as earlier. A flood of replies came back, most of which in one way or another had to do with requirements.
Hold on! Where did I say anything about requirements?! Frankly, I think the relevant 'requirements' were probably satisfied by this implementation – a sign was visibly posted for the reserved spot. The rea problem was not with the requirements, it was with the (business) messaging.
Let me make that last point more strongly. Talking 'requirements' when the issue is policy and rules is way off-target. Rules are rules, and requirements are requirements. First there are rules, then there are requirements. Why shouldn't business analysts engage directly with the (original) rules themselves, along with the associated terminology and messaging? No-brainer!
Ask yourself: Is your won requirements approach friendly to vocabulary, policies and messages? I mean directly. Wouldn't it be of great help to your organization in achieving its goals (not just build IT systems) if it were? In our experience, policy sources almost always need interpretation and disambiguation to achieve an effective practicable form. 'Reserved for Green Car' is a great case in point.6
In the knowledge age, the messaging component of any business problem space simply cannot be ignored7. In a digital world very seldom will there be any flesh-and-blood cop on the spot when it comes time for a metaphorical 'don't do that'.
1 The BRSolutions Professional Training Suite: https://brs1on1.com/order/. Take a 10-minute pinpoint assessment to determine whether this training could be helpful for you and your company: https://brs1on1.com/.
2 [Reference to last month's column.]
3 Crafting great business definitions is a key component of the BRSolutions Professional Training Suite: https://brs1on1.com/order/. Take a 10-minute pinpoint assessment to determine whether this training could be helpful for you and your company: https://brs1on1.com/.
4 These are general guidelines. Much depends on how the organization is set up and of course, internal personalities and interests.
5 In our RuleSpeak® we have a strong preference for 'only'.
6 These are key components of the BRSolutions Professional Training Suite: https://brs1on1.com/order/. Take a 10-minute pinpoint assessment to determine whether this training could be helpful for you and your company: https://brs1on1.com/.
7 I talk more about Business Messaging in my most recent two columns. [references]
Ron Ross
Latest posts by Ron Ross (see all)
- Business Rules Solutions: What is Data Science, Really? - December 6, 2021
- Business Rules Solutions: Rethinking your Business Management Space—Knowledge Alignment - October 4, 2021
- Business Rules Solutions: Concept Models: Who Are They For? - July 6, 2021
- Business Rule Solutions: Empowering People with Core Business Knowledge: Concept Models - October 5, 2020
- Business Rule Solutions: Getting the Knowledge Payload of Processes—Concept Models - July 6, 2020
Speak Your Mind