Background         

A Business Vocabulary and Business Rules Model (hereafter referred as Business Rules Model (BRM)) represents significant parts of a Business Operations Model (BOM).  The recently adopted OMG specification “Semantics of Business Vocabulary and Business Rules” (SBVR)^[1] provides a metamodel for a BRM.  At a very high level an SBVR-compliant BRM consists of:

• Business Vocabulary:  noun concepts and fact types, represented respectively by business terms and business fact type statements.^[2]
  
  
• Business Rules, represented by business rule statements.

The other major part of a BOM is represented by Business Processes.  They are outside of the scope of this paper.

A BRM is a business view that is often realized in programmatic data and logic in supporting IT applications.  In cases when a BRM was never formally defined, leveraging existing IT knowledge to discover the business vocabulary and business rules may look like a very intuitive way to make the BRM explicit.  However, there are two major concerns:

• Creating a BRM from programmatic data and logic is possible only with the help of human analysis knowledge enhancement.
  
  
• The large size and complexity of many existing applications (which may contain millions of lines of legacy code) can render the discovery process cost and time prohibitive -- and perhaps not feasible at all.

This paper describes an approach utilizing a methodology and tool suite that enables discovery of BRM from an application’s programmatic data and logic, within a predefined project scope and estimated budget.

Do not reinvent the wheel

The approach is not to develop a BRM from scratch but to discover business knowledge, especially business rules, that is hidden in existing operational systems and to make it explicit in a form that is usable by business people.

Business knowledge is hidden in three sources:  applications, documentation, and people.  Any comprehensive BRM discovery process should tap into all three.  Failure to do so may cause a significant portion of the BRM not to be populated in the first place, consequently causing additional cost and longer time to market.

Existing applications may well be the most accurate source of business knowledge because they provide functionality supporting actual business processes.  However, the business knowledge captured in applications may be incomplete since some business rules can be implemented outside of the boundary of automation and be supported by manual processes or external systems.  Therefore, the BRM discovered from the existing applications must be reconciled with any BRM discovered from documentation and people.

The process of BRM discovery from the three sources mentioned fits naturally into the legacy modernization paradigm known as "Architecture Driven Modernization" (ADM), a discipline that provides a framework for mining data and business logic from existing applications and their abstraction to the level of a BOM.

ADM Horseshoe model

The ADM Horseshoe model provides a holistic view of the approach^[3] and associated methodologies and tools that enable reuse of knowledge hidden in existing application and capturing this knowledge in a BRM.  Knowledge captured in a BRM enables implementation of business model driven solutions that is supported by the following capabilities:

• Understanding of existing business operations.
• Definition of the future business operation.
• BRM management -- BRM at the fingertips of business stakeholders.
• Generation of technical requirements and parts of the solution from the BRM.
• BRM-driven solution management.

ADM works to understand and evolve existing software assets^[4] to implement various modernization scenarios.  Most of these scenarios transform an existing solution into a target one.  These transformations involve:

• Discovering knowledge from the existing solution and abstracting it from implementation details while building an "As-Is" model at a certain level of knowledge abstraction.
  
  
• Incorporating new requirements.
  
  
• Defining a "To-Be" model and developing or generating the target solution. 

The concept of a 'horseshoe' is a metaphor for knowledge transformations in any kind of knowledge reuse process.^[3]  This concept is used in a paper on SOA-enabled workflow modernization^[5] in the context of ADM transformation scenarios.  Figure 1 illustrates the ultimate (or tall) ADM Horseshoe that is crossing IT/business domain boundary and involves knowledge abstraction to the level of the BOM.  It implies that the programmatic data and logic are used as sources for reconstruction of the vocabulary and the rules in the BRM.

Figure 1.  ADM Horseshoe model

Business Rules discovery from existing applications

Business Rules discovery from existing applications is achieved by applying a Knowledge Mining and Abstraction (KMA) Process for Business Rules.  The KMA Process is enabled by the KMA Methodology and KMA Tool Suite integrated with a third party Mining Tool (MT).

KMA Methodology

As shown in Figure 2, the system consists of a traditional client-server three-tier architecture.  End users, the questionnaire provider, and questionnaire reviewers access the documents through a standard browser connected to a web server via encrypted communications.  Questionnaire reviewers are responsible for checking the results of the plausibility tests on the end users' responses.  Various business modules handle the questionnaire contents, import and export data, and generate PDF versions of the questionnaires, for example.  A database stores all the data provided.

The business modules call two external elements:  the rule engine and an anonymizer module, which serves to uniquely identify individuals mentioned in the questionnaire without their names explicitly appearing to the questionnaire reviewers.  Two versions of the system have been developed:  a server-based solution (which runs on Microsoft Internet Information Services (IIS) and which interfaces with an Oracle back-end) and a stand-alone version distributed on a CD-ROM (which runs with a free Microsoft Cassini web server and which uses a Microsoft Access file as a database).

The majority of programmatic elements are implementation-specific and not related to the BOM the application supports.  The KMA Methodology has a mechanism that allows the analyst to skip unnecessary analysis of implementation-specific elements.  That is achieved by associating business significance values with programmatic elements.  Then the programmatic elements that have no assigned or low business significance values are excluded from the review by the analyst.  That allows the analyst to focus on the narrow application view that has higher probability to yield the BRM elements and to ignore the bulk of implementation specific application code.

The KMA Methodology defines the mechanisms for assigning business significance values to programmatic elements and the process for re-creating a BRM that is supported by existing application.  Figure 2 shows the high-level activities involved in KMA Methodology.

Figure 2.  KMA Methodology workflow

Activity 1 -- Plan and Procure analyzes the existing applications and produces the KMA Plan with a defined scope of the applications to be mined.

Activity 2 -- Discover Boundary Elements identifies data elements located on the boundary of the application (user interface fields, data base fields, message payloads, invocation parameters, etc.).  These boundary elements will be used by an analyst to define business terms and possibly some business facts in the initial business vocabulary.  The dynamic analysis of the application usage produces the boundary elements usage statistics that show how frequently these elements are participating in the real life transactions.  These statistics are used to reduce the scope of the KMA process by skipping analysis of the boundary elements that are obsolete and not participating in transactions.

Activity 3 -- Discover Vocabulary from people and documents produces business terms and business facts based on the knowledge discovered from people by interviewing SMEs and from documents by automated analysis of the text in a natural language (e.g., English).  Activity 3 can be performed concurrently with activity 2.

Activity 4 -- Create Initial Business Vocabulary traces the boundary elements discovered in activity 2 to the business terms and business facts identified in activity 3.  If there is no business term to be traced from the boundary element, the new business term may be created by the SME.  This activity produces the initial business vocabulary.  Boundary elements that are traced to the business terms are qualified by SMEs with a perceived business significance value.  Those that are not traced to business terms are discarded -- that will help to control the scope of the KMA process in the following activities.  SMEs may go further and assign business significance values that weight the boundary elements as being useful in creating business terms.

The following is an example of the source code in COBOL representing boundary elements (e.g., the data structure defined in the code is used to input data from a user screen or from a database).

01 PROD-TABLE.
   02 EACHRECORD OCCURS 10 TIMES INDEXED BY CNT1.
       03 PRODUCT_NAME PIC X(10).
       03 QTY_ON_HAND PIC ZZZ9.

The business terms and business facts that can be created based on this code are shown below.

Product, Product Name, and Quantity on Hand are discovered business terms, and
Product has Product Name and Product has Quantity on Hand are discovered business facts.

Activity 5 -- Discover Business Rule Implementations continues with mining existing application for programmatic logic -- business rule implementations that can be used for re-creating business rules in the BRM in activity 6.  Business rule implementations are snippets of the code that represent programmatic logic that may implement a complete, or a portion of a, business rule.

Activity 6 -- Discover Business Rules Model uses business rule implementations to re-create business rules in the BRM.  Business rules are created by an analyst, based on the analysis of one or more business rule implementations using a rules modeling tool.  As a result, more than one business rule implementation may be traceable to a single business rule and more than one business rule can be traced from a business rule implementation.  That reflects the reality where a single business rule may be implemented by different code snippets, residing in different program modules, written in different program languages, and running on different platforms.  On the other hand, the same snippet of the code may implement portions of different rules that have reusable parts.

While the definition of business rules remains a manual process, the KMA Methodology and tools provide the analyst with focused views on the relevant business rule implementations (code snippets) and reduce the analysis time by an order of magnitude.  The business significance values assigned to boundary elements are used to control the scope of the KMA process.  That is achieved by analyzing traceability links between the business rule implementations and boundary elements affected by them (downstream boundary elements) that have business significance values assigned in the activity 4.  These traceability links are provided by a Mining Tool (MT).

The analyst has the ability to define criteria for scope reduction.  For example, scope reduction criteria may be defined as follows:  select a threshold business significance value; include in the further analysis only those business rule implementations that are traceable to downstream boundary elements that meet some defined criterion such as "at least one downstream boundary element has business significance value greater than threshold" or "average of business significance values of downstream boundary elements is greater than threshold."

The following is an example of the source code in COBOL representing a candidate business rule implementation that captures programmatic logic.

SET CNT1 TO 1.
MOVE 0 TO REFILL.
SEARCH EACHRECORD
    AT END MOVE 1 TO REFILL
     WHEN QTY_ON_HAND (CNT1) = 0
END-SEARCH.

The business rule that can be created based on this code is shown below.

If at least one Product has Quantity on Hand equals 0 then the Product Stack must be refilled.

Activities 2-6 are performed iteratively until the complete As-Is BRM satisfying specific project requirements is produced.

Activity 7 -- Manage Business Rules Model continues BRM management.  Specifically, this activity produces a To-Be BRM as well as continuing future refinements of the BRM.

The KMA process re-creates an explicit BRM that is supported by current solutions and makes it available for continued management by business stakeholders.  All future changes to the business operations will be first introduced in the BOM (specifically in the BRM) and then implemented in the supporting IT solution, if required.  That effectively "puts business in the driver seat" by enabling business stakeholders to define and control business operations.

Tools

The KMA Tool Suite that enables discovery of business vocabulary and business rules from existing applications consists of the following components:

• Mining Tool (MT) -- any static code parsing and analysis tool that digests the application source code and produces the export file in OMG Knowledge Discovery Metamodel (KDM)^[6] compliant format.  Examples of MTs include:  Relativity Technologies' RMW, ASG's bequbic, SEEC's Application Manager, and many others.
  
  
• Dynamic Analysis Tool -- any dynamic system analysis tool that intercepts interactions between a user and the application, or between the application and the database, and collects usage frequency statistics for data fields.  An example of a dynamic system analysis tool is OpenConnect's Comprehend.
  
  
• Rules Modeling Tool -- a business rules management tool that is capable of defining business rules in structured natural language (e.g., structured English) and exporting/importing the BRM in SBVR-compliant format.  An example of a rules modeling tool is Unisys' Rules Modeler.
  
  
• Interactive Analyst Environment with traceability repository -- allows analysts to view and leverage boundary elements, business term, fact, and rule implementations discovered by the Mining Tool to recreate business terms, facts, and rules using the Rules Modeling Tool that is embedded into the environment.  The Interactive Analyst Environment also features a repository that stores traceability information between programmatic elements and BRM elements.  That type of traceability is supported by a conceptual package of KDM.  An example of such an environment is Unisys' Knowledge Modeler which Unisys integrates with its Rules Modeler and with some third-party Mining Tools and Dynamic Analysis Tools.

The KMA process is moving the knowledge hidden in applications (while transforming and enriching it) up the knowledge stack towards the pure business knowledge level.  This process crosses IT/Business domain boundaries and cannot be completely automated and necessarily requires human analyst involvement.  The Interactive Analyst Environment allows analysts to access knowledge in both the IT and the business domains.  By providing focused views of discovered knowledge and scope control mechanisms, it enables analysts to increase performance and productivity by an order of magnitude, compared to manual processes that would be necessary to perform the same functions.

Conclusions

Populating a BRM is a labor-intensive process that requires access to multiple sources of knowledge.  One of the most accurate sources of knowledge is existing applications that already implement a significant portion of BRM.  Leveraging this source, therefore, is an absolutely necessary component of the entire BRM building exercise.

The KMA process described in this paper enables an analyst to mine the application knowledge represented by programmatic data and logic and abstract it by dropping all implementation details to the level of pure BOM.  The KMA Methodology and KMA Suite enable KMA Analysts to reduce the time and the cost of this discovery by an order of magnitude compared to manual discovery.  A number of clients' pilot projects in the Public Sector, Travel, and Financial industries have proved the effectiveness of the KMA Process in producing a Business Vocabulary and Business Rules out of documentation and source code in COBOL, RPG, and Natural.

References

[1] Object Management Group.  Semantics of Business Vocabulary and Business Rules Specification.  http://www.omg.org/docs/dtc/06-03-02.pdf  

[2] Ronald G. Ross.  Business Rules Concepts. Getting to the Point of Knowledge. Second Edition.  Business Rules Solution, LLC (September 2005).  

[3] Carnegie Mellon -- Software Engineering Institute.  Reengineering:  The Horseshoe Model. http://www.sei.cmu.edu/reengineering/horseshoe_model.html.  

[4] Object Management Group.  Architecture-Driven Modernization Task Force.  http://adm.omg.org/  

[5] Vitaly Khusidman.  "SOA Enabled Workflow Modernization."  BPTrends (October 2006). http://www.bptrends.com/publicationfiles/
10-06-ART-SOA-Enabledworkflow-Khusidman2.pdf  

[6] Object Management Group.  Knowledge Discovery Metamodel.  http://www.omg.org/docs/ptc/07-03-15.pdf  

# # #