Blog: Dan E. Linstedt

« Data Modeling is vital to successful Business practices | Main | Business Intelligence and the IRS »

It's Business Modeling, not Data Modeling.

Whether or not it's an IT shop, or a business user - its critical to change the paradigm of thinking to Business Modeling. In the physical notion of storing data, IT is data modeling - however it should all be based on business modeling efforts.

There has been a divergence between the way business gets done, and the models that house the data for the business. This is causing severe friction, particularly when businesses go to make a change.

IT needs to change their thinking about modeling; in March 15, 2005 CIO magazine, Rick Pastore commented: "Alignment is Dead: Long Live Convergence".

As stated by Rick:

To initiate convergence, there's no one button to push; there are a whole slew of things to pursue - such as populating steering committees with business and IT leaders who work from one strategic blueprint, colocating IT managers in business units, abolishing the notion of IT projects in favor of business-funded Business Projects enabled by technology.

What is meant by "Business Modeling"? Isn't this just another form of process modeling or re-engineering? No. What is meant by business modeling is the idea that business processes are the drivers for collecting and using information (data), therefore the systems that are built to house that data should be modeled after the business.

For years, IT has spent time and money training data modelers how to build "data models" that meet IT needs and desires. Then, they go through undulations of requirements gathering and interpretation of those requirements to arrive at some arcane data model. Note: Not all data models are arcane, there are some great data modelers out there... But that doesn't take away from the fact that the models themselves diverge from the business interests.

A business comes to request a change to the model, IT says: it will cost X & Y, and take resources Q & R & S a couple months to get the change in. The business decides, it costs too much, or the impact is too large, or it will take too much time to make the change - now the data model and IT are constraining business, they are no longer enabling business and the data model is now out of alignment with the business.

Unfortunately these techniques for data modeling are old (for purposes of enterprise integration). In a most recent blog it was pointed out that 3rd Normal form was created in the 1960's, and Star Schema was created in the 1980's. Technology has moved on, changed, gotten faster and more agile. Why then hasn't IT changed their notions of how data models are built?

When was the last time the business had a model walk-through, and understood where and why the data is "modeled" the way it is? There has been a divergence of methods between how the business models (which has evolved over time), and how IT models the data for the business. Constant "alignment" takes place to keep the models up to date and matching the business changes. By alignment, IT continues to "review, update, and impact" existing data models.

Consider modeling in this light: If you have sales totals across the country to "watch", would you rather receive the data in columnar or tabular format (modeled as text), or would you rather start with a high level graph that showed further summaries of information (modeled as a graphic)? Most decision makers choose the graph, hence the dashboards and all the fancy analytics that re-model the data on display.

Now, what is the impact if the business person wants to see another country on the graph? Pretty minimal to the data model and to IT if in-fact, IT has the systems setup to capture world-wide information. On the other hand, what if the business acquires a new company, and wants to see their information included on the graph? The impact can be tremendous, cost loads of money, and take incredulous amounts of time to implement. This is NOT the way it should be done.

Two years ago I had the opportunity of meeting some decision makers for a large New York company, and discussing how they were handling their M&A activities. They had told me that their requirement was to merge data from 3 acquired companies in 3 months, they also let me know they were using modeling activities similar to the Data Vault, and were extremely pleased with the flexibility; they had just completed the 90 day M&A activities for their information systems.

Think about it, if SAP or PeopleSoft has a change to make to their data model, then they also usually have a huge impact to their application and all of their customers. It's a pain for businesses to upgrade to the new version to receive the new business functionality.

From a data modeling perspective, we in IT are often found "re-aligning our data models to match the new business models". We should begin converging our data modeling practices with the notions of business modeling.

What should be focused on for Business Modeling?
Business Modeling is done by the business, for the business and means something to the business. It may be implemented by IT going forward as an enabling technology, but it shouldn't constrain the businesses ability to execute decisions. IT should be a part of the business, and know that it's their job to represent the business properly.

So what does this really mean?
IT resources should begin working like business users, rotating in and out of business circles and understand the business problems. Along with this, comes the information modeling component, metadata embedding, and changes to the way the systems work which will permanently and positively impact the business going forward.

Why do we build applications? To meet business needs, how does the business track locate, and identify data? By using keys to information - and sometimes applications to gain access to that information. Why then do the data models separate the business from the information that it owns by introducing layers and layers of complexity?

What should Business Modeling be?
1. Businesses identify their information by key, if they can't key it uniquely then they cannot reference it - or they create new records containing duplicate information.

2. Businesses then describe that key with contextual elements, otherwise known as "making sense of what the key means" - in other words, the characteristics of the key. For instance, if you have a key to your house and a key to your "condo" - what tells you which key is which? Could be the appearance after a while, the shape, the color - maybe you put red nail polish on one key at first to discern each key. That's a descriptive attribute; the color can change over time. But the key number from the manufacturer is unique.

3. Then, the business proceeds to make associations between these key elements, mostly known as transactions or intersections, or relationships.

Let's take a look at a business example. The customer; the customer has a customer number: "XYZPDA1", if we lose this key, or the key changes between contracts and finance, then can we accurately identify this customer across our enterprise? No. Like it or not, businesses that "change" operational keys to business information are making a ghastly mistake, hence all the data quality efforts after the fact to clean this up - back to the example...

The customer has a name, address, and income bracket. These are descriptive attributes which can change over time - these are business elements that are periphery information and describe context about the customer key "XYZPDA1". The key itself is meaningless outside the "system" which tracks millions of customers (unless the keys have been encoded to match a business need, which does happen).

Now, we have an interaction between XYZPDA1 and EMP001. EMP001 closes a sale to this customer, and wants to record it, they sold $140,000.00 worth of data model changes (it was a good day). There's a service/product key hidden here too: SVC4000

Two keys with different semantic meanings and an interaction between these keys on 1/1/2005 for $140,000.00, so we have a defined grain for the transaction.

What does the business model look like?
CUSTOMER KEYS -> CUSTOMER-EMPLOYEE-SERVICE-SALE <- EMPLOYEE KEYS
^
SERVICE KEYS

Each set of keys, including the cross-grain sale item have descriptive elements. This is an appropriate data model that's simple, easy to understand, and stores the data according to the business model.

A breakdown of the thought process:
1. Lists of keys (like Customer Keys and Employee Keys) are called HUB's. They are the central hub of information - one hub for each key set, since they are separated by business definition. We are capturing business metadata; some of it is embedded in the architecture.

2. Linkages between Keys (like employee sells to customer), Link tables. The number and type of Hub keys embedded in the link define the granularity of the transaction, in other words, the link is defined BY the business definition of the transaction.

3. Descriptive data fits into Satellites. Descriptions for customer that are solely dependent on the customer key, are built in one-level deep Satellites, dependent on the Hub keys and recorded by date/time of data arrival or information generation. There can be satellites that describe the link tables too; they describe the transaction or the sale (like $14.00, and when the sale took place).

Below are several of the backing notions for this model:
1. All data "about" a particular business key, is always and only one level deep from the business key.
2. Data can be split in the Satellites by type of data and rate of change (delta processing), resulting in lower storage costs, and more flexible modeling techniques.
3. Business can add new pieces without destroying existing data sets.
4. Business can experiment with "what if" questions, in other words: what is the impact of this business change, and does it make business "easier or harder"?
5. Issues in the business processes are easier to spot and fix.

Here's an example of a business issue (real case) - I've changed the type of information around a bit to protect the company.

Example: A widget building company has a planning operation and a manufacturing operation. They build computer motherboards, all of the motherboards are custom made to order. They reward (bonus) planners for building and architecting plans that meet or exceed actuals in the manufacturing bill. That is: actual dates, cost, and labor.

In this model, we are to track parts. The planned parts and the manufactured parts that roll up on to a bill of material. We are also told to track the quantities manufactured, number of rejects, successes, and reworked items. Along with that, we are told to track the dates that the actual work starts and stops - but before the work starts, it is suggested that we track the planned dates for when the work should start and stop.

Objective from the business: 1) critical path analysis through their planning and manufacturing phase 2) understanding if their bonus plan for planned vs actuals is meeting corporate goals.

We carried the following tables: Part Key Hub, Bill Number Hub, Assembly number hub, Link between assembly number and itself (hierarchical bill), Link between parts and assemblies (describing which parts were on what assemblies), and two Assembly satellites: One housing quantities, one housing dates (planned dates and actual dates).

From this simple model, we were able to save the business millions of dollars (quickly). The business did a little statistical analysis, and found the following: out of 15 planners, 13 had re-planned parts only 3 times. 2 had re-planned parts 12 to 15 times (Planner YY and Planner ZZ).

Planner YY had 5 to 8 rejects with every manufactured actual, and was 80% on-time with the plan matching the actual.

Planner ZZ had 0 to 1 rejects with every manufactured actual, and was 98% on-time with the plan matching the actual.

What was interesting was that Planner ZZ's planned start and end dates held a increasingly accurate pattern (when viewed in a Gantt Chart). Started out 20% on-time, and grew to 98% on-time.

Long story short, Planner ZZ was discovered to be cheating the system, Planner YY was given 2 weeks to re-plan their complex part. Both actions saved the company money. Bottom line: the model lended itself to human pattern recognition, quite simply: the planned vs actual date satellite was growing at an unusual rate of change which sparked the business inquiry. It was the way the model was built that helped make the difference.

Simple, effective, elegant. This modeling paradigm can be (and is currently) utilized by customers who wish to eliminate operational data stores, staging areas, data warehouses, and data marts, all in favor of a single copy of the facts.

In this model, current data and historical data are available; exactly as it was entered. IT can also build virtual data marts until the hardware platform can't handle the size or performance; at which time physical tables can be built to help with the performance issues.

How we do business should be directly reflected in the way IT builds solutions, not the other way around. IT needs to change their data models into working "Business Models"; the Data Vault helps with this paradigm shift.

Cheers,
Dan L

Share: