SOA Challenges in CRM

Service oriented architecture (SOA) as a solution to the thorny technology issues involved in customer relationship management (CRM) remains largely hype. The promise of modular, reusable services connected seamlessly into larger applications, while great in theory, has, by some estimates, reached maybe 20 percent of its potential. It is time to ask why and what to do about it. Imagine a technology architect faced with integrating a Web site and a customer service system who attends an introductory briefing on the concepts of a service-oriented architecture. Our architect, who must then apply these concepts to applications that improve multichannel customer service, identifies five shortcomings. But what about the data management? Service oriented architecture does nothing to solve one of the major issues in CRM application development--the provisioning and maintenance of customer data from many sources--and in fact can make it highly complicated. Unless accounted for programmatically or via some intelligent middleware design, data is simply passed in and out of services via XML. When services are strung along into the processes that comprise an application, dependencies emerge which significantly reduce the benefits of an SOA. For example, an application that upgrades a customer account using four sequential services likely creates data in each step for the next (approvals, characteristics, et cetera). Step 4 is highly dependent on the data in each of the previous steps so if a change to the format of the account number occurs in step 1, step 4 also needs to be changed. Likewise inserting a step 2a likely means steps 3 and 4 need to be modified, resulting in a cascading maintenance effort. But my CRM processes aren't that simple Imagine a process that is not strictly sequential. For example, to fulfill a customer request for a loan we need four approvals (via four different services), which can occur in any order, but they must all occur before the fifth service creates the account and notifies the customer. Because services typically work synchronously (you call a service and wait for a response) and because they only have information from prior steps, it is difficult to model and execute a nonsequential process. But my services don't let me respond to activity I can't predict or model How do I model and arrange services into processes I can't predict in advance, such as customer service at an airport where the sequence of events is not planned, but made up based on events on the ground (current arrival and departure status, equipment status, weather)? But not everything is a service (yet) While purity of architecture is a laudable goal, very few organizations will actually adhere completely to the precepts of an SOA, especially given the huge investment in legacy CRM systems. More likely, IT environments will continue to include both services and traditional applications that require integration via databases, middleware, or custom APIs. But the logic in my services needs to change frequently Ultimately services make decisions by applying the logic programmed into them to the data they are given. But what if that logic changes frequently so that it becomes difficult to maintain inside the service? For example, a service evaluates a particular pattern of customer call center and Web-site activity to see if it indicates a security breach and, if so, then it notifies the account manager and opens an investigation. Since the triggering pattern must constantly evolve as data thieves get smarter, the need to constantly rewrite the code would inhibit the ability to stay ahead of the thieves. So how do we address these shortcomings? The common thread in all of the examples above is that they are event-driven. Event-driven CRM applications involve processes that are typically unpredictably nonlinear (their timing and sequence cannot be defined in advance), dynamic (their characteristics change quite frequently), and continuously influenced by outside events (they can quickly mutate in response to real-time external activity). They require a new technology platform that fits inside an SOA: complex event processing (CEP). CEP is uniquely suited to solve this new class of business problems found in multiple industries. This is because CEP enables the automated detection and understanding of often subtle and shifting patterns of human and system activity flowing through an IT infrastructure as well as the orchestration of timely responses. When implemented inside an SOA, CEP extends and enhances it to cover event-driven applications and hybrid applications involving events and services. About the Author David Cameron is vice president of marketing and product integration at AptSoft Corporation and can be emailed at david.cameron@aptsoft.com. Please visit www.aptsoft.com