Where are your business rules?
Do you document your business rules somewhere out of sight, e.g. coded in:
- Database stored procedures?
- Software applications?
Do you perhaps document them as part of the description of your
- Business data? Business rules can be reflected in the data model
- Business processes? Business processes will be constrained by business rules
- Requirements for computer systems? Requirements will reflect business rules but they not, themselves, business rules
Or are your business rules documented in a rules repository, easily visible and perhaps under the control of the business? When stored in a central location, they can be cross referred to from data models, processes and requirements.
The storage location of the rules will affect the ease with which they can be reviewed and maintained. It will therefore affect the ability of your organisation to respond quickly to changes of business rule; i.e. it will affect business agility.
Questions to ask about your organisation’s business rules
- Are they easily accessible and searchable?
- Are they under the control of the business or of IT?
- Are they buried away in documents, software applications or data base routines?
- Are the business rules distinct from business requirements specifications?
- How long does it take to change a business rule?
- Are your business rules integrated with your business process and data architectures?
- Are your business rules integrated with your automated workflow solutions?
Business rules in the business architecture
Business concepts and data
Concepts: Business owned definitions of data
Business concepts are the fundamental elements of the organisation. Examples are, ‘Customer’, ‘Product’ and ‘Sale’ or ‘Sales Order’. What is your organisation’s concept of a customer? What is your organisation’s concept of a customer, for example?
See section, ‘How well do you know your business data’ for a discussion about how rules can be captured in a data model.
Definitions of concepts and attribute types that are agreed and owned by the business can be considered as a form of business rule.
Business defined associations between concepts
Associations exist between instances of concepts, e.g. the associations between a customer, a sales order, the sales person, the product purchased and the delivery of that product. These essential associations can be considered as forms of business rule.
Business processes and tasks
Processes and tasks will be constrained by business rules.
Rather than cluttering each process or task description with a full definition of the business rules, you make things more agile if these descriptions can simply cross refer to a centrally defined business rule.
If rules are spread around each of the process definitions, maintenance of both the process definitions and the rules is made more complicated, labour intensive and error prone.
Rules and Requirements
Business rules are typically universally applicable across an organisation; they are not confined to a particular computer system. They must therefore be distinguished from the requirements for a system. Systems must be built to enforce business rules that are relevant to a particular requirement.
- Requirements are applicable for one or more computer systems
- Business rules are applicable to the whole business; the clue’s in the name
Gaining control of your business rules
- Extract them from inaccessible documents, applications and database code
- Hold them in their own repository
- Put them under the control of the business community rather than IT
- Ensure that they rules are reflected in business models, workflows and systems designs, i.e. in the business and technical architectures
- Implement the rules on automated rules repositories
- Dynamically integrate your business rules with your business workflows for increased business agility
See Capiro’s business rules consulting services.