Published in TDAN.com April 2001
The information systems that we are specifying and building today are much more complex in every dimension; human, organizational and technical, than the ones we were constructing just a decade
ago. We in IT are changing our system development methods and adopting new technologies to try to keep up. An approach that is evolving rapidly and achieving success is one that extends current
methods to place more emphasis on business rules. Call it a business rules-extended development method.
It is called a business rules-extended approach because business rules shouldn’t be touted as yet another new paradigm that blows away everything that has come before. What we are talking
about here is an extended role for business rules within our existing development processes. After all, business rules aren’t exactly a newly discovered system artifact. Business rules have
been essential components of every system we have ever built.
What’s Different In A Business Rules-Extended Approach?
In today’s system development approaches, discovering, analyzing and implementing business rules is not formalized. Data analysts do capture some business rules in their data models and often
document other business rules as text annotations. But most business rules are coded into application programs and stored procedures – and lost! The problem is that when management changes business
operations, it is the business rules that they change. Then we have to go business rule diving in the sea of program code to find and change them. This is a primary reason why modifying systems is
so time-consuming and error prone.
We in IT have learned the benefits of separating data from process and managing data as an independent component of systems, both logical and physical, and as an organizational asset. A business
rules-extended development approach does exactly the same thing for business rules.
Business Rule Management and Business Rule Repository
If we are to manage business rules as separate logical and physical system components, then we must have a business rule management function working in each information system project, if not
across the enterprise. Business rule management requires a supporting business rule repository in the same way a data management function needs a data dictionary/repository. So both a business rule
management function and a business rule repository are critical requirements of a business rules-extended approach to system specification and development.
Purpose of the Business Rules Repository
This article examines the requirements for a business rule repository. The purpose of a business rules repository is to support the business rule information needs of all the stakeholders (through
direct involvement or indirect impact) in a business rules-based approach to the initial development of systems and their lifetime enhancement. Specifically, the purpose of a business rules
repository is to provide:
- Support for the rule-related requirements of all business and IT stakeholders
- Query and reporting capability for impact analysis, traceability and business rule reuse including web-based publication
- Security for and the integrity of business rule and rule-related information
To derive the requirements of a business rules repository, we are going to look at the roles and responsibilities of business and IT stakeholders and their needs for rule-related information.
Stakeholders share many requirements in common. The requirements described below are not necessarily repeated role to role, and may not be exhaustive for any one role. They are simply descriptive
the purpose of helping us derive business rule repository requirements to support all the business rule stakeholders.
Stakeholder Requirements
Stakeholder: Business Process Owner
Functional and departmental managers are the ultimate beneficiaries of a business rules-based approach to business system building and enhancement. These managers are responsible for the effective
operation of the business processes within their areas. If business operations need to be modified to take advantage of new opportunities, to respond to external forces or other reasons, it is the
business rules that process owners will be changing. Business rules are management’s leverage point for quick business reaction to opportunities and threats.
Business process owners have a requirement to justify the business need for each rule. Implementing a business rule has personnel and system costs associated with it. Each business rule should
support a business policy the purpose of which is to further accomplishment of the organization’s objectives.
Depending on how your organization partitions oversight for business rules, business process owner may not be the best title for these people. A single business rule can be utilized by many
processes. If you view it from a data perspective, these business owners may represent major subject areas of information. The point is that there is a category of business manager who, responsible
for some zone of activity, is also responsible for or at least has a stake in every business rule that affects his/her activities. We’ll call these people business process owners for
convenience.
These are the business managers who will designate business rule stewards to represent their business rule interests on a day-to-day basis (see below). These managers will also form the steering
committee or executive council to which the business rule stewards will refer major business rule issues or questions that cannot be resolved at the steward level, and would provide direction to
the stewardship function. If you already have a data stewardship process implemented in your organization, business rules stewardship may simply become an extension of that role.
Repository Requirements: Business Process Owners
The following are business process owner requirements.
Functional requirement examples:
- The ability to access the definitions of all business rules currently in effect for business rule evaluation and change
- The ability to trace each business rule to all its related information
Information requirement examples:
Traceability from each business rule to:
- Its business motivation e.g. business policies and business objectives
- All the use cases in which testing the business rule is performed
- All the business processes in which the business rule is tested
Stakeholder: Business Rule Steward
If an organization establishes a business rule stewardship function, each business rule should have an assigned business rule steward. Business rule stewards are business people assigned to the
role by process owners to represent their interests, as described above. Business rule stewards have the responsibility to manage the business value of each rule. The business value of a business
rule means that it delivers a business benefit that justifies the costs of its enforcement and maintenance. More specifically, he/she:
- Ensures that each business rule remains congruent with its source business policies and objectives
- Proposes new versions of business rules and documents the benefits of business rule changes and costs
- Proposes retirement of business rules and documents the reasons
- Ensures that all required business rule definition properties have been documented in the business rule repository including all business processes in which each business rule is in effect
- Ensuring that business rules are uniformly applied across the company
Repository Requirements: Business Rule Stewards
The following are example business rule steward requirements.
Functional requirement examples:
- The ability to create new versions of business rules as part of a business rule change process
- The ability to track the progression of proposed changes through the approval process
Information requirement examples:
- Rule life cycle stages e.g. in effect, proposed new version, retired
- Rule version numbers and dates
- Traceability of each business rule to all the business processes/activities in which the business rule is tested
Stakeholder: Business Analyst
Whether supporting a new system initiative or a requested system change, business analysts will be discovering, analyzing, and documenting the business rules within their project’s scope.
Business and data analysts will be formulating new business rules and enhancements to the business rules currently in effect as well as recommending retirement of some current business rules. If a
change to a business rule is indicated, the analyst must be able to determine the impact of changing the business rule before he/she proposes any modifications.
As analysts begin to elicit and store business rule statements from business experts and other sources, they need to subject them to ongoing analysis as rigorous as we apply to data and data
structures. For instance, we are looking for evidence of duplicate business rules, conflicting business rules, sub-optimum business rules and business rules that are not business rules at all but
system workarounds rooted in legacy systems. The business rule repository should help ensure that a business rule under consideration:
- Is not a duplicate of an existing business rule
- Is not subsumed within an existing business rule
- Does not conflict with an existing business rule
- Its name complies with the business rule naming standard and it is adequately documented
One of the key benefits of a rule-extended development approach is reuse of business rules. We know that many business rules are triggered in more than one business process. Business analysts will
want to ensure consistency of business rule execution process to process.
Note: Depending on the methodology employed, there may be many different deliverables produced in the course of development project. You may also decide to use the business rule repository document
and track other deliverables associated with particular phases of your specific system development approach, particularly if they relate to the business rules. For our purposes, however, we assume
that the key deliverables, or metadata about them, that must go into the business rules repository are
- The rules themselves, and their inter-relationships at different levels of abstraction associated with different perspectives (business process owner, business rule analyst, system designer,
implementer) - Relationships to business motivation, however that is captured (objectives, policy, strategy, etc.)
- Relationships to business events, processes, data or objects
- Relationship to business organization, location, roles
That persist beyond and independent of any project. This applies alike to the discussion of the business analyst, designer and developer requirements.
Repository Requirements: Business Analysts
The following are business analyst requirements.
Functional requirement examples include the ability to:
- Perform business rule change impact analysis (to other rules, process, data, objects, policy, objectives, etc.)
- Research existing business rules for possible business rule reuse
- Perform business rule validation
Information requirement examples:
- Flexible business rule categories with each single business rule linked to one or many categories e.g. business rule type, business result (customer discounts, claim processing), business rule
steward - Traceability of each business rule to modeling artifacts e.g. activities in workflow models and attributes in data models; as relationships associated with organization, location, role and
motivation - Support the entry and inter-relationship of business rules at various levels of abstraction (business ramblings, business rules in business terms, atomic templated business rules, system
implementations of the rule)
Stakeholder: business rule Designer and System Developer
This role includes DBAs, designers, programmers and any other people who participate in crafting the design of the technical solution and in building the system’s implementation artifacts.
Reuse of business rule designs and implementations can improve quality and productivity. One of the rule-related tasks these people will be performing is business rule verification and reuse.
Rule verification ensures that all business rules, as functional requirements, have been included in our design models and that their execution has been adequately tested before implementation.
This rule-related function is designed to assure our business clients that all business rules have been included in systems functions and that their execution has been tested and proven to be
working correctly. For example, we would like to trace every business rule to the test cases designed to prove that its logic has been executed and the results are correctly recorded in the data.
Requirements: Business Rule Designers and System Developers
The following are business rule designer and developer requirements.
Functional requirement examples:
- The ability to perform business rule verification (defined above)
- The ability to research existing business rule design and implementation artifacts for possible reuse
Information requirement examples:
- Traceability to business rules – backward to business requirements and forward to test cases
- Traceability of business rules to design artifacts and to implementations in multiple technologies e.g. business rule engines, procedural code and stored procedures
Stakeholder: System Enhancement Staff
“System enhancement staff” represent a composite of the analysis, design and development roles just described, carried on as a continuing activity. While the organization may be
structured this way, the actual roles, and resulting repository requirements remain the same.
The Business Rule Management Function
To manage its information assets, many organizations have established an Information Resource Management, or Data Administration, function. This function is staffed, has its standards and
procedures and its activities are integrated into the IT information system development and enhancement process. To manage its business rule assets, each organization should establish a similar
business rule Resource Management function.
A business rule Resource Management function can feature several roles, among them business rule stewards. Responsibility for administering business rule repositories falls to what we are calling
the business rule Repository Administrator. The business rule administrator’s responsibilities include overseeing all business rule repository functions to:
- Provide business rule repository access for all qualified business and IT stakeholders
- Protect the quality of business rule information stored in the repository
- Ensure the data integrity and security of business rule information stored in the repository (see the Policies: Security & Integrity section below)
- Generate all business rule reports and documentation
If you establish an enterprise-wide business rule repository, you may also allow each IT project to establish its own separate working business rule repository for use during the life of the
project. In this case, the project leaders would need to assign a project team member as the project’s business rule administrator. The business rule repository would need to support the
ability to “check out” subsets of business rules and their related information, to a project level repository, and to then check them back into the repository later, after they have
been updated or added to. This also means preventing business rules from being checked out for update by more than one project at a time.
Before a new business rule is added into the project repository administrator business rule repository, the project repository administrator, either directly or by collaboration with and oversight
of business analysts, will want to “certify” that the business rule is correctly and completely documented and that it does not conflict with any business rules, data, requirements and
other artifacts already certified in the repository, and that the proper standards are being enforced. This is really an ensuring or verification of the business analysis activities described under
the Business Analyst section. On checking business rules back in to the corporate repository, the corporate business rule administrator would need to perform these same activities at an enterprise
level.
It may also be the case that all business rules defined at the organizational level or by a particular project may not, at the completion of a project, be “promoted” from the project or
business unit level repository to the enterprise repository, for management as a company wide knowledge asset. It may be that some business rules are specific to that particular project or section
of the organization. Management of this promotion process would be a responsibility of the business rule administrator. The business rule repository would need to support management and tracking of
these various statuses of business rules, as well as business rule versioning.
Repository Management Standards, Policies and Procedures
The responsibilities of a Business Rules Resource Management function, regardless of its level in the organization, include establishing the necessary standards, policies and procedures for
carrying out business rule management processes and maintaining the business rule repository. Some of these are listed below:
Standards
- Naming guidelines for business rules, objectives, requirements and other related artifacts
- Templates for standard recording of business rules and instructions for completing each template field
Policies and procedures for ensuring business rule value
- Rule information integrity (single physical repository or distributed)
- Version control
- Repository checkin/checkout
- Access control for security
- Repository backup and recovery
Requirements: Business Rule Repository Administrator
Having reviewed the scope of Business rule Management, we can now say that the following are business rule repository administration requirements.
Functional requirement examples:
- The ability to establish multiple physical business rule repositories
- The ability to maintain consistency among multiple physical repositories using comparison and checkin/checkout procedures
- The ability to test the integrity of business rule information in the repository
- The ability to administer repository access and security procedures and software
- Ability to implement and enforce business rule naming standards in the repository
Information requirement examples:
- A complete metamodel supporting all stakeholder information requirements
- Flexible business rule categories
Rule Repository Functional and Information Requirements
Now that we have established the functional and information requirements of all our business rule stakeholders, both business and IT, we can use them to state some more general requirements that
must be fulfilled by the business rule repository.
Functional Requirements: Business rule Repository
The following are some of the essential functions of a business rule repository.
Repository Integrity-checking
Integrity business rules will be checked during normal repository update activities such as adding new business rules and relating business rules to the data each references. However, not all
rule-related information may be available at the time an update is made. For example, when a business rule is added, all the processes in which it will be tested may not be known.
Integrity-checking programs, aware of the desired relationships among entities, look for missing relationships and report on them. For instance, a query that looks for business rules that are not
related to any business process (orphan business rules) is an example of an integrity-checking activity.
Reporting by “Action Point”
Action points are defined as business rule repository update and integrity-checking activities. For example, updating the status of a business rule from proposed to approved is an update activity.
The orphan business rule query mentioned above is an example of an integrity-checking activity.
Action point reporting notifies stakeholders e.g. business rule stewards, that a business rule repository activity has taken place that impacts business rules within their scope of interest. The
action point report may simply inform a business rule steward that an activity has taken place, or, as in the case of integrity-checking activities, that a problem has been detected that he/she
needs to address.
Queries and Reports
A powerful query capability will be needed to support the rule-related information needs of all stakeholders. There should be standard queries available, such as those that trace business rules to
related artifacts e.g. business processes and data definitions. Also, an easy-to-use ad hoc query tool should be available.
Examples of standard queries include:
- Impact analysis for proposed business rule revisions
- Business rules support what business goals (backward traceability)
- Business rules reference what data elements (forward traceability)
- Listing of business rules by different categories e.g. process where-used and responsible business rule steward
Repository Customization, Extensibility and Integration
From our discussions of stakeholder requirements, we can now say that we would like to be able to tailor our ideal business rule repository so that it can support:
- Standard business rule templates for capturing business rules in our defined, proper structure
- Customizable business rule categories
- Stating the above two points more broadly, we would like the repository to support metamodel, and related functionality, extensibility
- Integration with other repositories such as with a business rule engine repository and any separate requirements management or general metadata repository
Business Rule Documentation
Making business rule information available to all stakeholders can be done using the organization’s intranet web portal. Web publishing offers easy universal access to business rules via a
browser. Also, at the development project level, many of the required deliverables can be derived from the business rule repository.
Information Requirements: Business Rule Repository
The business rule repository’s information requirements can be captured, as is the case with any database, in its metamodel. Each organization’s business rule repository metamodel will
differ from others based on how each decides to adopt a business rules-extended system development approach. The example below shows only a segment of a complete metamodel. It encompasses a
simplified process owner/rule steward view. What we really want here is a metamodel will support all the information requirements we’ve identified for all our stakeholders, and be extensible
and customizable to our needs.
Summary
In this article, we have established some of the functional and information requirements of a business rules repository. These requirements were derived from identifying the stakeholders in a
business rule-extended approach to information system development and enhancement and examining their roles and responsibilities. With this framework of requirements to orient us, it now becomes
possible to discuss what is currently available in the marketplace in terms of business rule repositories and support for business rule management. It is an area that is progressing rapidly. New
tools, and business rule management related functions to existing business rule engines, are appearing. But that is a subject for another time…