PDF version of this report
You must have Adobe Acrobat reader to view, save, or print PDF files. The
reader is available for free
download.

Service Oriented Architecture Platforms

by Kirk Woodward

Copyright 2018, Faulkner Information Services. All
Rights Reserved.

Docid: 00018897

Publication Date: 1809

Report Type: TUTORIAL

Preview

A service oriented architecture (SOA) platform is an architectural
technical solution designed by an enterprise to implement the
transformation of the enterprise’s infrastructure into reusable services.
In effect, the company creates its own platform using existing
applications, in-house development, and third-party products as required.
Major vendors offer SOA suites, but an enterprise can and frequently
should take elements from various vendors in assembling its own SOA
platform. Often, an enterprise will benefit most from beginning with what
it has and planning for growth along SOA lines.

Report Contents:

• Executive Summary
• Description
• Current View
• Outlook
• Recommendations
• Web Links
• Related Reports

Executive Summary

[return to top of this
report]

Technology vendors both large and small are developing solutions to
assist organizations in capitalizing on the benefits of establishing a
service oriented architecture (SOA). The wide range of available products
offers the enterprise a significant opportunity to optimize the
network.

 

Related Faulkner Reports

Service Oriented Architecture Tutorial

XML Development Tools Tutorial

SOAs are conceptual frameworks designed to manage Web services and other
technologies in a way that provides efficient reuse of services to achieve
effective, dynamic, and even on-the-fly development and
integration of applications. Companies may maintain disparate portals and
applications, and frequently also connect to a number of partners with
their own applications that must be integrated through the firewall. Such
companies are prime candidates for an SOA.

An SOA platform is a technical solution to an agreed-on
conceptual framework, made up of the set of tools used to control and
manage the SOA. While some enterprises may choose to adopt a single-vendor
SOA solution, one of the benefits of an SOA is the ability to work with a
range of disparate technologies. In this sense, the SOA platform is the
enterprise’s infrastructure, whatever that may be, to the extent that the
infrastructure is designed, or more likely redesigned, to employ
reusable services in its architectural structure.

All of the major vendors in the technology market have rolled out SOA
products and services, and the number of SOA niche vendors has grown,
though many will likely be acquired by larger vendors looking to expand
their markets. Among the leading major vendors now offering SOA platforms
are IBM, with the largest share of the market; Oracle/BEA/Sun
Microsystems; Hewlett-Packard; and JBoss (open source).

Description

[return to top of this
report]

SOAs are architectural frameworks that facilitate the breaking down of
software elements and business processes into standardized components that
can be combined and reused with minimal effort. SOA is not itself a
technology; rather, it requires a layer of middleware to enforce policies
and rules for services such as security, routing, and workflow. In an SOA,
all functions are defined as services; however, the SOA only defines a
service’s required parameters and results, not the technology used to
implement those results. Thus the technology that delivers a service
is not the SOA itself, but its technical solution.

In an SOA, applications can be created and/or integrated quickly and with
less expense than in the past because they can be plugged into the
middleware to be reused or recombined into composite applications.
Services utilize published interfaces that enable them to communicate with
each other by passing data or by coordinating activity between two or more
services.

In this sense, then, an SOA platform is simply that part of an
enterprise’s infrastructure that allows for the use and extension of an
environment composed of applications and services. Such an environment may
include multiple technical solutions, either built in-house or acquired
from any number of vendors, as long as those services are able to
interrelate.

Current View

[return to top of this
report]

An SOA platform is not conceptually dependent on a single vendor, despite
the hopeful suggestions of vendors. An SOA platform comprises any design
an enterprise may use to employ reusable services in its infrastructure
architecture. In a sense an enterprise develops its own SOA platform as it
evaluates its infrastructure, identifies current available services,
designs the path it intends to follow for future growth, and implements
that path using reusable services, including third-party products as
required.

SOA is the current prominent version of distributed computing, a concept
that has been current for more than a decade, and has been deployed at
least to some extent in many organizations. Despite its relatively short
history, SOA technology is in use and its adoption is widening. However,
most companies are still using Web services, and the closely related
microservices, without the overlying architecture of an SOA. Web services
without an SOA require that users understand the data model and comply
with business rules, while an SOA platform allows users to perform work
with less understanding of the system.

SOAs include the ability of businesses to connect one application to
another, whether the applications are located inside of one enterprise or
across several. The most common technology used to achieve this is Web
services, although microservices are becoming increasingly popular. The
difference between an SOA and a Web service and/or a microservice is that
the SOA defines what must be done, and the Web service or microservice
performs the function. While an SOA is usually discussed in relation to
Web services or microservices, it is equally able to use other
technologies as well.

Deploying an SOA platform requires a specific way of thinking about
software resources. This approach can be facilitated by third party
vendors. Until recently, companies had no alternative but to use a
patchwork of software products in order to create an SOA platform.
However, that situation has changed, with almost all the large application
server vendors releasing SOA product lines and creating strategic
partnerships to target vertical markets. An increasing number of vendors
offer single-party SOA platform solutions. Whether this is a desirable
path to follow depends on the nature of the network being considered.

A number of the larger SOA platform vendors are described in Table 1.

As noted above, Microsoft links components of its product suite to SOA
but does not offer an SOA platform as such. The preceding table
demonstrates, nevertheless, that large software vendors provide SOA
technologies, making the benefits of SOAs available to both large and
small clients. These vendors have leveraged their previous
technologies, acquired smaller SOA solution vendors, or a combination of
both methods to deliver robust SOA platforms, including companies such as
Oracle, with its purchase of BEA; Hewlett-Packard, which purchased Mercury
Interactive; IBM and its Webify acquisition; Sun Microsystems’ SeeBeyond
takeover in 2005; Red Hat’s purchase of JBoss; and Software AG’s purchase
of webMethods, in a deal valued at about $550 million USD. Oracle’s
purchases of BEA in 2008 and of Sun Microsystems in 2010 were major events
in the SOA world. RedHat bought FuseSource, a systems integrator, in June
2012. SAP purchased Syclo in June 2012. The rate of acquisition in this
market, however, has slowed somewhat during recent years.

As remote devices and the use of social media have complicated the
picture of enterprise computing, a number of new players ofter products
that specialize in the integration of legacy and web services. Prominent
among these are Pusher and PubNub.

Outlook

[return to top of this
report]

SOA has been highly recommended for businesses and has met with some
adoption, while simultaneously major industry players have released SOA
products and support offerings. SOA can be used to integrate hosted
applications with internal systems, a capability that meets a wide need.
It can also be used to develop applications quickly and inexpensively
thanks in particular to the nature of Web Services, which make it easy to
reuse code in disparate environments. Because of its concrete and
practical benefits, and particularly due to the impact of cloud computing
and mobile devices, including smartphones, SOA has become a frequently
implemented approach, as evidenced by the heavy investment in the
technology that has been made by almost every major application server
vendor, an investment that is predicted to reach $16.4 billion by 2020.

Companies that successfully deploy SOA may find that at least some other
types of enterprise software and developer tools are no longer necessary.
If all distributed computing efforts become service-oriented, then tools
for integration and development, such as EAI, ETL, application server,
MOM, IDE, and RAD tools, EDA, and CEP, are likely to be subsumed by the
SOA deployment.

Looking further into the future, the packaged application market is
another that may be greatly impacted if SOA achieves maturity. There will
be less need for expensive products that are difficult to implement and
maintain if and when an SOA can more quickly and less expensively roll out
new applications through the creation and reuse of services as directed by
the SOA.

The consolidation of the SOA market is expected to continue over the next
few years. The market will most likely be dominated by vendors such
as IBM and Oracle. 

An organization may recognize the benefits that an implementation may
provide to its bottom line, but run into the problem of having few IT
staff members to implement it. This is where vendors such as IBM and
Oracle can capitalize on their large services units. 

Recommendations

[return to top of this
report]

The best candidates for SOA success will have the following
characteristics:

• A need for agile application integration and de-coupling. 
• Executive sponsorship of improved application development and
  integration.
• An IT department that participates in the strategic planning
  process.

To begin implementing a SOA, there are three typical levels of entry.

• Service-enable existing applications with web services and/or
  microservices. An organization has developed a limited number
  of Web services or microservices to meet tactical needs,
  with little or no interaction between the services. Security and
  management features are minimal.
• Service-oriented integration with business functions.
  Low-level interaction between services exists. One action may
  automatically engage another, and workflows link disparate services that
  implement business processes.
• Enterprise-wide transformation. An organization goes
  through an overall IT retrofit in this top-down approach.

Many vendors offer a “readiness assessment” service. This offer should be
approached with caution, as a readiness assessment from a specific vendor
may become a lengthy selling opportunity at the prospective client’s
expense.

Create a Plan. Implementing an SOA has much in common
with implementing enterprise software. The first step in either situation
is to examine the infrastructure, and the second is to create a plan. The
current and future needs of an organization must be examined closely to
determine where within the enterprise an SOA will provide the greatest
benefit with the fastest results. Aspects to consider include interaction
with the systems of trading partners, how services will be used, and what
goals can be achieved through the use of services. The development team
leaders should be involved at this stage of the process, and should remain
closely involved throughout the implementation.

Map Business Processes to Functions. The next step is to
look at business processes and map them to a set of functions, in order to
eliminate overlap and expose gaps. SOA is not just a technical
architecture of services, but also the policies, practices, and frameworks
that ensure that the right services are provided and consumed. Business
processes both within the organization and among trading partners must be
cataloged and analyzed.

Gain Trading Partner Support. The support of trading
partners must be enlisted in order to achieve success with an SOA. To get
this support, trading partners must be shown the relevancy of the SOA
to mutual business activities, and after deployment they should have
results pointed out quickly and regularly.

Phased Implementation. The first implementation phase
should focus on services that are most likely to be reused across the
enterprise. Identify the most generic services and link them in a manner
that serves the greatest number of users. With these generic services in
place, groups and trading partners can begin to see that applications are
being built more quickly and for a lower total cost of ownership. This
“bottom-up” approach to implementation has proven useful in many cases.

In order to maintain positive results, internal and external clients must
be regularly asked for input. Ensure that external clients, as well as the
organization, know what the reusable elements are and where they can be
found.

Outsourcing the Project. Outsourcing is another
alternative. However, in-house developers may have a greater understanding
of their employers’ needs than an outsourced organization can offer. The
closer an SOA’s goals are to a company’s core business, the greater will
be the risk in outsourcing. Routine programming, on the other hand, can
often be outsourced with little risk.

Web Links

[return to top of this
report]

• CA: http://www.ca.com/
• Hewlett-Packard: http://www.hp.com/
• IBM: http://www.ibm.com/
• Microsoft: http://www.microsoft.com/
• Oracle: http://www.oracle.com/
• Red Hat: http://www.redhat.com/
• SAP: http://www.sap.com/
• Software AG: http://www.softwareag.com/
• TIBCO: http://www.tibco.com/

About the Author

[return to top of this
report]

Kirk Woodward is a technical writer. In addition to
project management, his areas of expertise include enterprise software,
hardware systems, and the use of Internet resources.

[return to top of this
report]