In a past BR Bulletin, the article “Business Rule Mining: Reasonable or Lunacy” presented how to determine if business rule mining would help your project. Each organization is faced with numerous legacy applications that have become “black boxes.” Business rule mining is a systematic approach 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.
This article focuses on how to plan your first business rule (BR) mining project.
STEP 1: Identify the scope of your business rule mining project
It is useful to conduct a BR Proof of Concept. Benefits for doing so are to:
- Reveal rules hidden in code so business and IT can understand them better
- Identify how better management of rules through the rule life cycle benefits both the business and IT
- Understand the BR mining process
- Demonstrate the functionality of tools for mining BRs
- Develop metrics to extrapolate and estimate the rule mining and analysis effort
- Demonstrate how BR mining fits into your SDLC
- Begin to understand the BR Roles.
The scope can be as large as extracting all the rules in a legacy application or as small as extracting the rules for one particular focus area (i.e., state, region). Your first BR mining project should be a small application, well contained. The best choice is a small batch application. Additional criteria for your first project should include choosing an application that:
- Is implemented in technology that is common in your organization
- Has a development complexity comparable to your culture
- Has a level of documentation (or lack, thereof) that is common practice in your organization
- Has rules!
STEP 2: Choose your business rule mining methodology
The methodology outlines tasks and deliverables for your project plan. You will customize the plan for your project scope and purpose. A full methodology includes phases for collecting and inventorying the application system, data and program inspection, transcribing the legacy rules into business language, performing rule analysis, and validating the rules with the business and application SMEs.
STEP 3: Determine if the project will utilize a software tool with business rule mining functionality
The use of appropriate software can accelerate the tasks and improve the deliverables. There is a distinction between tools with BR mining functionality and general legacy understanding tools. Not all legacy understanding tools have BR mining functionality. Some examples of functionality to look for are the ability to:
- Search through multiple programs possibly in multiple languages to identify code snippets likely to contain embedded rule logic
- Identify synonyms across programs
- Provide application profiling reports, such as complexity, inventory, CRUD matrices, system flow, etc.
STEP 4: Choose your source rule repository
You should store the snippets of legacy code containing embedded rule logic, corresponding natural language translation into rules, and formal form rules in a source rule repository. In addition, you will want a business glossary, business terms, definitions and cross reference to legacy field names. For a Proof of Concept, the source rule repository can be as simple as a MS/Excel Spreadsheet. See the earlier article in this Business Rules Bulletin – “What is a Source Rule Repository Anyway” for more information on source rule repositories.
STEP 5: Conduct the Archeology Phase
The Archeology Phase uncovers the characteristics of and inventories the application artifacts. This information assists in estimating the project time and resources and in prioritizing where the mining should occur.
During archeology, you gather the application artifacts such as application code, JCL procedures for batch runs, screens for online applications, application documentation, file structures, application models, etc. The inventory information determined during Archaeology is:
- Application flow
- Types of BRs to mine (data constraints are generally easier to mine than complex inference rules)
- Quantity and types of documentation sources
- Type of application (batch or online)
- Type of application code
- Size of application (number of data files, number of programs, average number of lines of code for each program, number of batch routines or number of input and output screens)
- Design of application (highly structured, uses Call Routines, uses separate Read/Write routines)
- Types of tools available, such as tools with BR mining functionality, Source Rule Repository, etc.
- Percentage of time available from the business SMEs, application and database SMEs
STEP 6: Develop the Project Plan
The Archeology inventory information provides input to your project plan. You will review the application flow and identify the decision points, which are those places in the flow where the buried rules reside. For each decision, apply metrics to assist in developing the estimate. For example:
1. Estimate the number of fields updated in each decision and apply a rating – SIMPLE -1 to 5 fields updated; MEDIUM – 6 to 10 fields updated and COMPLEX – 11 plus fields updated
2. Estimate the number of programs involved in each decision and apply a rating – SIMPLE – 1 to 5; MEDIUM – 6 to 15 and COMPLEX – 16 plus
3. Estimate the number of source fields involved and then the number of second level source fields in each decision and apply a rating – SIMPLE – 1 to 5; MEDIUM – 6 to 15 and COMPLEX – 16 plus for each level.
Once you apply metrics to each decision, apply time estimates. Time estimates include effort needed to perform program and data inspection and rewriting the candidate rules in Natural Language and Formal Form.
Your plan will include time to maintain a business glossary, referencing legacy field names to business terms. Your plan will also include time for reviewing and validating rules with business and application SMEs.
STEP 7: Maintain business rule mining metrics
It is important to maintain BR mining metrics for program and data inspection and for transforming the rules from legacy code to natural business language and formal form. These metrics are useful in estimating future BR mining endeavors, and may improve as you gain experience with the methodology and tools.
STEP 8: Assign business rule mining roles
Finally, you assign roles to your project plan. There are new roles, such as data inspector, program inspector, business rule analysis, and business glossary administrator, along with familiar roles of business SME and application SME.
With the planning behind you, you are ready to start mining for rules!
