Canonical Database Architecture and DB2 Performance … Really?

by Susan Lawson, Daniel L. Luksetich
May 13, 2009

Change Control

Having generic centralized objects, maps, and message formats can lead to a change management nightmare. Usually, application development isn’t happening in a centralized fashion, but rather in various “stove-piped” groups. Once these various groups begin using centralized objects, they become dependent upon them. Likewise, the centralized objects develop dependencies on the applications using them. This dependency is in the area of change control, regression testing, and application approvals. When an application is using a central object or format, then that application becomes a stakeholder. Any change to the centralized object requires coordinated testing and approval from the various application teams. Often, these teams have their own development and testing in process, and schedules don’t mesh. Scheduling and testing issues can create an environment where applications can be deployed only once per month, leading to possible eventual abandonment of the centralized data access objects.

Potential ways around the change control issue include centralizing the regression testing and giving the central data access team the authority to dictate change to the application teams. At a minimum, you need strong communication to give plenty of advanced notice when changes are coming.

Database Performance Issues

As with any database design, the best performance is achieved using direct access via SQL to the database objects. Getting only the data that’s needed when it’s needed is the key to achieving high performance. Introducing layered access to your data stores can negatively impact database performance. A generic data access object lends itself to generic database performance. The performance issues created by generic data access can’t be resolved by tuning the database or system resources, such as adding memory or CPU. This is solely a problem of the application.

Layers and Layers

The key to high-performance database design is to move data-intensive processes as close to the data as possible. This allows for filtering of data to occur close to the data, and less data to be passed around and processed by other data processing layers. Consider Figure 3. How many service layers must be crossed before a piece of data is actually viewed by a person or processed by an application? As more layers are added to the architecture, more issues arise:

• More layers of abstraction leave more people clueless about how the data is physically stored. This could lead to people choosing data service objects for ease-of-use rather than performance, or choosing an access path that crosses layers that aren’t required.

• More layers of processing objects means more required machine power to run the processes. While machines are cheaper than people, they do need to be managed by people, and machine upgrades typically mean significant increases in software costs. This is especially true for IBM mainframes, where software licensing is typically based on MIPS consumed.