Rule Governance: Striking the Right Balance Between Agility and Control
Modifying business logic is inherently part of an application maintenance process. Moving to a business-driven process rather than an IT-driven development process requires adopting basic governance principles that put appropriate controls in place while allowing for agility.

First, the map of stakeholders needs to be clearly established. This is an important step in making sure everyone understands their roles and responsibilities in maintaining, reviewing, testing or deploying rules. Most importantly, the stakeholders' map gives a greater sense of empowerment and accountability for all the people involved in maintaining rules.

Then the rule management process must be defined, specifying how a change to the decision logic will be authored, approved, put in production, and eventually retired. For instance, a branch manager might have the authority to update surcharge and discount rules that apply to his region, while his regional manager will have overall responsibility for reviewing all pricing rules nationwide and approving them for deployment into production. Those processes set expectations among all stakeholders about what changes are allowed and when they will take effect.

Finally, the last step is to establish a clear set of controls that will provide the ability to monitor each business rule lifecycle from authoring to testing, deployment, and monitoring. As business rules embody the business decisions of an organization, understanding who changes them, when, and why is critical to proper governance. Equally important is the ability to provide execution reports that explain how decisions were reached for a given transaction.

Depending on the experience of the organization and the frequency and magnitude of expected rule changes, the best approach can be to set up a dedicated rule management team. Such a team would typically be a liaison between business and IT, and it would ensure that the rule development process is followed and evolves as needed.

Establishing such a collaborative, business-driven maintenance process for your decision services has powerful consequences for the organization and positive psychological consequences for all participants. Those consequences are a significant improvement in agility, an increased trust from the business in the IT systems, and a high level of support for the SOA vision across the organization.

Case Study - Using BRMS as an Essential Part of SOA Strategy
When organizations decide to adopt BRMS, they quickly realize the business value it can bring to SOA. A major financial services group with operations across Europe and Latin America is a good example. Due to its rapid growth through acquisition, this organization realized that it needed to invest heavily in IT modernization to align its various financial institutions and enhance its competitiveness across the markets in which it operates. It decided to adopt an SOA strategy to streamline its IT infrastructure from the front to the back office, with the goals of continuously improving customer service and reducing costs. The objective was to have a single platform across all banks in the group, standardizing processes and creating product factories (back-office systems able to process the products for various distribution channels, under different brands or for different packages).

As part of this SOA initiative, the company realized that management and automation of decisions within its business systems was a critical element to realizing the value of its overall IT investment. By adopting and implementing BRMS, it is working to maximize the reusability and adaptability of its platform across all banks, ensuring that its banks can respond quickly to changes in regulations and market conditions.

In a variety of systems that are subject to frequent business changes, the use of BRMS has separated the management of business policy from application code, allowing business experts to maintain these policies and to easily make changes to them based on the needs of the business. This enables both an increase in the speed with which it can adapt its systems to changes in the business environment (due to regulations, competitors, or internal factors) and a flexible approach to the variability that exists in handling unique requirements across geographies, customers, and processes. One of its most important requirements from a technology perspective is the separation of process and policy logic, since policies tend to change much more frequently and require rapid implementation and deployment. The use of BRMS technology provides the standard SOA benefits of decoupling, reusability, and standardization with the business benefits of reduced time to market and improved responsiveness to changing market conditions.

Conclusion
If you want to build business agility and value as part of your SOA initiative, where do you start? In terms of BRMS adoption, it is important to look for a product that is designed for SOA, both in terms of decision services composition and in terms of deployment, management, and execution of these services. Next, it makes sense to identify a starting point for the use of BRMS. The best place to begin is with the most dynamic business systems, where the frequency of changes to decision logic and the need for fast response to ongoing change are creating a barrier to agility. It is in these conditions where BRMS will allow your organization to make business change work to your advantage and to demonstrate the value that SOA promises.