With the economy in flux, the ability to adapt is more important than ever. Budgets and jobs are under scrutiny, and any wasted minute can be translated to money that can’t afford to be lost. Businesses are depending on IT to stay nimble and quickly manage data changes. But implementing changes to your data structures can be challenging. A vast amount of data is stored in DB2 on z/OS, and DB2 applications are complex. As a result, changing DB2 data structures can be difficult, labor-intensive, and error-prone—particularly when performed across subsystems. These are shortcomings that don’t bode well for growing a healthy business.

To understand how difficult it can be to change the structure of a large DB2 database, imagine the intricacies involved in trying to change the structure of a city—and the houses, furniture, and people who live there. A large number of objects with complex relational dependencies must be managed. It takes a brave person to manage that degree of change. Fortunately, vendors provide tools that make it easier to manage structural changes across DB2 subsystems. And the city analogy perfectly encapsulates how it works.

Imagine we’ve created a completely new city, which is represented by one large, complex DB2 database, and each of the 100,000 houses built within it is represented by one DB2 table. The citizens of the city are the users. This city— like the typical DB2 database—is an immovable, inanimate object. Any attempt to make changes to the city’s shape, structure, or even to individual groups of houses is fraught with risk and is costly in terms of time, resources, and availability.

As a city grows, it attracts more people, more houses, and more resources—in exactly the same way an organization evolves and demands changes to the DB2 database environment, such as the integration of a new Enterprise Resource Planning (ERP) or Customer Relationship Management (CRM) system. In our analogy, that new application may be a new school or the widening of the roads. It’s difficult to change the infrastructure; after all, the houses (tables) are already defined. But City Hall says the new school or new road is a required change, so the houses and people within them (data and users) must be moved. Of course, these people have lives to live, so the change must be non-disruptive. The people and all their furniture must be temporarily placed elsewhere, where it can still be used. City Hall demands the houses be torn down, but they need to be rebuilt exactly as they were before. That means rebuilding the houses brick by brick and putting the furniture back exactly as it was.

Your DB2 data is critical to your day-to-day business, but you may need to change the way that data is structured. Perhaps you need to implement an ERP system or remove an inefficient index. The best way to tear down and rebuild these structures is with a tool that intelligently manages change in complex environments—and ensures the integrity of the data. Changing one structure could have a ripple effect, so be sure the tool finds and changes all affected dependent structures accordingly.

With the massive changes required to dismantle and rebuild a city, the builder must complete thousands of tasks. When adding another floor onto a house to accommodate more people, an inexperienced builder can easily forget to add the supporting walls. When you change the structure of your database, you need a tool that adds checking phases into the process—to ensure the highest degree of quality.

For large databases with thousands of objects, it could take a long time to implement complex changes. Because data is unavailable while structures are being changed, the speed of change is essential. The required utility maintenance work takes the largest part of the change maintenance window, so execute those tasks in parallel. In the city, while roads are torn up to be widened, or the houses moved and rebuilt, multiple people are working in parallel to move the houses (the tables) and furniture (the data).

To provide business continuity, you must be able to test changes in a non-production environment and apply them when fully tested without losing any customizations local to each separate environment. It’s the equivalent to having a test city and a production city. Every street, every house, every piece of furniture that was changed needs to look identical. Use a tool that enables you to compare the structures and make modifications to ensure uniformity.

Who thought you could compare a DB2 database to Manchester, Miami, Munich, or Madrid? DB2 environments—like cities—can be daunting places. With tools that can effectively manage growth and change in an increasingly complex database environment, your team can help ensure the overall success of the business.