RULES ASSESSMENT - IS Rating Tool
Creative commons by sustainableitarchitecture.com
Version Beta V48 – 2010 – March 12nd

Mark->

weight for your rating

Bad

Basic

Medium

Advanced

Optimized

Guidelines

Criteria

Explanation

Tip: use this column for vertical scroll

Mastering Rules Knowledge

For each question check one choice ONLY

BR-KN-01 Enterprise Rules Architecture

Enterprise Rules Architecture should be seen as a part of the Enterprise Architecture. Indeed, it tackles rules and complements with Data Enterprise Architecture (see the Data Assessment part) and with Process Enterprise Architecture (see the Processes Assessment part).

The goals targeted by the Enterprise Rules Architecture are similar to ones established for Enterprise Data Architecture but applied to rules:
- full knowledge management of rules,
- enforcing a politics encouraging a unified rules modeling at the whole scale of the system rather than siloed rules modeling and implementations only within opaque IT languages.

About the strategy formulation
The rules management is a key topic as it allows to write down the company's business and organizational strategy. To achieve this goal in a right way, the strategy should be described by benefiting from Enterprise Data Architecture (Business objects and their lifecycles) and Enterprise Processes Architecture (Processes and uses cases). This is a key point to enforce a real alignment of the company's strategy with its data and processes definitions.

Reminder about organizational issues as already indicated when assessing data:
- Working procedures and organizational issues are out of the scope of the IS Rating Tool. Indeed, this tool is focus on Intrinsic Value of IS (1). Other organizational issues should be tackled through frameworks and methods such as CobiT, CMMI, etc.

(1) Before using the IS Rating Tool we invite you to find out the definition of IS Intrinsic Value and its differences with IS Use Value and IS Business Value (see our website).

BR-KN-01-1 Rules classification
Enterprise Rules Architecture should rely on a shared rules classification.

This classification is more difficult to establish than one applied to data (reference, master, transactional, decisional, data flow) as there is not standardization nor real unified best practices in this field. Therefore the IS Rating Tool provides a first level of classification that should be seen as the minimum to ensure.

FALSE

0,0

At least you should have a classification relying on these three types of rules:
- Core business rules. These rules are independent of any organizational issue. Whatever working procedures or workflows enforced within the system, core business rules are identical,
- Organizational rules. These rules depend on organizational choices such as working procedures and workflows. When organizations change then organizational rules must be updated and/or extended,
- Security rules. These rules are dedicated to security issues. They can enforce security policies both at the core business level and the organizational level.

Even though this classification could be enriched differently from one company to another, it should be the basis to enforce. Other types could be added such as: functional, calculation, IT, internal rules versus those related to business regulations, etc.

No rules classification shared at the whole scale of the system. Every project reinvents its own classification

A rules classification is established at the whole scale of the system but applied to some first early adopters projects only

A rules classification is established at the whole scale of the system and applied to less than 20% of new developments

A rules classification is established at the whole scale of the system and applied to 50% of new development at least, including third parties developments. It means that your RFP enforce your rules classification as a requirement to meet

Full shared classification of rules enforcing core business, organizational, and security types of rules for every project and third party developments. It means that your RPF enforce your rules classification as a requirement to meet

Main criteria to be considered for rating:
shared rules classification, enforcement scope, using within RFP

BR-KN-01-2 Business strategy formulation
The business strategy deals with all rules defining the core business of the company regardless of any organizational issues. Organisations rules can change frequently over time whereas business rules are more stable and represent the company's raison d'etre.

FALSE

0,0

Business rules should be established by benefiting from the business objects modeling as described in the Enterprise Data Architecture (see Data Assessment part). It means that every business rule should be attached to a well-identified business object or a specific domain of business objects. The business objects' lifecycles allow to establish business rules updating states of business objects (see Data Assessment part).

Business rules are not distinguished from organizational rules. Therefore the business strategy formulation is scattered within organizational descriptions

Business rules are distinguished from organizational rules but without a real linking to Enterprise Data Architecture. It means that the business strategy formulation is not aligned with business objects which is a real concern. In other words, it is very difficult to keep the control of the business strategy without a good command of the data definition

Business rules are described regardless of organizational issues. They are linked to the Enterprise Data Architecture through business objects and domains of business objects. But it is applied to less than 20% of the business strategy formulation

Business rules are described regardless of organizational issues. They are linked to the Enterprise Data Architecture through business objects and domains of business objects. It is applied to 50% at least of the business strategy formulation

Business rules are described regardless of organizational issues at the whole scale of the system. They are linked to the Enterprise Data Architecture through business objects and domains of business objects

Main criteria to be considered for rating:
description of business rules regardless of organizational issues, linking to Enterprise Data Architecture, enforcement scope

BR-KN-01-3 Organizational strategy formulation
The organizational strategy deals with all rules defining how actors must/should act to deliver the business strategy in a cost-effective and optimum way.

FALSE

0,0

Organizational rules should be established by benefiting from the modeling of processes and working procedures as described in the Enterprise Processes Architecture (see Processes Assessment part). It means that every organizational rules should be attached to well-identified processes or working procedures (uses cases).

Organizational rules are not distinguished from business rules. Therefore the organizational strategy formulation is scattered within business descriptions

Organization rules are distinguished from business rules but without a real linking to Enterprise Processes Architecture. It means that the organizational strategy formulation is not aligned with processes and uses cases which is a real concern. In other words, it is very difficult to keep the control of the organizational strategy without a good command of the processes and uses cases definition

Organizational rules are described regardless of business issues. They are linked to the Enterprise Processes Architecture through processes and uses cases. But it is applied to less than 20% of the organizational strategy formulation

Organizational rules are described regardless of business issues. They are linked to the Enterprise Processes Architecture through processes and uses cases. It is applied to 50% at least of the organizational strategy formulation

Organizational rules are described regardless of business issues at the whole scale of the system. They are linked to the Enterprise Processes Architecture through processes and uses cases

Main criteria to be considered for rating:
description of organizational rules regardless of business issues, linking to Enterprise Processes Architecture, enforcement scope

BR-KN-01-4 Security policies formulation
The securities policies gather all rules defining the permissions management applied to enforce the business strategy and the organizational strategy.

FALSE

0,0

Security policies should be distinguished from other types of rules such as business and organizational rules. By isolating these rules it becomes easier to oversee them and ensure specific control. Even though they are isolated, they should rely on the same description process as one used to establish business and organizational rules. It means that security policies should be attached to either business objects stemming from the Enterprise Data Architecture or processes and uses cases stemming from the Enterprise Processes Architecture.

Security policies are not distinguished from other types of rules. It means that it is difficult to get a full description of security policies as they are scattered within the formulation of business and organisational strategies

Security policies are distinguished from other types of rules but without a real linking to Enterprise Data Architecture and Enterprise Processes Architecture. It means that the security policies formulation is not aligned with data, processes and uses cases which is a real concern. In other words, it is very difficult to keep the control of the security policies strategy without a good command of the data, processes and uses cases definition

Security policies are described regardless of business and organizational issues. They are linked to the Enterprise Data Architecture and the Enterprise Processes Architecture through data, processes and uses cases. But it is applied to less than 20% of the security policies formulation

Security policies are described regardless of business and organizational issues. They are linked to the Enterprise Data Architecture and the Enterprise Processes Architecture through data, processes and uses cases. It is applied to 50% at least of the security policies formulation

Security policies are well-distinguished from other types of rules. Getting a full description of the security policies at the whole scale of the system is easy and accurate. These security rules are linked to the Enterprise Data Architecture and the Enterprise Processes Architecture

Main criteria to be considered for rating:
linked to the Enterprise Architecture, enforcement scope

BR-KN-02 Rules modeling

BR-KN-02-1 Rules grammar
Rather than a pure informal description of rules, using a well-established grammar brings many benefits: encourages knowledge sharing, improve auditability, allows for automatically translating rules into runnable IT components.

FALSE

0,0

A rules grammar should be used to author all types of rules as described in BR-KN-01-1: core business rules, organizational rules, security policies. Many languages can be used depending on the company's culture. It could be a specific grammar such as a functional pseudo-code, a standard approach such as SBVR (Semantics of Business Vocabulary and Rules) from OMG, but also a rules grammar stemming from a rules engine also known as a BRMS (Business Rules Management System).

In any case, this grammar should be meaningful for all IS Stakeholders (not only IT specialists) and should be either IT runnable directly or translatable into runnable IT components.

Lack of a unified rules grammar. It means that every project reinvents its own language from pure informal descriptions to specific grammars. Sharing the rules knowledge between projects is difficult because of discrepancies between rules descriptions

A first attempt to enforce a unified rules grammar exists but limited to first early adopters projects only. The translation of these rules into runnable IT components is not available

A shared rules grammar is applied to less than 20% of the system. The rest uses informal and heterogeneous representations. The translation into runnable IT components still remains very limited

A shared rules grammar is enforced at a significant part of the system, at least 50%. Within this scope the knowledge sharing of rules is encouraged and the translation into runnable IT components is enforced when needed

A shared rules grammar is enforced at the whole scale of the system. Every project must use this grammar to author their rules. A well-established procedure exists to translate rules into runnable IT components when needed

Main criteria to be considered for rating:
unified rules grammar, ability to translated rules into runnable IT components, enforcement scope

BR-KN-02-2 Rules naming
Every rule must have a unique naming allowing its identification in an easy way

FALSE

0,0

A unified rules naming should be enforced to support the knowledge sharing. It should follow the rules classification as defined in BR-KN-01-1 by enforcing code such as: COR (core business rules), ORG (organizational rules) and SEC (security policies). Moreover, this naming rules should not include any specific code stemming from projects as reuse must be encourage. It means that the rules naming should be aligned with Enterprise Architecture's concepts such as domains of business objects, processes... as defined through the Enterprise Data Architecture and the Enterprise Processes Architecture.

Lack of a rules naming enforced at the whole scale of the system. It means that every project establishes its own rules naming, slowing down the knowledge sharing across projects

A first attempt to enforce a unified rules naming exists but limited to first early adopters projects only. This rules naming doesn't really follow the rules classification and concepts stemming from the Enterprise Architecture

A unified rules naming is applied to less than 20% of the system. The rest uses specific rules naming. The unified rules naming follows the rules classification and is aligned with concepts stemming from the Enterprise Architecture

A unified rules naming is applied to a significant part of the system, at least 50%. Within this scope the knowledge sharing of rules is encouraged. This unified rules naming follows the rules classification and is aligned with concepts stemming from the Enterprise Architecture

A shared rules naming is enforced at the whole scale of the system. This rules naming follows the rules classification and is aligned with concepts stemming from the Enterprise Architecture

Main criteria to be considered for rating:
Unified rules naming, aligned with concepts stemming from the Enterprise Architecture, enforcement scope

BR-KN-02-3 Rules sets and dependencies
Rules can be linked to each other to meet business requirements. Therefore, it becomes necessary to define sets of rules and links between rules.

FALSE

0,0

In order to encourage readability and reusability of rules, it should be possible to define sets of rules. Moreover, links between rules and sets of rules should be available to establish complete executions flows of rules meeting requirements.

Rules sets and dependencies between rules are not well-established. Every project uses a specific approach. Most of the time, rules are limited to a basic portfolio without efficient descriptions of links between rules

Rules sets and dependencies between rules exist but are not well-used. Only some early adopters projects benefit from the ability to define executions flows of rules

Rules sets and dependencies between rules are well-established but applied to less than 20% of the system. It means that the rest of the system uses a basic portfolio of rules without efficient descriptions of links between rules

Rules sets and dependencies between rules are well-established and applied to a significant part of the system, at least 50% Within this scope, rich executions flows between rules can be defined to fully meet requirements

Rules sets and dependencies between rules are well-established and used at the whole scale of the system. It means that rich executions flows between rules can be defined to fully meet requirements

Main criteria to be considered for rating:
sets of rules and dependencies between rules, enforcement scope

BR-KN-02-4 Rules templates
To encourage the knowledge management of rules, it is recommended to establish rules templates. A rule template defines a scope of limited data and actions usable when authoring rules. For example, rules authored in the marketing field shouldn't have access to data related to Human Resources. Then, it means that a rule template forbids authors of rules in the field of the marketing to use HR data.

FALSE

0,0

A well-established modeling procedure should be used to define relevant rules templates. These templates should be aligned with concepts stemming from the Enterprise Data Architecture and the Enterprise Processes Architecture. For example, a set of rules templates should exist for every domain of business objects. A good rule template allows to hide a significant part of the complexity. It runs as a pattern.

Lack of rules templates. It means that there is a lack of knowledge management because it is impossible to factorize and hide a part of the rules complexity into rules templates

Some rules templates are used but limited to early adopters projects only

Rules templates are used but applied to less than 20% of the system. It means that the rest of the system doesn't hide complexity within rules templates

Rules templates are used to hide a part of the rules complexity. It is applied to a significant part of the system, at least 50%

Rules templates are used to hide a part of the rules complexity. They are applied at the whole scale of the system and then allow for streamlining rules definitions

Main criteria to be considered for rating:
use of rules templates, enforcement scope

BR-KN-02-5 Reference and Master Data
values applied to rules definitions
When authoring rules, many reference and master data values are used. For example: types of clients, products hierarchy codes, marketing codes, pricing configurations, discounts values depending on countries, structures and organizations codes, functional and IT parameters, etc.

Therefore the quality of rules depends also on the quality of these ref/master data values. As we focus on data values, their data structures are taken into consideration by default.

However, transactional data used by rules are not measured here. This domain of data is tackled with the next question BR-KN-02-6.

FALSE

0,0

All reference and master data values should be retrieved from a unified data repository ensuring a high quality of data. It means that the rules definitions are aligned with ref/master data values stemming from the MDM (Master Data management). To get more details about the MDM see the Data Assessment part.

Ref/master data values used when authoring rules don't stem from a unified data repository. It means that there is a huge risk of poor rules quality due to a lack of ref/master data management

Ref/master data values used when authoring rules are retrieved from a data repository but limited to the rules management. Most of the time it relies on decision tables embedded inside the rules management system. This approach brings data quality troubles because ref/master data values are also managed outside the boundaries of the rules needs. Therefore it slows down the quality of rules

Ref/master data used when authoring rules are retrieved from a unified data repository. But it is applied to less than 20% of the system. The rest is managed through decisions tables embedded inside the rules management system. In other words, the MDM is partially used to enforce ref/master data values when authoring rules

Ref/master data used when authoring rules are retrieved from a unified data repository. It is applied to a significant scope of the system, at least 50%. Therefore, the MDM is really used to enforce ref/master data values when authoring rules

All ref/master data values used when authoring rules are retrieved from a unified data repository located at the whole scale of the system. It means that rules definitions are fully aligned with the MDM

Main criteria to be considered for rating:
alignment with the MDM, enforcement scope

BR-KN-02-6 Transactional data subsets
Applied to rules
When authoring rules, it is necessary to establish transactional data subsets on which each rule can be executed. Rather than design a specific transactional data subset per rule, it is recommended to define more standard data subsets reusable by several rules.

Reference and master data used by rules are measured through the question BR-KN-02-5.

FALSE

0,0

Modeling procedures should exist to establish the default transactional data set on which a rule can be defined and executed. These data sets should be established with help from the Enterprise Data Architecture and the Enterprise Processes Architecture.
For example, a rule applied to the business object Customer can use all data related to this business object's data structure. It means that rather than designing a specific data set for each rule, it is recommended to reuse data structures stemming from the Enterprise Architecture. In doing so, readability and maintainability of rules and data knowledge are reinforced.

Data subsets used by rules are established in a specific way for each rule. When the number of rules increases then many data sets must be maintained. This is difficult to manage and not cost-effective. Moreover, it means that Enterprise Data Architecture is not aligned with rules definitions, which is a big concern

Data subsets used by rules are established with help from data structures stemming from Enterprise Architecture. But this is just a data translation not a full reuse of data structures defined within the Enterprise Data Architecture. It means that Enterprise Architecture is not really aligned with rules definitions

Data subsets are well-established and stem from concepts defined through the Enterprise Architecture. But it is applied to less than 20% of the system. Within this scope, rules rely on these data subsets. Outside this scope, it is defined through specific data subsets not aligned with the Enterprise Architecture

Data subsets are well-established and stem from concepts defined through the Enterprise Architecture. It is applied to a significant scope of the system, at least 50%. Within this scope, rules rely on these data subsets. Outside this scope, it is defined through specific data subsets not aligned with the Enterprise Architecture

Data subsets are well-established and stem from concepts defined through the Enterprise Architecture. Therefore rules rely on these data subsets at the whole scale of the system. It means that the Enterprise Architecture is fully aligned with rules definitions

Main criteria to be considered for rating:
alignment with the Enterprise Architecture, enforcement scope

BR-KN-03 Rules enforcement

BR-KN-03-1 Explicit demand versus event activation
Rules can be executed either through an explicit demand or through an event activation. Both are required to meet requirements of complex systems and contribute to improve the knowledge of rules.

FALSE

0,0

Most of the time, rules are executed through explicit demands submitted by human actors and IT systems. However, beyond this usual approach, rules should be also executed when events are thrown within the system, regardless of explicit demands. Here is an example of a rule executed only if well-identified events are validated:
"On each stock variation greater than 100 within the last 20 seconds then execute <<RULE>>"
Using events to enforce rules is very powerful and complements with usual explicit execution mode. From an IT point of view, this approach requires a CEP tool (Complex Event Processing) which complements with the BRMS (Business Rules Management System).

Rules are executed through explicit demands only. It means that the events activation is not applied. In other words, the rules integration is delivered by software calls and/or human actor involvements only

The events activation is limited to first early adopters projects only. The rules integration is done through explicit demands mainly

The events activation is applied to less than 20% of the system

The events activation is applied to a significant scope of the system, at least 50%

Rules can be executed through both explicit calls and events activations. The events activation is applied at the whole scale of the system. Therefore, the knowledge management of rules is enriched by the events activation

Main criteria to be considered for rating:
explicit execution, events activation, enforcement scope

BR-KN-04 Ability to act

BR-KN-04-1 Funding
A budget is established to support the Enterprise Rules Architecture

FALSE

0,0

The decision to raise a funding is dependent on the ROI. Spending time to establish a unified and shared rules classification and grammar is expensive. Therefore, the drivers to engage such a funding should be well-argued. At the very least, they include these four benefits:
- better readability of rules which is a significant gain to ensure business-IT alignment and audit operations,
- better reusability of rules which can be a real gain to streamline design and maintenance costs,
- ability to set up a translation of rules into runnable IT components which is a right way to decrease IT costs and enforce the business-IT alignment,
- reinforce the knowledge management applied to rules. It means a better command of the strategy formulation benefiting from a full and unified description, aligned with the Enterprise Data Architecture and the Enterprise Processes Architecture.

When these benefits are not well-understood within the organization it becomes difficult to engage sustainable funds supporting the Enterprise Rules Architecture. It means that the knowledge management of rules is not viewed as a key factor to support the business and its formulation.

No real budget dedicated to Enterprise Rules Architecture

Partial Enterprise Rules Architecture budgets are identified depending on projects requirements related to the rules management

A budget is established to support Enterprise Rules Architecture but applied to less than 20% of the system

A budget is established to support Enterprise Rules Architecture, applied to 50% of the system at least

A budget is established to support Enterprise Rules Architecture at the whole scale of the system

Main criteria to be considered for rating:
complete budget, scope enforcement

BR-KN-04-2 Replacement Value
Ability of your organization to (re)author rules from scratch (blank page).

FALSE

0,0

The replacement value must be gauged regardless of any financial issue. You must estimate it without any limitation as this is a theoretical assessment only. However when answering this question you have to provide detailed information explaining your score. When rules documentations are up-to-date and teams have a good command of rules modeling procedures then your score is high. Conversely, when it is difficult to gather the knowledge of rules because of poor documentations and/or lack of specialists in rules authoring, then your score should be decreased.

The effort to redesign or reauthor is too high. It would be impossible to do this work

It should be possible to do this work within a subset of the system, less than 30%, but we cannot estimate it. Doing this work at a large scale of the system is impossible

We are able to estimate the work of redesign but applied to less than 50% of the system

We are able to estimate the work of redesign applied to a large scale of the system, more than 50%

We are able to estimate the work of redesign applied to the whole scale of the system, at least more than 80% of the scope

Main criteria to be considered for rating:
scope of possible redesign, ability to estimate the work

Intermediary mark
Mastering Rules Knowledge

out of

130

0,0%

Mastering Rules Governance Features
Reminder: organizational issues are out of the IS Rating Tool scope

For each question check one choice ONLY

BR-GV-01 Rules governance

Rules governance features are the business functions used by IS Stakeholders to manage rules. This is a list of business features brought by the BRMS, such as rules authoring, version management, etc.

The way of these functions are used through processes and organizations are not measured here. Indeed, the IS Rating Tool copes with the IS Intrinsic value which means the list of rules governance features, not the quality or maturity levels of organizations to use them.

Amongst these features, a detailed assessment is required to measure the rules lifecycles and version management function.

BR-GV-01-1 Unified rules governance
All rules benefit from unified and shared governance functions used by all IS Stakeholders, not only by IT specialists

FALSE

0,0

All rules are managed through unified and shared governance functions such as: authoring rules, version management, traceability of rules executions, rules history, rules tests, rights management, etc. These functions are applied to every type of rules: core business rules, organizational rules and security policies (see BR-KN-01-1).
From an IT point of view, these business governance functions are brought by a BRMS (Business Rules Management System).

Rules governance functions are not unified. Every project uses its own solutions with discrepancies from other projects. Most of the time, rules are documented through poor systems such as spreadsheets without real governance functions

Lack of metrics but you suppose that less than 50% of rules share some basic governance functions, without using a BRMS

About 20% of rules share governance functions brought by a BRMS applied to a subset of the system. The rest of rules is managed through heterogeneous functions including spreadsheets

More than 50% of rules share governance functions brought by a BRMS applied to a subset of the system. The rest of rules is managed through heterogeneous functions including spreadsheets

A large scope of the system shares rules governance functions brought by the BRMS. These functions are used by both IS Stakeholders and IT specialists depending on needs

Main criteria to be considered for rating:
shared and unified rules governance functions, use of spreadsheets, BRMS

BR-GV-01-2 Rules lifecycles and
version management
Amongst rules governance functions, the lifecycle and version management is a significant feature requiring a specific assessment

FALSE

0,0

The lifecycle and version management of rules is vitally important to enforce a real rules governance. Two types of features are needed:
- It should be possible to create versions of rules and compare versions,
- it should be possible to manage stages of rules from their inceptions to their retirements.

It means that at any time, it should be possible to reverse rules changes by benefiting from a full version history of rules authoring.

Rules used data which should benefit from the version management brought by the MDM applied to ref/master data structures and values (see Data Assessment part). It means that every rule should have a context identifier defining in which version of data its execution is issued. In doing so, when the BRMS looks up the MDM to retrieve ref/master data values, it provides the context in which this request is issued, then the version.

No unified and complete rules lifecycle and version management. Every project establishes its own solution including basic copy of rules

Lifecycle and version management is enforced by adding codes and dates of validity to rules without real business governance functions. It means that this mechanism is used by IT specialists mainly

Lifecycle and version management is brought by a BRMS but applied to less than 20% of the system. The rest of rules are managed through heterogeneous approaches including copy of rules

Lifecycle and version management is brought by a BRMS applied to 50% of the system at least. All IS Stakeholders are able to use the lifecycle and version management of rules. The connection to the data version management is not well-established

Lifecycle and version management is brought by a BRMS applied to a large scale of the system, more than 80%. All IS Stakeholders are able to use the lifecycle and version management of rules. The connection to the data version management is well-established

Main criteria to be considered for rating:
unified lifecycle and version management functions, enforcement scope

BR-GV-01-3 Rules authoring
Rules authoring should be possible for all IS Stakeholders, not for IT specialists only

FALSE

0,0

A unified rules authoring function should be available for all IS Stakeholders and managed through a secured authentication. It means that authoring rules should not be dedicated to IT specialists only. According to the company's culture, key business users can be involved in authoring rules directly or prefer to delegate this work to IT teams. In any case, rules should rely on a business oriented grammar ensuring a full business understanding and formulation of rules (see also BR-KN-02-1 Rules grammar).

No unified rules authoring functions. Every project uses different approaches from spreadsheets to more sophisticated tools

Some unified authoring functions exist but they are used by IT specialists only. It means that there is a risk of business-IT misalignment

Unified rules authoring functions exist. They are brought by a BRMS. They are applied to less than 20% of the system. The rest uses heterogeneous approaches. IS Stakeholders are not really involved in authoring and reading rules

Unified rules authoring functions exist. They are brought by a BRMS. They are applied to 50% of the system at least. All IS Stakeholders are able to use these functions

Unified rules authoring functions exist. They are brought by a BRMS. They are applied to a large scale of the system, more than 80%. All IS Stakeholders are able to use these functions

Main criteria to be considered for rating:
unified rules authoring functions, business oriented, enforcement scope

BR-GV-02 Managing Rules as a real Asset

Rules are a real IS Asset changing over time. They allow to formalize the business strategy, the organization strategy and the security policies (see BR-KN-01-2, 3 and 4). It is significant valuable to measure trends rather than occasional performances only. It means that key indicators should be defined and measured over time.

Moreover, it is valuable to set up rules overseeing rules. This approach allows to throw alerts in real time when needed.

As a real IS Asset, all rules executions should be tracked through a unified business audit trail.

BR-GV-02-1 Rules Asset measurement
Key indicators should be defined to follow rules assets over time.

FALSE

0,0

A lot of key indicators could be defined to follow rules assets. You should distinguish key indicators applied to rules executions and those applied to rules definitions. These indicators should be useful to all IS Stakeholders, not only within IT department. Depending on the company's culture, key indicators related to rules assets can enrich an IT scorecard and/or contribute to establish a more global scorecard at the whole scale of the system. Defining key indicators is not easy to achieve as it requires a good level of maturity in the management of systems. However the accuracy of key indicators are less important than their variations over time. It means that you should be interested in trends rather than occasional performances only.
Example of key indicators:
- number of rules related to a business regulation,
- number of rules modifications within a period of time,
- number of rules executions within a period of time,
- rules not used within a period of time,
- rules used the greatest number of time during a period,
- ratio of business rules compared to organizational rules per business unit within the company,
- all measures brought by the IS Rating Tool,
- etc.

Lack of key indicators to follow rules assets. Therefore an informal knowledge of rules assets is enforced only and still remain in hands of some key people within the system

Some key indicators about rules assets are established but they don't rely on a structured approach such as the IS Rating Tool. Therefore, these key indicators are used mainly within IT department, without a real involvement of all IS Stakeholders and without possible bench-learning with other organizations

A first level of key indicators about rules assets is established and rely on a structured approach such as the IS Rating Tool. As these indicators are not fully detailed, they are used within IT department mainly

A rich set of key indicators about rules assets is established and rely on a structured approach such as the IS Rating Tool but they still remain IT oriented only. This set of key indicators is updated over time and allows IT department for managing its own risks. This is a good foundation to deploy a further extended approach encompasses business key indicators

A rich set of key indicators about rules assets are followed closely by different IS Stakeholders, not within IT department only. These key indicators are updated over time to compute trends. They rely on a structured approach such as the IS Rating Tool. Correlations between key indicators allow for making some forecasts and then contribute to risks management at the whole scale of the system

Main criteria to be considered for rating:
key indicators relying on a structured approach, ability to provide key indicators meaningful outside the IT department

BR-GV-02-2 Rules Asset overseeing
Beyond key indicators applied to rules assets (see BR-GV-02-1), rules overseeing some key business and organizational rules and security policies should be also established.

FALSE

0,0

When rules are managed through a rules repository such as a BRMS, it becomes easier to add alerts to oversee them. These alerts can check the outcomes of rules executions but also can react depending on thresholds applied to key performance indicators (see BR-GV-02-1). Alerts are defined as rules and benefit from the rules management system. For example:
- outcomes of a rule must be conformed to min/max values constraints. It means that all post-conditions applied to rules could be considered as rules overseeing,
- maximum number of a rule execution within a period of time,
- etc.

Lack of unified approach to set up business rules overseeing rules. Every project establishes its own solution depending on requirements

Some business rules are defined to oversee rules but they are hard-coded within opaque software, not meaningful for all IS Stake-holders. It means that BRMS repository is not used

Some rules are defined to oversee rules through a BRMS. However, as these rules still remain limited, IS Stakeholders are not really involved

A rich set of rules are established over the rules repository to oversee rules in real time, but limited to less than 50% of the system. These rules are authored and executed through a BRMS to avoid the approach of hard-coding. IS Stakeholders are partially involved

A rich set of rules are established over the rules repository to oversee rules in real time, at a large scale of the system. These rules are authored and executed through a BRMS to avoid the approach of hard-coding. IS Stakeholders are fully involved in managing these rules

BR-GV-02-3 Rules Asset tracking
All rules execution should be tracked in order to enforce IS traceability

FALSE

0,0

When a rules repository is enforced by a BRMS, then a unified business audit trail should be available directly. This audit trail is used to keep track all rules executions. Query functions allow all IS Stakeholders for seeking and consulting the audit trail, depending on their permissions.

Lack of unified approach to ensure traceability of rules executions. Every project establishes its own audit trail mechanism. It brings a big concern to deliver audit operations needed by business regulations

A unified solution to ensure an audit trail of rules executions is established but without benefiting from a BRMS. This solution still remains IT and business IS Stake-holders are not really involved

Audit trail of rules executions is established with help from a BRMS at a subset of the system, less than 50% only. It copes with some key rules only which means that all rules don't benefit from the audit trail brought by the BRMS

Audit trail of rules executions is established with help from a BRMS, at a subset of the system, less than 50% only. It copes with all rules

Audit trail of rules executions is established with help from a BRMS, at the whole scale of the system, applied to all rules. It means that all IS Stakeholders are able to use the audit trail, depending on their permissions

Main criteria to be considered for rating:
using a BRMS to establish a unified audit trail of rules executions, involvement of IS Stakeholders

Intermediary mark
Mastering Rules Governance

out of

0,0%

Mastering IT Approach To Manage Rules

For each question check one choice ONLY

BR-IT-01 Rules engine versus
hard-coding

All rules descriptions ensured with help from the Enterprise Rules Architecture (see BR-KN) and managed through rules governance functions (see BR-GV) shouldn't be diluted through an heavy and rigid hard-coded development only.

It means that to ensure a good Business-IT alignment, a rules engine should be used. When it is enriched with rules governance features, as discussed in BR-GV, it becomes a Business Rules Management System (BRMS).

BR-IT-01-1 BRMS applied to
Existing systems
To leverage existing systems without overhauling them, it is recommended to extract key hard-coded rules to rewrite them with help from the BRMS. To achieve this goal, modeling and implementation procedures should be established, and a strategic long-term plan should be defined to support this progressive restructuring of existing systems.

FALSE

0,0

Modeling and implementation procedures should exist to enforce a progressive extracting of existing hard-coded rules for the benefit of the rules engine. In doing so, the readability, agility and ability to audit the system is really improved. When combining this approach with an efficient Enterprise Rules Architecture (see BR-KN), your company can attain a better Business-IT alignment.

No modeling and implementation procedures to support a progressive extracting of existing hard-coded rules. It means that existing systems cannot benefit from the BRMS. The Business-IT alignment applied to existing systems is slowed down

Modeling and implementation procedures exist to extract and rewrite hard-coded rules for the benefit of a BRMS. But this approach is not aligned with the Enterprise Rules Architecture. These procedures are used by some early adopters projects without a long term strategy applied to a large scale of the system

Modeling and implementation procedures exist to extract and rewrite hard-coded rules for the benefit of a BRMS. This approach is aligned with the Enterprise Rules Architecture. These procedures are used at a significant scope of the system, at least 20% but without a long term strategy applied to a large scale of the system

Modeling and implementation procedures exist to extract and rewrite hard-coded rules for the benefit of a BRMS. This approach is applied by benefiting from the Enterprise Rules Architecture. A clear strategy is applied to restructure existing systems with this approach, at least 10% of the system is rewritten per year and included software packages customizations such as with ERP

Main criteria to be considered for rating:
modeling and implementation procedures to extract and rewrite rules, long-term strategy to support the rewriting of hard-coded rules

BR-IT-01-2 BRMS Applied to new development
Every new development and software package customization should benefit from the BRMS in order to improve transparency, agility and ability to audit systems. A strategic long-term plan should be defined to endorse the BRMS use at a large scale of the system.

FALSE

0,0

Modeling and implementation procedures should exist to support the BRMS use rather than an approach of hard-coding only. It means that the number of rules grows when developing and acquiring new systems, including software packages such as ERP. Indeed, customizations of software packages should be put to the BRMS to ensure a better rules traceability and a better way of managing software packages upgrades.

No modeling and implementation procedures to support the BRMS use. It means that new systems don't benefit from the BRMS. Therefore, the IS is hard-coded mainly which brings huge concerns to align it with business requirements

Modeling and implementation procedures exist to support the BRMS use. But this approach is not aligned with the Enterprise Rules Architecture. These procedures are used by some early adopters projects without a long-term strategy applied to a large scale of the system

Modeling and implementation procedures exist to support the BRMS use. This approach is aligned with the Enterprise Rules Architecture. These procedures are used at a significant scope of the system, at least 20% but without a long-term strategy applied to a large scale of the system

Modeling and implementation procedures exist to support the BRMS use. This approach is applied by benefiting from the Enterprise Rules Architecture. A clear strategy is applied to the whole scale of the system, including software customizations such as ERP

Main criteria to be considered for rating:
modeling and implementation procedures to support the BRMS use, long-term strategy to limit the approach of hard-coding of rules

BR-IT-01-3 Level of hard-coded rules
Regardless of your mark about the BRMS applied to existing systems and new developments (BR-IT-01-1, 2), you should be able to measure the level of hard-coding of rules within the system.

FALSE

0,0

You should be able to estimate the level of hard-coded rules within the system. Without any rule engine, your mark is bad. When using a rule engine, your mark depends on how it is deploy within the system.

No use of BRMS then the system is fully hard-coded

Use of heterogeneous approaches to put some rules into rules engines. It means that every project establishes its own rules engine depending on its requirements and funds. Lack of metrics to estimate the percentage of rules managed through rules engines

Use of a BRMS at a large scale of the system but applied to some specific uses cases only. For example, all pre- and post-conditions of services (SOA) are established with help from the BRMS. You can estimate that about 20% of rules are managed through the BRMS

Use of a BRMS at a large scale of the system to manage organizational rules and security policies only. It means that core business rules still remain hard-coded mainly. You can estimate that about 40% of rules are managed through the BRMS

Use of a BRMS at a large scale of the system to manage all types of rules: organizational and core business rules, and security policies. More than 50% of rules are managed through the BRMS

Main criteria to be considered for rating:
use of a BRMS, enforcement scope

BR-IT-02 Rules execution and test

BR-IT-02-1 BRMS applied to batch operations
The BRMS shouldn't be limited to real-time operations only. Most of the time, a significant part of the system works in a batch mode and rules can be shared with ones used in real-time system. Moreover, it could be helpful to restructure batch treatments with a rules engine for restructuring them into more real-time executions.

FALSE

0,0

Most of the time the BRMS is applied to real-time operations first. However, to really improve the agility and traceability of the whole system, it is necessary to tackle rules within batch operations also. Then modeling and implementation procedures should exist to enforce the BRMS use when designing batch operations.
Today's new BRMS technologies remove many IT barriers in term of rules execution performance. For example, some BRMS tools allow for automatically translating business rules into Cobol language and then compile it to run on mainframes directly.
Beyond this IT ability to execute large set of rules, modeling procedures should be also well-established to redesign usual heavy batch operations in more real-time ones. As business is becoming more agile and real-time then the level of batch operations should decrease for the benefit of real-time operations.

There is a significant part of batch operations within the system and they don't benefit from a BRMS. It means that your system still remains hard-coded mainly

There is a significant part of batch operations within the system. Only some of these operations benefit from the BRMS because you face IT problems in term of rules execution performance. You can estimate than less than 10% of batch operations are managed through the BRMS

There is a significant part of batch operations within the system. You can estimate that 30% at least of batch operations are managed through the BRMS. The reuse of rules between real-time and batch operations is enforced

There is a significant part of batch operations within the system. You can estimate that 50% at least of batch operations are managed through the BRMS. The reuse of rules between real-time and batch operations is enforced

First case: the system hasn't a significant part of batch operations. Therefore using or not a BRMS is not a key point. Thus, by default your score is 'optimized'

Second case: there is a significant part of batch operations within the system and they fully benefit from the BRMS. Moreover your modeling procedures encourage a restructuring of batch operations for being more real-time. The reuse of rules between real-time and batch operations is enforced

Main criteria to be considered for rating:
use of a BRMS, enforcement scope

BR-IT-02-2 BRMS with MDM
In order to deploy the BRMS at a large scale of the system, it is necessary to streamline data quality first. It means that reference and master data values used by rules should be retrieved through a unified data repository providing the “one version of the truth”, in other words a MDM must be enforced.

FALSE

0,0

When a rule is executed, it consumes two natures of data. First transactional data stemming from the system issuing the rule execution request. Second, reference and master data. For those data their origin is more complicated as they are often duplicated and scattered across the whole IS.
Then when adding a new rule within the BRMS, this question is raised: where must we retrieve reference and master data values for this rule? Are they provided by the system issuing the rule execution request? Are they provided by other siloed systems? Are they provided by the integration layer?
In short, adding a new rule within the BRMS could become a nightmare when ref and master data values are not well-managed. To fix this problem, it is necessary to establish a reference and master data repository first, in other words a Master Data Management solution (MDM).
Moreover, to succeed in this approach, modeling and implementation procedures should exist to ensure that the unified data model designed for the MDM is well-established to support rules integration as described here.
To get more information about those modeling procedures we invite you to visit the MDM Alliance Group community (mdmalliancegroup.com).

No use of MDM. Adding a new rule in the BRMS is a heavy work to retrieve ref and master data values scattered across the system. Therefore, the BRMS use is slowed down by the lack of MDM

Limited use of the MDM. Adding a new rule in the BRMS still remains a heavy work as the scope of the MDM is reduced. Many IT developments still remain required to retrieve ref and master data values across the system. Even though you are willing to connect the BRMS with the MDM, this is not yet available

Full use of the MDM with the BRMS but applied to less than 20% of the system. Within this scope, adding a new rule is cost-effective and reliable as all ref and master data are retrieved through the MDM directly. The data models used by the MDM are not completely designed to match the connection with the BRMS which is a trouble to deploy this approach at a larger scale of the system

Full use of the MDM with the BRMS applied to about 50% of the system. Within this scope, adding a new rule is cost-effective and reliable as all ref and master data are retrieved through the MDM directly. The data models used by the MDM are designed to match the connection with the BRMS which is a good foundation to deploy this approach to the rest of the system

Full use of the MDM with the BRMS. Adding a new rule is cost-effective and reliable as all ref and master data are retrieved through the MDM directly. The data models used by the MDM are designed to support the connection with the BRMS. This architecture MDM+BRMS is used at the whole scale of the system

Main criteria to be considered for rating:
linking value of MDM+BRMS, ability of data models to support the connection with the BRMS

BR-IT-02-3 Test rules against requirements
When using a BRMS, it is valuable and cost-effective to establish tests procedures of rules

FALSE

0,0

When using a BRMS, rules are both readable by business users and IT runnable directly. It avoids heavy waterfall lifecycle development where rules are testable after having implemented them only. Even though all tests cases are not runnable before some IT integration and development, the ability to test rules when using a BRMS is significant improved.
Furthermore, it is highly recommended to set up non regression user acceptance tests of rules.

Lack of tests procedures of rules. Every project uses its own approach depending on IT platforms used. Most of the time, a waterfall lifecycle development is enforced, preventing efficient tests of rules before implemented them

Some tests procedures of rules exist but they not rely on the BRMS. It means that there is a gap between the rules definitions and their tests. This gap could provide some Business-IT misalignments

Some tests procedures of rules exist and rely on the BRMS. But this approach is applied to a subset of the system, around 20%

Some tests procedures of rules exist and rely on the BRMS. This approach is applied to 50% at least of the system

Tests procedures of rules are well-defined and rely on the BRMS. This approach is applied to a significant scale of the system. It means that most of the tests cases of rules can be checked by business users before having integrated them within the software. This approach is used to enforce non regression user acceptance tests of rules

Main criteria to be considered for rating:
use of the BRMS to enforce test rules, endorsement scope

BR-IT-02-4 BRMS loose-coupling architecture
To enforce a real agile rules management, it is recommended to follow the loose-coupling architecture.

FALSE

0,0

To enforce the BRMS loose-coupling architecture three patterns should be used:
- agnostic request: when a system issued a rule execution request, it mustn't know which rules could be run. It means that the requester is agnostic towards rules. It provides to the BRMS a context only. With this context, the BRMS must be able to compute which rules are the right ones to execute,
- data context: the context provided by the requester to the BRMS must be comprised of a header and a body. The header brings the call context including the caller's identifier and from where its requests is issued such as its pre-condition or post-condition. The header should integrate other information such as a version label. The body is comprised of all data related to business objects handled by the caller. It means that rather than conveyed a specific data flow, it is more agile to send a large data flow. Thanks to this approach, when adding a new rule requiring new data values, it is more likely that these values are already conveyed by the caller, which avoids a useless software maintenance,
- variation points: within the logical architecture of the system, it is highly recommended to set up some patterns establishing systematic calls to the BRMS, even if no rules are required when designing the first version of the system. For example, every pre- and post-condition of services (SOA) should integrate a call to the BRMS when implementing the software. Afterwards, when it is time to configure the system, it is easy to add new rules to customize pre- and post-conditions of services without any software maintenance.

No loose-coupling architecture. The BRMS is tightly coupled with the software. It means that adding new rules requires heavy IT development. This situation could compromise the use of the BRMS

All patterns enforcing the BRMS loose-coupling are fully used. It means that the BRMS integration is well-streamlined. Adding a new rule doesn't require heavy IT development.

Note: if your mark is bad about the connection to the MDM (see BR-IT-02-2) then you should have trouble to add new rules within the BRMS even if it is implemented in loose-coupling architecture

Main criteria to be considered for rating:
loose-coupling architecture, ability to add easily new rules without software modifications

Intermediary mark
Mastering IT approach to manage Rules

out of

0,0%

Performance Level Percentage about your IS ability to manage
Rules as a real IS asset

0,0%