This artice was “work in progress” for almost one year. I’ve decided to publish it as unfinished to work further on the material in an iterative way.

 

All models are wrong; some models are useful” – Geroge Box

I don’t get it why people don’t get it that enterprise data models don’t work.

What are enterprise data models? The illusion of having one data model per real world phenomena for all possible areas of usage within an enterprise/company. One model “to rule them all…one model to bring them all and in the darkness bind them”. Another nice definition from http://tdan.com/the-enterprise-data-model:

An Enterprise Data Model is an integrated view of the data produced and consumed across an entire organization. It incorporates an appropriate industry perspective. An Enterprise Data Model (EDM) represents a single integrated definition of data, unbiased of any system or application. It is independent of “how” the data is physically sourced, stored, processed or accessed. The model unites, formalizes and represents the things important to an organization, as well as the rules governing them.

In practice, you can easily spot an enterprise data model: For example, if you have one and only one class model that consists of classes with things business people need (e. g. customers, orders, payments etc.).

Enterprise data models can do much harm to companies. Unfortunately, there are software architects that still try to do it. To me, it seems like there is much room for improvement. So I’ve collected some reasons why you shouldn’t do it. I’ve separated them into fundamental, business and technology reasons.

Fundamental reasons

Fundamental reasons are facts, that are based on a philosophical (to be exact: epistemological) ground. They cannot be “solved” but only be recognized and one can try to address them accordingly. We simply derive some of the ubiquitous problems from theory to practice:

• Let a model be a definite number of classes / entities that belong together conceptually.
• Models are used in contexts (contexts aka specific business domains or units like sales, purchase, support etc.)
• A model has a name
• Without context, there is no meaning for a name
• With meaning, there is also a specific context
• To be worthwhile, models have to used in a very detailed context that gives them a concise meaning
• Models that are used together in very detailed context are coupled very strongly.
• Because the context determines the meaning of a model, the context leads changes, the model follows changes.
• Therefore models change their meaning when the specific context of the model changes
• Models are always used in a specific context
• Therefore an enterprise data model that tries to reuse models for different contexts doesn’t work.

Fundamental problem

If you use one model for different contexts you’ll get a change in the model if a context changes. You can’t foresee if that change is also valid for all the other contexts where is used in.

• Accept that there is not on model that fits it all.
• Embrace context-dependent models and separate them as strict as your business needs it.
• Don’t put generic (=context-agnostic) architectures in your way. Those just add complicatedness additionally upon the essential complexity of your business domains. Remember: Because they are generic, they never can solve context-dependent problems. Without a specific context, ambiguity makes life harder (because every stakeholder in the overall model could see the model in another context / from another perspective).

Bottom line: Accept that there is no one model for all!

Business reasons

If you aren’t convinced yet, please tell me so that I can avoid your projects, here are some reasons, why enterprise data models are bad for the your business.

• Models will change when specific business requirements evolve.
• The business will evolve faster than the implementation of the model.
• To be competitive, the model must be quickly adapted to the new business requirements.
  The implementation must be changed faster than the next enterprise data model expert group can meet to decide a change (not to mention the time needed for analyzing the impact of the change for other data model stakeholders)
• After the decision on how to extend the existing model, time pressure is high, degrading of the quality of the implemented model is forseeable (because shortcuts in the implementation have to be taken to meet deadlines).
• After the introduction of an enterprise data model in a company, all business units that use it are dependent on it (“one model…to bind them”).
• A quickly made change to a model results in an degrading quality of the overall system of models – your software system
• Changes are likely to be avoided, because they are getting more and more risky.
• Or worse: Changes become use-case-specific, making an enterprise data model even more preposterous.
• Your business processes will get more rigid and fragile, quality of service and business agility are decreasing, innovation is stagnating, customers are leaving, you’ll get out of money and run out of business.

Business solutions

Don’t thrive for general solution, identify your competitive advantages and enforce them, build specific software solutions that support them, standardize your processes that are second to your main creation of value and buy off-the-shelf software.

Bottom line: Don’t believe everything your IT/architects/software engineers say. Business first, technology second.

Technical reasons

Not convinced yet? Well, you must be a technology-driven guy. Hmm…let’s see if I can get you there:

• If you have big data models, you’ll see that as universal hammer to use it everywhere (supported by the sunk cost fallacy: “we’ve invested so much money in our models, so use it dammit!”)
• With this argument, the enterprise data model will harm almost all of your in-house developed software.
• Software reusability as argument for enterprise data models is an illusion.
• A data models can only be used effecticly in one context.
• Worse, data models as well as their parts have relationships with other data models. These relationships are also context-dependent.
• No chance to reduce models because of many unknown dependencies / clients
• Because your models have to be context-agnostic, they cannot contain any business logic, because this logic is context dependent
  • What you end with is a so called anemic model. For example classes with attributes, that hold a state (=data).
  • These models are cheap to create and are therefore worth almost nothing, so where is your fucking business value, enterprise data model?
• You have separate owners of the diverse layers / components? Think about it: Every component has its own product lifecycle. You have to coordinate / communicate with serveral component owners before you can get a release of your product (that depends on a variety of different dependencies / components)

What does work instead?

There is no silver bullet in software development because there ain’t one PERIOD (a solution would be a model anyway, which is itself context-dependent…see above).

But here are some general suggestions that you can try:

Be determined

Build of your business function, that distinguishes your your competitors. Build that part of your data models as specific for your business needs as possible.

Less build, more buy

• Standardize your processes that don’t distinguishes you from your competitors
  • Use standard sofware with as less customization as possible to avoid vendor lock-ins.

Copy your model

• Code duplication is only bad for general non-functional requirements (security, logging etc.) because they are nothing worth in terms of generating revenue
• Allow for code duplication of implemented business functions aka use cases (they will evolve independently anyway)
• Design for replacability instead of reusabilty to be more flexible if business needs change radically
  • Additionally, with this approach you can simply delete business functions that aren’t needed anymore

Go faster

• Support experimentaion of business rules / data models through enabling small and frequently releases

We use an enterprise data model. Should I quit?

No, because as of today enterprise data models are still common in other companies. But here is, what you can do:

• Wake up your architects (perhaps with arguments from this article)!
• Build context-specific views of your existing models (e. g. by using the Interface Segregation Principle to cut down bloated interfaces or start with view models that drive use-case-specific requests from your GUI towards your backend systems)
• Once you’ve figured out, what is needed, replace the bloated models with your specific ones step by step.

Bottom line

Competitive advantage first, technology second.

Additional resources:

• Book “Agile Software Development: Principle, Patterns and Practices”
• Book “Object Oriented Software Development: A use case driven approach”
• Paper “Epistemological foundations of requirements engineering” from Alfred Holl https://www.in.th-nuernberg.de/professors/Holl/Personal/Buchbeitrag40_Homepage.pdf
• Video “Strategic Design” from Eric Evans https://vimeo.com/12674642
• Video “Architecture Without an End State” from Michael Nygard https://vimeo.com/41763228
• Article “The Fallacies of Enterprise Computing” from Ted Neward http://blogs.tedneward.com/post/enterprise-computing-fallacies/#models-can-be-centralized:63f5940fe4930058d151265425e8ed3f (incl. a wrong understanding of DDD unfortunately)