Embedded Files
One of the most common mistakes in enterprise software doesn't happen in the code.
It happens much earlier.
The database becomes the business model.
At first glance, this seems perfectly reasonable. After all, every business concept eventually needs to be stored somewhere.
But an information model and a database model solve two completely different problems.
Confusing the two is one of the fastest ways to make a system difficult to evolve.
Two Models, Two Purposes
Two Models, Two Purposes
An information model describes the business.
It answers questions such as:
What is an Account?
What is a Transaction?
What is a Customer?
How are these concepts related?
What business rules govern them?
Its purpose is to capture the language and structure of the business, independent of technology.
A database model, on the other hand, describes an implementation.
It answers different questions:
How should the data be stored?
Which fields should be indexed?
Should the data be normalised or denormalised?
How should data be partitioned?
How do we achieve the required performance?
How do we support backup, replication, and recovery?
These are engineering decisions, not business decisions.
The Cost of Starting with the Database
The Cost of Starting with the Database
Many projects begin by designing tables.
Soon the business starts adapting to those tables.
Relationships become constrained by foreign keys.
Business concepts become rows.
Complex concepts become nullable columns.
Eventually, developers stop talking about Accounts, Transactions, and Customers.
They start talking about tables.
At that point, the implementation has begun to define the business.
That's backwards.
Business Concepts Outlive Technology
Business Concepts Outlive Technology
Databases change.
Oracle becomes PostgreSQL.
PostgreSQL becomes a cloud-managed service.
Relational storage becomes document storage.
Performance requirements evolve.
Indexing strategies change.
Partitioning changes.
The business concepts remain.
A Customer is still a Customer.
A Transaction is still a Transaction.
An Account is still an Account.
Those concepts should survive changes in technology without requiring the business itself to be redefined.
Policy Before Detail
Policy Before Detail
Architecture is fundamentally about separating policy from implementation.
The information model is policy.
It defines what the business is and how it behaves.
The database model is an implementation.
Its responsibility is to store and retrieve that information efficiently.
A good database model faithfully supports the information model.
It should never dictate it.
AI Doesn't Change This
AI Doesn't Change This
Modern AI can generate database schemas, migrations, repositories, and SQL remarkably well.
But it cannot determine what your business concepts should be.
If your information model is weak, AI will generate an equally weak implementation—only much faster.
As with every other part of software architecture, AI amplifies the quality of the design it is given.
Designing Systems That Last
Designing Systems That Last
When designing enterprise software, the order matters.
Understand the business.
Model the business concepts.
Define the relationships and business rules.
Design the information model.
Build the database model that best supports it.
Not the other way around.
Final Thoughts
Final Thoughts
The most successful systems aren't built around tables.
They are built around business concepts.
Your database exists to serve the business—not to define it.
The information model is your policy.
The database model is just one implementation.
Design them in that order, and your architecture will continue to support the business long after today's database technology has been replaced.
Page updated
Report abuse