Business process reengineering (BPR) allows management to realign organizational functions along more strategic lines. Companies examine processes now supporting the business and redesign those processes to reflect more efficient ways to achieve organizational goals. BPR is not an isolated phenomenon in today's highly automated environments. Information Systems (IS) organizations, due to the large installed base of legacy systems, play a key role in BPR efforts. Redesigning business processes that are tightly coupled with legacy systems implies that there will be a huge impact on those systems. Conversely, understanding current business functions requires analysis of these same systems. Fortunately, a rapidly emerging discipline supports analysis and migration of legacy systems to support BPR. It is called "Systems Redevelopment".

System transformation has several phases. These include enterprise and system-specific assessments, positioning of systems for ultimate transformation and the actual transformation stage itself. Some combination of these related disciplines are typically required to support changing business requirements.

Systems redevelopment has advantages over traditional analysis techniques. IT analysts, isolated within functional areas, tend to miss the "big picture" view required to support BPR analysis. Additionally, analysts may lack formal approaches for capturing and depicting cross functional views of legacy systems. Systems redevelopment, however, provides well defined analysis techniques and deliverables to support BPR. A second advantage is that these analysis techniques provide the basis for an implementation plan based on BPR project findings. Redevelopment techniques also leverage extraction / derivation tools to streamline this process. Finally, formal redevelopment techniques can be combined into various "scenarios" to support a wide array of BPR recommendations.
The objective of the majority of these systems "redevelopment" efforts is to replace, integrate or somehow accommodate legacy systems to more effectively meet business goals. As a result of this directive, improved understanding of legacy systems, through business rule capture, is becoming an increasingly common goal.

Many organizations have found that the IT department actually contains a company's functional expertise. But over time, that expertise has been lost. When company's make the decision to move to distributed systems or other technological environments, they need to determine what functions were currently being performed and what functions needed to be added. Business rule extraction is the way to determine what a company has before attempting to move forward."

While templates, packages and other reusable components streamline design efforts, business rules embedded in legacy systems still provide that "competitive edge". These rules are "locked up" in legacy systems and efforts to respecify them in today's high pressure, downsized environments is a costly, time consuming endeavor. Legacy rule capture and reuse has been described as the "missing link" in the systems transformation process.

Rule isolation and extraction is performed by tracing logic paths based on various selection criteria. This includes logic leading to the creation of a given output variable, logic linked to some type of conditional and logic associated with a given input transaction type. Analysts must review a rule after extraction in order to use it as is, extract again based on a different criteria or subset the extracted rule further. These techniques are somewhat tool dependent, but it is important to establish an initial extraction criteria regardless of the tool being applied.

Required rule extraction tool criteria minimally includes an ability to "slice" out a rule based on a specified selection criteria. Since business rules do not limit themselves to the confines of a source program, extraction tools must be able to analyze logic across program boundaries. Beyond that, a rule extraction tool should be able to bypass or highlight implementation dependent logic, store an extracted rule, further extract against a previously extracted rule, display a rule in varying formats to promote understandability and transform an extracted rule into a reusable format.

Certain tools can load a system into its knowledge base and transform it into predicate logic. Rule analysis is then facilitated through cross system extraction and simplification techniques. Rules may be displayed in decision vectors or as source code. The real power of are that they allow IT professionals and non-technical analysts, to examine extracted rules and verify what functions a system is actually performing.
The industry wants automated solutions in this area because people do not like to do the work required to get useful results.
Early, misguided efforts in business rule capture stemmed from the lack of sophisticated reuse strategy in many organizations.
While most tools offer static source code analysis to support rule extraction, other tools provide dynamic analysis by tracing logic paths during program execution. Dynamic analysis is performed when a program is executed, dynamic analysis can capture a logic path based on the transaction being performed. Sophisticated tools support the creation of a union of slices allowing analysts to fine tune extracted views.

Business rule capture is a key issue because most development projects do not have the luxury of starting from scratch.

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.