creating and using business rules

Creating and Using Business RulesThis topic has not yet been rated - Rate this topic Business rules (or business policies) define and control the structure, operation, and strategy of an organization. Business rules may be formally defined in procedure manuals, contracts, or agreements, or may exist as knowledge or expertise embodied in employees. Business rules are dynamic and subject to change over time, and can be found in all types of applications. Finance and insurance, e-business, transportation, telecommunications, Web-based services, and personalization are just a few of the many business domains that are governed by business rules. Each of these business domains shares the need to convey business strategies, policies, and regulations to information technology (IT) personnel for inclusion into software applications.Traditional procedural and object-oriented programming languages, such as C, C++, and Microsoft Visual Basic, are oriented towards programmers. Even advanced object-oriented languages, such as Java and C#, are still primarily programmers' languages. The traditional software development cycle of design, develop, compile, and test requires substantial time and coordination, and does not enable nonprogrammers to participate in the maintenance of automated business policies. The Business Rules Framework addresses this problem by providing a development environment that allows rapid application creation without the lengthy cycle of traditional application programming. For example, business policies constructed by using this framework can be updated without recompiling and redeploying the associated orchestrations.The Business Rules Framework is tightly integrated with Microsoft BizTalk Server, and developers can use the following features to build and manage business rules:

A high-performance rule engine that implements an inference mechanism to evaluate the business rules.

A rich set of application programming interfaces (APIs) for developing rule-based applications.

A graphical user interface, the Business Rule Composer, which developers, business analysts, and administrators can use in various ways to efficiently develop and apply rules and policies.

A seamless integration with BizTalk orchestrations, which enables you to invoke a business policy or a set of business rules from a BizTalk orchestration.

The Rule Engine Deployment Wizard, which enables you to rapidly import or export business rules or the vocabularies used by the rules, as well as to deploy or undeploy these rules.

The business rules (policy) you create by using the Business Rules Framework can be used in an orchestrated business process, as shown in the following figure.

This section provides conceptual information about how you can leverage the Business Rules Framework and use the tools that BizTalk Server provides to develop business rules.

In This Section Creating Business Rules

Business Rules Framework Security

Programming with Business Rules Framework

Rule Engine Configuration and Tuning Parameters 222222222222222222222222222222222

Policies and Rules – Improving business agility: Part 1: Support for business agilityMaryann Hondo ([email protected]), Senior Technical Staff Member, IBMJerome Boyer ([email protected]), Senior Technical Staff Member, IBMAndy Ritchie ([email protected]), Senior Software Engineer, IBMSummary: One challenge in architecting and implementing agility in business solutions today is that the use of the terms - policy and rule, differs across products. It is not uncommon to find different products defining their own "policy" or "rules" capabilities making these capabilities control the life cycle of business assets defined by the product. When this type of diversity in definition surfaces, it is usually an indication that this capability is an emerging aspect of software development that has not yet formed a "standard" and this can sometime create islands of assets.

In order to communicate the information effectively, we have separated the content into 2

articles; Part 1 deals with terms, abstract concepts and relationships, Part 2 describes techniques for applying the concepts to business problems.View more content in this seriesDate: 16 Mar 2010 Level: Intermediate PDF: A4 and Letter (212KB | 23 pages)Get Adobe® Reader® Also available in: Korean Russian Japanese

Activity: 13499 views Comments: 0 (View | Add comment - Sign in)

Average rating (2 votes)Rate this articleGoalsThe ultimate goal of any architecture is to provide the business with direction on how to achieve the stated business targets, goals and objectives. Once a business driven need for agility had been identified, then using best practices and aligning specific products to meet the business requirements can be achieved and the architects can successfully build a fully automated intelligent solution. The amount of variability around the application and management of policy and rules should be seen as an opportunity to bring tremendous agility to business services but it also requires businesses to establish their own principles of governance for the management of business rules and business policy as first class business assets.The primary goal of part 1 is to present a strawman for a definition of the terms policy and rules and provide a context for evaluating both the relationship between policy and rules and the relationship between business analysts, architects and IT staff. Starting with a brief explanation of the relationship between business policies and business rules helps establish a context to evaluate how policies and rules can be used individually or in combination to implement/enforce business strategies, tactics and industry regulations. The intent is to illustrate how architects can help business and IT achieve specific business goals and objectives that have been defined. To accomplish this goal in the first section of this paper, we propose definitions for the terms and make some assertions regarding the use of the terms and their relationship to one another. This part of the article can be seen to be more abstract, in that its focus is the relationships and representing business agility goals, which by nature are dynamic.Back to topOverviewIn Part 1, the definition of terms is intended to establish a common set of term to use throughout the rest of the material. Having a common definition for what a policy is and what a rule is (whether or not you fully agree with the definition) allows us to then look at relationships between policy types and rule types as well as looking at when each type is appropriate for use.The Motivation section provides an industry standard context (references to OMG work) for our definition of terms. Included in the section is a set of assertions we derived from the references and interpreted for the purpose of this paper. The industry work has broader applicability, and this paper focuses on a section of the work.The Levels of Abstraction section reflects our strategy in the application of those assertions to a set of technical problems. Architecture of business logic is not new, and many of new

requirements for agility are anchored in unachieved objectives from previous attempts. Software development is evolutionary.The Starting Top Down – Business Layer section helps readers recognize that a key aspect of agility is the relationship between elements. To be agile means you want one thing to influence the behavior of another thing. Agility, without guidance can result in unreliability. To achieve business agility in support of better performance means business, architectures and operations are in alignment to achieve a common set of goals. Business analysts define these business directives and business goals.Setting a goal and achieving a goal are different tasks. In the Architecture layer, the key relationship between the business analyst and the architect is highlighted and the challenges of interpreting business goals and crafting an agile architecture is explored.Part 1 concludes with an exploration of another key relationship, the Operational Layer. Any successful business relies on a division of labor. The business directives are interpreted by the architects and maintained by the operations staff. For agility to support the business it is important that the individual pieces can also be seen within a business context --- an operational event may have a business impact. Back to topDefinition of termsWithin this article we use the following definitions of terms:

A general definition of "policy" is that it is a statement of intent or guidance . In computer systems we assert a clarification that a policy is a "course of action selected from alternatives in light of given conditions".

o A "business policy" then, is a type of business directive that expresses the course of action that the business wants to have happen within a set of business conditions.

A "rule" is the exercise of authority and control. o By extension, a business rule is the direct exercise of business control under the

governance model of the business.An illustration of the relationship between policies and rules is that one of more business rules can be derived to implement a business policy. The business directive is implemented by the combination of business policies and rules. In the context of a solution like a business process which is governed by specific business policies, the process is guided by the policy by invoking the appropriate business rules

Figure 1. Policies and Rules as Business Directives

Back to topMotivationIn any business, there will be specific business strategies, business tactics, business goals and business objectives which can be implemented in business applications and these business applications have key business metrics that can be measured at any given point in time. Yet, today it is not uncommon for one business to merge with another similar business or to combine companies, relocate across the globe, which may present a challenge. Each organization might have its own metrics or the business might now be faced with changing industry regulations or new regulations as they expand into a new market. So the new business challenges are not only to meet the business goals of today, but to design strategies that are adaptable to cater to short term or well planned long term change in the business over time.This means that many business software developers need to design business applications with a goal to provide flexibility as well as robustness if these business services are to provide continuity over changing circumstance as well as optimized business performance. The first step in any project includes capturing and establishing a common set of business requirements. Some of these requirements should be expressed as business policy directives. It is important to also capture which requirements may remain relatively constant over time, and which (that are recognized early in the design phase) may require frequent change. Early identification of where change is expected can improve design and implementation of the projects to reduce ongoing future changes and resulting costs.Most governing bodies have a set of policies under which they operate on a daily basis. In a democracy for example, people vote to have a set of laws established and trust that the enforcement of any specific civil policy is done within the parameters of these laws (or rules). An individual civil policy may change as parties or individuals have a term of office and those parties are empowered to choose to apply policies in specific ways, but the laws for enforcement largely remain in place albeit with support from a judicial system. Business agility will require a similar separation of concern and a set of controls to provide checks and balances that the systems are operating as expected within the stated business policies.First, a set of Assertions:

1. A business establishes a set of business guidelines and manages its resources under a business governance lifecycle. In such a business environment establishing good governance includes defining both a set of policies and a set of rules to build in agility.

2. The agility provided by expressing some business requirements as policy expressions can be seen when business conditions are variable and it is possible to define a set of guidelines reflecting a range of business conditions. When these business policies can be identified and governed as the business conditions change, this can in turn make the execution of specific business rules be more agile and adapt to the changes within the policy range.

3. The business policy may have its own lifecycle of change to allow the business to evolve or modify its range of behavior within its existing business process comfort zone based on the monitoring of its capabilities relative to small changes in business conditions. Depending on the maturity of the organization with regard to its use of technology, there are places where automation of the operational processes of the business (aka "IT") through rules evaluation and execution can also provide strong business control.

4. Having complementary technology throughout an organization (i.e. in business applications and "IT processes") can enable the enforcement of business policies in the operational process and this can provide an effective balance for business and IT in the enforcement of required or compliant behavior.

5. The management of a comprehensive strategy for Business Rules and Business Policies should allow for the definition of a range of flexible business assets (enabled by both policies and rules) that can be modified (under the appropriate controls) as the conditions of the business change. Agile control may require separate but coordinated governance lifecycles for business policies and business in a well architected infrastructure will provide many business benefits such as improved business alignment, reduced time to value, reduced amount of change and cost to make changes and more control provided to business users.

6. As companies instantiate business rules and business policies they will face a strong need to standardize their own operational policies (i.e. access control policies) and operational rules (i.e. service level agreements), in order to be able to manage and coordinate the operational assets of rules and policy with the same efficiency as the management of the business assets.

Again, having a consistent approach to business and operational assets for policy and rules management will allow a business to change business assets and be able to report on the operational enforcement of that change back to the business. Different technologies can be involved on the IT side or the business side to support the specified business constraints and goals since they work at different levels of detail, but the end goal is the coordinated management of the operational assets in support of the business requirements for the specified project or business strategy and tactics.Back to topLevels of abstraction in policies and rulesAfter years of experience in working with a broad range of customers who want to automate their business operation, patterns have emerged that reflect a decomposition of the realities of making business work. Any business has things it wants to accomplish (its goals and objectives), and any business needs to express policies about how the assets of the business are managed in the achievement of those goals and objectives. How well the business achieves its goals and objectives can be measured in different ways, including capturing data as audit policies, Business measures (metrics) or Key Performance Indicators (KPI’s). Since business people want to and need to be business people and not computer geeks we need to acknowledge another axis in the

matrix of control. We assert there are 3 general levels at which controls are captured and governed -- the business layer, the architectural layer and the operational layer.The role of Architects (who are responsible for the integrity of the overall business architecture) often includes mapping or translating the business goals, to the current set of hardware and software assets [the architectural layer] that instantiate the business process and business services. Architects also work closely with a broad group of IT subject matter experts to specify how to make a set of hardware and software run efficiently and effectively in a managed environment [the operational layer]. The architecture needs to cover a range of directives from security, access control, and service level agreements to Business workflow, event processing, and information management and business rules.

Figure 2. Different types of Business Directives, Policies with Goals & Objectives

Working with customers we have found that using these 3 levels of abstraction can be useful for all parties to focus a general discussion of an agility problem into a more concrete discussion of a solution by acknowledging that any solution might include different requirements from multiple perspectives. Knowing that something is a business layer concern (i.e. the expression of a high level need to protect the assets of the business) can help you focus on specifying requirements and harvesting assets for an appropriate solution (i.e. developing a business dashboard as opposed to creating a binary representation of every asset in the raised floor space) since the tooling and reporting mechanisms may vary for any given solution. It is important, therefore to always keep in mind the business goals and objectives of the agility problem.Back to topStarting top down - Business layerBusiness Directives and Goals

Once an organization decides to automate its business processes, the first step is to capture the business requirements as a set of business directives. Business directives include a set of goals to implement and a set of business metrics to measure results against the goals. There are different methodologies used to represent this, but the OMG has defined some models and techniques that we have interpreted and applied in decomposing this common set of elements needed generally by business when looking to solutions for business policy and business rules. For full detail see the OMG Business Motivation Model documents [reference http://www.omg.org/spec/BMM/1.0/ since we reference them here as a way of illustrating that there are common paths to capturing and expressing business goals and objectives].Business Directives, Business Policy and Business RulesAt a conceptual level, the OMG "Business Motivation Model" (BMM) provides a way to explore the relationship between rules and polices in the context of a larger conceptual framework of how businesses are organized and make decisions. In this way it reflects some of the principles of Governance.

In the BMM model, there is an attempt to understand; "the aspiration of the business (its Vision), its action plans (its Mission), the refinement of the Vision into Goals and Objectives, the identification of Strategies to achieve the Goals and the identification of Tactics for achieving the Objectives".

Directives might consist of some combination of Business policies and business rules and the OMG documents compare and contrast the two which we summarize as follows:

Business Policies o Are managed under the control of the business.o A business policy governs a business process.o Business policies can be expressed with natural language which can be

ambiguous.o Given the ambiguity of natural language, business policies are often not directly

actionable and need interpretation to be enforced. Business Rules

o Are managed under the control of the business.o A business rule executes an action of a business process.o Business rules are expressed without ambiguity, in terms of a standard business

vocabulary (SBVR)o Business rules (because they are defined in terms of a specific SBVR) are directly

actionable since they reflect specific business actions and assets with specific agreed to definitions and actions.

Starting to identify all the business elements (rules and policies) can be difficult. Good methodologies address the fact that there will most likely be iterative attempts at implementing the policies and rules in a project as most policies and rules change over time. The figure below is a rough canonical form of such a methodology, illustrating that answers to specific questions may produce a refinement of previously specified elements and that it is important to ensure that the rules and policies defined also have associated metrics by which their success can be measured.

Figure 3. Lifecycle of Business Directives

It is natural for any group starting this task, to try to express some behaviors as business rules and some as business policies. Starting at either place does not preclude a revisiting or refining the concepts as more details are revealed. In the exercise of identifying business directives it is important to identify assets for consumption and use by business analysts and business architects. Some questions to ask might include; how do business analysts expect to monitor policies? How do business architects plan to provide this monitoring capability? Do business analysts expect to author their own business rules? Understanding these expectations gives architects an opportunity to evaluate and select the approach that best supports the business (business policy or business rule or some combination).A simple example of application of this technique corresponds to general business guidelines like Anti-Money Laundering (AML) legislation. When this legislation was introduced, businesses in the financial sector were already functioning. They had no option but to update their overall strategy to align with this new legislation and in many cases this meant adding new business processes, business policies and business rules to implement and enforce the AML legislation. It often included adding new business objectives and metrics for auditing or refocusing the current audit practices to be applied across the business. A general business directive around anti money laundering (AML) can state something as general as: the financial institution should not accept payments that expose it and its producers to possible criminal fines and penalties.

If we want to try to look at how to deconstruct a set of concrete business policies and business rules from this example directive from AML, then we note from the beginning it is possible to express the business directive as a business policy or a business rule but it is most naturally expressed as a set of business policies. Business policies supporting this directive may look like "Agents and employees should always know the source of client funds used to pay premiums." Or "the Bank will not accept routine payments by cashier’s checks, money orders, bank drafts and traveler’s checks for $10,000 or above."Another example of a general business directive that might be taken from a typical credit practice by a business analyst might include a general statement (a business directive) like "our company will not sell anything to a customer with bad credit".Each LOB might interpret this to be something more specific, and if there were a common service that provided a common credit rating, the policy might be refined:

Listing 1. Credit directive expressed as a business policy

Business Policy: XYZ will not sell anything to a customer whose account has been determined to have a bad credit rating

In any of these activities, it is important to recognize that the effectiveness of the business Policy will depend on its precision and wherever possible business policies should express requirements according to a business vocabulary (i.e. the analyst knows what subset of assets this particular business controls and does not always list every individual item). The granularity of the business control is reflected in its business vocabulary since it is only possible to collect metrics and enforce business policies when the guidance correlates to specific business assets. A business policy might state a restriction, "do not sell" to "customers" with a "bad credit rating" but if a business cannot discriminate between requests from customers with a good credit rating and customers with a bad credit rating, the policy might be nice on paper, but it will not be effective in practice.For those cases where a good business vocabulary exists, business analysts and architects may opt to be even more specific and use a rule expression to capture the directive, rather than having to express the semantics of the business policy in natural language (i.e. "do not sell to customers with a bad credit rating") which would then need to be interpreted by a business process. In the figure below, we can see that a rule can express the semantics of the policy i.e., "bad credit rating" when the business vocabulary indicates that "bad credit rating" is implemented as the equivalent of a calculation within a "credit report" in which "bad" means a ranking below 500. The Business rules derived from the business policy above may be expressed as:

Listing 2. Credit directive expressed as a rule within a business vocabulary

When one of the credit reports has a rating below 500, mark the borrower as blacklisted.

If a customer is black listed then refuse the business and warn the customer with an

explanation message.

On the other hand, a business application that is able to interpret a business policy can be more than adequate. Business Policy or Business Rule? It’s a business decision, based on business value, informed by goals for agility and business capability. The differentiation of rules and policies based on a particular directive being “actionable” (derived from the OMG definition) is an illustration of where and why ambiguity exists today between policy and rules concepts at a business level, and it also illustrates why the harvesting of business directives is an important activity. If you accept our assertion, that the two concepts (policies and rules) are peers at the business level and that they both are required in many business solutions, then we can start to use the presence and range of a standard business vocabulary to help us select the right approach. Assuming we have harvested a set of business directives from business analysts, the next step is to evaluate how to architect a solution that reflects the directives and accomplishes the business goals.Back to topBusiness goals, objectives and resultsAt a conceptual level, the OMG "Business Motivation Model" (BMM) also provides a structure to capture and track business results corresponding to business directives. The BMM acknowledges that where business directives are going to be implemented there can also be different strategies for tracking business results.If business policies are the vehicle for business directives, then having some confirmation of the results of the enforcement is key to ensure the directive is effective and aligns to the business goals and objectives. Policy enforcement engines can record audit trails or implement event mechanisms to notify the business of the results of the enforcement. If business rules are implemented via a BRMS, audit trails or event mechanisms can notify the business of the results of the rules execution.Business results or metrics can be defined to be qualitative or quantitative.

Business Goals are defined to be a statement of the expected state or condition of the business if the Business Directives take effect as expected. These business goals are normally defined in a qualitative manner and have an extended period of having this change take place.

o Business Goal – Transition all systems to use the new AML process over the next year.

o Business Goal - Ensure that personally identifiable information is protected. Business Objectives are defined to be a detailed measure of performance at specific

checkpoints to achieve the business directive. These are normally quantitative and very specific about timescales in which they should be achieved. Often these can be defined as Key Performance Indicators (KPI) or Critical Success Factors (CSF).

o Business Objective – In the first month of using the new AML process is expected that 10,000 AML checks will have been done. A specific KPI could be defined to measure the AML checks done on a monthly basis and what percentages identified a problem to be investigated.

o In enforcing PCI compliance - Ensure that due diligence is ensured through tracking of failed login attempts and identifying what is the normal amount and what constitutes a system under attack.

Back to topArchitecture layerAt the architecture level, the architects focus on the "how". Understanding the control capability of the existing architecture is important in determining if the harvested directives can be implemented as rules (as executable elements) and where harvested directives can be expressed as architectural policies.Working from the example above, an architect might assess that a business directive (i.e. for AML) should be applied to "tellers". It is implied by the directive, that there is a business role within the bank called "teller" and that people perform that role. Providing agility for business processes means that within the architecture there is recognition of which human tasks are and which are automated tasks. As part of architecture there might be a definition of a "teller" task, but with the new directive the role might need to change. The tasks might change from human tasks to an automated workflow, for example. At the architectural level, it is important to look at each directive and decide based on a number of criteria whether or not to express this as a policy and how to express this as a policy that can be enforced. Architects might recognize that identifying who is a "teller" from a business perspective might require not only a new related business policy (about how to identify who is a teller to the business), but we may also need to have this business role definition included in the operational elements of user provisioning where user management components establish the corresponding operational access control policy (i.e., tellers have access to the banking transaction). Setting up operational security policies like the teller policy is not unique and different governance models within the business might be required to ensure that people are identified in different ways when accessing any type of data hosted on any business asset (the business policy).A broad business directive is important to harvest and the architects will need to assist the business in refining the directive to ensure there exists architectural support for a combination of rules and policies across the sub-domains of the business process, as well as in the sub-domains of the operational process (i.e. access control, user identification, password management) to fully implement the solution. A different loan underwriting directive might be supported at the architecture level by defining a new common architectural service that is capable of providing credit scores. The use of Business Rule Management System technology can be essential to support harvesting and reuse of common executable elements. Depending on the granularity of the Business vocabulary, the rule might be a specific calculation or it might be an expression of the conditions for accepting or rejecting a loan or defining the terms and conditions of the loan. This distinction is one of the tasks for architects as they make the Business Goals and Objectives more concrete. It is important to remember that there is still a need to trace back to the business directive and business policy when these architectural choices are made. The architects define what metrics will be possible to collect and where they can be correlated to ensure that the operational elements at runtime produce the corresponding business data for the business consumer.The maturity of the organization (relative to its use of digital assets/resources, to automate and optimize its business processes) will always impact the extent to which any given business policy can be communicated or enforced. The business target or actor with regard to enforcement of

business policy is also important to capture even if a service is fully automated. In some cases, the "business policy" may still need to be something to read (i.e. a privacy disclaimer on a web page). There are technology choices when implementing business policy enforcement and business directives that require consent, may need to be encoded as an action (i.e. the user of a business travel application is asked if they are adhering to business travel policy). Alternatively, for optimization and consistency across organizations, it may be a requirement that enforcement be an automatic part of the middleware in which case the method of enforcement may not be visible to end users, nor is it required to be (i.e. a rule might enforce a security policy for message encryption on all outgoing messages without the end user having to initiate the encryption).The diversity of options is why it is important to see policy and rules as part of an ecosystem for agility in which the over arching business requirement is to harvest the directives and provide traceability of business policy enforcement. Whether orchestrating human tasks in a workflow (i.e. BPEL for People) or automating business processes in BPM suites, a business policy enforcement strategy is enhanced by use of rules engines and policy management. Once a set of business directives have been harvested, and business requirements for agility have been captured, the architectural level is responsible for harvesting the choices for implementations. There is no one size fits all and business analysts, architects and IT staff must make a collective decision based on business value and cost.As an illustration of these principles, let’s consider the previous business directive but now from the perspective of the architectural layer.An example of a directive around anti money laundering (AML) can state: the financial institution should not accept payments that expose it and its producers to possible criminal fines and penalties.

The business directive is for the business to protect itself, so that the business is not accused of impropriety as it executes its business applications. The high level business requirement necessary to achieve a business directive like "financial institution should not accept payments that can expose it to criminal fine" could be manifested in several ways. In the past it was common to find a "human" instantiation of the "the financial institution" -- i.e., the training of the staff of the financial institution included communicating to each line of business a set of warnings on what is appropriate business conduct regarding accepting or making payments to third parties. In today’s businesses, staff training is still the first line of defense. But when you have bank clerks on 3 continents, it may not be practical to assume that such a policy is enforced manually. Even though you have partitioned the roles so that clerks (for example) are not supporting all transactions and even though there may be visibility into the accounts by other bank employees (supervisors reviewing the account transactions) an automated system for evaluating exchanges (e.g. wire and other inter-bank transactions) may be required to be in compliance with the directive.A more efficient way to achieve the goal in a financial institution that is "tech savvy" is to have the architect, capture these business requirements and design automated business and technical services to guide and control the behavior of the staff. The architecture would definite rules to evaluate and flag any risky criminal payment through the use of automated analysis of records and transactions. The new architecture would include a new management approval action

triggered on specified transactions that are dynamically marked "at risk" as part of a business manager workflow. Architects have a challenging task. What architectural constructs can aid the solution architect?Architects can begin the business directive refinement process by leveraging the classification and sub-classifications defined in the business rule ecosystem. Two commonly used subtypes are: Structural types and Behavioral or Operational types.

Figure 4. Business Directives – Business Rules Sub-Types

We start with structural rule types, because these rules reflect specific items within a business data domain and these roughly reflect the business scope. An example of a structural rule might be "A customer must be resident in the country in order to open a new account" or "It is necessary that each rental has exactly one requested car group." or "a Bank account is attached to one Customer only." These structural rule types impact the creation of business assets or business artifacts that are then represented in a business process or business model. Once there are structural assets, a behavioral business rule type usually reflects some action that is enforceable and it often relates to characteristics of a specific implementation of a business process or business model. It is not a surprise that there are choices here. A behavioral (sometime also named operative) rule can be further decomposed to support different patterns of implementation depending on the granularity of the process implementation. In the figure below we identify some examples of behavioral rules based on our experience with a variety of customer implementations.

Figure 5. Behavioral Rules Sub-decomposition

In any rule decomposition exercise it’s important to look for patterns. These are two common characteristics of behavioral business rules -- those that express constraints, or those that express guidelines. Constraints are things that are a necessity, things that must be done. A constraint can explicitly use the word "MUST HAVE", or it might be more implicit like "it is necessary that," (and usually need to be "enforced"). Guidelines warn about an undesirable circumstance (and are often translated to warning messages). A Process Flow subtype is generally the subtype used to express the parameters or metadata for the flow. Routing rules are an example of how a business process can direct the execution of steps and the order of activities. In some environments, it may be helpful to distinguish process flow rules from business logic rules that determine the values of the parameters on which the process flow is directed.Decisions are a subtype in which new information is created from existing data based on mathematical equations. ECA, Event Condition Action is a specific pattern of a rule where the condition is evaluated once the occurrence of an event is found. Most ECA rules use temporal operators to search events related to their timestamp of creation or occurrence. A rule statement like "Filter events of a given symbol name within the last x seconds, and aggregate the computed value = price * volume metric" would need a specific rule expression, and the rule engine at runtime would need a sliding time window statefull mechanism to support execution of the expression. Capturing the semantic of temporal conditions is a very important task of the rule analyst during the analysis phase.Action enabler is a sub type which initiates another action in the system. An example would be the rule execution triggering a business process, which asynchronously calls a service. This type represents a business user point of view in that the focus is on the rule triggering a business process, such as an escalation, an audit, an assessment process.Inference is a subtype that often reflects an advance agile methodology. The assumption is that the behavioral rule content may influence the evaluation in which the rule is processed. It

generates or updates data elements and these new conditions may force re-evaluation of the rules.It is important to note that the temporal operator as described in ECA rule is a more general concept that can apply to conditions within the other sub types of rule. There is no rule type to support temporal constraints. For example in a process flow it is possible to define timer condition which when fired execute a given task within the process. A condition statement like: "a card transaction issued by a gas station merchant followed by a card transaction on the same card from the same merchant within two hours may be a fraud". This condition can apply in an inference rule, as a Fraud is created or in a stream processing statement if the transaction event is part of a stream. Much of this practice is just good architectural design. The part that involves policy and rules is deciding whether or not the controls can be static or whether some of the characteristics change over time or some other business variable. For example, a key point of variability in Banking is geography. Different rules and policies apply in different countries, in addition to international rules for banking.

Common requests business people are expecting from their IT architecture:Adaptability – Measure the ability to change the business logic easily. The motivation can be due to short deadline constraint, or frequent small changes or important change that may occur every week, month or quarter. Traceability – Represents the need to clearly implement the business logic as what was agreed upon the business unit and the IT team, in a way that every party understands the logic. This is leading to express the logic in natural or close to natural language. Auditability – Represents the ability to trace from the business motivation to the execution of the policy to better understand what the logic behind a decision. Reusability – Need to share business logic across processes or applications and stay consistent across applications/transactions.Manageability - This variable addresses the life cycle management of the business logic. Who writes what, and when, and all the questions related to maintenance and evolutions of the rule-based service.Back to topOperational layerFigure 3 illustrates that there is a lifecycle between the architectural and the operational layer in addition to the lifecycle between the business layer and the architectural layer. All parties must be aware there is frequently another iteration required to refine business directives to an operational scope. We also assert that Information Technology (IT) is a business function and often an operational environment will have its own business policy constraints expressed within which architecture must adapt. The stated business directives harvested in the examples above might be seen to reflect a Line of Business or aggregate LOB perspective. There are other businesses directives that a Chief Security Officer or a Chief Information Officer might need to express and control. For example, architects defining a solution need to be aware of the existence of and granularity of runtime or operational policy decision points (PDP’s ) or policy enforcement points (PEP's) in order to design a solution that matches the range of control offered by operational policy management. If the policies expressed by the architects (via a Policy Authoring Point) can not be enforced by the current operational environment, the architects need to work with IT to make this

new directive operational. Organizations often delegate to IT the responsibility to chose where and how to operationalize cross LOB policies for consistency and optimization. A common example is a message security policy, which often needs to be enforced consistently and at a specific point in operational infrastructure, i.e. the DMZ. Operational policy constraints are often impacted by the type of appliance doing the policy enforcement or by the overall network protection directives.The business directives delegated to IT are expected to ensure that any given policy enforcement in the DMZ is enforcing business directives originally expressed by a business policy although the techniques used to meet this goal may be achieved in many ways including the use of rules. Therefore Figure 3 captures that the process of refining policies and rules INCLUDES the “round tripping” of operational measurements to provide the business with the correlation of operational and business metrics. Rules technology can be consumed by IT as well as LOB applications and when good practices of architecture and reuse are put in place, the architects can build a common structure that serves both sets of requirements.An example of the importance of the refinement of policy and rules enforcement in the overall lifecycle comes into play when we look at each level of abstraction and business directives for something traditionally seen as "operational security" i.e. Access Control. At the highest conceptual level, every business needs a policy for who can access what, but no CEO is going to author that policy down to the granularity of individual employees and the records they can access (unless there are less then 10 employees). Most LOB’s have their own "policy" for access to the resources they own. To optimize the management of access control, an IT organization might have a policy enforcement point or set of enforcement points. When building a cross LOB operational policy enforcement mechanism, the architects responsible for Information Technology infrastructure might recommend the use of a rules engine within a policy enforcement strategy to determine which policy to apply to any given transaction within a LOB or across LOB’s (i.e. federation of services). Rules engines are often used to implement and enforce policy "decisions" in an operational runtime environment.An illustration of an operational policy enforcement architectural style for managing security policy is shown in the figure below.

Figure 6. Operational Policy Enforcement

A second example is where an architect may decide there is a business need for a shared architectural Policy decision point where business application decisions can be managed, shared and re-used across multiple processes or even multiple applications. At the operational level this policy decision point may include multiple business rules which are authored and combined together to implement the required decisions to meet the business policy directives.To extend our interpretation of the BMM principles, the capturing of business directives (according to the BMM above) also includes capturing Threats and Opportunities as well as capturing Strategies and Tactics (typically architectural concerns).Within the various definitions of architectural strategies, policies and rules may be refined in each architectural style and be applied to each of these areas (Business Policies, Threats and Opportunities, Strategies and Tactics). Knowing that there are variations highlights the value of a disciplined exchange (sometimes called governance) that must occur between the business, the architects and the operational staff to put in place a methodology to guide the definition of any specific Course of Action. A good governance practice will be needed to provide the

accountability for the specific business problem including how to move from a business conceptual model to a more concrete definition of architectures and operations. The reason to target architects with this responsibility is that an evaluation needs to be performed in the context of different architectural styles ( i.e. SOA) and must consider best practices for applying rule implementations ( e.g. in service design, in service selection, in service orchestration) and policy enforcement mechanisms. Architectural styles also have their own best practices for things like utilizing Business Process Management Suites to address business process efficiency issues (i.e. by identifying up front "who is involved?", "when they should be involved?" "What do they need to do?"). BPM suites can also support human and automated actors. At a glance the business logic to implement in BPM is linked to people, task, and data to process within a task. When deciding what people are able to perform which task, most organizations group people into functional "roles" so the architects must work with both the business owners of the role definitions and the operational owners of the user provisioning tasks. Often the criteria by which a person performs a task is related to which roles they are assigned, and most organizations express these as business policies including the temporary assignment of a role to an individual (i.e. vacation) or allowing one person to give a task to another person to perform (i.e. delegation). A Business Rules Management System can complement BPM by adding the ‘why’ to a BPM task, why it behaves a certain way, why the decision is done. Architects can encourage business analysts to use a BRMS help to support the variability of the rules, by using predefined structures to help define the business agility factors in a structured form (i.e. If then else statement or decision table, rule flow, decision tree, function, rule template) to leverage simple deployment patterns, inference, or pattern matching within a set of business processes.Back to topConclusionUsing Policies and Rules to enforce Business Strategies and tactics to achieve and monitor business goals has multiple advantages improving your business in terms of cost reduction, and the ability to meet short term changes as well as long term changes. Doing more with the same budget and adding greater empowerment of business users to do more is a very positive step for aligning IT and Business. The key points are:

Business, Architectural and Operational Policy are all important and are all required to work in unison especially in the larger solutions

Business Policies and Rules are peer entities which can be derived and used together to implement Business Policy Directives

Expected Business Results can be defined by the Business team using Business goals and more detailed Business Objectives to measure performance against the Business directives

Projects which take a top down approach, decompose policy directives into detailed policies and rules. The benefits of doing this are that it can improve traceability of how more detailed policies and rules align with higher level business directives and goals across multiple different operational systems which must work unison

ResourcesLearn

Business Objectives are defined to be a detailed measure of performance at specific checkpoints to achieve the business directive.

Business Goals are defined to be a statement of the expected state or condition of the business if the Business Directives take effect as expected.

Learn more about business directive.

In the SOA and Web services area on developerWorks, get the resources you need to advance your skills.

Browse the technology bookstore for books on these and other technical topics.

Get products and technologies Download IBM product evaluation versions or explore the online trials in the IBM SOA

Sandbox and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.

Discuss Check out developerWorks blogs and get involved in the developerWorks community.

About the authorsMaryann Hondo is a Senior Technical Staff Member in the WebSphere Technical Institute at IBM working with WebSphere DataPower Appliances, SOA architectures, SOA policy and SOA security. Maryann previously worked in IBM’s Enterprise services organization with SOA enablement focusing on security services. Maryann is a co-author of the WS-Security, WS-Trust, WS-SecureConversation, WS-Policy and WS-Federation specifications produced by IBM and other business partners under the Web Services Security Roadmap.Jerome Boyer is the IBM Expert on Enterprise Business Rule Management Systems in BPM, SOA and Complex Event Processing deployments. As an STSM, Jerome assumes a leadership role within IBM Software Services for WebSphere (ISSW), as the lead ILOG BRMS Architect. With more than 20 years of experience in directing, managing and developing large-scale, enterprise-wide IT solutions: Telecom, Finance, Insurance, e-business market. He is deeply involved in the technical and architecture assessments for most ILOG engagements around business rules deployment. Jerome is also author of the ISIS methodology which aims gathering best practices on how to implement BRMS.Andy Ritchie is a Senior Software engineer in IBM focussed on BPM, Master Data Management (MDM) and Application Integration solutions integrating with Business Rules Management Systems (BRMS). He is a Development Architect who often works with IBM services and technical sales teams on solutions and methodologies. With more than 24 years in IBM he has a broad and varied experience, from architecting IBM SOA Middleware, solutions in multiple industries around SAP applications with a specific focus on BPM and SOA Service Governance areas where Policy and Rules are important. , Previously he spent an 18 year period in IBM Development on ISDN, X.25 communications and Speech products.2222222222222222222222

Business Rules Framework Architecture1 out of 1 rated this helpful - Rate this topic The following figure shows the component architecture of the Business Rules Framework.

Some of the components of the framework are described in the following paragraphs.

Policy ClassA Policy object is a single instance of a business policy, and provides the interface that is used by rule-based applications. It provides an abstraction that frees the application developer from concern about the location of the rule store, extracting rule sets from the rule store, instantiating instances of the underlying rule engine, and ensuring that long-term facts are asserted into the engine. In many scenarios, a rule-based application uses concurrent instances of the Policy object. These concurrent instances can represent the same policy, different versions of the same policy, or different versions of different policies.

RuleEngine ClassThe RuleEngine object serves as the execution engine for business policies. It uses three plug-in components (translator, inference engine, and tracking interceptor) for implementation. A RuleEngine object takes a RuleSet object representing a business policy as input and uses the

translator, inference engine, and tracking interceptor configured for the rule set to implement the business policy defined by the rule set.

Fact RetrieverA fact retriever is an optional, user-defined, plug-in component that is responsible for gathering long-term facts for use by business policies. For more information, see How to Create a Fact Retriever. Before execution, a Policy object instance provides its RuleEngine instance to the fact retriever, giving it the opportunity to update the set of facts in the rule engine's working memory. For more information, see Short-Term Facts vs. Long-Term Facts.

Rule Engine Update ServiceThe Rule Engine Update service provides dynamic business policy updates in a distributed environment. An autostart Microsoft Windows NT service application is responsible for subscribing to policy deployment and undeployment events that occur when business policies are changed. In a typical enterprise scenario, business policies are deployed after being updated, tested, and versioned. Deployment consists of adding the updated policy to a secure, persistent rule store and optionally executing logic on the store to publish information about the updated policy to all interested parties (note that information about the policy is published and not the policy itself). The Rule Engine Update service, running on a server hosting rule-based applications, receives the policy update notification and caches the information for subsequent use. The use of a pub/sub model for policy updates enables you to change business policies in near real time without service downtime or interruption.

Policy/Vocabulary Authoring ToolsThe Business Rule Composer in Microsoft BizTalk Server provides policy and vocabulary authoring capabilities to both end users and developers.

Rule StoreA rule store is a repository for business policies and vocabularies. The repository can be a simple file or a secure, scalable, persistent, and reliable database such as Microsoft SQL Server. (SQL Server is used as the default rule store for the framework).

CachingThe Business Rules Engine Framework provides a caching mechanism for RuleEngine instances. Each RuleEngine instance contains an in-memory representation of a specific policy version. The following steps describe the process when a new Policy instance is instantiated (either with a call on the API or execution of the Call Rules shape):

1. The Policy object requests a RuleEngine instance from the rule engine cache.

2. If a RuleEngine instance for the policy version exists in the cache, the RuleEngine instance is returned to the Policy object. If a RuleEngine instance is not available, the cache creates a new instance. When a RuleEngine instance is instantiated, it does, in turn, create a new fact retriever instance if one is configured for the policy version.

When the Execute method is called on the Policy object, the following steps occur: 1. The Policy object calls the UpdateFactsmethod on the fact retriever instance if a fact

retriever exists. The fact retriever's implementation of the method may assert long term facts into the working memory of the RuleEngine.

2. The Policy object asserts the short term facts contained in the Array that was passed in the Execute call.

3. The Policy object calls Execute on the RuleEngine.

4. The RuleEngine completes execution and returns control to the Policyobject.

5. ThePolicyobject retracts the short term facts from the RuleEngine. The long term facts asserted by the fact retriever will remain in the working memory of the rule engine.

After the Dispose method is called on the Policy object, the RuleEngine instance is released back to the rule engine cache.The rule engine cache will have multiple rule engine instances for a given policy version if the load requires it, and each rule engine instance has its own fact retriever instance.

See Also 33333333333333333333333

Policies and Rules – Improving business agility: Part 1: Support for business agilityMaryann Hondo ([email protected]), Senior Technical Staff Member, IBMJerome Boyer ([email protected]), Senior Technical Staff Member, IBMAndy Ritchie ([email protected]), Senior Software Engineer, IBMSummary: One challenge in architecting and implementing agility in business solutions today is that the use of the terms - policy and rule, differs across products. It is not uncommon to find different products defining their own "policy" or "rules" capabilities making these capabilities control the life cycle of business assets defined by the product. When this type of diversity in definition surfaces, it is usually an indication that this capability is an emerging aspect of software development that has not yet formed a "standard" and this can sometime create islands of assets.

In order to communicate the information effectively, we have separated the content into 2 articles; Part 1 deals with terms, abstract concepts and relationships, Part 2 describes techniques for applying the concepts to business problems.View more content in this seriesDate: 16 Mar 2010 Level: Intermediate PDF: A4 and Letter (212KB | 23 pages)Get Adobe® Reader® Also available in: Korean Russian Japanese

Activity: 13499 views Comments: 0 (View | Add comment - Sign in)

Average rating (2 votes)Rate this articleGoalsThe ultimate goal of any architecture is to provide the business with direction on how to achieve the stated business targets, goals and objectives. Once a business driven need for agility had been identified, then using best practices and aligning specific products to meet the business requirements can be achieved and the architects can successfully build a fully automated intelligent solution. The amount of variability around the application and management of policy and rules should be seen as an opportunity to bring tremendous agility to business services but it also requires businesses to establish their own principles of governance for the management of business rules and business policy as first class business assets.The primary goal of part 1 is to present a strawman for a definition of the terms policy and rules and provide a context for evaluating both the relationship between policy and rules and the relationship between business analysts, architects and IT staff. Starting with a brief explanation of the relationship between business policies and business rules helps establish a context to evaluate how policies and rules can be used individually or in combination to implement/enforce business strategies, tactics and industry regulations. The intent is to illustrate how architects can help business and IT achieve specific business goals and objectives that have been defined. To accomplish this goal in the first section of this paper, we propose definitions for the terms and make some assertions regarding the use of the terms and their relationship to one another. This part of the article can be seen to be more abstract, in that its focus is the relationships and representing business agility goals, which by nature are dynamic.Back to topOverviewIn Part 1, the definition of terms is intended to establish a common set of term to use throughout the rest of the material. Having a common definition for what a policy is and what a rule is (whether or not you fully agree with the definition) allows us to then look at relationships between policy types and rule types as well as looking at when each type is appropriate for use.The Motivation section provides an industry standard context (references to OMG work) for our definition of terms. Included in the section is a set of assertions we derived from the references and interpreted for the purpose of this paper. The industry work has broader applicability, and this paper focuses on a section of the work.The Levels of Abstraction section reflects our strategy in the application of those assertions to a set of technical problems. Architecture of business logic is not new, and many of new requirements for agility are anchored in unachieved objectives from previous attempts. Software development is evolutionary.The Starting Top Down – Business Layer section helps readers recognize that a key aspect of agility is the relationship between elements. To be agile means you want one thing to influence the behavior of another thing. Agility, without guidance can result in unreliability. To achieve business agility in support of better performance means business, architectures and operations

are in alignment to achieve a common set of goals. Business analysts define these business directives and business goals.Setting a goal and achieving a goal are different tasks. In the Architecture layer, the key relationship between the business analyst and the architect is highlighted and the challenges of interpreting business goals and crafting an agile architecture is explored.Part 1 concludes with an exploration of another key relationship, the Operational Layer. Any successful business relies on a division of labor. The business directives are interpreted by the architects and maintained by the operations staff. For agility to support the business it is important that the individual pieces can also be seen within a business context --- an operational event may have a business impact. Back to topDefinition of termsWithin this article we use the following definitions of terms:

A general definition of "policy" is that it is a statement of intent or guidance . In computer systems we assert a clarification that a policy is a "course of action selected from alternatives in light of given conditions".

o A "business policy" then, is a type of business directive that expresses the course of action that the business wants to have happen within a set of business conditions.

A "rule" is the exercise of authority and control. o By extension, a business rule is the direct exercise of business control under the

governance model of the business.An illustration of the relationship between policies and rules is that one of more business rules can be derived to implement a business policy. The business directive is implemented by the combination of business policies and rules. In the context of a solution like a business process which is governed by specific business policies, the process is guided by the policy by invoking the appropriate business rules

Figure 1. Policies and Rules as Business Directives

Back to topMotivationIn any business, there will be specific business strategies, business tactics, business goals and business objectives which can be implemented in business applications and these business

applications have key business metrics that can be measured at any given point in time. Yet, today it is not uncommon for one business to merge with another similar business or to combine companies, relocate across the globe, which may present a challenge. Each organization might have its own metrics or the business might now be faced with changing industry regulations or new regulations as they expand into a new market. So the new business challenges are not only to meet the business goals of today, but to design strategies that are adaptable to cater to short term or well planned long term change in the business over time.This means that many business software developers need to design business applications with a goal to provide flexibility as well as robustness if these business services are to provide continuity over changing circumstance as well as optimized business performance. The first step in any project includes capturing and establishing a common set of business requirements. Some of these requirements should be expressed as business policy directives. It is important to also capture which requirements may remain relatively constant over time, and which (that are recognized early in the design phase) may require frequent change. Early identification of where change is expected can improve design and implementation of the projects to reduce ongoing future changes and resulting costs.Most governing bodies have a set of policies under which they operate on a daily basis. In a democracy for example, people vote to have a set of laws established and trust that the enforcement of any specific civil policy is done within the parameters of these laws (or rules). An individual civil policy may change as parties or individuals have a term of office and those parties are empowered to choose to apply policies in specific ways, but the laws for enforcement largely remain in place albeit with support from a judicial system. Business agility will require a similar separation of concern and a set of controls to provide checks and balances that the systems are operating as expected within the stated business policies.First, a set of Assertions:

1. A business establishes a set of business guidelines and manages its resources under a business governance lifecycle. In such a business environment establishing good governance includes defining both a set of policies and a set of rules to build in agility.

2. The agility provided by expressing some business requirements as policy expressions can be seen when business conditions are variable and it is possible to define a set of guidelines reflecting a range of business conditions. When these business policies can be identified and governed as the business conditions change, this can in turn make the execution of specific business rules be more agile and adapt to the changes within the policy range.

3. The business policy may have its own lifecycle of change to allow the business to evolve or modify its range of behavior within its existing business process comfort zone based on the monitoring of its capabilities relative to small changes in business conditions. Depending on the maturity of the organization with regard to its use of technology, there are places where automation of the operational processes of the business (aka "IT") through rules evaluation and execution can also provide strong business control.

4. Having complementary technology throughout an organization (i.e. in business applications and "IT processes") can enable the enforcement of business policies in the operational process and this can provide an effective balance for business and IT in the enforcement of required or compliant behavior.

5. The management of a comprehensive strategy for Business Rules and Business Policies should allow for the definition of a range of flexible business assets (enabled by both

policies and rules) that can be modified (under the appropriate controls) as the conditions of the business change. Agile control may require separate but coordinated governance lifecycles for business policies and business in a well architected infrastructure will provide many business benefits such as improved business alignment, reduced time to value, reduced amount of change and cost to make changes and more control provided to business users.

6. As companies instantiate business rules and business policies they will face a strong need to standardize their own operational policies (i.e. access control policies) and operational rules (i.e. service level agreements), in order to be able to manage and coordinate the operational assets of rules and policy with the same efficiency as the management of the business assets.

Again, having a consistent approach to business and operational assets for policy and rules management will allow a business to change business assets and be able to report on the operational enforcement of that change back to the business. Different technologies can be involved on the IT side or the business side to support the specified business constraints and goals since they work at different levels of detail, but the end goal is the coordinated management of the operational assets in support of the business requirements for the specified project or business strategy and tactics.Back to topLevels of abstraction in policies and rulesAfter years of experience in working with a broad range of customers who want to automate their business operation, patterns have emerged that reflect a decomposition of the realities of making business work. Any business has things it wants to accomplish (its goals and objectives), and any business needs to express policies about how the assets of the business are managed in the achievement of those goals and objectives. How well the business achieves its goals and objectives can be measured in different ways, including capturing data as audit policies, Business measures (metrics) or Key Performance Indicators (KPI’s). Since business people want to and need to be business people and not computer geeks we need to acknowledge another axis in the matrix of control. We assert there are 3 general levels at which controls are captured and governed -- the business layer, the architectural layer and the operational layer.The role of Architects (who are responsible for the integrity of the overall business architecture) often includes mapping or translating the business goals, to the current set of hardware and software assets [the architectural layer] that instantiate the business process and business services. Architects also work closely with a broad group of IT subject matter experts to specify how to make a set of hardware and software run efficiently and effectively in a managed environment [the operational layer]. The architecture needs to cover a range of directives from security, access control, and service level agreements to Business workflow, event processing, and information management and business rules.

Figure 2. Different types of Business Directives, Policies with Goals & Objectives

Working with customers we have found that using these 3 levels of abstraction can be useful for all parties to focus a general discussion of an agility problem into a more concrete discussion of a solution by acknowledging that any solution might include different requirements from multiple perspectives. Knowing that something is a business layer concern (i.e. the expression of a high level need to protect the assets of the business) can help you focus on specifying requirements and harvesting assets for an appropriate solution (i.e. developing a business dashboard as opposed to creating a binary representation of every asset in the raised floor space) since the tooling and reporting mechanisms may vary for any given solution. It is important, therefore to always keep in mind the business goals and objectives of the agility problem.Back to topStarting top down - Business layerBusiness Directives and GoalsOnce an organization decides to automate its business processes, the first step is to capture the business requirements as a set of business directives. Business directives include a set of goals to implement and a set of business metrics to measure results against the goals. There are different methodologies used to represent this, but the OMG has defined some models and techniques that we have interpreted and applied in decomposing this common set of elements needed generally by business when looking to solutions for business policy and business rules. For full detail see the OMG Business Motivation Model documents [reference http://www.omg.org/spec/BMM/1.0/ since we reference them here as a way of illustrating that there are common paths to capturing and expressing business goals and objectives].Business Directives, Business Policy and Business Rules

At a conceptual level, the OMG "Business Motivation Model" (BMM) provides a way to explore the relationship between rules and polices in the context of a larger conceptual framework of how businesses are organized and make decisions. In this way it reflects some of the principles of Governance.

In the BMM model, there is an attempt to understand; "the aspiration of the business (its Vision), its action plans (its Mission), the refinement of the Vision into Goals and Objectives, the identification of Strategies to achieve the Goals and the identification of Tactics for achieving the Objectives".

Directives might consist of some combination of Business policies and business rules and the OMG documents compare and contrast the two which we summarize as follows:

Business Policies o Are managed under the control of the business.o A business policy governs a business process.o Business policies can be expressed with natural language which can be

ambiguous.o Given the ambiguity of natural language, business policies are often not directly

actionable and need interpretation to be enforced. Business Rules

o Are managed under the control of the business.o A business rule executes an action of a business process.o Business rules are expressed without ambiguity, in terms of a standard business

vocabulary (SBVR)o Business rules (because they are defined in terms of a specific SBVR) are directly

actionable since they reflect specific business actions and assets with specific agreed to definitions and actions.

Starting to identify all the business elements (rules and policies) can be difficult. Good methodologies address the fact that there will most likely be iterative attempts at implementing the policies and rules in a project as most policies and rules change over time. The figure below is a rough canonical form of such a methodology, illustrating that answers to specific questions may produce a refinement of previously specified elements and that it is important to ensure that the rules and policies defined also have associated metrics by which their success can be measured.