What’s missing is a way for non-technical users to clearly communicate the business model* of their own company’s data to their technical experts.
In the beginning, there was an idea for a company. A group had an idea to create and sell a line of products. The way the company would grow their business was simple. They’d make money by selling their incredible products to many customers all over the world. Everyone would want these products. Who wouldn’t? Their products were going to be amazing!
Customers would place orders for products. An order form would need to allow for multiple entries as people would want more associated products from the company based on the continued excitement around their brand and offering. Products might even be sold under different brands as the products needed the ability to cater to customers of differing financial means and/or global locations.
They sketched out a plan for their business ( and perhaps, albeit unbeknownst to them, the data they’d need to manage ) one night on a napkin. It looked like this:
Of course there would be other entities and relationships to account for. Orders for Products may be placed online or in a store at the mall. Products would be stored in a Facility. A Facility would have an Address and would ship products to another Address. Any Customer’s billing address and shipping address may differ depending on their relationship to a Product as well. No problem.
The components for business were clearly communicated with each other on the back of a shared napkin that night, using circles, lines, and some labels. Simple!
Alas, real data would need to be associated with all these entities and relationships and there was A LOT of it. Each entity might find itself needing to account for many attributes that they cared about capturing to aid the business in its growth and success.
Luckily for the company, there were applications already available to help solve the data management problem for different areas of their business. So they rushed out and purchased CRM, ERP, point of sales systems, and other applications to help manage this data.
Unfortunately for the business users though, these systems, while wonderful and incredibly useful in their utility, mapped the simple business concepts they’d sketched out on that napkin to several disparate, complex underlying storage systems.
A purchase no longer looked like an order form, but something more like a complex schematic. A customer morphed from an actual person having a set of attributes to a collection of disjoint columns and rows, related by keys across multiple, multiple tables.
And thus, the seed of the disconnect was planted.
Technical experts were soon hired who understood the complexities of these data models and the programming languages required to get data in and out of the underlying systems. These experts combined to form IT and they were charged with supporting the data technology needs of the business. They performed their duties with intelligence, rigor, and tenacity, but soon became outpaced by the speed of the business.
As the company charged forward to success, new applications continued to pour in as business bought new systems to support itself or acquired existing systems through mergers and acquisition. These systems contained other machine oriented data models, all with their own complex storage systems. IT became very adept at taking care of all this data, yet completely swamped with a backlog of requirements for updating the management and maintenance of all the existing data processing.
As IT went deeper into the underlying systems to make sure the right data kept flowing and processing correctly, the language of business was lost. The rift between business and IT solidified, and the disconnect between business and their data grew. The company and IT no longer knew how to communicate with each other. Each group’s understanding of the data differed. Teams of people were organized around systems separated by technical and functional boundaries, resulting in data and departmental silos. The organizational fissures deepened as the storage of the data moved further away from their initial, simple back of the napkin model.
Meanwhile, out in the world, technology advanced to a point where a business person could reach into their pocket, grab their phone, and in an instant have immediate access to any of their personal data through simple apps. They grew frustrated when they went to work and didn’t have the same access to their own company’s data. A request to IT was met with a response that it would take 12–16 weeks to provide the answer. How could this be?
From IT’s perspective though, this was a fantastic response time given all the other ongoing work in support of the business. To business users though, the initial response given to their request was both maddening and unacceptable. By the time they’d get their data, it would be too late!
Business and IT could not have empathy for each other because they did not have the ability to put each other in each other’s shoes and see what each other’s data experience was like. And so, the frustration and friction between the groups grew as did the real threat of invisible data.
Surely technology can help solve this problem though, right? Well, in my experience, adding more technology to a problem created and perpetuated by technology isn’t necessarily a guaranteed recipe for success. However…
What could possibly go wrong? What could possibly go right?
* A business model of data captures data in a coherent structure similar to how normal human beings, not machines, think about data. Business rules are defined and applied within the structure of the model. This model is easily understood and validated by executives and subject matter experts together. The conceptual model of data and physical storage of data are closely aligned, making it simple for non-technical users to understand, communicate, and interact with the data for their business.