The presenter positively glowed with enthusiasm as she showed us how easily the schemas collections of documents in MongoDB could follow the changes in the way you structure the data in your application. I was at an interesting presentation recently of MongoDB with .NET. The presenter explained, brightly, that using MongoDB was a liberating experience because it meant that one could break free of having to share databases between applications by creating many different applications, each of which had its own database. This meant that each application domain could develop its own private schema. To reinforce the point, she had a PowerPoint slide, with the left hand side showing the bad old days, with applications having to share a corporate database, what he called the ‘monolithic’ design, and on the right was the new architecture, where each service using different data storage technologies. In this bright new world, sharing data via a central database was no longer necessary.

Applications can share data via RESTful services and one could see the attraction of a solution composed of loose-coupled federation of applications, communicating via HTTP, This leaves each development team free to choose their preferred database technology and design, since it is private to them. There is no up-front need to decide on a shared understanding of the application domain since that is a matter for the interface, which is a ‘consumer-driven’ contract to supply data in the right form.

One can see the attraction of course, but are we are sleepwalking into a strange repetition of history? In the early eighties, many large organizations struggled to control the proliferation of small, ‘siloed’ applications, each solving a specific business problem and each having a ‘private’ database. By the mid-eighties, we reached the crisis of ‘siloed’ information systems. Such were the difficulties of getting the right information from them, in the right form, for any kind of cooperation or reporting that we then spent the next fifteen years having to re-engineer them. The struggle gave rise to whole industries such as Data Warehousing, and gave me a good living for many years. Of course, network bandwidth has grown vastly since then but so has the complexity and volume of corporate data

The problem of developing and releasing individual applications where several were close-coupled to one monolithic server was solved many years ago, in the 1990s, by creating abstraction layers within databases to provide an interface to applications. We have subsequently reinvented the problem for which siloed applications are the “solution” by ignoring the obvious best practice of having an abstraction layer for each application, based in the database and defined by a customer-driven contract. By doing this, we decouple the application sufficiently from the database to allow asynchronous releases, and we don’t need to create a rat’s nest of RESTful services to share information!