The formal definition of information modeling (IM) is misleading as it focuses on plain technicalities omitting drama from the story. The IM deficiency is behind Reason #3 of startups' early demise - business scaleup.
IM is to a lesser degree a rigorous process and more of a human interpretation of facts. So it seems natural to move the scale of the IM definition to the human being side. (If most of the critical information is verbal, can we disregard listening skills in IM?)
We may say that IM plays the role of glasses that transform the world around us into chunks of data. One needs the magic of design thinking to discover the chunks' causality (semantics).
Design thinking drills on systematic reasoning rooted in structured knowledge - the product of information standardization and unification.
It means that we don't start IM from scratch, we start it using the existing Information Classifying and Coding System (ICCS) and continue adding new blocks to it.
ICCS feeds and expands on IM. The ICCS omnipresence means that IM transcends the business - the vector of IM does not coincide with that of business digitization. In other words, the final destination of IM-driven business transformation can't be predicted with certainty.
IM is iterative in nature. Every next iteration is triggered by a leap in our perspective on business. Crenger.com exemplifies the IM evolution. It started from the notion that engineering leads the business, and then it extended to management, procurement, maintenance, training, and certification.
The IM evolution is slow compared to that of front-end technologies. Its inertia is a sword of Damocles hanging over digitization.
IM creates abstractions by trimming out inessential facts. It is devil's-in-detail ground. Crenger.com considers IM inadequate if it covers only 99% of use cases. What changes our business perspective is the last 1%.
What is the use case? It is a mini-story intended to capture the essence of some business episode with all the actors (and their context interpretation biases) involved. To turn life into a sequence of episodes some domain knowledge is needed.
People without listening skills and emotionally disconnected from business are unable to perform this job, regardless of domain expertise.
Another key conclusion is that vicarious experience is useless in IM. What keeps on feeding crenger.com with the use cases is 7 desalination megaprojects on my resume.
The best illustration of the 1% rule at work is the automation of the request for quotation (RFQ) compilation. RFQ is a bundle of engineering documents like specifications, drawings, and datasheets. Auto-generation of each of them is an engineering challenge. What entirely changed the perspective of crenger.com on the task is an addition to the bundle an invitation to bidding. It is a letter with standard content to be signed off by an authorizer from the procurement department. This deceptively simple task created a cascade of changes in IM to accommodate the business decision-making hierarchy. It, in its turn, leads to the deepest business abstraction ever - the company.
Once the business data semantics has been established, it's time to move to Data Modeling (DM). To explain its purpose. let's consider the creation of an Excel table. While IM defines its column names and quantity, DM chooses the column cells' format - text, number, date, etc.
In business applications, the "column" names are the ICCS categories, and the "column" cell formats are not chosen but modeled like a color by "blending" above mentioned primitive formats. If IM searches for details, DM - for commonalities.
Today DM enjoys a high degree of automation; codes and database tables - the core of the back-end development - are generated in no time. Why should one be concerned about DM?
The problem is that DM is responsible for data creation and destruction. They are at the core of the DM and IM validation. Normally, it fails.
Data destruction polluting the database with data leftovers points to flawed data creation. This problem is incomparable with a less obvious one - unfriendliness of the data creation. It plagued many IT applications available on the market.
The major culprit is so-called good practices in engineering, management, procurement, etc. They are unwritten rules behind data creation, not captured by the use cases. The rules dive deep into personal experience and tacit knowledge discussed by me extensively in "Now-How Creation".
For example, the use case instructs us to model the project commissioning check as an object containing a description of what to check and the due date of its execution (at least). The data should be manually entered in the user dialog box about 20,000 times! Adding check rules to DM makes this work redundant.
A person who aces in IM may trip over her biases in DM. For example, the tank and the pump don't have common points in construction and operation. They are placed at different locations in the ICCS hierarchy. Surprisingly, both are mapped to the same data model!
The selection of the data model varies depending on whether
- data is temporary or permanent
- data is critical or not
- data is of the highest security level or not
- data may be extended in the future or not