 | Level: Introductory Arun Chhatpar (arunchhatpar@gmail.com), Software Architect, OmniViz
04 Mar 2008 The business rules architect plays a crucial role designing business rules
models that are well organized and intuitive for both technical and
business stakeholders to understand. This article discusses the importance of the role
and uses the business rules development life cycle to describe the responsibilities
of the rules architect in creating a reliable and extensible business rules
implementation.
What is a business rules architect?
As described in the article "Introduction to business rules"
(see
Resources), business rules are a means of
implementing and enforcing business policies. Business rules management
(BRM) systems automate and manage decisions based on business rules. As BRM systems
become more popular and more companies start implementing them on a larger
scale, they become increasingly complex. So it is important to
design them right from the get-go. A business rules architect is the person
responsible for correctly designing these BRM systems.
Business rules architects work in conjunction with business owners and
IT personnel to build a holistic view of an organization's business rules strategy. The
rules architect is the person who transforms the business requirements of an
organization into
software systems that are solid and stable. The rules architect is tasked
with reducing the overall cost of creating and maintaining business rules by
designing and building simplistic and reusable components.
Qualities of an effective rules architect
Being a rules architect means that you need to not only have technical skills,
but you also need effective communication skills. Let's a take a look at the most
important qualities that are required for a rules architect:
- Expertise in business rules—The rules architect must have experience designing
and developing business rules and systems, and the rules architect needs to have worked with
different BRM tools and systems.
- Ability to understand the business—Understanding the driving force behind
business rules is very important to being able to design a robust system.
- Vision to look beyond the system at hand—Just like an enterprise architect,
a rules architect must not only think about the current system under design,
but also see how it fits in with the enterprise-wide vision and the
organization's architecture as a whole.
- Great communication skills—The ability to communicate effectively with both
business and IT personnel is critical to the success of the rules architect.
- Technologically proficient—A rules architect must have hands-on experience
developing software to completely appreciate the challenges of building a good system
design. Ideally, a rules architect will have held different key positions in
an IT organization, which would enable him or her to understand system
bottlenecks and limitations, and would also help him or her design and propose
the right solutions.
Now that we know what qualities make up a good rules architect, let's take a look
at the key responsibilities of the rules architect in each step of the business
rules development life cycle.
Business rules development life cycle
The goal of a business rules system architect is to separate the business concerns
from the logical code and assemble them in an easily manageable system that allows business users
to create and update rules in an English-like syntax. As with any software system
development, business rules systems have a defined life cycle. The three
major steps in rules development are authoring, deployment, and
maintenance. Let's look at each of these steps and what role the rules
architect plays in each one.
Rules authoring
The first step that a rules architect takes in the business rules development
life cycles is authoring. The subtasks involved in the authoring step are to:
- Identify business rules—The rules architect needs to know what rules must
go in the BRM system. It's a long and iterative process and involves many
interviews, meetings, and discussions with business users.
- Classify rules—The rules architect then needs to classify the rules
that have been identified into the
appropriate categories. Some examples of the categories are front-end
validation rules, back-end workflow rules, knockout rules, and tiering placement
rules.
- Define templates—The rules architect defines artifacts and templates
using the BRM tool. During this substep, the overall structure of the business
logic is defined as templates and making some specific parts of the designated
templates editable. The business user then uses an RMA (explained next) to edit these values according to their business requirements. The set of
editable values can be presented in a Web page using whatever controls and labels that are suitable for the business environment. After they are defined, these templates will act as guiding principles and starting
points for business users to write the rules in the BRM system in an
English-like language. The most common artifacts provided by almost every
industry-leading BRM tool are rule and rule-set templates, decision tables, and
decision trees. In decision tables, rows and
columns represent different conditions and the resulting action is defined by
their intersections. Decision trees graphically depict chains of dependent
conditions leading to an action.
- Create a user interface to put business rules in BRM systems—The rules architect must provide
business users with an interface to create the rules, which is called the rule
maintenance application (RMA), as shown in Figure 1.
- Create rules—The rules architect must then create the rules using RMA.
Figure 1 shows the process of rules authoring.
Figure 1. Complete BRM system architecture
highlighting business rules authoring process
As Figure 1 shows, IT personnel create the templates using the BRM integrated
development environment (IDE) tool, and business
users use these templates to write rules from the RMA. The rules architect plays
a key role in this process.
At the start of the authoring process, the rules architect assists with proper
identification of rules. Proper identification helps to keep unnecessary rules
from creeping into the rules repository. The rules architect has to make sure that all rules are
captured using techniques—such as requirements gathering—through numerous
interviews with business users. The architect may also use tools such as
IBM Rational® RequisitePro® to make this easier (see Rational RequisitePro to the rescue sidebar).
|
Rational RequisitePro to the rescue
The IBM
Rational software product portfolio includes an integrated tool called Rational RequisitePro for managing
requirements. One of its primary features is the ability to manage project-related
documents. You can manage documents created by different business users and
combine them to create one big stack of rules. You can download a trial version and learn more
about Rational RequisitePro from IBM developerWorks (see Resources). |
|
Following identification, the rules architect must ensure correct classification or rules into appropriate
categories. It is very important to classify the rules properly because
classification affects all three steps of the rules life cycle (authoring,
deployment, and maintenance).
The rules architect must then use the right artifacts to define templates. What
are artifacts in BRM systems? They are prototypes, or building blocks, that a
rules author can use to
logically create a set of rules. Examples of artifacts from BRM tools
include rule sets, decision tables, decision trees, and score cards. Should you
use a rule set or a decision tree to define a group of rules? The rules architect
has to decide which rules to use in order to define a group of rules and ensure
that the right artifacts are used to define them.
The rules architect must also design for code reusability. This is where the
architect's technical knowledge is essential. You have to design your rule base
to be extensible and reusable at the same time.
After the business users have created their rules in RMA, the next step is
to deploy them along with your existing application, which is explained next.
Rules deployment
As mentioned earlier, the rules architect must be able to look beyond the current
system. It's not just about what rules go into the system. A rules architect must
also consider how the system under development would interface with existing applications. Most business
rules implementations are either a replacement of existing legacy applications or
a subcomponent of a larger system architecture. The complexity introduced by such a
mixed system makes the integration of a business rules system that much more
challenging. It's outside the scope of this article to describe the complete
integration of legacy systems with newer applications, but let's take a closer
look at some of the steps involved in the deployment process.
The rules architect must choose the type of target implementation. The
current BRM tools allow you to have different deployment options for the rules
engine. Some of these are:
- Inline Java™ application—Runs the rules engine as an inline Java
application.
- Web service deployment—Allows the rules engine to be deployed as a Web
service, accessible from other applications via a standard Simple Object Access
Protocol (SOAP) interface.
- Enterprise JavaBeans (EJB) in an application server—Integrates the
rules engine inside the application server running as an EJB.
The rules architect must define interfaces to interact with existing
external and legacy applications. This step involves integrating new business rules
applications with other applications and enterprise information systems that have
been in operation for some time, often referred to as an enterprise's "legacy"
systems. An enterprise cannot afford any disruption in these legacy systems. So
the rules architect must ensure that the new system works seamlessly with
existing applications. This could involve either opening up your new systems to
other applications or implementing other system interfaces to interact with it.
The rules architect must now deploy the rules engine.
Figure 2 illustrates the rules deployment process of a BRM system.
Figure 2. Complete BRM system architecture
highlighting business rules deployment and integration with external and legacy
applications
The system shown in Figure 2 is quite simple, but that would hardly be the
case in real life. In reality, the rules architect would have been very diligent
about creating the interfaces between the rules engine and the
external and legacy applications.
The rules architect must consider the performance of the rules engine and not let
it become the limiting factor of your overall system performance. This is
different from the performance of the system where the rules engine gets deployed.
Rather, it refers to the performance of the rules engine itself in terms of the
amount of time it takes
to execute the rules and return results back to the calling application. There are
several factors that adversely affect performance, such as improper design of the
data model (for example,
creating a need for multidimensional arrays in your data model). It is always
better to keep the design simple and use single-dimensional arrays. Bad
interface design, hardware limitations, and cross-system interaction can also
degrade performance of the whole system.
From an infrastructure point of view, the rules architect must promote correct
management of the rules repository. Proper management can be achieved by organizing business
rules centrally and modeling business processes and components based on task.
The rules architect must encourage shared infrastructure and applications to reduce costs and improve
information flow. Proper management of the rules repository also enables the architect to reuse business
rules and components for new business areas, enter new markets
quickly, and override specific components as
needed to address new requirements.
Rules deployment is more of an IT task; business users are not involved in it.
They come into the picture again in the final process of rules maintenance as
explained next.
Rules maintenance
The final process in the rules development life cycle is rules maintenance.
Business users, working in conjunction with the rules architect, maintain rules in
an ongoing process. The process gives business users the ability to
make changes to the rules without having to ask the IT staff to do it for them. The
idea behind BRM systems was to give business users complete control over changing
the business logic without having to work with IT personnel. The key here is to have a common
rules repository. It is important to understand the necessity of the rules
repository to understand the rules maintenance process. The repository
must be shared and accessible by different applications. Figure
3 helps illustrate this sharing.
Figure 3. Architectural view of a BRM system
As you can see, all three components—the IDE,
the RMA, and the rules engine—are using a common rules repository. The
idea here is to provide a common base and still allow independent access to business
rules to all components. So even though the rules engine is pointing to the
same repository at run time, business users can make changes to the rules, and
those changes are instantly picked up by rules engine without any intervention from IT. Of
course the rules architect still has to manage things like release management and
versioning. Ideally, however, this is how it works.
The rules architect must provide business users with an interface to change
rules. This interface is the same RMA created in rules authoring that the business
users use to manage and update rules. The templates created there are packaged
together and usually deployed on an application server, giving the business
users a simple Web interface for rules management.
The rules architect must create a strategy for version control. Versioning
provides a trail of all changes. It is very important to incorporate
even the changes that the business users make, so you can
roll back changes in case of a problem.
The rules architect must also create a code-release strategy. Although business
users may not be accustomed to release management concepts, they shouldn't be allowed to
make changes all the time. The rules architect must enforce a workable release
strategy, and business users must be made aware of and follow it. After the
strategy is in
place, business users can update the rules as needed according to the release
schedule.
Figure 4 shows the process of rules maintenance by business users.
Figure 4. Complete BRM system architecture
highlighting business rules maintenance using RMA
Just as in the authoring and deployment steps, the rules architect has certain
responsibilities in the maintenance step as well. But at this point in the
process, the architect does not have much to do other than to ensure that the
new rules system is deployed properly and the RMA is always available for business
users to make changes to the rules.
Another responsibility of the rules architect is to create a simple
and user-friendly interface. The rules developer usually creates the RMA pages,
but the architect can and should enforce a simple approach to designing the
look and feel of the user interface (UI). I cannot stress how important this is. At one of my engagements,
one of the leading BRM tools was almost thrown out because its out-of-the-box
UI was very hard to work with. So, try to keep it simple.
The job of a rules architect might sound straightforward on the surface, but it is probably one
of the must challenging jobs in IT today.
Summary
A good rules architect is someone who truly understands the business rules
landscape well—not just the business rules and the interfaces to legacy
applications—but the real soul of the system. They are the ones who, given a
particular system to implement, will come up with a number of different solutions,
but will also know the right one to choose. I hope this article gave you a good
introduction to this challenging role.
Acknowledgment
I would like to thank Deven Samant, my mentor and business rules systems guru,
for his guidance and expertise in advising me on this article.
Resources Learn
-
Introduction to business rules (developerWorks, February 2008) demonstrates the
importance of business rules management (BRM) systems in
bridging the gap between business and IT.
-
Business Rules Community has a
lot of articles and tutorials and is a very good place to start learning more about
business rules.
-
"The Phased Approach to Mining Business Rules," Business Rules Journal, Vol. 8, No. 5 (May 2007),
by Mukundan Agaram, has very good examples on how to mine for business rules in
your system.
-
Very informative article by
Ronald G Ross that makes a good case on if all rules are business rules.
-
Creating and deploying business rules
(Neil Kolban, developerWorks, October 2006) is a neat tutorial that shows you how
to use IBM WebSphere Integration Developer to create and deploy a solution that uses
business rules, and then test that solution in IBM WebSphere Process Server.
-
WebSphere Process Server: IBM's new foundation for SOA
(Wolfgang Kulhanek and Carol Serna, developerWorks, September 2005) is an
introductory article explaining WebSphere Process Server and the business rules
service component for that server.
- Read the article
Business rules management systems
for an explanation of what BRM systems are and what you
should look for before selecting one for your enterprise.
-
Business Rules for Everyone blog
has
informative and interesting discussions on business rules, design, and
architecture.
- The
Enterprise Decision Management (EDM) blog
is a good source of articles and discussions on EDM.
- The article
IBM WebSphere Developer Technical Journal: Introducing the WebSphere Integration Reference Architecture
(developerWorks WebSphere, August 2005) provides an overview of the WebSphere
Information Integration architecture.
- Get the latest version of
Business Process
Execution Language for Web Services, Version 1.1 specification.
- To learn more about IBM WebSphere Business
Integration Server, visit the
WebSphere Business
Integration Server product site.
You'll find technical documentation, how-to articles, education, downloads,
product information, and more.
- Find resources for IBM WebSphere Business
Integration developers on the
WebSphere Business Integration zone.
- Take advantage of
IBM WebSphere training and certification resources.
- See the
Rational EGL resources page
for information about Enterprise Generation Language (EGL), the modern version of
4GL, which is used for defining business rule logic.
- Rational Unified Process includes the
business modeling discipline, which focuses on how to understand the business
domain—including business rules—effectively. Find out more
about Rational Unified Process® (RUP®).
Get products and technologies
Discuss
About the author | | | Arun Chhatpar is a regular contributing author to IBM developerWorks and
he possesses
more than ten years of software design and development experience encompassing
decision
analytics, rusiness rules management systems, core Java, UI frameworks, and
workflow orchestration. He is also a Sun Certified Enterprise Architect and
business rules expert. |
Rate this page
| |
