Is your organization challenged with the need to take an existing legacy system and re-architect it into new technology? But, what happens if that legacy application has no current system documentation, no available application SMEs or business SMEs who you can interview to identify how the existing system works?
The solution is the vision of Business Rules, with emphasis on business rule mining. Business rules are the most essential, non procedural statements behind business policy and requirements. The business rules represent the thinking of business leaders and how the leaders want to implement business policy. Unfortunately, many of those business rules have been automated and lost in program code.
This article is the first of a two part series on Business Rule Mining. This first article highlights when to consider Business Rule Mining as part of your efforts for re-architecting your legacy application or possibly just unleashing and externalizing the business rule assets from your legacy application.
Business rule mining is the process of extracting essential intellectual business content (business rules) from packaged or legacy software, recasting them in natural language, and storing them in a source rule repository for further analysis or forward engineering. The goal is to capture these legacy business rules in a way that the business can validated, control and change them over time.
Let's explore three important questions when considering business rule mining as part of your project effort: why, when, and what.
1. Why do business rule mining?
Generally, the main reason to consider business rule mining is to gain a basic understanding of how and why an existing system works today, whether or not there is a need to implement new technology. It is important for many organizations to begin understanding and documenting the business rules of the as-is systems because:
2. When is business rule mining helpful?
The business's rules today are locked, in bondage, within legacy systems. For many organizations, the first step toward unlocking the intellect of the company is to dig for the existing rules in legacy code. Listed below are some of the circumstances for which business rule mining is helpful:
It is important that someone knows what the rules are.
3. What do you need to get started?
As with any project, to be successful, you need to have a well-defined scope and purpose for your project. The scope and purpose will help direct the candidate rules that you are targeting for mining (i.e., mining rules for a particular sub-function of the application, particular state or region, etc.). Along, with good project management practices, the business rule mining approach consists of:
The business rule mining methodology ensures that you do not extract candidate business rule code without reference to its related business process, order or dependency. There are three key phases of a complete business rule mining methodology:
Archeology - The discovery and collection of legacy system artifacts related to project scope and the development of an overall understanding of the system.
Program Inspection - The profiling and interrogating of program code eventually to uncover the declarative business rules implemented and embedded in the program code.
Data Inspection - The interrogating and modeling of system data and metadata to discover data based business rules.
In addition, business rule mining tools can speed the identification of candidate rules as directed by the methodology. It is important to understand not all legacy understanding tools have the functionality necessary for business rule mining.
You will need several kinds of business rule mining expertise. First, you will need expertise in the legacy application code and platform. Second, someone on your project should be experienced in the business rule mining tool, if your project will make use of one. Third, it will be important to have a resource that is knowledgeable in business rule analysis and management to assist in translating the candidate rules from the code statements to the business rule templates. Fourth, you may want to include a resource that will capture related rules from documents or people. A fifth resource may be useful in integrating rules mined from code with rules captured from people and documents. Two other experts to consider is someone responsible for the project glossary (reconciling terms across programs, people, and documentation) and one who administers the source rule repository (which holds the candidate code, translated rules, glossary, and other metadata).
Once you understand the role of business rule mining to your project, the next step is to plan and scope it. So, the second article in this series provides direction in planning your first business rule mining project.