Multi-Database & Polyglot Persistence

Data Persistence Platforms (popularly termed as Databases) as we know are like goalkeepers i.e., any Application's last line of blemish and first line of service...or as some may arguably choose to see, the first line of blemish as well. Picture a professional soccer goalkeeper tending to a hockey goalpost in a critical professional hockey match to get feel for what I am alluding to.

Note that I specifically chose to use the word 'service' here as in today's computing paradigm of Micro Services aka traditional 'SOA' and / or Component based Applications Architecture and Cloud Computing emergence, Data Persistence Platforms are in fact comprised of componentized Micro Services providing DAL APIs to the upper application layers with as much abstraction as feasible, for data persistence and retrieval (if done rightly to this end in the least).

In context of the above therefore, it becomes so much more important now more than ever before that Data Architects should bear a bigger responsibility towards ensuring that the right tool is used for the specific purpose under consideration.

As in the past, often young ventures in the business of providing SW Products and / or Services start off on the premise of providing their SW Products and / or Services to as many Customers as possible in order to maximize the potential for revenue flow in its incubation stages for sustainability. Now, from a business perspective there's hardly anything wrong with this approach as long as the revenue keeps coming in at a steady rate except for the fact that this is where the tendency to cater to every Customers' individual platform of choice often comes into play leading to what manifests as Products and / or Services being made available to the Customers with the Customers' choice of Data Persistence Platforms. 

This exactly is where the technical architecture of the model starts to lose scale as the Customer base grows, and no Data Architect would need me to elaborate any further on the 'why's and 'how's of it all. The million dollar question then is whether Data Architects are in an enviable position to either totally prevent and / or re-factor this from happening or not. In my humble opinion and experience it is a very steep climb towards such a change and most often not so without some very legitimate business driven reasons for the same too.

However, a Data Architect could certainly mitigate the exposure to this phenomenon or at least make an honest effort at the same, all impediments to such notwithstanding.

This is where what we know as Polyglot Persistence comes into play. Take a peek at what Martin Fowler has to say about it: