SOA Meets Business Rules

As the pace of change within businesses across many industries continues to accelerate, market demands are driving the need for increased business agility. Achieving business agility within an enterprise requires rapid implementation of changes to business logic across the organization's applications. In order to accommodate dynamic logic that varies by industry, geography, and over time across all enterprise operations, two critical issues must be resolved. The first is how the logic can be maintained with the necessary degree of agility. The second is how to support that agility across many disparate applications. Organizations that face these challenges are beginning to turn to two approaches in combination to meet them head-on: a business rules management system (BRMS) approach to achieve the agility and a Web Services/Service-Oriented Architecture (SOA) to make it accessible to many different applications across the enterprise.

The 'implicit' approach that buries business logic within applications cannot accommodate rapid and frequent changes -- without a heavy burden in terms of time and cost. This outdated method is being abandoned widely as organizations seek new alternatives. Web services and business rules are complementary technologies that provide an excellent alternative. When these two approaches are deployed in combination, organizations benefit from their strengths in ways that enhance business agility. The "loosely-coupled" approach of Web services/SOA, together with the "de-coupled" approach of business rules management systems (BRMSs) enables organizations to better represent business logic in "explicit" format that can be more quickly and easily modified and shared across many applications.

Why Business Rules?

More and more businesses today are competing in markets that require them to be flexible, fast moving, accommodating to customer requests -- in general to be more agile. For those businesses, taking the implicit approach to business logic results in scattered and fragmented implementation that soon becomes a maintenance nightmare. If it takes weeks or even months to roll out a set of rule changes, how can you hope to keep up in a business where change now occurs daily, or even hourly? In such a business environment, implementing business logic implicit within multiple applications just exacerbates the complexity and maintenance challenge, since it is highly inefficient, error-prone and breeds inconsistencies that become problematic.

By contrast, a business rules management system (BRMS) maintains the business logic explicit to software assets, such us managing data, producing web forms, etc., and provides a common repository for the business rules and the application logic. After testing and validation the business logic can be deployed to a business rules server. The business rules server may be implemented as a Web Service that is accessible to many SOA enabled applications across the organization. By supporting shared business logic within the SOA architecture that can be addressed by many disparate applications, organizations can reduce redundancy, speed implementation, lessen inconsistency and improve the overall efficiency of both the applications and the business processes they serve.

By externalizing business logic from underlying application systems, a BRMS can enable application logic to change more flexibly and quickly. In addition to explicitly defining and managing business logic, enabling business analysts to capture the business logic in English increases auditability and visibility dramatically. Costly, time-consuming transformation from business terms to programmer requirements and subsequent implementation can be reduced or eliminated. This in turn empowers business analysts to create and maintain the business logic directly, allowing them to make changes with little or no IT intervention. Externalizing the business rules and storing them in a BRMS repository makes business logic more visible to the business's domain experts, so they can better understand how business policies and rules are applied to the business processes they manage. In addition, by separating out the business rules from the implementation, applications gain the ability to become more "process-aware," which further advances their ability to accommodate the changes expected in a dynamic business climate.

Web Services and SOA: the Case for Application Integration

In all types of industries -- from banking, insurance, retail and manufacturing to healthcare, telecom, utilities and government -- line-of-business applications help drive business processes that have immediate, direct impact on operational efficiency and productivity. Thus the speed with which enterprises can react to dynamically changing market conditions and customer/constituent requirements is directly linked to the speed with which the organization can infuse those changes into the many applications that support its business processes.

Taken separately, business rules technology and Web services each facilitate the integration of disparate applications across the enterprise in different ways. But taken together, business rules and Web services provide a powerful approach for application integration and distributed information sharing. The adoption of business rules coupled with the implementation of a Service-Oriented Architecture enhances the integration of strategic enterprise applications across multiple business units. For instance, the same business logic that has been explicitly defined and managed in the BRMS can be shared across an SOA with as many other applications as needed. These applications can be either new or legacy applications, communicating via XML with the Business Rules Service. This fosters orderly, incremental introduction of new application and business logic into the operation as needed, and eliminates the disruptive effects of a brute force "rip-and-replace" of entire applications or systems.

An SOA and Web services architecture by itself does not define the implementation of business logic within a service or application. SOA is a loosely coupled architecture, but without also de-coupling the business logic from the application services, SOA's potential positive impact on business agility is greatly diminished. Introducing a BRMS as a service allows the behavior of a business process or service itself to be managed without redundancy and redeployment of business logic for every application. Thus the powerful combination of business rules technology with Web services/SOA not only extends the value of externalizing business logic across the enterprise, but also increases the value of getting all applications, old and new, to interoperate more efficiently.

The Regulatory Compliance Example

The need for business agility is particularly acute for multinational organizations deploying systems and applications for managing regulatory compliance. Highly dynamic and conditional, multi-jurisdictional regulations pose an extreme challenge in terms of agility and the need to quickly and easily accommodate change. Thus compliance applications offer a good example for illustrating how implementation of the business rules approach within a Service-Oriented Architecture can meet the challenge of business agility. The question becomes, how can compliance logic be implemented quickly enough within the transaction processing, decision support and other applications of the enterprise to keep pace with the rate of regulatory changes?

Let's take privacy regulations as our example. From an information technology standpoint, supporting the business requirement to comply with privacy regulations across all affiliated companies and jurisdictions seems a daunting task. Regulations are substantial, highly conditional, including exceptions and special cases, varying from jurisdiction to jurisdiction, and affect many aspects of the operation of individual business units and their interactions, as well. The independent formulation of regulations by legislatures or government agencies produces logic not designed to fit cleanly into the myriad applications that must behave to support compliance.

Agile implementation of dynamic compliance logic is most immediately facilitated by externalizing the implementation of the logic from all the other parts of an application. This can be accomplished in one of two ways. The first option is the use of tables that are consulted by the application to influence its behavior. The second -- which turns out to be a far superior choice in the case of compliance -- is the use of a business rules engine within the application. The rules engine influences the application's behavior by interpreting logic loaded from a rule repository consisting of rules that represent the regulations.

Tables are agile for simple logic, such as yes/no decisions, or determining the value for a single parameter. It does not take more than a few inter-relationships among tables, however, to render them too complex to understand, populate, and maintain. Furthermore, tables are a poor choice unless the logic follows strict, simple patterns that can be reflected in the structure of the tables themselves. Regulations, as well as many business procedures, cannot be expected to conform to strict, simple patterns. Regulations typically require complex conditions that vary by jurisdiction and other factors. Even worse, exceptions and special cases, the bane of tabular logic, are rife in regulations and commonly introduced over time by regulatory authorities. Consequently, rule engines that execute externalized logic within applications are the best approach for the kind of agility required by compliance. In addition, business rules greatly enhance the speed of rolling out compliance changes by eliminating the IT bottleneck caused by dependency on programmer intervention to create and maintain the business rules that represent the regulations. In compliance, the lack of dependence on IT means that the business managers who are responsible for regulatory compliance can own and manage their own processes using the BRMS.

Once regulatory compliance rules are created or updated in the rule server and made available as a Web service, the SOA approach ensures that all applications across the enterprise that need to access that decoupled logic to remain in compliance can do so. In the case of compliance, supporting only applications that share tightly coupled implementing technologies and platforms is impractical. Why not implement business logic within loosely coupled services that can be leveraged by disparate applications implemented using any technology operating on any platform? In a sense, the SOA approach more widely and rapidly distributes the benefits of business rules across the entire organization, eliminating redundancy, delays, and inconsistencies across applications. Such a Web services architecture also facilitates easier load balancing, increased scalability and, in using reliable messaging, fault tolerance.

* * *

For many organizations, the benefits of implementing business rules technology together with Web services/SOA architectures is becoming increasingly compelling as the strategic advantages of increased agility become more obvious. Providing a flexible way to create, change and standardize business rules quickly is a key driver for successfully improving the bottom line impact of applications that support mission-critical business processes. BRMSs can help companies to gain greater agility by more efficiently managing those processes to drive strategic benefits such as improved customer service and responsiveness, higher revenues, regulatory compliance, quicker time-to-market and reduced overall IT and operational costs. The implementation of business rules together with a Web services/SOA architecture offers enterprises a strategic, two-pronged approach for integrating applications and increasing business agility.

About the Author

Hans Witt, CEO and President of Haley Systems, has 30 years of product leadership and executive management experience with some of the worldŐs most successful software brands, including IBM, NCR, Datapoint Corporation, Microsoft and Intel. At Microsoft from 1988 through 1996, the Systems Management product unit he managed generated hundreds of millions of dollars in revenue. Prior to joining Haley, he was General Manager for the knowledge management organization at IntelŐs Architecture Labs. He holds a Business Administration degree from the University of Hanover and the equivalent of a Masters degree in Computer Sciences/Artificial Intelligence from the University of Brunswick, both in Germany.

More by Hans Witt