Business Process Implementation for IT Professionals phần 3 doc

5.5 Metamodel structure The business rule metamodel attributes that are utilized as the basis for further discussion are: § Creation date; § Name; § Description; § Purpose; § Source; § Owner; § Category; § Scope; § Detail level; § Strength; § Priority; § Persistence; § Format; § Implementation method; § Compliance monitor; § Domain specific. Other metamodels certainly are possible, but the one utilized here will effectively serve as a vehicle for discovering the opportunities and problems associated with the use of business rules as an integral part of business operation. That structure, along with some refinements discussed later, can be considered as the core of a comprehensive business rule metamodel. 5.5.1 Rule identification The first four attributes of the metamodel structure, creation date, name, description, and purpose, provide a unique identifier for the rule. The meaning and values for each attribute are generally self-explanatory. A separate ID attribute is not specified in this structure but, depending on need, could certainly be added. Using only the values of the four identifier attributes, it should be possible to define a rule with sufficient detail to distinguish it from all other rules. Although additional information is provided by the values of the other attributes, they should not be needed for the identification of a unique rule. The remaining attributes and values can, of course, be used to search for rules with specific characteristics. 5.5.2 Rule advocacy The attributes of source and owner provide an indication as to the original and continuing advocates for keeping the rule. All rules must have a business reason for their creation and continued existence. As part of the life cycle process, that reason must be examined periodically and verified as to its continued validity. As a result of their direct involvement with the rule, the creator and the owner are the primary advocates and must be consulted if any alteration in the rule status is contemplated. The source of the rule and the ownership of the rule must be from a business perspective. The source and the current owner can be the same or they can differ, and the owner can change periodically for many business reasons. The rule administrator is not necessarily the owner, and the administration function is usually considered from a technical perspective. If the source or the owner for a rule is not specified and cannot be easily identified, that rule should be considered a candidate for elimination. All these conditions should be specified as part of the rule life cycle activities. 5.5.3 Rule classification taxonomy In a very real sense, any classification scheme is somewhat arbitrary, even though some means of classification is usually considered necessary to reflect the utilization and implementation of the rule within the enterprise. There is also another major reason for the classification of rules. In any reasonably sized enterprise, there likely are thousands of business rules. The intricacies of effectively creating, maintaining, using, reusing, and discarding the rules require some classification scheme regardless of the configuration management approach used. The purpose of the classification scheme is to reduce the number of rules that would need to be considered at any one time. Many investigators have advanced and defended specific rule taxonomies, resulting in considerable debate and conflict. Most of the taxonomies are specific to the area and emphasis being advanced by the investigator and are usually defined to efficiently accommodate the needs of the proposed approach. Because the set of rules for an enterprise exists independently of any taxonomy, it is possible to define and utilize multiple taxonomies. Each taxonomy could be optimized to serve a specific purpose, such as configuration management or conflict analysis. One taxonomy could be business oriented, while another could be implementation oriented. Specification of a rule taxonomy as a separate degree of freedom governed by needs of the business and independent of the other defining rule characteristics would accomplish the following: § Eliminate the unnecessary conflict over the definition of the ultimate rule taxonomy; § Allow different user groups to optimize their access to and use of the rules. The price that must be paid for that flexibility is, of course, the additional time and effort to place each rule (either automatically or manually) into its proper place in every taxonomy utilized. In addition, as has been previously stated, a robust repository is also necessary for the simultaneous definition of multiple taxonomies. For illustration purposes in this section, some specific taxonomy is necessary. A relatively robust taxonomy that interacts efficiently with the process implementation methodology discussed later is defined and utilized. It is defined in business-oriented terms and is matrix oriented. Although it effectively provides a comprehensive example of the information needed in a taxonomy, it is not intended that this classification scheme be considered as the only appropriate one. Many schemes are possible and may simultaneously coexist with each other and the one presented here. Three structure attributes, category, scope, and detail level, are used in this taxonomy. They provide the basis on which to classify the rule into a suitable category. Figure 5.1 indicates one method of specifying values for the category and scope attributes using a matrix structure. The rows of the matrix represent the specific aspect of the enterprise that the rule addresses. Although the rows may not provide a complete taxonomy, the author has yet to find a case where a proposed rule could not be reasonably placed into one of the rows. Figure 5.1: Example of business rule taxonomy. The columns of the matrix represent the scope or sphere of influence within the enterprise. Each of the columns and rows can be further decomposed into smaller units as necessary for the understanding of a particular rule. For example, the organization unit row can be divided into the individual organizations of the enterprise. The degree of decomposition determines the detail level of the rule. Although not indicated in the figure, each matrix cell should be decomposed in both category and scope for as many levels as rules are reasonably expected to be defined. Because the amount of detail that can be produced in that manner is quite large, this process will not be explicitly performed in this presentation. 5.5.4 Rule operation The last seven attributes of the rule structure provide the operational conditions for the realization of the rule. Those conditions are specified by the strength, priority, persistence, format, implementation method, compliance monitor, and domain-specific attributes. A brief discussion of each of those attributes follows. The strength attribute was discussed in some detail in Section 5.3, so it is not considered further at this time. The interactions of that attribute with other operational attributes are examined later as necessary. The priority attribute is utilized when there is a rule conflict. Although in theory there should never be a rule conflict with rules covering the same area, in practice that is difficult to control because there usually are a large number of rules with many different originators and owners. The priority attribute indicates the desired outcome in a conflict situation. The simplest priority scheme is probably the values “required,” “where possible,” and “guideline.” Although better than nothing, that priority scheme generally is ineffective in resolving conflicts since the chance of conflicting rules having the same priority is relatively large. That is where reasoning and analysis over a given rule set become necessary. As with any type of attributes, care must be taken to ensure that all rules are not simply given the highest value possible by their originators. That requires good administration and configuration management functions. The persistence attribute indicates the period during which the rule will be effective. There are many possible values for the persistence attribute: § From creation until explicitly deleted. Example: “From now on, all employees will enter the building through the south entrance only.” § From creation until a specific occurrence, date, or time. Example: “Until the renovations are complete, all employees will enter the building through the south entrance only.” § For a certain period. Example: “For a 2-week period starting this Friday, all employees will enter the building through the south entrance only.” § During periods indicated by the state of a defined entity. Example: “When the red light is on, all employees will enter the building through the south entrance only.” In the examples, for better understanding, the period during which the rule is effective is included in the rule statement. That, of course, does not have to be the case. A rule can be stated without any indication as to its period of applicability. In that case, a specific indication as to the effectiveness period must be included as the value of the attribute. If it is unknown, that condition also should be stated. The format attribute provides the style of the business rule. Styles could include: § A rule language; § Structured English (or other natural language) text; § A mathematical expression; § Freeform text; § A table or matrix (including the case of one cell); § Procedural code; § A combination of any of the above. All those styles are useful in expressing business rules. Which form is the most appropriate in a given situation depends on the level and the purpose of the rule and the manner in which it will be used. A single style is not sufficient to represent all the different types of rules that are needed in the enterprise. Because of the desirability to compare and reason about rules of differing styles, some means of translating to a common formalism is desirable. That need is discussed further in Section 5.8, which considers the use of a repository. Each of the styles can provide for parameters whose values can be changed without changing the rule statement itself. In many cases, that parameterization can facilitate rule creation and management. Currently, no standards are available for business rules, and that lack, unfortunately, extends to the definitions of style. Almost anything can be used, as determined by the creator of the rule. The enterprise needs—and should set—some internal standards in this area to be in a better position to effectively manage business rule usage. In many cases, the creator of the rule uses a style that must be converted into one or more other styles before it can be used. Products that can accommodate business rule inputs generally require their own specific style (remember the lack of standards). The use of many different products, each with individual style requirements, can create a difficult problem. Errors can easily be made in translating rules from one style into another. The need for many target styles complicates the testing and identification of error conditions in the application as a whole. With that said, it still is probably better to set a single standard for the creation of business rules and then translate them into the various formats needed rather than create them with different formats. In that way, all the rules have at least the same standard style(s), which facilitates their comparison and reuse. Rule styles other than those listed could also be defined, depending on the particular needs of an enterprise. The more structured the format and the more it is parameterized, the easier it is to automatically utilize the rule in the operation of the enterprise. The implementation method attribute indicates the method(s) by which the rule will be accommodated. This attribute is key to the successful utilization of business rules because it provides for an explicit relationship between the rule statement and the means for realizing it. By examining the proposed linkage, it can be determined if the proposal will provide the most effective method of rule realization and, if not, what the method should become. In many contemporary instances, rules are stated without any indication as to how the rule will be incorporated into the business. Without that explicit linkage, the use of business rules as an integral part of enterprise operation will fail. The major utilization methods include the following: 1. Specifically including or considering a rule in the development of manual procedures and practices; 2. Considering a rule as the requirements for a software development are being developed; 3. Specifically including a rule in the requirements for a software development; 4. Manually considering or incorporating a rule as part of an application design activity; 5. Entering a rule into a product and interpreting it at compile time; 6. Accessing a rule from a library and interpreting it at compile time; 7. Entering a rule into a product and interpreting it at run time; 8. Accessing a rule from a library and interpreting it at run time. Each implementation method is illustrated as part of an overall rules system, as defined in Section 5.8. In general, the methods become more automatic and less error prone as listed from top to bottom. Depending on the strength of a rule, one implementation method may be more appropriate than the others. For a required rule, the desired method would be the eighth one in the list, directly accessing the rule and utilizing it at run time. If changes are needed, they could be made and the altered rule bound at the desired time. For a guideline rule, methods 1, 2, and 4 are probably most appropriate; the rule does not have to be followed exactly, although some type of fuzzy logic could be used to determine which rule would be utilized. The value of the compliance monitor attribute, which is closely associated with the rule implementation method, explicitly defines how the rule realization is examined to determine if it produces its defined constraints. A good way to start is to associate one or more compliance monitor techniques with each implementation method. Others can be defined if needed. The numbers in the following list correspond with the numbers in the implementation methods list. 1. Use a design review of draft materials to determine if and to what extent applicable business rules are reflected in the document text. 2,3,4. Use a design review of requireme nts to determine if and to what extent applicable business rules are contained in the requireme nts specificati on. Perform complianc e audit of finished software to determine if the software accurately reflects the requireme nts, including those requireme nts associate d with business rules. Test finished system to determine if applicable business rules are being accurately reflected. 5,6. Test product with suitable environme nt conditions designed to determine if product reacts properly to incorporat ed business rules. Test product integrated with the entire applicatio n to determine if business rules are being interprete d properly. 7,8. Test product with suitable environme nt conditions designed to determine if product reacts properly to incorporat ed business rules. Test product integrated with the entire applicatio n to determine if business rules are being interprete d properly. Change business rule parameter value or structure and retest to determine if change is being implement ed correctly. The domain-specific attribute, the final one in the metamodel, consists of any domain requirements that may arise from regulatory bodies, required standards, or similar sources. Requirements must be considered when the applicable domain is involved. For example, assume this rule: “Insert the maximum number of ads into the bill envelope without increasing the amount of postage due.” The domain-specific value for that rule could be a reference to the regulation that the post office uses to calculate the amount of postage to be paid. 5.5.5 Examples Two examples of business rules with differing characteristics are shown in Tables 5.1 and 5.2. The rules are designed to illustrate the wide variety of rules that can be accommodated using the metamodel defined at the beginning of this section. Readers are invited to take any business rules with which they are familiar and (1) ensure that it is a well-formed business rule by determining if it has the required characteristics and (2) determine the specific characteristics of the rule by determining values for all the metamodel structure attributes. Table 5.1: Emergency Response Rule Metamodel Creation date: 1/1/95 Name: Emergency Response Rule Description: In the event of an emergency that requires a field response by employees, at least two employees will be dispatched to the trouble location. Purpose: The purpose of this rule is to help provide safe working conditions under emergency conditions. Source: Safety Department Owner: Vice President of Administration Category: Operations: function Scope: Process Detail level: Dispatch function/trouble resolution process Strength: Requirement Priority: High Persistence: Immediately, until rescinded Format: Text only Implementation method: Included in all software requirements dealing with dispatch functionality Compliance monitor: Design review Domain specific: None Table 5.2: Sales Tax Calculation Rule Metamodel Creation date: 6/1/95 Name: Sales Tax Calculation Rule Description: This rule requires that the sales tax be calculated using this formula: ST = (Price * Tax rate) rounded up to next cent if not already at a whole cent. Purpose: The purpose of this rule is to provide the rule for calculating the sales tax on products. Source: Tax Department Owner: Chief Accounting Officer Category: Operations: function Scope: Transaction Detail level: Tax calculation function, tax calculation transaction Strength: Requirement Priority: High Persistence: Immediately, until rescinded Format: Mathematical equation Implementation method: Business rule library that is accessed by software at run time Compliance monitor: Module test and application integration test Domain specific: Tax code reference: Sect. 10.556.9 State Code 5.6 Rules versus requirements Although the modeling, implementation, and use of process business rules are not covered until later in this book, one area of potential confusion needs to be addressed early: the relationship between process business rules and the requirements for software products that support a process. In general, the software requirements must be consistent with applicable process business rules (and other types of business rules, for that matter) but they do not necessarily have to contain the rule itself, nor do they have to be rules themselves. In fact, they should, in general, not be business rules. Business rules are oriented toward understanding and defining the operation of the business, while requirements are oriented toward defining the operation of a software product. If a process business rule states that “all preventative maintenance will be performed between midnight and 7:00 A.M. except for weekends, when it can be done anytime,” then a software scheduler that supports the maintenance process could have a requirement that “a means must exist through a GUI interface to specify the time period, based on days of the week during which work can be scheduled.” That example of a requirement is a product requirement or rule that supports the business rule. It clearly is not a business rule in the sense we have been assuming and using business rules. The author refuses to be drawn into a philosophical discussion concerning the definition of a product requirement as a special type of business rule. It is not necessary, or probably even feasible, to provide a definitive answer to that question. In the development of software product requirements, additional business rules may be identified. If a prospective requirement further defines the process that the software will support, it can also be considered a business rule and may or may not be kept as a requirement. As an example, assume a casual customer billing business rule has been specified. A software product that will be used to monitor customer account status could be given a requirement that “if a customer is delinquent in any payment for the last year, that customer will be billed every month instead of every other month.” In that case, the requirement is clearly process related even though it initially was defined as a software product requirement. With that understanding, the requirement should also be considered as a business rule and the needed product requirement reconsidered. In the example, the product requirement could (and probably should) be restated to the following: “The product will be capable of generating a bill at intervals determined by customer status.” Whether a candidate software requirement is process related must be determined from the individual circumstances. If it is determined to be such, a recast of the requirement and an addition to the business rule set probably is appropriate. 5.7 Rule engine As an aid in the configuration management of business rules and to make the incorporation of business rules into the enterprise more effective, the concept of a rule engine has been advanced. Although not well defined, the implicit purpose of the rule engine is to provide an efficient mechanism for rule administration and use. The functionality of a rule engine can range anywhere between the following two extremes depicted: § The functionality is that of a passive library that is used only to contain rule definitions. The library usually has functions that allow rules to be created, deleted, copied, and manually browsed, but there is little additional functionality. Although better than nothing, this type of rule engine is minimally useful. It is not possible to use this type of engine with implementation methods 5, 6, 7, and 8, as defined in the list in Section 5.5.4. That severely limits the effective use of rules in the operation of the business. § The functionality is that of a full-function repository utilizing an explicit robust rule metamodel. This engine would allow the full range of implementation methods as well as provide for the efficient reuse of rules. Configuration management functions would be enhanced through automatic discovery of rule conflicts, overlaps, and possibly gaps. To achieve the second type of rule engine, a large number of problems must be addressed and solved. Further discussion of what is needed to accomplish the realization of this engine is beyond the scope of this chapter. The main purpose of including the concept of a rule engine is to alert readers that they should be cautious in assuming a specific meaning when they encounter the term. Some types of rule engines being offered are modified inference engines, database constraint checkers, and workflow engines. Those are all legitimate implementations, but each has a relatively narrow focus. Examples of uses of these types of engines are given in Section 5.8. 5.8 Rule system An illustration of the architecture for a complete business rule system as utilized in the implementation of a process is presented in Figure 5.2; the discussion given in this section is based on the diagram in the figure. In addition to the end user, five different human-oriented roles are shown: administrator, owner or agent, analyst, software developer, and data modeler. Those roles could be performed by five different staff members, or they could be combined as warranted. In addition, some parts of the roles may be automated through the use of expert systems or similar approaches. For the purpose of this discussion, however, it is assumed that the roles are performed by individual staff members. Because Figure 5.2 is designed to show a systems approach to the operational environment for business rules, it must incorporate many interrelated functions and entities necessary to the implementation of a process. If the reader is unfamiliar with some of them, the terms and functions presented in the figure are discussed in other areas of the book. [...]... complete process life cycle is discussed in Section 8.2 It is concerned not only with process definition but also with implementation and the changes that occur in the normal course of business Because of the importance of process as the unit of enterprise automation, a concerted effort is made to differentiate a process implementation from a traditional functional system implementation Even though it sometimes... repository facilitates the life cycle management of the rule base Because of its central position in the analysis and management of the rule base, the format of the rules in the repository is generally suited to these purposes Many rule formats will be required for the effective use of the rules under different circumstances and environments It will be necessary to convert the repository rule form... model must be implemented in some form One failing of many process reengineering and management-by -process efforts is that the entire focus is on process definition and very little attention is paid to the process implementation needs and the associated life cycle management requirements Process implementation requires design, fabrication (build), and operate activities as well as an oversight function... architecture The administrator assigns the proper characteristics, such as a specific implementation type, and places it in the repository If new functionality is needed to accommodate the implementation type, it must be acquired and provisioned by the enterprise organizations responsible for that type of activity before creation is considered complete Before being made generally available, the new business. .. perspective 6.4 .3. 3 Tangible liabilities As with assets, an enterprise can change its liabilities by performing an appropriate enterprise financial event The major difference is that the valuation of tangible liabilities usually is not difficult The liability almost always is the amount owed in dollars The connection with the automation assets usually is indirect because there is no concept of liability, per... was well documented in Chapter 1, and a process approach to enterprise automation is assumed This chapter concentrates on developing unit and class asset models for business processes in sufficient detail to serve as the starting point for the process implementation methodology in Part III Although there is only one class model, there are multiple unit models because of the different purposes for which... difficult-tounderstand representations In addition, past and current software practice does not use an explicit form of the incorporated rule, as is indicated by the repository The rules exist only in the software code form There are legitimate reasons for using this type of rule implementation as long as the rule is also replicated in the repository Efficiency considerations in the form of response time or throughput... pp 41–49 Hibbard, J., “Software Gains Capital Treatment,” Information Week , Issue 664, 1998, pp 18– 20 Hodgson, A., et al., “Accounting for Intangibles—A Theoretical Perspective,” Accounting and Business Research, Vol 23, No 90, 19 93, pp 138 –150 Lee, T A., “Cash Flow Accounting and the Allocation Problem,” J Business Finance and Accounting, Vol 9, 1982, pp 34 1 35 2 Parker, C., “A Fundamental Reassessment... current business and technical climate indicate that a process- based approach be adopted That means the automation methodology must be able to efficiently convert a business process specification into a workflow structure that is utilized by the enterprise automation environment The implemented business process should be compatible with the computing infrastructure and other business process implementations... transformation process The dynamic model also contains a feedback path, such that the revenue generated can be used to obtain more assets, which then can be used to generate additional revenue That classic case of positive feedback loop would allow uncontrolled growth and prosperity for the enterprise as long as other activities that tend to inhibit the main process do not exist The major inhibiting . liability inhibits it because the assets are used to service the liability instead of being used to produce revenue. Figure 6 .3: Transformation process and intangibles. 6.2 Initial financial. utilization of business rules because it provides for an explicit relationship between the rule statement and the means for realizing it. By examining the proposed linkage, it can be determined. this section. Readers are invited to take any business rules with which they are familiar and (1) ensure that it is a well-formed business rule by determining if it has the required characteristics