Business rules.

BEST PRACTISE PAPER BUSINESS RULES


Introduction
Business rules represent the language and fundamental structure of an organization (Hay,
2003). Every organization follows its own sets of rules and is governed by its policies and procedures. Today’s business relationships are complex, hence to represent such a complex relationship; a good data model is of extreme importance. Business rules are usually atomic i.e. it cannot be broken further into much details hence business rules are the pillars of information systems. Business rules helps in creating a complete view in analyzing companies data, they provide with the medium to communicate between the users and designers. Business rules provides the application layer with data’s that are preliminarily filtered using various rules and constraints such rules can either be embedded in the codes or can be written separately using triggers and stored procedures, hence business rules forms the heart of any business logic. So what factor should determine a business rule? Is it the technological aspects or the business regulations? Is every business rule covered in a model? How a business rules be written, what are the various aspects that a business rule should cover. Well there can be many answers to these questions as business rules changes from organization to organization hence it’s up to the organization to research and find the best practice for its business rules.

Best practice
Business rules written by a business analyst must be in a form that the business owner can immediately accept it or reject it. All business rules should be business and not technology oriented. It must be written in a way that it’s fairly easy to convert the business rules into operational system. It must be atomic, unambiguous¸ compact, consistent and Compatible. The
main source of business rules are company managers or policy makers and various written documents hence there should be a good communication process between the user and the analyst. Business rules can be divided into four part terms, facts, derivations and constraints Terms and Facts are structural assertion where as constraints are action assertion (Hay D. C., january 1,2002). Business rules development process can be broadly classified into three parts
1) Discovering
2) Analyzing and
3) Implementing
In the discovering part, the business rules that governs the organization should be observed carefully and be able to describe the operations of the organization using the plain simple translated language. This business rule is further analyzed.
In the analyzing part the analyst must be able to analyze, organize and manage the business rules discovered, the analyzing part is extremely important and must be done with proper discussion with the user. Different relationships are decided and hence mapping should be done accordingly, that the project architects should have proper training for creating business process and domain model. It’s extremely important to create and establish an organized repository of business rules. Since individual projects generally work on fragments of business processes and we have to assemble the whole project into a single project at the end.

In the implementation part proper entities and attributes are chosen and different data models are created using proper relationships. The end product is the Entity relationship diagram or the ERDs. There is no industry standard notation for ER model and the notation can be easily done using some drawing tools. A lot of time should be given in developing an enhancing accurately represented Data models. As change in business rules can change Data models, Data models should be able to accommodate any change in the business rules; hence a true data
model must possess the ability to inherit as well as to adapt to the change.
At the end the user can test whether the original business rules is validated. Business rules keeps on evolving and same business rules can be used by more than one application hence business rules should not be hard coded.

Assessment
A data model is created based on the business rules of the organization there are certain rules that a data models can and cannot represent. Terms and facts can be represented in the data model and some parts of derivations too i.e. derived attributes can be shown but not derivation formulae’s where as for constraints to be represented , some can be represented and some cannot.
The key benefit of using a business rule based repository model is that the information can be understood by the user as well as the IT professionals. Rules repositories will provide with a full system specification hence allowing independent decisions while handling business rules this holds good even when there is a lot of change in the architecture. Using proper business rule approach the system design can be changed when there is a change in the business rules, business rules can change as a result of new legislative mandates or emerging products,
services, partnership mergers and acquisitions or competition. Using business rule approach provides many advantages in the built system it makes the system simple provides with a theoretical base as well as small number of necessary non technical concepts which are very useful. Using business rule approach can make rule reuse easy and provides with a simplified system design as well as enhance performance. Business rules approaches are beneficial to the business community as well as software engineers. There can be few barriers in adopting such business rules approach like profit driven resistance and the existing culture of an organization to do such things.

Conclusion and recommendation
The business rule approach has made an initial successful entrance in the market and many companies are looking for developing there system using business rule approach. A system that is more flexible, a system that can change easily, a system that the business managers them self design. With different modeling techniques like the OODBMS and UML using business rules for development it is just a matter of time when business rule approach will be the standard way of developing almost all the systems.
All the business organization should use the repository of business rules for their system design in this way they can develop a system that is more flexible, cost effective and delivers high performance.

Glossary
Business rules A statement that defines or constraints some aspects of business rule.
ERD Entity relationship diagram.
UML Unified Modeling Language.
OODBMS Object oriented database management system.
BIBLOGRAPHY
Hay, D. C. (january 1,2002). A Repository Model- Business Rules. The Data Administration
Newsletter, Issue 13. .
Hay, D. (2003). What Exactly is a Data Model? DM review Vol 13,Issue 2.