Everyone involved in managing or improving a business process should understand data modeling. For real. And almost everyone is in a position to improve a business process by understanding the current one and making suggestions to improve it. Understanding a business process means understanding business objects, events, the relations among them, and the business rules that govern the process, and that’s what data modeling is all about.
Sure, data modeling is the first step to designing a database, but that’s just a coincidence. A well designed database is well designed both because it’s efficient and because it matches business needs.
The first step in data modeling is understanding entities. An entity is like a business object: examples may include customer, order, product, patient, blogger, post, or whatever. The next step is to understand relationships among the entities, like a customer may place many orders or a post is written by a blogger. Then the data modeler thinks about the attributes of the entities, like the name of the blogger, the price of the product, and so on. The attributes and relationships are where the business rules come from. Examples of rules may be “a post is written by exactly one blogger” or “every order must have a shipping address.” It’s not really a sequential step by step thing, more like a series of really interesting brainstorm sessions, but you get the idea.
Data modeling can get really complex, especially when it includes enough detail to generate an actual database, but that’s beside the point. We’re talking about clear thinking about business things, events, relationships, and rules. The point is that this kind of thinking can enable a business person to understand better the things, events, and rules of a business, and then to define more rational processes based on that understanding.
Today a lot of the problems that data modeling helps reveal relate to overcomplicated org charts and artificial complexities of legacy information systems. Often the business evolves around the system, and it takes clear thinking to untangle the process spaghetti that results.
I worked with one company that organized itself by four different product line channels, served by matrixed support functions like accounts receivable and claims. Worked pretty well, except when you wanted to know all of your contacts with a given customer, for example. The same customer could have had a different record for each channel, then more information was socked away in the matrixed support functions. Furthermore, the customer records were all laid out differently, and had different addresses, contact information, billing instructions, and so on.
Maybe I’m oversimplifying, but shouldn’t one customer have one file with the same information that everyone uses? It seems to me that if applied in the real world this data-oriented perspective could really make things simpler and more cost effective.