Decoupling for Minimal Maintenance
Within many corporate IT organizations, there’s now a clear understanding of the need to decouple process-control parameters from application code to support the development of flexible application logic. Applications may be categorized according to levels of flexibility and ease of sharing, from least desirable (least flexible or easy to share) to most desirable.
Figure 5 presents a graphical, high-level overview of the procedural approach to system maintenance. As the business environment evolves, user change requests accumulate in the IT pipeline. Multiple, unrelated change requests are queued and applied collectively to minimize overhead. Delay is part of the process.
In the table-driven approach in Figure 6, multiple change requests are distributed and independently applied, in parallel, across a series of tables. Each table describes some set of attributes for objects in the evolving business world. Business experts who request changes to business rules also are the ones most qualified to directly apply those changes to the tables that drive the application. Overhead is minimized and, often, IT involvement can be entirely eliminated.
Table-driven design is already familiar to most programmers. It’s commonly found in the traditional concept of a driver program in transaction processing. Logic paths are selected at execution time, depending on the literal value of the current transaction code. Here, though, the transaction code is usually directly associated with a given subroutine in a procedural manner. There’s no way to change this association without changing the driver program itself. A truly table-driven approach would indirectly relate transaction code to subroutine via an external table.
There are many other benefits of in-memory tables, including reduction in maintenance cycle time, a shared understanding of the operation of system and a resultant system capable of user interaction at any level—operations, architecture, programming, strategic planning and tactical adaptation, and others.
The Business Case
While table-driven design is a well-understood concept to most programmers, the business case for adopting this methodology is what’s most important to the executive suite. Fortunately, this methodology offers significant benefits in performance and profitability.
More transactions performed in the same time means more revenue. The increased efficiency gained by using the shortest path to data reduces program execution time from hours to minutes. By placing rules in tables external to the application logic, time to implement is reduced from months to hours. This found time enables IT resources to focus on revenue-generating tasks or other efforts, increasing productivity and saving money. An increased return on investment occurs without the need for migration or costly upgrades.
This methodology works best in environments where mainframes are processing significant numbers of transactions, in industries such as financial, retail, insurance and telecommunications, as increased efficiency in these transaction-rich environments means substantial cost savings and increased revenue. Companies that adopt these practices also enjoy competitive advantages because they can complete processes faster than competitors, accelerate time to market, and react more easily to dynamic market conditions.