In your organization, who decides what database platform will be utilized for that new application being built? For many groups, that decision is made by the Development Team while for others, it is the Database Team. But, which is best equipped to make that decision? As is usually the case, the answer lies in joint cooperation between the two.
Naturally, development teams and DBAs alike can fall into traps of only wanting to work with technologies with which they are familiar. In many organizations, the CTO or others upline may drive the adoption of new technologies. The trap here, however, is not to just implement the shiny new toy on the market, but to make well-informed decisions of what is truly the best fit.
Go With What You Know?
With the pressure to get applications released as quickly as possible, the trap of going with what you already know is very appealing. After all, it requires little to no learning of new technologies and you may even already have extensive code libraries that can be repurposed. As a Technical Account Manager (TAM), I see this happen often where there is no other compelling reason to adopt a given database platform other than familiarity. I have applications forced into a relational database model where it should have been done with a NoSQL platform – or vice-versa. With all the rush to the finish line, often it is almost a necessity given the time constraints. The biggest challenge, of course, is the impact on the users when the application does not meet the required performance metrics. This is closely followed by the frustration of the DBA Team in managing a system that is constantly sub-par.
But It’s New…
As mentioned above, another trap is in implementing a technology just because it is new. The challenge with this approach is precisely “because it is new.” New software carries the risk that any and all bugs may not have manifest and there is substantial risk in hitting these bugs at the most unfortunate times. This risk is compounded by the unavailability of subject matter experts. If you can even find them, they will probably not be cheap! This can artificially drive the cost of deployment through the roof, not to mention the dreaded question of how long will it take to recover a system when the team has limited experience with it.
I, as have many others, have been tasked with supporting a database platform with which I/we had little to no experience. It made it extremely scary and increased stress levels exponentially. Fear would overcome me when a system went down, wondering if we would be able to recover a solution with which we had little experience. It is bad enough to get called into a war room in the middle of the night for a known technology, but go in there wondering if you can even resolve the issue is quite another thing!
Paying for Familiarity
Another issue is choosing a higher cost database platform when perhaps an open source database solution would be more than adequate. I remember once as the MySQL DBA Team Leader for a large company going head-to-head with a large “enterprise” platform for a new project. When asked what it would cost to deploy on MySQL, my response was nothing! The large enterprise platform DBA said his solution would cost approximately $1,000,000 due to licensing costs per year. I thought it made the decision a no-brainer, but apparently, I was wrong as the organization chose to spend a million dollars per year! What drives such a decision? Familiarity. They simply felt more comfortable with the large “enterprise” solution because they had worked with it for so long. For the record, MySQL would have been a perfect solution for their requirements, even if I was a little biased in my opinion. Did they take time to do a proof of concept (POC) to see if MySQL would meet expectations before making such a huge decision? No, sadly they did not! Development drove the decision process with leadership that went with what they knew best, regardless of the potential savings to the company.
And… A Solution
So, what is the solution? We implemented what I see other companies implementing today as a TAM – a Center of Excellence (CoE). While that term can mean different things to different people, it essentially means to me that management, development, and database teams work together to review new applications to decide which solution is best. To be successful, such processes should involve decision criteria that assist in making the best choice. Criteria should evaluate whether an RDBMS or NoSQL solution is required. Or, should parts of the application be powered by different technologies? If NoSQL is chosen, what technologies can the DBAs support? Do they need to add a new platform to their skillsets? Do new resources need to be hired to support this?
Without a CoE, often the DBA Team is unaware of a chosen technology until it is nearing production. By then, if they do not have sufficient expertise, it is often too late to get it in time. As a result, the application is launched without appropriate support. With the CoE, the deficiency in support viability is identified before development begins and the leadership can decide to either continue or to change plans. If the decision is made to proceed, the next question is whether to implement training for the DBA Team or to hire subject matter experts.
For development, it takes the pressure off them as well as both teams can work together to ensure the DBA Team is supporting the development efforts all along. The teams can essentially learn together and build off one another’s knowledge throughout the development phase. I know what you are thinking – that is a pipe dream. For many organizations perhaps it is, but for many today it is the future.
When done this way, management can rest assured that decisions are not made in a vacuum and that everything is being done to develop a stable and performant application. If I am the CTO of such an organization, I know I am utilizing all the resources available to me. The empowerment of the application and DBA teams builds strong morale and the insight into what is coming next relieves a lot of tension. Whether leadership knows it or not, teams are often wondering what is going to be dumped in their laps next to support and whether they will be ready. This alleviates most of that stress.
So, has your organization implemented a Center of Excellence or something similar? If not, perhaps it is time to give it a chance.
Don’t let database complexity overwhelm you. Check out our eBook, ‘How to Manage Complex Database Environments Effectively’ to learn how to effortlessly navigate the challenges of complex database environments! Download the eBook now!
