Enterprise Service-Oriented Architecture - Customer Relationship Management

When I wrote the third edition of this august volume back in 2004, service-oriented architectures were not fully realized yet. They were the dream of a number of companies that had started to use them in conjunction primarily with business services. At that time, Rearden Commerce had what I would call the only complete SOA. Now there are many companies that claim they’ve completely developed enterprise SOA, among them SAP with NetWeaver, Microsoft, Oracle, and countless others. Do I know that they are complete? No, I don’t, and, thus, I can’t really say they are either. You’ll have to take the vendor’s word, for what it’s worth.

What Is SOA?
First, a simple definition:
SOA is a series of loosely joined services that communicate with each other regardless of the underlying platform. It restructures applications from a single large module to a series of smaller modules—services—that can be used and reused and recombined into applications that are specific to a situation or location. What complexity it has is primarily due to how a company cares to call and use the service or combinations of services.

A service-oriented architecture’s great strength is that it supports a common set of technology standards, particularly web services, as well as corporate (and beyond) processes and business rules. The services, data, rules, and processes can be shared, but the interfaces and even the workflows can be specific to the applications that are using them. Within the framework of an SOA, though, the shared components can be used (and reused) in any applications that fall within the framework and at any company using the reusable parts.

For example, let’s say you have a process that covers a customer service process from initial contact to service solution. That means:

  • Receiving the request for the communication via any of a number
    of selectable channels.
  • Responding to the request via the appropriate channel.
  • Entering the information provided by the requestor.
  • Opening a ticket that might be solved immediately or routed to a higher level of technician or to a supervisor, or it might send a request to a central scheduling authority to provide an onsite visit to the customer by a field service technician.
  • Having the appropriate customer service representative resolve the issue.
  • Entering the data for the resolution of the issue.
  • Contacting the requestor to inform them of the solution or the suggested course of action.
  • Closing the ticket if it is positively resolved or, if not, routing it further until it is resolved and the ticket is closed.
  • Updating the knowledge base if necessary.
  • Tracking the quality of the customer service support.

Note the complexity of this process, especially in item 4 where there are multiple directions for the process to go. It might go to a supervisor, which would send it on one path, or be routed to a field service technician, which would direct it through an entirely different series of steps to get there and to execute the instruction.

That same field service call can also get complex. It is often through a selected partner in a geographical location who has multiple calls to do in that location, adding scheduling optimization and territory management to the mix of how the process works. It is conceivable that the web services and/or the SOA the partner uses are somewhat different from the ones the parent company uses.

Never fear, those of you who are faint of heart. As Rick Merrifield et al. pointed out in their Harvard Business Review article “The Next Revolution in Productivity” in June 2008 (thanks to my dear friend and CRM business analyst Hatrice Basak Yildrim for pointing me to this one):

The beauty of SOA is that it allows activities—or processes built from such activities—to be accessed using the now-ubiquitous Internet in a standardized fashion. . . . This transformation makes it vastly easier to share discrete activities and entire processes internally, to buy or sell them externally, to delegate their execution to suppliers or customers, and to update and maintain IT systems.

The benefit of an SOA is that all these processes—which intersect the customer service department, the field service agents (even if outsourced), the supervisors, the level 2 technicians, the aggrieved customers, and likely the IVR and CTI systems and those responsible for them—can interchangeably use the standardized services to appropriately communicate with the right facilities at the right time. Even more valuable, SOAs allow automatic access to the web services associated with specific business rules, allowing for sophisticated communications that trigger workflow actions based on pre-established conditions—without you having to do anything! Except respond when it’s you it’s notifying.

With the increasing complexity of traditional CRM technological models, the levels of customization, configuration, and integration have increased to something that could befuddle even the most razorsharp IT architect—especially when the models are proprietary. But there has been a sea change over the past several years that allowed SOA to gain enormous ground at enormous speed. Why? It’s a more flexible architecture with an enterprise-wide scope that can manage ongoing business change.

To take it to the next level, a slightly more complicated definition:
An SOA is a collection of decoupled business services and IT functions that are constantly evolving along with business requirements. These services communicate with each other. The communication can involve something as simple as data passing from a sales force automation system to an order management system. It could also involve two or more services coordinating some activity. For example, you are providing a just completed, authenticated document compiled automatically as an Adobe Acrobat file (.PDF) to a person registering on the website for the first time. His registration, when completed and submitted, extracts the document from a data store somewhere on the system and then time and date stamps the extraction and e-mails the document to the new registrant. The data from the new registrant populates multiple data sources. Some means of connecting these services to each other is needed, most often through provided connectors or customized code. Each component involved is interopera without being dependent on the other components.

One other remark on SOA before I forget. Remember that SOA is outcome-based, not activity or methodology focused. What that means in plain Yiddish is oy, how hard is this, really, to understand? What this means in ordinary English is that SOA architecture is designed to achieve desired outcomes, not to organize work in a particular way. That’s why the components are reusable. They can be plugged in to systems to achieve a result. They don’t force any particular methodology into the system, nor do they require a particular activity or process to function according to “SOA rules.” The outcome desired as the outcome achieved, no matter which approach was taken to achieve it, is what SOA lives for.

The SOA Marketplace
Commensurate with the evolution of this technology is the hype surrounding it. Back in 2003, ZapThink, an all-things-SOA company, blissfully forecast a $43 billion market in 2007, which I benignly accepted. It was way off. If the market is seen as a middleware-driven market, it was $2 billion in 2007, with IBM, through its Websphere product, owning 64 percent according to a considerably more conservative 2008 Research and Markets report on the sizing of the SOA market. The anticipated market is roughly $9.3 billion by 2014. Given my track record on guessing this—or at least agreeing with those guessing— well, take it for what it’s worth. Not much, but at least an indication that SOA is important.

There are a dozen other players in the market including BEA, now owned by Oracle, and Web Methods, now owned by Software AG. (I’m owned by my five cats.)

Building and Maintaining an Enterprise SOA
Once you know what SOA is, the question becomes, is it right for my business? How should you evaluate this architecture? Here is a brief checklist of what you might want to ask vendors—and ask yourself—to see if SOA or SOA-based applications make sense for your company.

Traditionally, when assessing enterprise architectures, you are considering the:

  • Environment What platforms and databases might be of value?
  • Organization Should the architecture be the now nearly defunct two-tier client/server or the n-tier architecture that is so favorable to web architectures?
  • Infrastructure Should your architecture be object-oriented with reusable assets? What standards are applicable to your architecture? What measures for authentication and security are appropriate?
  • Applications What applications should be used to execute your business rules or to implement web services?
  • Need for customization How much customization will be necessary? What kinds of tools are available to do the customization? Should you, for example, standardize on Oracle and customize using Oracle’s authoring and development tools? Or find a universal tool for best-of-breed implementations?
  • Integration How many third-party and legacy systems must the applications integrate with—internally and externally? Will you use middleware, web services, or something else to integrate data, business processes, and workflow?

Once you’ve asked the questions, if you’ve come to the conclusion that SOA works for you, then how to build the SOA becomes the next concern.

One of the considerations you will probably have is how to handle dynamically changing business processes and the shifting IT structure. Well, “interenterprise on the move” is probably the right mantra to chant. Massive overhauls aren’t necessary for IT to begin implementing an SOA. What is most important is developing architecture flexible enough to handle changes in IT functions and business processes as they occur, not all at once.

Build and Maintain a Platform-Independent SOA
The SOA is built around a strategic business initiative and appropriate business processes and services. IT functions interface with the business functions, so as the business processes evolve and change, so do the services and the IT environment. What makes this interesting is that you will be able to ascertain the state of IT services and functions through the business actions being taken by the system. While maintaining platform independence, recognize that you will be running across multiple platforms in multiple environments as you develop this architectural model.

Develop in Increments and Use the Reusable
Iterative methodologies are often effective because they are prototypedependent and always involve the user in each completed production cycle. That allows changes “on the fly, ” so to speak. When developing your prototype SOA, remember that the idea of a reusable asset is to use it again. That means you don’t have to throw out code that didn’t absolutely apply in a particular instance. As you are developing the pieces of the architecture and testing them, you can use the assets in more appropriate places or even rework the code so it can be used elsewhere.

Encapsulate Existing/Legacy Functionality
Rather than create connectors and adapters or use middleware per se to integrate legacy and third-party systems with the newer system, develop web services interfaces to meet that requirement. Those web services will be available even as the functions and processes change over time.

Shoot for Standards-Based Interoperability
Historically, I’ve been a fan of enterprise suites and less a fan of bestof-breed approaches. But I have to admit, the advent of web services and the tsunami of interest in developing standards for data and messaging interchanges have me more convinced than ever that best of breed is a viable approach. Best of breed makes sense as an option if the BOB applications can speak a common language. I know I can reach an audience in English, but when I have to wait for simultaneous translation, the flow is badly interrupted, and I lose time and momentum. If XMLcompliant applications can speak to each other in “XMLese, ”then who cares who makes the applications, as long as they work well together? SOAs can create the framework for this level of interoperability.

Functionality vs. Usability
The more things change, the more they remain the same. One of the timeless arguments in the world of CRM vendors is functionality versus usability. While customers often buy their applications based on the coolness of the functions and features, they only use roughly 10 to 40 percent of the available functionality. The same argument goes for the SOA and web services. While it is good to have an SOA with web services of varying stripes and hues, they are only clutter unless someone is using them. So that means the SOA has to be designed with the ever-popular user in mind.

Business Rules
Business rules are not business processes. They are constraints that are placed on a business that might trigger processes. They will ordinarily reflect some business policy or practice that is institutionalized in the rule. In the world of Business Process Management (BPM), they become variables or key points within the process. For example, there could be a business rule that triggers a second monthly meter reading for a utility company when the number of cycles used reaches a particular threshold or triggers a different price structure for a high volume of usage that is then distributed to the various systems engaged. Or there could be a human business rule that constrains the way a salesperson goes about his work. For example, at York International, Pennsylvania-housed HVAC company, they were having a problem with the profitability of their highly complex service level agreements with some of their customers. Extensive analysis found that they were losing money on many service level agreements (SLAs). They created a business rule that was embedded in their sales process (through a Siebel sales application) that would not let the SLA proceed unless it met a profitability threshold.

Of course, embedding a business rule in a process can complicate matters. There are often multiple rules embedded in the large BPM processes and they have to be ferreted out in order to make the changes appropriately. They aren’t necessary so easy to catch. That’s why there are dozens of vendors on the market that are attempting to create business rule technologies that can handle the ferreting and embedding as needed. With the technology, business rules can be implemented in a repeatable and consistent fashion, and integrated with BPM and other applications that are being used by the company. As process management and change become increasingly real time, the ability to extract and change or re-embed or develop the business rules associated with those processes becomes increasingly important. BPM solutions will have to factor that kind of activity into their solutions. If they don’t, embed the following rule into your purchasing processes: “If the BPM applications don’t have business rule capabilities, don’t buy.”

In the technology you will likely deal with when it comes to SOA, the business rules are part of a business logic that assumes constraints or changes in the state of the data. It also constrains the use of data by individuals—an authorization constraint—and will trigger when an action on the data occurs. For example, take the rule mentioned above for the utility company. If you add the ability for managerial override of the percentage price changes due to volume, the technology could automatically trigger the workflow rules that allow the override request to be routed to the appropriate manager. By being able to see and steer the business rules that are in specific processes, you will be able to modify, subtract, or add rules to each process or even do a universal change to all the rules by some parameter or other criterion. Sleep will come easier if you can. Imagine doing it all manually? To err is human;to have business rules capabilities is, uh, good. Divine is stretching it.

SOA and Integration
Okay, SOA promises a beautiful world of applications that work together seamlessly, but that world is theoretical at best and ridiculously optimistic at worst. Since anyone reading this chapter is not likely to be an IT guy (because you don’t need to be reading “SOA for Poets” if you are, or if you do need to, you shouldn’t be an IT guy), you may think, as the business whiz you are, that you don’t have to concern yourself with how this all works.

To some degree, you’re right. But the reality is that when you are using applications that should be having a lovely coordinated conversation with each other and they instead spew disconnected invective back at you—meaning you can’t get the information, data, services, functions, or results you want—you will need to know how to tell the IT guy what is wrong. If you don’t, your customers are going to get upset.

Think of it this way. When you look at a Fortune 1000 company, the average number of applications it has working is between 400 and 3, 000. Do you have a clue how to integrate that? Not only does integrating an SOA have extensive hardware requirements so that applications run seamlessly, you must also consider:

  • Incompatible data formats between applications

  • Legacy systems that don’t have the necessary APIs natively so they have to be built—say, to foster the integration between the supply chain and CRM systems

  • Licensing, control, and asset management issues that legacy systems create

  • The evolution of on-demand (SaaS) as a viable delivery architecture—which means that it needs to be tied to legacy on-premises applications

But it goes further than that because even if you solve the problems created by the somewhat static conditions here, there are more dynamic elements that need to be accounted for in the integration strategy:

  • Changes in business rules due to new management, changed business conditions, or new processes

  • Changes in business models due to new products, corporaterollups or other acquisitions or mergers, new customer expectations, or new compliance and governance issues

  • Changing IT infrastructure due to new protocols and standards or simply growth (or cutbacks) at the company

  • Issues of external connectivity to partners, customers, or external agencies

All in all, these are not easy issues to deal with, but they are real—the cold water dashed on SOA users’ faces. Be alert to possible problems with integration and you will be able to solve them a little more readily.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Customer Relationship Management Topics