by October 9, 2006 0 comments

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

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

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

No Comments so far

Jump into a conversation

No Comments Yet!

You can be the one to start a conversation.