The Nature of Database Agility

The word “agile” marched into the IT vocabulary in 2001 when a small band of software developers wrote and published The Manifesto for Agile Software Development, hoping thereby to increase the quality and speed of software development. The initiative had legs, and thus the term “agile” was soon kidnapped by marketers — and we began to hear of agile project management software, agile data warehousing, agile BI, and even agile master data management (MDM).

To be fair, in many instances the use of the word “agile” owed a debt to the practice of agile software development, which embraces such principles as:

• The early and continuous delivery of capability
• Catering for changing requirements
• Close cooperation between business people and developers
• Measuring progress by delivered capability
• Simplicity
• Attention to design

In fact, such principles can be applied to projects in many areas of IT, from interface design to database design. It makes sense to run projects in that way if you can because many of these principles are good practices. Yes, we should try to deliver piece by piece if that’s possible. Yes, we should cater for changing requirements, if possible. Yes, we should cooperate as closely as possible with the business users who we serve. Yes, we should measure progress by actual achievement. Yes, simplicity is a virtue. Yes, design matters.

What Makes a Database Agile?

While the principles of agility focus on how IT projects are organized and how collaboration with business users should be handled, there is another important aspect to genuine agility — the power of the software tools that are involved. They too can be awkward and ineffective, or they can be agile.

So what are the capabilities that would make a database agile?

Let’s consider the most complex database scenario imaginable: an Independent Software Vendor (ISV) wishing to build, maintain and market a suite of applications. The complexity comes from the fact that an ISV needs to satisfy a broad population of customers from many companies, rather than a group of users from just one. And then there are the ISV’s own business requirements. For example, to address the largest possible market, the ISV may want to run the apps:

1. In a software as a service (SaaS) manner
2. On-premises
3. In a hybrid part-on-premises/part-in-the-cloud manner

In practice, there are quite a few factors that may contribute to database agility. Let’s discuss them one by one:

• Database standards. Databases need to be SQL-compliant and ACID-compliant, pure and simple. Business-critical applications depend on the reliability of transactional consistency and data durability, and SQL makes it easier to code an application and find skilled developers. In addition, ISVs want it because customers expect it. There’s also the need for developers to be able to easily use the product so other technical developer features such as stored procedures matter.
• High-availability and disaster recovery (DR). For an ISV running a SaaS implementation, reliability in this area will be a matter of life and death. There’s an ease of use and efficiency issue here, too. Setting up and managing high availability configurations and DR need to be both easy and as resource efficient as possible.
• Scalability. True scalability matters for an ISV. Clearly, an ISV will not want to swap out one database product for another. If their chosen database doesn’t scale well and it encounters high data volumes, some quick fix will be needed – and an awkward design compromise will follow, costing developer time and make the database more difficult to manage.
• Multitenancy. For most companies, a database’s support for multitenancy has little importance, but for an ISV offering a cloud service, it does. They will have many customers running in the cloud and they will want them to share the same run-time environment while also having their own databases. They will also want to manage it all from a single install, so that version upgrades are reasonably painless.
• SaaS, on-premises, and hybrid. If a database works well on-premises and in the cloud (by providing multitenancy, for example), it will not necessarily work well in hybrid deployment, where part of the application is on-premises and part in the cloud. If hybrid deployment is difficult or impossible, the ISV customer may be unable to use AWS or any other cloud service for overflow compute capacity. Consequently, the ISV will not be able to sell that as a service.
• Distributed capability. There are degrees to this. Some databases provide a level of data replication that allow data to be mirrored between sites easily. It’s rare for a database to provide very flexible replication – for example, allowing data updates at any location among multiple locations or efficiently replicating data in a hub-and-spoke fashion to multiple regional sites from a central site. For the ISV, a versatile capability of this ilk is a selling point for their software. For the customer, it provides deployment choices and very likely, saves money.
• DBA requirements. The ISV naturally wants a database to be “DBA light” partly because it diminishes the actual costs of support. Some databases are far better than others in this respect, having minimal DBA requirements while others are troublesome.

The ISV and the Agile Database

ISVs migrating to the cloud know they need to make adjustments to turn their application into a service offering. The smart ISV will take this as an opportunity to shed aging components that will hold them back from moving in an agile fashion. Relying on decades-old database technology that’s been hacked to fit a cloud model is a dangerous strategy. You may be able to bend it to your needs today – but it will become more brittle with each new requirement, and you’ll begin to worry that this is the change that will break it.

Instead, find a database that ticks off all these dimensions of agility. That may be impressive, in terms of a checklist, but when you consider the strengths of the product in depth, its attractiveness to ISVs distinguishes itself in an unusual and important way.

Consider, for example, a SaaS capability. Finding a database that can migrate applications to and from the cloud dynamically in real time, can mean that ISVs can use a database to offer unique deployment options to their customers that stretch the very definition of hybrid, if they so choose: on-premises, in the cloud, hybrid, moving in and out according to workload and so on. None of this takes much effort beyond scheduling for it to happen.

If that’s not agility, what is?