Revolutive IT™
Legacy Systems and Business Process Reengineering


By William Ulrich (Original text on

I n any BPR project, the as-is model should be used as a basis to redesign workflows. As processes are eliminated, updated, added, and re-sequenced, links to legacy system functions are maintained. The modeling approach used can be flexible, because the open transition model supports mapping of legacy functions to object, user interface, or other types of models. Upon completion of the new business model, work can begin on the retooling strategy. This requires an assessment of the existing architecture and target requirements which results in a detailed, retooling implementation plan.

The first step in the assessment requires management to identify feasible retooling hypotheses. This includes surround strategies, redevelopment, offshore options, internet options and / or package acquisition. Several basic issues drive which hypotheses are considered. An immediate requirement to address customer service consolidation may necessitate surround technology, such as graphical front-ends or data warehouse. An offshore rewrite could also serve as an interim strategy to stabilize a weak system. Additionally, selected off-the-shelf packages may meet retooling requirements. Finally, redeveloping impacted systems may be the ideal long-term solution to meet BPR requirements.

The analysis needed to finalize the retooling plan includes maintaining links between business models and detailed design models, further decomposition of legacy functions, and mapping legacy functions to detailed target models. The type and depth of analysis depends on the strategy being examined. Fore xample, requirements mapping to a package compares package models with target and legacy design models to determine reuse, deactivation, integration, and migration requirements.

Full-scale redevelopment, depending on the target architecture, requires detailed extraction and reuse of existing business rules. Extracted business rules must be mapped, at the applicable level of detail, to target design models. Augmentation of target models, and reuse of key business rules, can significantly streamline redevelopment cycles and shorten implementation windows. Many of the existing business rules can be reused under a target architecture. Organizations are spending a lot of money trying to recreate business rules when they don't have to.

These concepts challenge traditional BPR retooling strategies which include surrounding impacted systems or undertaking a complete rewrite. The first approach ignores the fact that underlying architectures remain segregated and convoluted. The second approach rarely accommodates legacy migration requirements and tends to exceed delivery windows and budget plans. Selecting a common sense approach, based on detailed analysis of target and existing architectures, yields the best results.

Several redevelopment options can be applied as a way to retool legacy architectures.
Regardless of the approach, systems should be phased in over time, while deactivating legacy components along the way. One approach is to create a system to support the cross section of the business being reengineered. In the order processing example, this means mapping all business rules extracted from multiple standalone systems to a target design model. Rule extraction is accomplished using a combination of slicing and cross-system extraction tools.
Another approach, applying similar techniques, performs multi-system integration on all relevant systems. This approach retools the existing architecture on a broad scale. The focus is on mapping legacy to target design models, rule reuse, redundant rule consolidation, legacy deactivation, and transition management. Both approaches require phased decomposition of existing systems into reusable business logic, data access, and communication segments.
Data store consolidation and redesign is performed concurrently.
Internet utilization requires an assessment of the role of legacy data and functionality. Leveraging the Internet requires more than setting loose scores of para coders. Redevelopment offers this broader view of the issue and the solution. Even package strategies require a retooling component. Legacy systems must be inventoried, deactivated, and integrated as part of package implementation. If the package requires retooling, redevelopment techniques may be applied after implementation. Any of these longer term approaches can be coupled with a parallel, interim surround strategy to deliver value near-term.

Our solutions are the most efficient, flexible, quality-based and cheaper of the market, due to our fully innovative and customer-driven approach. Discover them and compare them to the solutions provided you by our competitors.

Copyright 2002 Atlantis Technologies. All rights reserved.