We communicate using semantics, in other words - a language. It has repeating patterns and rules which enable us to create familiarity that translates to meaning and leads to understanding. We learn languages by exposure to the patterns and rules and experimenting until the useful level of understanding is achieved. I am not a linguistic expert of any sort, and I am sure my statement is not exactly what the textbooks would use to define a language. I apologize for that. Nonetheless, I would say it is a reasonable framing of what constitutes a means of communication.
Now without language, there is no communication. Without communication there is isolation and disconnect. We spend a great deal of resources to develop, compare and interpret information. However, when we exchange structured information, we often spend very little resources on ensuring the information we exchange is well understood and exists within a clearly understood contract.
When we sign up to exchange data, we often focus on the channel rather than the semantics. We will agree when to deliver information, where and how. We will also agree on the scope. For example, every Friday, we will get a export of all the new customers in a spreadsheet delivered to this xyz server. We will agree on the format, which will allow us to extract meaning from the data and also on the usage, provided there is sufficient risk or value embedded in the data. Notice however, that semantics has a limited presence in this definition.
Things get a bit better when the provider gives you a set of definitions, which is a portion of their semantic definition of the data. However, this definition is often riddled in several ways. Firstly, it is likely that it was partially defined, since the context of the contract is limited to a certain business activity. It would be rare for an organization to provide a definition based on a mature internal semantics language. Secondly, the domain of your business is at least slightly different from your provider and your definition of a product is not necessarily the same as your provider (and so are many more definitions). Lastly, your business is not likely to hold a mature semantics language for the same reasons your provider does not (there is little direct profit value out of such activities).
Now, this is the pit fall. When the semantics differ, and dissemination of the semantics is poor, you end up with augmented meanings and improper use of the data. It takes teams of knowledge workers to daily address complaints and quality issues, which we often blame on our provider or "bugs" in our systems.
To be clear, I am not pointing to any specific organization I have worked with, or for before. There is not a single institution I have ever come across which does not exhibit this phenomena. Nonetheless, this is simply a clear indication of a low maturity of data management.
So, what do we do?
Well, everything is driven by value or perceived value. There is a price tag to these activities. You would need to imagine a world without these issues first, and imagine the efficiency and the opportunity that come along with effective data management. Then you need to draw attention to the vision. In other words - market it. Finally, you need to work with the leaders of the organization to consciously integrate design and operational behavior changes to reduce ambiguity and create better semantics harmony. Internally and across organizations.
Ultimately, this will lead to a data exchange language which will allow us all to communicate and respond more effectively. So instead of having to ask questions about people meant by "date originated" or "number of irregular accounts", we can focus on value enhancements and product development rather than reactive and corrective behavior.
No comments:
Post a Comment