You need a common message format to communicate with new and existing applications. This common message needs to map to these various database formats. Mapping can be efficient and easy to manage as long as the local and common formats remain stable. Unfortunately, stability is elusive in a modern dynamic environment. So if an application is locked into a specific map, how can you manage change? Figure 1 shows two simple COBOL record layouts. In each example, if data movement is by individual attributes, there’s a certain amount of flexibility in mapping. However, if movement is at the record level, then a change to the main format, as shown in Figure 2, could break the local format.
The situation described in this simplistic example is real. Companies can find themselves locked into fixed message formats that make any mapping change extremely difficult to manage. Although our example demonstrates the problem with fixed formats, the problem isn’t just limited to these fixed message formats.
Possible solutions may include creating maps of maps or versioning of message formats. By mapping to maps, you can establish a central cushion to allow some applications a layer of isolation from changes to message formats. This should allow for more flexibility, but adds more complexity to the architecture and possibly more processing cost. Versioning seems more practical, and some message brokering software accommodates it. There’s still increased management cost in maintaining multiple versions, and this can lead to slow adaptation to the messaging architecture and quick abandonment of the architecture due to confusion.
Common Object Management
Typically, a central group manages a set of common data access objects. The common objects are generic in nature and built with flexibility in mind. This typically comes at the cost of performance. When a request comes into the group for access to a certain piece of data, the group first considers the available objects to see if one can be reused.
This makes sense from an object management perspective. Fewer objects to manage lowers management cost. The trade-off is that applications sharing the objects are locked into the use of the object. This means they may be accessing data they don’t need, and then just dropping it onto the floor, leading to potential performance issues. Returning data from DB2 unnecessarily carries a resource cost. Also, if an application needs more information from an object that currently isn’t provided, developers must go to the central group to change the object or create a new one. Any change to the central object could result in increased data access costs for all applications using the object, not just the one requesting the change. Versioning of objects could help resolve this performance issue but at the price of higher management costs.
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.