Service Oriented Architecture-SOA
Learn About Service Oriented Architecture (SOA)
What is Service Oriented Architecture?
IT departments are managing increasingly complex IT portfolios. Yet as business needs change,
these departments must still ensure that their technologies remain aligned with business goals.
Failure to do so compromises organizational agility.
The problem for IT departments is typically not insufficient functionality; rather, it is that critical
business systems such as customer relationship management (CRM) and enterprise resource
planning (ERP) operate in isolation from other critical business systems—despite the fact that
business processes often span multiple applications. To obtain an end-to-end view of a complex
business process necessitates integration of information and process silos. In the past, this has
been accomplished either though time-consuming manual interventions, or through hard-coded
solutions that are difficult to maintain.
Service orientation is an approach to organizing distributed IT resources into an integrated
solution that breaks down information silos and maximizes business agility. Service orientation
modularizes IT resources, creating loosely coupled business processes that integrate information
across business systems. Critical to a well-designed service-oriented architecture is producing
business process solutions that are relatively free from the constraints of the underlying IT
infrastructure, because this enables the greater agility that businesses are seeking.
Service Oriented Architecture (SOA) ultimately enables the delivery of a new generation of
dynamic applications (sometimes called composite applications). These applications provide end
users with more accurate and comprehensive information and insight into processes, as well as
the flexibility to access it in the most suitable form and presentation factor, whether through the
Web or through a rich client or mobile device. Dynamic applications are what enable businesses
to improve and automate manual tasks, to realize a consistent view of customers and partner
relations, and to orchestrate business processes that comply with internal mandates and
external regulations. The net result is that these businesses are able to gain the agility
necessary for superior marketplace performance.
Service orientation is a means for integrating across diverse systems. Each IT resource, whether
an application, system, or trading partner, can be accessed as a service. These capabilities are
available through interfaces; complexity arises when service providers differ in their operating
system or communication protocols, resulting in inoperability.
Service orientation uses standard protocols and conventional interfaces—usually Web services—
to facilitate access to business logic and information among diverse services. Specifically, SOA
allows the underlying service capabilities and interfaces to be composed into processes. Each
process is itself a service, one that now offers up a new, aggregated capability. Because each
new process is exposed through a standardized interface, the underlying implementation of the
individual service providers is free to change without impacting how the service is consumed.
Complex, distributed IT resources are a concern for businesses. Too frequently, the existing IT
portfolio does not adequately meet specific business needs, is costly to manage and maintain,
and is inflexible in the face of business growth and change. The solution, however, is not to rip
and replace systems or applications, nor to completely renovate them, but rather to find a way
to leverage existing IT investments so that overall organizational goals are effectively
Service orientation helps to accomplish these goals by making systems more responsive to
business needs, simpler to develop, and easier to maintain and manage. Implementing a
solution architecture based upon service orientation helps organizations plan ahead for change,
rather than responding reactively.
Who does SOA?
Strictly speaking, SOA is done by developers and solution architects. However, stakeholders in a
service-oriented solution span a range of roles, and it is critical that their interests not only be
taken into account but that they actively drive the design of the SOA solution.
Starting with those interests, the business analyst is concerned with bringing IT investments
more in line with the business strategy. For the developer, this means that the SOA solution
must map the sources of business information—systems, staff, trading partners—into a unified
and comprehensive view such that the business analyst has greater insight into the costs and
benefits of various investments.
The chief technology officer (CTO) of the organization will work with developers to ensure that
when designing a solution to meet the needs of the business analyst, the integrity of existing IT
systems and applications resources are preserved, even as new capabilities are developed.
And the IT manager, concerned with effectively integrating distributed systems such that
management is simplified, will work with the developer to ensure that these goals are also met.
Ultimately, the developers and solution architects are concerned with creating dynamic
collaborative applications that meet the goals of the various stakeholders. The service
orientation approach enables them to do so in a way that meets the needs of the organization
as a whole.
What SOA isn’t
There are numerous misconceptions about what SOA is—that it is a product that can be
purchased (it is not; it is a design philosophy that informs how the solution should be built);
that the goal is to build a SOA (it is not; SOA is a means to an end); or that SOA requires a
complete technological and business process overhaul (it doesn’t; SOA solutions should be
incremental and built on current investments).
SOA is also often equated with Web services, and the terms used interchangeably. While it is
true that SOA is made easier and more pervasive through the broad adoption of Web services–
based standards and protocols, the two are distinct. SOA is an approach to designing systems—
in effect the architectural drawings or blueprint—that directs how IT resources will be integrated
and which services will be exposed for use. In contrast, Web services is an implementation
methodology that uses specific standards and language protocols to execute on a SOA solution.
Before starting a SOA
Before a developer writes a single line of code, it is critical to identify both specific business
drivers of the SOA endeavor and the dependencies between the business and the underlying
technologies. Neglecting the business context can result in a project in which SOA infrastructure
is pursued for its own sake, or where investments are made that do not line up well with the
needs and priorities of the business.
Two approaches are commonly pursued for implementing SOA: top-down and bottom-up. Both
approaches have possible pitfalls that can prevent success. Many organizations that have
attempted to roll out SOA infrastructure through a top-down approach have discovered that
when the infrastructure is finally delivered it is out of sync with the needs of the business.
Likewise, a bottom-up approach can fail as well, because it can lead to a chaotic implementation
of services created without regard to organizational goals.
The “middle-out” approach is a successful hybrid of the two other approaches. Business drivers
and strategic vision are first employed to set clear direction and priorities. Based on these, the
organization takes multiple iterative steps to build out slices of end-to-end capabilities, with
each iteration delivering a new, dynamic application back to the business that is used to create