Business Rule Management System
I suspect that many of you are familiar with the term "hard coding a value" whereby the age of an individual or their location is written into the condition (or action) of a business rule (in this case) as shown below:
if customer.age > 21 and customer.city == 'denver'
Such coding practices are perfectly expectable provided that the conditional values, age and city, never change. They become entirely unacceptable if a need for different values could be anticipated. A classic example of where this practice occurred that caused considerable heartache in the IT industry was the Y2K issue where dates were updated using only the last 2 digits of a four digit number because the first 2 digits were hard-coded to 19 i.e. 1998, 1999. All was well provided that the date did not advance to a time beyond the 1900’s since no one could be certain of what would happen when the millennia arrived (2000). A considerably amount of work (albeit boring) and money, approximately $200 billion, went into revising systems by way of software rewrites and computer chip replacements in order to thwart any detrimental outcomes. It is obvious how a simple change or an assumption can have sweeping consequences.
You may wonder what Y2K has to do with Business Rule Management Systems (BRMS). Well, what if we considered rules themselves to be hard-coded. If we were to write 100s of rules in Java, .NET or whatever language that only worked for a given scenario or assumption, would that not constitute hard-coded logic? By hard-coded, we obviously mean compiled. For example, if a credit card company has a variety of bonus campaigns, each with their own unique list of rules that may change within a week’s time, what would be the most effective way of writing software to deal with these responsibilities?
A BRMS is a software application, typically written in Java but may also be written in C# or C++, that allows for the swift and elegant replacement of groupings of business rules or a repository of business functionality. Rules in this repository are often contained within XML files referred to as instance files i.e. instances or snapshots of the rules as they appear today, tomorrow, yesterday or some day. Replacing the file with another file replaces one set of rules for another. How did these rules get placed into XML files? Read my article titled: The Templatization of Business Rules.
The rules are placed into an XML format for the following reasons:
- can distinguish a well formed document using XSDs (XML Schema Defintion) or DTDs (Document Type Definition) - this means that if the rule entries are incorrect, the well formed document checker will let us know.
- parsers, either DOM or SAX parsers, are readily available and are often built into the API of the software language (C# in particular) enabling for ease of storage and ease of reconfiguration back into the system
- no database is required. The need to create database tables with strongly typed columns (anything other than varchar, text or blob) is not a requirement.
- rules in a BRMS are organized in a network that can be visualized as a grouping of sub-networks contained within a larger network that are organized by flow of events or lock-step flows as illustrated in the figure below. The colored nodes represent sub-networks, black/white nodes represent decision nodes and/or sub-flows ...
Placing rules into XML does not address how human beings can easily read this information. That's right; even us software engineers struggle reading XML. To compensate for this difficulty, some BRMS vendors have provided english like syntax akin to the following:
if the customer's age is greater than 21 and the customers city is denver
Consider that it is possible to have hundreds, if not thousands, of such rules that can be updated, deleted and added to the repository. Would it be possible for more than one individual to make these changes? How and when will the newer rules get deployed? How do we test these rules? Can I have of log of rule changes?
Architecture of the BRMS
The typical architecture of a BRMS is one that is centered on web technologies. The software developer, using a Data Dictionary, UML Class and Sequence Diagrams and copious notes gleaned from lengthy coversations with SMEs (Subject Matter Experts) develops a rule application via an IDE (Integrated Development Environment) that includes, among other things, a rule flow invocation, rule templates and a web application. This application can be used by a BA/Rule Author to edit rules using an internet browser or even an ipad. Once completed, the rules are stored, by way of the rule application, in the rule repository. The runtime application will then employ the rules to process incoming customers requests.
What comprises the web & application server is software that can handle incoming html requests, generate XML and HTML content, store the generated information in a repository, access this information upon an incoming customer request, create a rule network, use the network to access and to store information in the database and, finally, send a reply.
Software Development using the BRMS
You may wonder why there has been no mention of a componentized design whereby a group of rules represent a component that can easily be switched via some proxy or handle methodology for some other group of rules in an application. This is a common architectural design that has been used successfully in a number of large software systems: by componentizing different portions of the application, one component of functionality is replaced for another.
You may also wonder why I have mentioned BAs and ease of readibility and software development. Well here's something to consider: a BRMS is relatively ineffective if a BA cannot read and develop the rules. After all, BAs represent the business and its needs as described in the rules. Take the bonus campaign example, the BA is on the hook to ensure that money is not lost due to improper logic i.e. a bad rule. This is the reason that English like rule syntax languages have been created so that anyone can open an IDE to a BRMS and begin developing rules. It is also the reason why a component based architecture will not necessarily work since such designs are synonymous with compiled java, C# or C++ code, and compiling is not in the BA's realm of expertise.
If rule development can be done seamlessly by someone who is not a software developer, then the business is empowered to bring effective changes to market in an expidited manner. This means that the software developer is on the hook to develop rule templates that are used by the BA to construct the business rules. Now the BA does not need to know anything about templates. In many development environments, all the BA can access is a portion of the rules as they apply to their particular division.
Benefits of the BRMS
- Reduced reliance upon IT - the entire point of rule templatization is to enable rule developers i.e. non-software engineers to write rules without the assistance of the IT department. This is a major benefit to the organization as the time delay between rule deployment in a traditional software environment vs the BRMS is considerable enough to warrant a proof of concept or a discussion at the very minimum. Testing and Quality Assurance should still be involved to ensure the system integrity prior to each rules update.
- Rule managed is controlled by the business - with IT 'out of the picture', business managers now have control over rule lifecycles and editing of rules. With one less department in the mix, confusion is minimized.
- High correlation of business venacular to rule development - rules can be written in such a way that they can be read by anyone familiar with the business thereby not requiring IT expertise. See the article An Object Model and the Data Dictionary Components such as decision trees, decision tables, score models and rule flows offer an immense development aid.
- Automated processes can be instituted to deploy rules. To react to market changes and the competition, this may prove invaluable.
Disadvantages of the BRMS
- Extreme expertise required to develop and implement - Individuals that posses vendor specific BRMS knowledge, business rules knowledge, advanced software skills to deploy, design and develop applications, communication skills to effectively communicate with the business and knowledge of industry best practices are required. Since such individuals are rare, they may be employed only with considerable expense to the corporation.
- Extensive development cycle is the norm - Creating a BRMS is not easy task as it requires a stable Object Model, rule harvesting, organization and template rule creation and system design and development that includes a well defined security model. All of these processess are not common to an out-of-the-box vendor BRMS implementation and are unique to each development environment.
- IT departments may always need to be involved - something as simple as introduction of new rule condition requires the involvement of IT department. If new rule types are introduced, there, too, the IT department will have to be involved. The goal to dispense with the use of the IT department may never come to pass.
- Not optimized for highly computational tasks - a BRMS is not the ideal development environment for writing complex algorithms for a number of reasons beginning with decreased efficiency of the rule engine to handle these computations and ending with a failed attempt to templatize such code. If it is difficult for the IT department to implement, it will be difficult for the rule developer to do the same.
- Perturbation of the Object Model may have system wide implications - having been involved in a number of BRMS training and consulting engagements, it is our experience that something as simple as an enum can reak havoc on software development requiring, at times, hours of work to fix compiler errors. Though this may be true for the general software process, it is especially true for a BRMS since the way data is sent to the rule engine is typically by way of an object model. Obviously, if the model changes it willl affect all the rules whose conditions and actions are dependent upon it.
- Strong coupling to a particular BRMS vendor - once the decision has been made to develop a system using a BRMS, the success of implementation hinges upon the functionality and attributes of a particular BRMS vendor. The option to write-out or remove this product without serious cost, development, efficiency and time implications are next nill.
- Enterprise Rule Applications
- Articles from Software Fans
- Visual Studio .NET
- C++ Tutorials
- The World of IT Training
- Python Tutorial
- Blaze Advisor
did you know? HSG is one of the foremost training companies in the United States
Our courses focus on two areas: the most current and critical object-oriented and component based tools, technologies and languages; and the fundamentals of effective development methodology. Our programs are designed to deliver technology essentials while improving development staff productivity.
An experienced trainer and faculty member will identify the client's individual training requirements, then adapt and tailor the course appropriately. Our custom training solutions reduce time, risk and cost while keeping development teams motivated. The Hartmann Software Group's faculty consists of veteran software engineers, some of whom currently teach at several Colorado Universities. Our faculty's wealth of knowledge combined with their continued real world consulting experience enables us to produce more effective training programs to ensure our clients receive the highest quality and most relevant instruction available. Instruction is available at client locations or at various training facilities located in the metropolitan Denver area.
course schedule we are always working
- 10174: Configuring Microsoft ShareP 2010
4 May, 2015 - 8 May, 2015
- 10174: Configuring MS Share-P 2010
6 April, 2015 - 10 April, 2015
- 10265: Developing Data Access Solutions
11 May, 2015 - 15 May, 2015
- 10266: Programming with C#
6 April, 2015 - 10 April, 2015
- 10267: Introduction to Web Development
6 April, 2015 - 10 April, 2015
- See our complete public course listing
consulting services we do what we know ... write software
The coaching program integrates our course instruction with hands on software development practices. By employing XP (Extreme Programming) techniques, we teach students as follows:
Configure and integrate the needed development tools
MOntitor each students progress and offer feedback, perspective and alternatives when needed.
Establish an Action plan to yield a set of deliverables in order to guarantee productive learning.
Establish an Commit to a deliverable time line.
Hold each student accountable to a standard that is comparable to that of an engineer/project manager with at least one year's experience in the field.
These coaching cycles typically last 2-4 weeks in duration.
Business Rule isolation and integration for large scale systems using Blaze Advisor
Develop Java, .NET, Perl, Python, TCL and C++ related technologies for Web, Telephony, Transactional i.e. financial and a variety of other considerations.
Windows and Unix/Linux System Administration.
Application Server Administration, in particular, Weblogic, Oracle and JBoss.
Desperate application communication by way of Web Services (SOAP & Restful), RMI, EJBs, Sockets, HTTP, FTP and a number of other protocols.
Graphics Rich application development work i.e. fat clients and/or Web Clients to include graphic design
Performance improvement through code rewrites, code interpreter enhancements, inline and native code compilations and system alterations.
Mentoring of IT and Business Teams for quick and guaranteed expertise transfer.
Architect both small and large software development systems to include: Data Dictionaries, UML Diagrams, Software & Systems Selections and more