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:
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:
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 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:
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:
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.
Customer Relationship Management Related Tutorials
|Principles of service marketing management Tutorial||SAP Cloud for Customer (C4C) Tutorial|
Customer Relationship Management Related Interview Questions
|Customer Relationship Management Interview Questions||Principles of service marketing management Interview Questions|
|Customer Care Interview Questions||Customer Service Professional Interview Questions|
|Business process outsourcing (BPO) Interview Questions||SAP Cloud for Customer (C4C) Interview Questions|
Customer Relationship Management Related Practice Tests
|Customer Relationship Management Practice Tests||Principles of service marketing management Practice Tests|
|Customer Care Practice Tests||Business process outsourcing (BPO) Practice Tests|
Customer Relationship Management Tutorial
Omg! Your Customer Really Is Your Bff!
Crm,cmr,vrm Or . . . Who Cares?
The Customer Owns The Experience
Enterprise 2.0:not Exactly What You Think
A Company Like Me:new Business
Do You Have The Ring? Tools For Customer Engagement
Love Your Customers Publicly: Blogs And Podcasts
Wikis Are A Weird Name For Collaboration, N’est Çe Pas?
Social Networks, User Communities: Who Loves Ya, Baby?
Movin’ And Groovin’: The Use Of Mobile Devices
The Collaborative Value Chain
Sales And Marketing: The Customer Is The Right Subject
Customer Service Is Our Name—and Our Game
The Difference:crm,the Public Sector,and Politics
Soa For Poets
At Home Or In The Clouds-and In Open Spaces Between
Big Picture,big Strategies
Mapping The Customer Experience
Process And Data Go Together Like…crm Operations
Value Given,value Received
When You Buy The Application,you Buy The Vendor,though You Don't Implement Him
Waving To The Future
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.