The evolving role of the business analyst

The business rules analyst emerges as a new star in the

business world

Skill Level: Intermediate

Arun Chhatpar (arunchhatpar@gmail.com)

Senior Rules Architect
Software Architect and Consultant

03 Jun 2008

Traditionally, the business analyst has been responsible for analyzing the business
needs of companies by identifying business problems and proposing solutions. With
the advent of Service-Oriented Architecture (SOA), the business analyst has to think
about issues such as IT services and how to define business logic as rules for easier
and faster change cycles. Thus, a new position called the business rules analyst has
emerged. This article will examine the role of this new star in the business world and
will also help you understand how this role can help improve the return on investment
(ROI) on your business applications.

Introduction
Consider this hypothetical business rule from a mortgage lender: For a $250,000
mortgage, the borrower's combined bank balance must be greater than $20,000 for
last three months, the borrower's credit score must be greater than 650, and the
borrower must not have an open credit of more than $35,000.

Effective management of such complex rules has always been a challenge for
finance-related industries, such as insurance, banking, and mortgage-lendingor
even investment institutions, for that matter. We all know that necessity is the mother
of invention, so this immediate need to realize the value of managing business rules
over the long term has given rise to a new role: the business rules analyst.

The evolving role of the business analyst

Copyright IBM Corporation 1994, 2007. All rights reserved. Page 1 of 10
developerWorks ibm.com/developerWorks

The IT profession has undergone significant change over the past decade. It was IT
software developers who created and implemented enterprisewide applications and
served as major contributors to innovation. But after the tech bubble burst in 2001,
the strategic and business value of IT continued to evolve. IT professionals are once
again being asked to deliver innovative systems to solve complex business
problems. The architectural model established by SOA and further defined by the
common principles of service orientation provides the potential to finally unite the
business and automation domains of an enterprise. To accomplish this though,
organizations must take the time to model and build services that encapsulate and
express business logic in an accurate and extensible manner.

The creation of business services is therefore becoming the focal point of many
contemporary SOA initiatives. Business services require the collaboration of
business analysis and architecture expertise. Although the business rules analyst's
role is fairly new, it has played a key role in this evolution. This role includes new
approaches to business knowledge acquisition and its management, the use of
business process management tools, and more sophisticated approaches to
requirements management.

Business rules and business rules management (BRM)

systems
One of the responsibilities of a business rules analyst is to extract and manage
business rules, which can be defined as a representation of business logic that is
pertinent to a specific business function in a specific industry. Not too long ago
almost all business logic was hard-coded in the business application itself, which
made it very difficult to make even minor changes. But with the advent of BRM,
along with other object-oriented technologies, that pain has been eased.

So what is a BRM system? A BRM system is a complete set of software tools to

create and manage business rules. A business rules engine (BRE), which helps
separate the business rules from the application code, is at the core of any BRM
system. Almost every BRM system (See Resources for a list of top companies in this
field) allows its users to create the rules in English-like language. This in turn allows
the business users to modify the rules frequently without the need of IT intervention
and hence allows the applications to be more adaptable with the dynamic rules.

Every business has rules and almost always, without an exception, the business
units want complete control over these rules. A BRM system makes it possible for
business users to take that control back. See Resources to learn more about
business rules and BRMS.

What is a business rules analyst? Is it really a new role?

The evolving role of the business analyst

Page 2 of 10 Copyright IBM Corporation 1994, 2007. All rights reserved.
ibm.com/developerWorks developerWorks

The term business analyst is not new. How is this new role of the business rules
analyst different from the role of a business analyst? A business analyst is
responsible for analyzing the business needs of their clients to help identify business
problems and propose solutions (see Resources for a link). A business rules analyst,
however, can be thought of as a business analyst with a focus on business rules.
The role's primary objective is to focus on separating rules from code.

You do not need a special degree or qualification to become a business rules

analyst, but you should have experience as a business analyst. Analytical skills are
important for a business rules analyst to discover, capture, and express business
rules in simple English that is easily understandable by business peers as well as
the IT people who are going to design the business application. It is also useful for a
business rules analyst to have an understanding of object-oriented programming
concepts. A business rules analyst doesn't necessarily need to have working
experience as a software developer, but that experience certainly helps them
appreciate and implement the reusability aspect of software development.

The skills needed for this new role are very similar to that of a general business
analyst, but the focus and day-to-day responsibilities are quite different. For
example, it would be the business analyst who facilitates sessions to capture
business rules for a new business application, whereas the business rules analyst
would ensure that the extracted rules reflect the business intent and will result in the
desired business behavior. The business rules analyst also uses these sessions to
understand how rules are enforced, how they are going to change, and how
rule-related issues such as conflicting rules would be resolved.

Figure 1 will help you understand the responsibilities of the two different roles.

Figure 1. The roles of a business analyst and a business rules analyst

The evolving role of the business analyst

Copyright IBM Corporation 1994, 2007. All rights reserved. Page 3 of 10
developerWorks ibm.com/developerWorks

Figure 1 shows the role each expert plays in the rules application development
cycle. There are four steps involved, as explained next.

1. Define the business application. Based on real market need, business

owners decide to introduce a new product. The key players in this step
are business owners and business analysts. After an in-depth feasibility
study and quantitative analysis, they define the requirements for the new
application. The majority of work at this step is done by the business
analysts.

2. Discover rules. The requirements then come to the business rules

analyst, who goes through the documents and extracts business rules
from these requirements. The business rules analyst comes up with a list
of rules in the form of structured natural-language statements that clearly,
completely, and concisely express the rules to be implemented in the
application. The business rules analyst must use his or her knowledge of
process modeling and fact modeling to discover these rules. This step
also involves validating the rules and developing scenarios for testing.

3. Create a framework for writing rules. In this application design and

development step, the business rules analyst works very closely with
rules architects and rules developers to help them design the application
in a way that ensures that the rules reflect the business intent and that the
application will result in the desired business behavior. The key players
here are business rules analysts, rules architects, and rules developers.
The architects design the framework for business rules analysts to write

The evolving role of the business analyst

Page 4 of 10 Copyright IBM Corporation 1994, 2007. All rights reserved.
ibm.com/developerWorks developerWorks

the rules in a simple, English-like language. This is the most important

step, because the business rules analyst has to make sure there is no
redundancy in the rules while also helping the rules architects make
components that will be reusable in other similar applications. The
business rules analyst also structures the rules properly based on a
logical model and works with the rules architect to help design the
application in the BRM system. The rules architect along with expert
developers then create a rules application, known at this stage as rules
templates. Rules templates are guiding models that business rules
analysts use to create the actual rules.

4. Create and manage rules. The final step is to create or add the rules to
the application. The business rules analyst uses a simple Web-based
user interface to create rules for the first time. The business rules analyst
uses the same interface to manage rules in the future. You might have
noticed that the business analysts primarily interact with the management
and business owners, whereas the business rules analysts must talk to all
levels involved in developing the actual solution that the business rules
are part of.

After the rules are created and tested, they are deployed and interfaced with other
logical components of a system. A good business rules analyst elicits the invaluable
knowledge from the business experts, digitizes it, and helps manage it in the most
efficient manner possible.

"With great power comes great responsibility"

I know that's a quote from the "Spider-Man" movie, but the business rules analyst
does have a very important set of responsibilities. The basic responsibilities of a
business rules analyst is to come up with the list of rules in the form of structured
natural-language statements that clearly and completely express the rules, facts,
policies, and procedures to be implemented in the application.

A business rules analyst usually acts in a consulting capacity to a project. Although

the responsibilities might vary from one organization to another, the business rules
analyst generally takes on the following responsibilities:

1. Identify and organize business rules. After the business analysts and
key business stakeholders have defined the requirements, it's the
business rules analyst who has to start the process of identifying the rules
and organizing them into logical groups. The fundamental goal of the
business rules analyst is to get the project defined early by translating the
initial high-level vision into something realistic. They also help to identify
potential areas of automation. Because not all business logic qualifies as

The evolving role of the business analyst

Copyright IBM Corporation 1994, 2007. All rights reserved. Page 5 of 10
developerWorks ibm.com/developerWorks

a business rule, the business rules analyst needs to be able to determine

the difference.

2. Define groups (rulesets) to classify the rules for optimal

understanding and easy searching. This is one of the most important
and difficult responsibilities of a business rules analyst. Although it's not
easy to define, an initial set of groups or rulesets greatly helps with
classifying the identified rules into appropriate groups by functionality,
business domain, or geographic parameters.

3. Ensure reusability of rules across the enterprise. There is a very good

chance that some of the rules that are part of current application are
needed in another project. It's the responsibility of the business rules
analyst to be aware of any and all such business logic. This greatly
reduces the total number of net new rules that need to be developed. It
also make the rules architect happy, because it follows one of the basic
principles of object-oriented concepts.

4. Ensure that the rules use consistent terminology and are readable.
In a BRM system, the rules are created in English-like language, so it
becomes very critical to follow consistent syntax and terminology in all
applications and across the enterprise, which requires the creation of
guides and reference manuals.

5. Promote awareness about the advantages of a business rules

approach. I know it's hard to imagine, but not everyone in an organization
will understand the advantages of business rules engines and a BRM
system. It is the sole responsibility of the business rules analyst to explain
and promote this in very clear terms.

6. Improve the ROI by thoughtful management of rules. In the end it's all
about money, isn't it? The business rules analyst has to live and believe in
the most basic principle of business: reduce costs to improve profits! And
all the responsibilities listed above would eventually result in just
thatlower costs and improved ROI.

Qualities that make the difference

The best business rules analysts are well-organized and patient and have great
communication skills. They have the ability to dig through the complex requirements
given to them by business analysts and stakeholders, and extract the right rules that
would work optimally in a BRM system.

IBM Rational RequisitePro to the rescue...

again!

The evolving role of the business analyst

Page 6 of 10 Copyright IBM Corporation 1994, 2007. All rights reserved.
ibm.com/developerWorks developerWorks

Understanding the requirements created by the business analyst

and then extracting business rules from those requirements is one
of the major responsibilities of a business rules analyst. The IBM
Rational software product portfolio includes an integrated tool for
managing requirements called Rational RequisitePro. One of its
primary features allows you to manage project-related documents.
You can manage documents created by different business users
and combine them to create one big stack of rules. Download a trial
version and learn more about Rational RequisitePro from IBM
developerWorks (see Resources).

The following is a list of must-have abilities for a business rules analyst:

Visualize and implement the bigger picture.

Reduce overall costs and improve ROI.
Provide more efficient use of resources by grouping rules into structured
rulesets.
Correctly identify whether any information in the requirements being
delivered is inconsistent, incomplete, or even irrelevant.
Compile the business information into clear and concise sets that are
easily understood by peers.
Facilitate the resolution of rule-related issues.
Act as a communication broker; business rules analysts typically have
very good connections within the business community and therefore are
in a position to help development teams find the right people to work with.
So now that you know what it takes to be a business rules analyst, do you think it's
in you to handle all the responsibilities? Are you the next Peter Parker for your
company?

Summary
You should now have a complete understanding of what a business rules analyst
does and why the role is so important to your organization. By having a position that
controls the business rules and changes as well as bridges the communication
between management and IT, your organization will see increased ROI and a more
productive workforce.

The evolving role of the business analyst

Copyright IBM Corporation 1994, 2007. All rights reserved. Page 7 of 10
developerWorks ibm.com/developerWorks

Resources
Learn
Rethinking the Role of Business Analysts: Towards Agile Business Analysts? is
an informative article about how the role of a business analyst is changing with
agile computing.
" Introduction to business rules: Taking advantage of Business Rules
Management Systems" (Arun Chhatpar, developerWorks, February 2008)
provides an introduction to business rules and the importance of a BRM system.
" The role of a rules architect: Transform business requirements into IT
realizations" (Arun Chhatpar, developerWorks, March 2008) discusses the
importance of the role and responsibilities of the rules architect in creating a
reliable and extensible business rules implementation.
" Implement business logic with the Drools rules engine" (Ricardo Olivieri,
developerWorks, May 2006) shows you how to use the open-source Drools
rules engine to make a Java application more adaptive to changes.
" WebSphere Process Server: IBM's new foundation for SOA" (Wolfgang
Kulhanek and Carol Serna, developerWorks, September 2005) is an
introductory article explaining IBM WebSphere Process Server and the
business rules service component for that server.
Business rules management systems explains BRM systems and what you
should look for before selecting one for your enterprise.
See "Model and build ESB SOA frameworks" (Naveen Balani, developerWorks,
March 2005) to find out how to model and construct Enterprise Service Bus
(ESB) SOA frameworks, which is probably the quickest and most cost-effective
way to integrate applications.
Business Rules Community has a lot of articles and tutorials and is very good
place to start learning more about business rules.
This very informative article by Ronald G Ross that makes a good case on
whether 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 WebSphere Process Server.
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 evolving role of the business analyst

Page 8 of 10 Copyright IBM Corporation 1994, 2007. All rights reserved.
ibm.com/developerWorks developerWorks

" IBM WebSphere Developer Technical Journal: Introducing the WebSphere

Integration Reference Architecture" (Scott Simmons, developerWorks, August
2005) provides an overview of the WebSphere Information Integration
architecture.
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.
Get products and technologies
Rational Unified Process (RUP) 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 the latest version of Business Process Execution Language for Web
Services, Version 1.1 specification.
IBM WebSphere Process Server has business rules as one of the server
components for its business process management suite.
Discuss
Participate in the discussion forum for this content.
Get involved in the developerWorks community by participating in
developerWorks blogs.
Participate in the discussion forum.

About the author

Arun Chhatpar
Arun Chhatpar is a regular contributing author to IBM developerWorks, and he has
more than 10 years of software design and development experience encompassing
decision analytics, business rules management systems, core Java, UI frameworks
and workflow orchestration. He is also a Sun Certified Enterprise Architect and
business rules expert.

The evolving role of the business analyst

Copyright IBM Corporation 1994, 2007. All rights reserved. Page 9 of 10
developerWorks ibm.com/developerWorks

Trademarks
IBM, the IBM logo, ibm.com, DB2, developerWorks, Lotus, Rational, Rational Unified
Process, RequisitePro, RUP, Tivoli, and WebSphere are trademarks or registered
trademarks of International Business Machines Corporation in the United States,
other countries, or both. These and other IBM trademarked terms are marked on their
first occurrence in this information with the appropriate symbol ( or ), indicating
US registered or common law trademarks owned by IBM at the time this information
was published. Such trademarks may also be registered or common law trademarks
in other countries. A current list of IBM trademarks is available on the Web at
http://www.ibm.com/legal/copytrade.shtml.
Java and all Java-based trademarks and logos are trademarks of Sun Microsystems,
Inc. in the United States, other countries, or both.

The evolving role of the business analyst

Page 10 of 10 Copyright IBM Corporation 1994, 2007. All rights reserved.