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

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