A common legacy thought pattern is that you need a single data model and hence usually a single system or single PaaS instance.  This is very expensive thinking and while on the surface it makes sense, it makes for far more expensive configuration and customisation of software systems.

I have just about finished Inside of RavenDB 4.0, and the Author has succinctly summarised this.

  • A common bad practice is to integrate between different applications using a shared database. This has been looked down upon for quite a while….
  • Typically, shared database solutions suffer because they attempt to force disparate applications to treat the data in the same manner. This is a pretty bad idea, since different applications tend to treat even very similar concepts in a variety of ways. The most common example is a billing application and a fulfillment application. Both have the concept of a customer, and both actually refer to the same thing when they talk about a customer. But the fulfillment application needs to keep track of very different data from the billing application. What will the fulfillment app do with the CreditScore field, and what can the billing app gain from looking at the ShippingManifest details?
  • Each application should model its data independently and evolve it as it needs to. Keeping everything in a shared database leads to required coordination between the various application teams. That results in increased complexity in evolving the data model as the various applications are being worked on….
  • In this way, each application is independent and can evolve and grow on its own, with well-defined boundaries and integration points to its siblings.

The need to have a single system and hence a single data model is further mitigated with the advent of PaaS and SaaS, as the cost of maintaining multiple instances of a platform is no longer an expensive pursuit.  The cost of synchronising technical teams and business areas is the single most expensive cost.  If you need to report across applications and programs, keep it for your data aggregation solution, such as your data lake, event sourced views or inbuilt adapters that can aggregate data.

Beware of anyone selling you the one data model to rule them all in your application design, as reporting concerns belong in other facets of your application and data portfolio.