As BPM begins to expand beyond isolated projects to mainstream programs at the division or enterprise level, there is a need to engage a far greater number of business people in the...

Retooling Legacy Systems to Meet Business Process Retooling Requirements

Business analysts continue to streamline and consolidate business processes to stay competitive and lower costs. As this occurs, entrenched application systems can impede these efforts. To fully realize the goal of business process retooling efforts, organizations may need to retool the legacy applications and data structures supporting those processes.

Consider a scenario where batch applications update customer data through a series of input data streams collected by daily, online transaction systems. Based on newly defined customer management processes, front-line users require access to information from the time an order is taken throughout the fulfillment, billing and collection cycle. Stovepipe applications and data structures, however, are creating a roadblock to achieving this goal.

One commonly pursued option is to deploy business process management software with middleware. Middleware connects process-driven front-ends to back-end applications through transaction-based interfaces. Many times, however, this approach is handcuffed by inconsistently defined data structures that are only accessible through applications specifically crafted to process that data. In other words, non-invasive integration approaches are unlikely to address systemic process retooling requirements in all cases.

Legacy application architectures have locked essential business data into “data prisons”. Front-line users simply cannot gain access to essential information, in the format and combination required, to fully support retooled business processes and user roles.

One common example involves applications built around an aging master file that is updated via a batch processing cycle that sorts and merges data over and over again. The data is inaccessible to end-users who need a wide range of information in a rapid, flexible fashion – based on retooled business processes. If middleware options fall short, you likely have a systemic problem that requires retooling application and data architectures.

The proposition of retooling data and application architectures makes many executives squeamish. Legacy systems are viewed as black boxes that should not be tampered with at all cost. The advent of powerful application modernization tools, however, coupled with modernization processes, make legacy application retooling feasible.

Modernization applies a phased approach to legacy retooling by building upon functional production systems. Integrating front-ends is a common first step. Subsequent steps, each of which may be deployed as an interim version of the application, break down as follows. Note that these steps are situation dependent and should be adjusted as circumstances dictate.

1. Run application analysis and cross-reference tools across the applications of interest.
2. Based on the findings, establish a viable plan that can meet long-term business requirements through a phased approach.
3. Rationalize common data definitions across existing operational systems.
4. Use a bottom-up / top-down approach to redesign core application data structures.
5. Create a non-operational, interim database to provide query-based data access to front-line users and to fully vet new data requirements.
6. Identify, isolate and consolidate redundant functions into common subroutines.
7. Continue refactoring applications by creating an I/O layer, user interface layer and functional logic layer.
8. Strip away obsolete, implementation dependent logic from the application and replace this logic with appropriate functionality as required.
9. Change operational logic to access the interim data structure so that this data structure becomes the operational database.
10. Phase in various portions of the retooled application as the situation dictates.
11. Migrate to a more modern language if the situation dictates.
12. Continue refining and refactoring application functionality as required.

Legacy application retooling is an option that should be explored if non-invasive integration options cannot fulfill business process retooling objectives. This is a viable consideration that demystifies the process of retooling application and data architectures to deliver cost effective options to business process retooling requirements.

William Ulrich is President of Tactical Strategy Group, Inc., Co-chair of the OMG Architecture-Driven Modernization Task Force and author of “Legacy Systems: Transformation Strategies”. He may be reached through his web site at www.systemtransformation.com.

Back to Articles, including BPM, SOA, BDM, BA & OP