What to consider when planning your database strategy

What to consider when planning your database strategy

Image:
What to consider when planning your database strategy

Four priorities to focus on

One thing is certain. The volume of data continues to grow. Good if you sell databases, but if you are in charge of your data management strategy the job is becoming ever more complex. While "Relational databases still dominate the database world, and there's no reason to expect that to change" (according to O'Reilly's Technology Trends for 2022) other options are growing in popularity.

What this suggests is that more customers are using a variety of options for different tasks. The relational database remains the workhorse for many transactional systems, while other specialist systems such as NoSQL, graph and object oriented take on specific tasks. That alone makes for complexity in terms of basic management, but when data is integral to your competitive advantage, especially having a single view of all your customer or company information, then it makes the task of integrating databases hugely difficult.

It is no surprise that many of our clients are talking to us about how best to optimise and streamline their database strategies. They need the agility and scale to meet expanding demand for data processing and analysis, while reducing their costs in terms of licensing and support. Simplifying database environments is a major priority, particularly to address data integration, so our clients are deciding whether they stick with the traditional proprietary vendors and perhaps move to the cloud or move away from their commercial providers to open source database providers who are rapidly growing in popularity.

Whatever strategy you adopt, it requires careful consideration, as it will have consequences for how future proof your database environment will be so here are four priorities I think you should focus on:

1. Is open source right for you?

Historically, open source databases were dismissed by its detractors (mainly the traditional proprietary vendors) as insecure and unstable, but as Red Hat's The State of Enterprise Open Source 2022 report suggests, "89% [of surveyed IT leaders] see enterprise open source as more secure or as secure as proprietary software."

Indeed, one survey we conducted in 2020 indicated that over 35% of respondents were considering or moving to open source databases. However, that does not mean open source is the right option for every enterprise. It is critical you start with a business case and with open source databases this should not be predicated on cost savings. The key question should be: can switching to open source deliver a competitive advantage for your organisation?

There are other considerations as well. If you use the free version of an open source database you become dependent on the community for updates. If it is an active user group, it could mean regular updates and innovations, but it will be important to qualify how organised the group is in delivering updates and planning to add new functionality. You should also consider the migration path from an existing database to an open source equivalent, as integrating it into an enterprise IT environment will require careful planning and implementation. It is not just plug and play. Indeed, many commentators suggest a quicker win is to start by build new applications on open source databases rather than migrating existing ones.

There are also different licencing models as some open source vendors have taken steps to protect their IP, but it does affect how you use the software. Some vendors have chosen licenses with restrictions. For example, MongoDB uses the Server Side Public License (SSPL) and Elastic is moving away from a pure open source license. There is also the consideration of an open source project maintained by one individual or company. There is always a danger you could be at risk of unilateral changes to licensing which could impact you, especially if you are over reliant on one technology.

However, perhaps the biggest elephant in the room is that not every app can be moved from a commercial database to an open source equivalent. For example, all the top tier enterprise resource planning (ERP) applications run on their own databases - Oracle eBusiness Suite, PeopleSoft and JD Edwards run on Oracle Database and SAP business applications are optimised to run on SAP HANA.

2. Should I move to my existing vendor's cloud-based database?

This could be perceived as the straight forward option for many customers, particularly if an organisation has invested heavily in the existing in-house version of a database. Migration is challenging when you have multiple databases, so sticking with your vendor will avoid nasty surprises, right? Also, your ERP applications are optimised to run on the vendor's database, so wouldn't it be easier to stick with what you know?

Wrong. Moving existing in-house applications to the cloud often means a complete re-implementation and the vendor will encourage you to adopt the vanilla version of the SaaS database losing any customisations you may have. If you are prepared to adjust your workflows, then this might be the right approach, but you do have to consider the change costs of adapting existing processes. People must get used to change, and that can slow productivity.

Licencing is also a consideration in the cloud. While the premise of the cloud, particularly in the public cloud reduces your infrastructure costs and offers the flexibility of subscription pricing, the vendor's goal is for you to use more of its cloud infrastructure. The ease of adding users, scaling usage and adding instances are all ways for the vendor to make you stickier on their cloud database platform. Costs can scale as quickly as a cloud database.

You also need to read the licencing documents carefully, many cloud users operate multiple cloud databases. What rights do you have to port data? What costs are attached?

3. Have you thought about security?

Whether you go with a cloud-based database from your existing provider or are looking to switch to an open source alternative, security must be high on your agenda.

For example, enterprises are now very confident implementing open source databases for mission-critical applications, as they have become more robust and reliable.

However, open source strategies encourage far more dynamic IT adoption models. This creates more pressure to understand the security supply chain and how the various components fit together, with many recommending companies look to develop a Software Bill of Materials (SBOM). According to the most recent Open Source Security and Risk Analysis (OSSRA) report by Synopsis, of the more than 2,000 codebases examined: "These dependencies are where the greatest risk exposure exists within a software supply chain."

Particularly with open source databases, where it is incumbent upon users to implement updates and patches, organisations must be vigilant to ensure the optimal performance.

If you are moving to a vendor's cloud-based database, this does not give you immunity from shared responsibility for the security of your data. The traditional database vendors have always seemed very dependent on patching to avoid exposure to vulnerabilities, but in the 21st Century this can no longer be considered sufficient. I would recommend a defence-in-depth approach, which relies on layered security employing multiple levels or layers of controls designed to provide comprehensive protection against the misuse of data assets and their supporting infrastructure. An entire ecosystem of layered security options, including end-point protection, application protection, multifactor authentication (MFA), network security devices, event correlation and process controls, are combined, delivering a layered security strategy that provides comprehensive, enterprise-level protection with prevention, detection and response.

4. Do you have the skills in place to deal with open source databases?

Across the board there are challenges to find and retain top enterprise IT talent. As open source databases grow in popularity you have to consider how "in demand" skills are for a particular technology. If there isn't demand that could suggest a technology is not as strong as others and perhaps you should not invest in it. This can be an issue if an open source project forks with different factions splitting off and diluting the core skills of a community. Equally if there is strong demand for skills in a database technology that could suggest a vibrant community worth investing in, but also could increase competition for skills.

There are also growing issues around existing applications from the likes of Oracle. In a study we commissioned from CIO.com 50% of Oracle customers said they were using older application versions and that as much as 51% of internal staff are supporting these applications. Worryingly, the top two reasons for respondents struggling to recruit and retain talent in on-premise technology skills were firstly candidates wanting to work on more advanced technology followed by companies unable to locate talent with legacy technology expertise. Companies need to be careful not to assume established existing databases, such as Oracle Database, will mean there is a steady flow of employees with the right skills available.

There are many considerations to ponder as you look to develop your database strategy moving forward, which underlines one key point. Of course, there are concerns about full support for some existing databases coming to end forcing customers to make a rapid decision to upgrade or switch their database, but that does not need to be the case. There are alternative providers of support for existing databases who can help you map out a smart path to transformation. It may well be that due to customisations and complexity, you keep some existing databases in-house, then map out ways to move some to their cloud equivalents either from the existing vendor or an open source alternative.

Keeping some of your existing databases does not mean you stop innovating. It simply helps to prioritise where transformation should happen first and you can still look at ways to optimise existing databases by taking advantage of enhancement packs you are entitled to within the terms of your licensing agreement.

Fundamentally, your approach should be: take your time, plan properly and don't be rushed into a decision.

Dan Ashton is senior director product marketing at Rimini Street