The goal of this task is to derive business rules from legacy systems and represent them in a way that supports event modeling as defined in the event derivation analysis task. The approach is premised on the need to reduce rule specification time, while concurrently defining a migration path from legacy applications.
Three assumptions underlie this concept. First, certain business rules embedded in legacy systems may need to remain unchanged under the target system. Rule examination and reuse verifies continuity and integrity. Additionally, respecification of complex rules can be streamlined by reviewing existing rules as input to this process. This would prevent analysts from re-inventing the wheel or re-inventing an existing rule, that should be carried forward intact, erroneously.
Finally, if functions within a legacy system are unrelated to the system being developed, selective rule deactivation may apply. This allows for portions of a legacy system to remain intact, while rules added to the new system are deactivated. Deactivation avoids functional replication between legacy and replacement architectures. This task flags physical rules to be deactivated using the Legacy Transition Meta-model or LTM.
The approach used in this task is to assume that a rule is linked to a transaction, an output, a calculation or some other physically concrete and identifiable item in a program. Logic leading to and/or from the occurrence of one of these items (this can be defined by the user and implemented using various tools) is traced across physical boundaries until all source comprising the rule is isolated. Once identified, the rule can be mapped to a target paradigm of choice.
In terms of the target paradigm used for mapping rules, this task is used in conjunction with Event Derivation Analysis. The target business rule model to support the mapping process is derived from the Martin/Odell Object Oriented Analysis (OOA) method and focuses on the use of triggers, preconditions and post conditions.
If the target architecture is Information Engineering based, refer to the Process Action Analysis task and various scenarios that incorporate that task’s step guidelines. The overall rule definition and mapping approach is shown below.
Specific objectives of the Business Rule Derivation Analysis task include the following:
· Specify target business rules to support previously defined event diagram
· Examine, extract and reuse, where applicable, legacy business rules as an integral component of target rule specification process
· Determine how redundantly defined legacy business rules should be consolidated within the specification process of a target business rule that replaces existing functionality
· Identify and tag business rules to be deactivated using the Legacy Transition Meta-model (LTM - refer to TIM Appendix for details) as required by scenario or project
Note: While this task supports wide-spread rule analysis and reuse, analysts can review and, optionally, reuse rules on a selective basis based on scenario/project objectives.
This task, as much as any TIM task, is linked to techniques defined in other development methods. Event modeling, in the context of this task, is based on the Martin/Odell (OOA) model referenced earlier in the task objective section.
This and other prerequisite entrance criteria are listed below.
Note: All entrance criteria listed for event derivation analysis apply to this task as well because completion of event derivation analysis is required entrance criteria for this task.
· Acceptance and availability of event modeling techniques defined in the Martin/Odell model
· A corresponding object oriented, event driven development methodology that defines notations and techniques under an integrated approach
· Completion of event derivation analysis task defining the operation name and trigger for a given rule
· Completion of data name rationalization, code stabilization and remodularization tasks as defined by scenario driving this task
Note: The degree of code improvement depends on driving scenario, original code condition and time requirements. Rationalization of data definitions tends to be a critical prerequisite to rule derivation in most cases.
· Availability of populated LTM linking forms, programs, execution language and other legacy objects to functions and process/bus rule objects
Note: LTM leverages prior event derivation analysis, and facilitates management of rule deactivation activities. LTM is a requirement for large scale business rule derivation projects.
The personnel and skill requirements necessary to meet the business rule derivation analysis task are identified below.
· Redevelopment Expert
- Ability to navigate legacy systems and source code using analysis tools defined within this task and derive events and business rules from the system
· Business Rule Modeling Expert
- Expertise in event and business rule modeling and development using object oriented CASE tools
Note: High degree of expertise is required since this task does not outline full set of techniques necessary for building rules.
· Current Systems Expert
- Knowledge of the functionality of current data utilization
· Target System Functional Expert
- Knowledge of target data requirements
· Application Area Manager
- Authorization to review and approve approach and plan
The system components and related inputs required to initiate and complete the business rule derivation analysis task are listed below.
Note: See Entrance Criteria section for notes regarding the optional nature of certain input requirements.
· Event model created during event derivation analysis task
· Object model created during object derivation analysis task
· Environmental analysis documentation including batch run streams, load modules and related source programs
· Functional mapping form 004, built in function hierarchy analysis, that links current program to current function to, optionally, target function
· Function dependency models derived during function dependency analysis task
· On-line screen and batch job data flow diagrams (DFD) derived during general systems architecture assessment
· Inventory and cross reference of user I/O views completed during presentation layer assessment depicting
· Existing application source, JCL, PROCs, screen map definitions and other physical system components
Note: Each of above tasks contributes to evolution of LTM. While LTM is technically optional, managing rule derivation across large environments is nearly impossible without a formal management facility. Consider LTM a requirement for all but trivial projects.
· LTM repository populated with event and process/business rule object instances linked to legacy forms, JCL, source programs, control tables and other legacy objects
Technologies supporting the business rule derivation analysis task include business rule modeling, business rule capture, interactive system analysis and open systems repository tools. These tools are used to represent information as required by this task.
Business rule capture tool
Required rule extraction tool criteria include the ability to "slice" out a rule based on 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. This analysis may be performed either statically or dynamically (during actual execution of a system).
Beyond these criteria, 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.
Business rule modeling tool
This tool should be able to represent operations defined in the business rule diagram, shown below, and facilitate specification of triggers (when), preconditions (if) and post conditions (then) within a rule editor as follows:
This tool should also integrate with the event modeling tool used to specify events in event derivation analysis. Additional feature should include ability to test rules through immediate execution of the model.
Interactive system analysis tool
The interactive system analysis tool should be able to trace logic across a system through data usage and execution linkage. Analysis may be depicted either graphically or highlighted in interactive source code views.
Open systems repository
Open repository provides the ability to trace established and add new business rule objects within the LTM. It also supports linking rule objects to source and other legacy components. This is critical since analysts must examine and embed countless legacy rules spanning multiple physical components and formats. The LTM provides the audit trail to support rule reconciliation and deactivation.
Requirements include the ability to add and update event objects, attributes and relationships. A recommended baseline LTM meta-model may be found in the TIM Appendix section.
The business rule derivation analysis task is comprised of the following task steps:
Identify Legacy Business Rules Reconcile, Respecify and Deactivate Rules
