SOA: What's all the “noise” about?

There's been a lot of noise and confusion over Service Oriented Architecture in the market for quite some time now. In this article, we clear the fog around this concept by telling you what it is and isn't, as well as what it takes to deploy the same

Monday, October 09, 2006

Print

Comment

Email

Digg

Del.icio.us

Reddit

Twitter

Service Oriented Architecture or SOA is the hottest buzzword in the industry today.Though it's hot, it's also confusing, because besides SOA, a lot of other terms that promise to do similar things have also cropped up. These include terms like ESB and ESA that have added to this confusion.

Moreover, while we hear of so many terms, we don't really see any successful implementations in India. In fact, the news is full of successful SOA
deployments across the world, but when it comes to India, you hardly find any. So in this article, we'll try our best to bust some of this hype and explain what the big deal is about this whole SOA business. Before we get into the actual details of SOA, let's first take a simplistic scenario to understand its capabilities.

Any typical enterprise today, would have various business applications deployed. These could be ERP to streamline internal workflow and business processes, or CRM to handle customers more effectively, or SCM to ensure smooth flow of supplies, etc. The trouble is that all of these are meant primarily to make internal business processes more efficient. Plus, they're not necessarily integrated to each other. Moreover, if you want to make any of their services accessible directly to your customers, it would be a long drawn and tedious exercise. For instance, consider a bank that has all these applications deployed and its processes automated.

Suppose you want to get your address changed in this bank. The process for the same would be to go to the bank, or maybe send them an e-mail to get this done. This process would take time. Suppose the bank extended a part of its internal CRM application directly to the customer over a thin client or even the Web and allowed the change to happen directly, after authentication of course. Adding such a capability into your CRM application would require you to update it, which could take plenty of time. That's where SOA comes into the picture. This would allow you to easily extend your existing business applications' capabilities to the customer, without ripping through the application's code. It would do this by providing a loosely coupled service between the application and the user interface.

So the bottomline is that every organization has various business applications running. SOA allows you to extend their capabilities or integrate them without disturbing them too much. This allows an organization to expand its business and offer new services to customers faster than traditional methods. Another area where SOA shines is in company mergers. When a merger happens, chances are that the merging companies would have different applications, platforms, etc. These could be performing redundant or completely different processes. SOA can help integrate these platforms without bringing in major changes to the existing infrastructure. Let's see how SOA makes this possible.

So what is SOA?
SOA is a set of components that are loosely coupled with your business applications. In SOA nomenclature, these are called services. By loosely coupled, we mean that these components are independent of the various applications. So you can modify them or add new ones depending upon the service that you want to provide. All this happens without disturbing the core applications. In some cases, you could even reuse some of these components.

Interestingly, this approach is nothing new. It has been around for quite some time. Remember CORBA, COM, DCOM? They all followed the same approach of providing a system that's composed of loosely coupled, distributed components. The trouble was that they never managed to successfully integrate across different platforms, simply because they were not really centered around any business process. With Service Oriented Architecture, all systems see each other as a service with which they can communicate easily for information retrieval.

And what it isn't...
Let us explode some myths and fallacies around SOA.

1. SOA is not equal to Web services. On the other hand, Web services are one way of implementing SOA. For instance, web services can't
address all the parameters involved in communication between various business applications. Web services are more suited for an end user centric type of an interaction, wherein you allow a customer to access a certain aspect of your business application.

2. SOA is not about enabling service delivery alone. Many times, SOA is interpreted as an architecture that will smoothen delivery of services within an organization's ecosystem. In other words, SOA is not only about making different applications talk to each other. Yes, SOA will allow your ERP application to access data from your CRM application, but that's not the only purpose it will solve. We'll come to the purposes it resolves, later in this story.

3. SOA is not about ripping and replacing your legacy infrastructure. Your legacy applications will stay 'as is', but will be treated as services in SOA. Again, we'll see how when we look at its architecture later.

4. SOA is not the same as ESB or ESA. We're assuming that you would have come across these other terms at one point of time or the other, and they would have given you the impression of being the same as SOA. Well they are not at all the same. ESB (Enterprise Service Bus) is not an architecture, but a part of SOA. For instance, one example of ESB would be a layer of components that sit between your legacy and enterprise applications on one side, and the client interface on the other. It would facilitate the communication between the two sides. Another good example of ESB is the middle layer that integrates two different applications. A lot of vendors have rolled out ESB implementations for facilitating SOA implementations. For instance, IBM provides ESB patterns built using the IBM Business Integration portfolio of products. Sonic Software provides an ESB solution called Sonic ESB; while BEA has the Aqualogic Services Bus that does the same thing. ESB is largely looked upon as a tool for facilitating integration within enterprise applications, legacy systems and services.

ESA or Enterprise Services Architecture, is best defined as more of a proprietary term coined by SAP for the capabilities they provide using their NetWeaver platform. You can therefore call it SAP's SOA initiative.

Going the SOA way
The key to deploying SOA successfully is to change your mindset about how an IT project is implemented. Instead of thinking products, technologies, and platforms, you have to think about your business processes. You have to first understand how they work and then how to extend their capabilities. A word of caution here-there are also cases where SOA has not delivered. According to analysts, the reason for these failures is that the implementers have not mapped the SOA implementation correctly to the business processes. This has led to a change in the business process itself. For instance, consider a bank that provides various services like investment banking, insurance, credits, short term over drafts, etc through its existing applications. An SOA based implementation for integrating these systems should in the end deliver the exact same services, but in a better manner. This is only possible if the business processes are understood and mapped correctly.

SOA can be used in many ways, depending upon your business needs. For instance, you can use it to implement a business application such as a CRM. You could use it to integrate your existing business applications. You can even use it to extend the capabilities of your existing business applications. The OASIS consortium has started an initiative to standardize SOA implementation processes and has released a Community Draft for public comments. With the public final draft in awaited status, does it mean you can't go for an SOA implementation right now? The answer is, yes you can still go for it, after careful evaluation. While it hasn't been standardized, many software vendors have developed their implementation processes and maturity models.

In 2005 Sonic Software, AmberPoint, BearingPoint and Systinet announced their Service-Oriented Architecture Maturity Model, in which the maturity of SOA is characterized in five levels, from Initial Services up to Optimized Business Services. Similarly IBM has come up with its own model called the Service Integration Maturity Model which looks into SOA by classifying the related aspects into seven levels that address issues from IT infrastructure to the business viewpoint. Whether you should go for a vendor specific implementation of SOA is a different discussion altogether. That would involve evaluating the various offerings and mapping them to your business requirements.

Expertise required
Like we said, deploying SOA requires a different mindset. You need developers in your team who know .NET, Java, web services, etc. You also need networking professionals. But in addition to these, you need people who have sound knowledge of business processes. These could come from various departments in your organization. Ultimately, they have to define what's really required, and then somebody has to translate it into a Service Oriented Architecture.

Anadi Misra and Anubhav Verma

Page(s)   1