Today’s business challenges are consistently increasing in number, frequency and complexity. Addressing these challenges requires a level of agility that has not been technologically attainable in the past. However, innovative approaches and technologies such as Service-Oriented Architecture and Decision Management are now enabling companies to better connect, organize, manage and enable their organizations.
Although often implemented independently, there is an increased level of value when considering a cooperative implementation of the two approaches. This article presents the synergies between them, and discusses how you can leverage both together to reach higher levels of agility and flexibility.
The SOA perspective
SOA enables greater business efficiency by providing capabilities to compose new applications on the fly, and allows us to maximize the ROI of core systems. SOA promotes meaningful cooperation between business and IT by exposing business-oriented services, and fosters more effective communication between disparate groups and functions, and breaks down the walls of silos to create a disciplined, connected enterprise.
The Decision Management perspective
Decision Management enables business logic to be moved out of programming code and into a central repository. It increases an organization’s ability to respond to market changes and opportunities. Decision Management allows business policies to be maintained by business users in English-like syntax, and enables better-informed, more consistent decisions across the enterprise.
SOA needs Decision Management
If you are thinking about SOA you should be thinking about Decision Management.
A key benefit of Service-Oriented Architectures is the enablement of business users to perform their day-to-day tasks in a flexible, agile and powerful manner. Business users can create new applications and services by combining existing services. However, the dynamic nature of some business services presents challenges that a SOA cannot inherently address.
Service implementations can be static such as retrieving customer history from a service-enabled Mainframe. Static services can be implemented and re-used relatively trouble-free because of their infrequent necessity to change.
Services can also implement business logic that is more dynamic in nature, therefore requiring a higher frequency of change.
For example, a business service can implement policies for:
- determining lending eligibility (if applicant is first-time home buyer and loan-to-value is less than 85%, approve the application)
- ensuring government-regulated compliance for claims processing (if claim does not contain National Provider Identification, suspend the claim)
- offering incentives to customers based on historical performance (if customer made 3 purchases in the last 30 days, offer 5% discount on next purchase)
These examples can require frequent change based on the market, promotions or changing government regulations.
When a service implements dynamic business policies, it must be able to change more rapidly, and by the business resources that understand them best. If the policies remain within the program code of the service, maintenance must still be performed by a technical resource. The agility, flexibility and power of the implementation are limited no matter how robust the SOA approach may be. Although SOA provides benefits to the enterprise, it will not allow business policies to be maintained separately from the process.
Enter Decision Management…
Leveraging Decision Management in a SOA enables a higher level of business agility, flexibility and power by moving business policies out of program code into a central repository. Business policies are re-authored using paradigms that enable maintenance by non-technical users. Lead time for changes is reduced because technical resources no longer have to search for business policies in code, and the dependencies and impacts of the changes can be more easily assessed.
Decision Management technologies provide service-oriented capabilities that allow business policies to be implemented as Decision Services in the SOA. Business policies are maintained in the central repository, and the Decision Service uses those policies to deliver its functionality.
Building on the brief example given earlier, consider a healthcare company with a mainframe-based business process that defines how member claims are processed. A well-implemented SOA initiative enabled greater agility and flexibility by carving functional “pieces” of the mainframe and exposing them as business services to the enterprise. Therefore, the organization could better adapt to new regulations that require changes to the business process. However, without Decision Management, strategic business policies remained buried in the mainframe code which must be maintained by the IT group. The effort to change processes was reduced; however the effort to change strategic business policies remained the same.
To achieve maximum agility and flexibility the company implemented a Business Rule Management System (BRMS) to externalize the strategic business policies from the mainframe. Business policies such as suspending a claim if it does not contain the National Provider Identification could be easily maintained by business users in a central repository.The business policy on the mainframe looked like this:
IF PVD-IND-DATA = SPACES MOVE “PEND” to CLAIM-STATUS.
And was re-authored in the BRMS like this:
If the claim’s NPI is unknown then set the claim’s status to “PEND”.
A Decision Service containing the business policies is deployed to the SOA enabling current and new business processes to leverage its functionality. As new requirements arise, business users make changes to the business policies in the repository. Once the changes are tested, they are seamlessly moved into production through a refresh of the Decision Service.
In addition to implementing business policies, Decision Services can be developed to provide other types of functionality to automate and manage the SOA during runtime. Examples include orchestrating the process flows between services, or performing data validation and edits for service-to-service contract enforcement. Decision Services function as any other service in the SOA, and are managed by IT according to the SOA governance policies of the enterprise.
Decision Management needs SOA
If you are thinking about Decision Management you should be thinking about SOA.
A key benefit to Decision Management is smarter, more consistent decisions across the enterprise. However, many Decision Management initiatives occur within the scope of a particular business unit or silo. Companies struggle to expand their Decision Management efforts, resulting in unfavorable ROI calculations, as stakeholders expect more return for their investment. The maximum value of Decision Management adoption is reachable when implementation occurs enterprise-wide.
Decision Management is not a technology; it is a way of business. This implies that Decision Management adoption requires more than localized changes to organizations, technologies and architectures. Enterprise-wide adoption requires a focus on making changes with enterprise scope.
Enter Service-Oriented Architecture…
Decision Management technologies are inherently service-oriented. They provide an interface for other systems and applications to send and receive information and decisions. Therefore, the ROI of Decision Management, like other service-based technologies, can be measured by answering:
- How many Decision Services are in use?
- How many applications are using the Decision Services?
- What is the value in Decision Service re-use versus traditional development costs?
Based on these measurements, the greatest value of Decision Management is realized when it is applied across the entire enterprise, therefore maximizing Decision Service deployment and re-use. Decision Management becomes Enterprise Decision Management.
SOA provides the architectural foundation for expanding Decision Management beyond the boundaries of business units and silos, and provides many capabilities for Decision Services including lookup and use, data availability, data transformation and leveraging core systems and resources.
For example, consider an underwriting group in an insurance company. The group implemented a BRMS solution to automate field and relationship validations on electronic applications. The validation policies were not unique to the underwriting group – other groups within the organization could benefit from the same validation functionality. Duplicating the policies in other groups would be expensive and would expose the organization to potential inconsistencies. However, deploying the policies as a Decision Service to the SOA allowed other groups to consistently leverage the same validations. Reuse was maximized, time to change was reduced and ROI was increased. Without SOA as an architectural foundation, the policies implemented by the underwriting group would have remained localized within their business silo.
Companies that do not focus on enabling an enterprise-wide architectural foundation such as SOA will inevitably struggle to realize maximum ROI for their Decision Management initiatives. And like SOA, achieving Enterprise Decision Management is an incremental process, requiring lower-risk projects to yield higher rewards.
In closing, when considering SOA or Decision Management, you should be considering the other. When the approaches are implemented cooperatively, the ROI of your transformation initiatives is increased greatly.
