Does Your Database Do Agile?
Does Your Database Do Agile?
Here are the questions you need to be able to answer to see if your database is ready for the jump.
Join the DZone community and get the full member experience.Join For Free
According to a Harvard Business Review article, an environment in which Agile can flourish enables teams to quickly “churn out“ innovations in products and functional processes. The Agile model is being adopted by more and more companies as customer demand for applications grows, with the expectation that apps are delivered and updated quickly enough that they can satisfy today’s needs.
Creating such an environment in the enterprise requires the support of core infrastructure—most notably, the database. Unfortunately, many companies are finding their Agile development efforts thwarted by inflexible, insecure and/or incomplete database systems.
There are a few questions companies need to ask themselves to determine whether their database systems are designed to nurture or negate Agile efforts in the enterprise.
1. What Does It Take to Thrive When The World Around Our Business and Industry Is Rapidly Changing?
You may have heard the Agile model compared with the waterfall model. With the latter, more traditional, model, developers work in a linear fashion: they gather requirements, design, code, test, fix issues revealed by tests, and deliver a final product. With Agile, developers deliver iterative products along the way. These products won’t be exactly what was requested—not at first—and one iteration will likely look very different from the next. But the iterative systems will let users get work done right away, without having to wait until a “final” version comes along. (And, even then, the final isn’t final, as developers will evolve the application based on internal and external customer demand.)
If your database is not capable of effecting this level of change in a way that is efficient and cost effective, you’re never going to be able to do Agile software development in the way it’s meant to be done. In fact, you’ll be constrained by things you cannot change
2. Is the System Flexible? Does It Support a Wide Variety of Data Types?
One thing that prevents developers from implementing the kind of changes just discussed is fixed schema. With relational databases, for example, you have to define all of your data models up front, which is really hard to do in a rapidly changing environment. And that means there’s a really good chance that you’re going to eventually encounter data—or data requirements—that don’t match the models. What then?
Well, you have to go back to square one and spend a lot of time (and money) to revise the data model, rewrite the ETL, and reload the data. Companies simply can’t be Agile and innovative when developers are trying to use a database that wasn’t designed with flexibility in mind. It truly is like trying to fit a square peg in a round hole.
Databases that are schema-agnostic, such as NoSQL systems, can accommodate the iterative and changeable nature of the Agile model. Now, I’m not saying that you don’t model your data with a NoSQL database. But I am saying that to fully adopt Agile development a database needs to empower you to model just the data you need, right when you need it, so that you can effectively build data services.
And when data inevitably changes or a new source is introduced, the new shape can be brought in and curated to meet your needs right inside the database—without the need for external tools or additional application code. All this can be achieved when the database is engineered from the ground up to be flexible and provides frameworks that make it easy to ingest, secure, curate and access new shapes of data.
3. Does the Database System Integrate Key Enterprise-Level Capabilities?
Companies that decide a NoSQL database will help them achieve their Agile development goals have choices, but it’s important to ground Agile aspirations in enterprise realities. Sure, companies can download an open source NoSQL database and cobble together a system that includes enterprise features. But it would be a stretch for even the most talented developers to seamlessly build out enterprise features including—but certainly not limited to—search, native storage for data in a variety of languages, advanced security, scalability, and high availability and disaster recovery. Just getting the products to work together in this kind of scenario would be a lot of work, and it’s very likely that significant coding would be required to fill the inevitable deficiencies in the system. All of this takes time, and it’s time taken away from things the customer really wants and will be able to use—today.
In fact, “today” is really the operative word when it comes to Agile. Developers must be able to work today to meet today’s customer demands. Tomorrow just doesn’t cut it in today’s dynamic digital environment.
Opinions expressed by DZone contributors are their own.