In part 12 of “Memoirs of an Enterprise Architect” I discussed the IT Chargeback Model. This week I will talk about Database Rationalization.
Does your organization have a good process around managing all of the databases running your business?
It may not sound like a big deal, but there are many business questions that Enterprise Architecture (EA) should be able to provide the answers to so you can make better decisions with less risk. Here are some of them:
- Where are our production databases running that contain restricted or highly restricted data?
- Do we have any development databases containing restricted or highly restricted data?
- What databases are running on non-supported or denied technologies?
- Do we have any databases not related to a production application?
- Are we following all compliance and retention requirements with our database?
- How many standalone databases does my organization have versus virtualized?
I’m sure you can think of more questions, but having the answers to some or all of the above can identify risk and cost saving measures. In my previous blog articles I wrote about how you can save millions with Application Rationalization and Report Rationalization. Well, Database Rationalization is no different, but it is often overlooked.
Where to Start?
Once you identify the source of record for databases, whether it be your CMDB or Asset Manager, then you can integrate with your EA solution such as Troux. The rest of the steps are very similar to the Application Rationalization steps so I will not restate them here. In addition, you can use this information to suggest some new objects to the senior leadership such as standardizing on one or two database technologies, and/or you can make a case for no longer allowing standalone databases and instead have a database grid such as Oracle’s Megagrid technology for virtualizing databases.
Database Rationalization can and will most likely save your organization millions by:
- Reduce complexity through virtualization and/or standardizing on two database technologies.
- Reduce headcount in the form of database administrators (DBA) (i.e. less databases, fewer DBAs needed.
- Reduce database servers, SAN storage, and NAS storage.
- Prevent lawsuits by identifying non-compliance in production and development.
- Reduce redundancy by removing Disaster Recovery, High Availability, or Mirroring solutions to standalone databases and instead providing database grids for different classes of systems.
See you next week, same time, same place where I will do a deep dive into what it means to answer key business decisions and provide more “Insight” since that has been a strong theme throughout this whole blog series.