Extracting Business Rules from Legacy Code

1
Extracting Business Rules from Legacy Code
2
Overview

• Problem Context
• What are Business Rules?
• Business Vocabulary Business Rules
• Mining Rules from Legacy Source Code
• Example Rules Mining
• Why Automation to Find Business Rules?

3
Problem Context of Business Rules Extraction

• Large Legacy SW Systems are complex and are
  continuing to grow in complexity
• Oceans of code, multiple languages / dialects,
  distributed systems
• Outdated or missing documentation
• Difficult to make small changes across
  large-scale systems
• Nearly impossible to make large changes
• Reliable and effective change to large systems
  requires
• Understanding of explicit business rules from the
  software
• Traceability of business rules to implementing
  software
• Analysis of business rules for continued
  relevance
• Alignment with business rules of other systems
  and organizations
• Nearly impossible to accurately define Business
  Rules without looking at code.

4
Finding Business Rules

• Finding Rules through
• Interviewing the Programmer / Analyst
• Interviewing the Users
• Reviewing existing Policy Manuals, Documentation,
  etc.
• Does the IT system really do what the SMEs think
  it does?
• Have they seen every scenario?
• Only the code can tell you what the Business
  actually does
• Source Code Browsers
• How much source code have you have?
• How complex is the code?
• How long will that take?

5
What are Business Rules?

• Actionable business directive whose purpose is to
  advise or inform and that introduces
• an obligation that covers conduct, action,
  practice, or procedures
• a necessity that is intended as a definitional
  criterion.
• A business rule is typically expressed in an
  English declarative statement (not as a process
  or procedure).
• tabular forms are also common
• Enforcement of a business rule is separate from
  the rule itself
• partly enforced by daily, manual business
  activities
• partly enforced by IT systems
• may span multiple systems
• system requirements are rules about enforcing
  business rules in the systems

6
Business Vocabulary and Business Rules Are
Independent Of Implementation

• Not dependent on any business process,
  information systems, or record keeping system.
• Business rules depend only on the business
  vocabulary.
• First get the business vocabulary
• Being implementation independent, a vocabulary
  and rules set can inform or validate any
  implementation design or integration of
  implementations.
• Being in English, a vocabulary and rules set can
  be validated and maintained by business people.

Business Rules
Business Fact Types
Business Terms
7
Business Vocabulary and Business Rules

• Business rules on business fact types.
• Business fact types build on business terms.
• A business vocabulary comprises business terms
  and business fact types.
• To get business rules
• First get the business vocabulary
• Then build rules using vocabulary
• Interleave activities in practice

Business Rules a rental must specify exactly 1
car group
Business Fact Types rental specifies car group
Business Vocabulary (car rental business)
Business Terms rental car group
8
Business Rules are rarely obvious in the code

• We need to locate business rules related data and
  logic and abstract them to the level of business
  understanding

You can interview the people, but how do you
interview the software?
9
Finding Business Rules -If it were only this easy
COBOL Code
current balance
MOVE 1000 TO MIN-PAYMENT ALLOWED. COMPUTE
CURRENT-PAYMENT (NEW-CURR-BALANCE 0.1). IF
CURRENT-PAYMENT lt MIN-PAYMENT-ALLOWED AND
NEW-CURR-BALANCE gt 1000 THEN MOVE
MIN-PAYMENT-ALLOWED TO CURRENT-PAYMENT IF
NEW-CURR-BALANCE lt 1000 THEN MOVE
NEW-CURR-BALANCE TO CURRENT-PAYMENT. IF
NEW-CURR-BALANCE lt 1 THEN MOVE ZEROES TO
CURRENT-PAYMENT
10
current balance
current balance
10.00
Individual Rules
if current balance is 100.00 or more then
current payment is 10 of current balance. if
current balance is less than 100.00 and is
10.00 or more then current payment is 10.00. if
current balance is less than 10.00 and is 0.01
or more then current payment is current
balance. if current balance is less than 0.01
then current payment is 0.00.
Composed Rule (decision table)
current payment is determined by current
balance if 100.00 or more then 10 of current
balance else if less than 100.00 and is 10.00
or more then 10.00 else if less than 10.00 and
is 0.01 or more then current balance else if is
less than 0.01 then 0.00.
10
Not all rules from code are Business Rules

• From a BR tool Vendors Web Site
• End Of File Switch Is Equal TO 1 Apply
  VALIDATE-PUR-MASTER Unit End Of File Switch Is
  Equal To 1
• 1 is Added To Error Counter
• Error Message Is Equal To VENDOR NUMBER MAY NOT
  BE NULL
• When Purchase Order Vendor Number Is Equal To
  Spaces Or Purchase Order Vendor Number Is Equal
  To 0
• (4) Working Area For Quantity Due Is Computed As
  PUR-ORD-QTY Minus PUR-REC-QTY Plus Purchase Order
  Quantity Returned To Vendor
• When purchased Status Is Equal To O
• (5) 1 Is Added to Error Counter When Working Area
  For Quantity Due Is Equal To 0
• (6) Error Message Is Equal to OPEN ORDER HAS
  ZERO BALANCE DUE
• When Working Area For Quantity Due Is Equal
  to 0
• (7) Working Area For Quantity Due Is Computed As
  PUR-ORD-QTY Minus PUR-REC-QTY Plus Purchase Order
  Quantity Returned To Vendor
• When Purchased Order Status Is Equal
  To C
• (8) Inventory Cat Is Equal To 86
• When Inventory Purchase Order Cost Is
  More Than 500.00 And Inventory Purchase
  Order Cost Is Less Than 1000.00
• (9) Inventory Sales price Is Computed as
  Inventory Purchase Order Cost Multiplied By
  Inventory Markup Percent
• When Inventory Purchase Order Cost Is
  More Than 500.00 And Inventory Purchase Order
  Cost Is Less Than 1000.00
• (10) Inventory Cat Is Equal To 87
• When Inventory Purchase Order Cost Is
  More Than 1000.00 And Inventory Purchase Order
  Cost Is Less Than 5000.00
• (11) Inventory Cat Is Equal to 90

• Typical Problem (Rule s)
• Nonsensical rule (1)
• COBOL symbols are not business term (1,4,6)
• Direct use of implementation technology is not
  business vocabulary or business rule
  (1,2,3,4,5,6,7,12)
• Over specification (2,3)
• Failure to abstract variable (Inventory Cat)
  to named business term (8,10,11)
• Duplicated (cloned) business terms implies
  independence when rules may be coupled (47, 89)

11
The Code only hints at Business Rules

• Code
• Contains data definitions, information flows,
  computational procedures, comments
• Represents
• Business vocabulary
• Fragments of Business rule enforcement procedures
• Software architecture vocabulary, structures,
  procedures
• Hardware and communication vocabulary, procedures
• Business meaning of the data and actions is
  determined only at the system inputs and outputs.
• Business rules are usually not localized in the
  code
• Information is lost or tangled when programmed
• Partly in organization context of software
• Requires people to recover this information using
  code clues

12
The Mod Group

• Uses Compiler-grade analysis of source code
• Yield high degrees of automation
• Provide maximum accuracy by providing access to
  code details
• Complier-grade Automation makes the impossible
  practical..Not easy!

13
Technology Parsing Key Concepts
Parse
Analyze
p0
Static Analysis (Cross reference information, UML
class models)
Source Codes (COBOL, DB2, IMS, JCL)
Enables problem remediation
and
Rules
Dynamic Analysis (Test coverage/actual execution)
Rule Compiler
Transform
Format
Tool Definition (Cross reference analysis, UML
model extraction, COBOL to Java translation,
Execution Coverage)
or
Migration (CO BOL to Java method translation)
Language Definitions (COBOL, DB2, IMS, JCL, )
14
emergeIT interviews your software

• Pre-processing the raw code to produce an
  indexed, cross-referenced, navigable models for
  analysis.
• Cutting through the application to help you find
  the seams leading to knowledge that has
  business value.
• Helping you to construct business models and
  maintaining traceability for you.

15
EmergeIT Mining Process

• Identify seed elements with business meaning by
  analyzing boundaries (e.g. Screens, Reports,
  Database/File structures) Outcome driven
• Trace seed elements by cross cutting through the
  entire application
• Branch at business significant processing points
• Identify more business significant elements
  (terms, facts and rules) by tracing through the
  branches
• Branch until business significant elements are
  exhausted
• Validate with the SMEs and iterate until all seed
  elements are exhausted

16
emergeIT Methodology
Application Surface (where business interacts)
Business OutcomeSurface Artifact
Seam with branches
Branch end
Business significant elements (terms, facts,
rules)
Business Significant Processing Points
Processing point (Rule Conclusions)
Branching point (Rule Conditions)
17
BlackboxIT
evolveIT enables the user to select and create
many different views of the program structure,
data structure, screens and many other program
elements and relationship.
18
What We Do

• We are a company that offers application
  modernization services using a proprietary set of
  tools and processes that reduces risk and lowers
  the cost of modernizing legacy systems.
• Automated Modernization Services
• Software Remodeling / Mass Change
• Reorganize for Services Oriented Architecture
• Field Length Change / mass change
• Partial/Full System Conversion
• Application source code, Data Base, UI layer,
• Prepare for Package / Rules Engine Implementation
• Cobol Business Rules Identification
• Cobol online documentation / analysis