The On-Ramp to Service-Oriented Architecture

tel: 407.591.4950 | toll-free: 1.888.943.5363 | web: www.eprentise.com
The On-Ramp to Service-Oriented
Architecture
an eprentise white paper

The On-Ramp to Service-Oriented Architecture
Copyright © 2014 eprentise, LLC. All rights reserved. www.eprentise.com | Page 2
© 2014 eprentise, LLC. All rights reserved.
eprentise® is a registered trademark of eprentise, LLC.
FlexField Express and FlexField are registered trademarks of Sage Implementations, LLC.
Oracle, Oracle Applications, and E-Business Suite are registered trademarks of Oracle Corporation.
All other company or product names are used for identification only and may be trademarks of their respective owners.
Author: Helene Abrams
Published: December 08, 2007
www.eprentise.com

It’s crucial for a business to be well informed when considering which system architecture to
implement. Service-Oriented Architecture (SOA) has come to the forefront of IT architectures because the
Internet makes it easier than ever before to connect to and subscribe to services. In that regard, SOA
makes alluring promises of easier integration and enhanced ability to change business processes. Even
before reaching those possibilities, however, the move to SOA raises the age old conflicts between
stability and flexibility, between technology choices and business choices, and between best-of-breed and
all-in-one applications. Increasingly, IT professionals have been looking towards SOA as a method to
integrate their disparate applications and manage change. The “plug and play” capabilities of SOA have a
lot of potential, but an SOA is complicated and not appropriate for all environments.
One of the keys to implementing SOA (and with implementing any other technology) is a business
justification for the advent. Information Week reports that approximately a quarter of SOA and web
services projects fell short of expectations usually because of business and IT alignment problems.
1
Using
an SOA to integrate technologies doesn’t standardize the business processes or ensure that the SOA-
based business components are widely accepted by different parts of the organization. Integrating
systems that don’t have consistent business rules or have data conflicts among them leads to
management and governance issues, increases the cost of implementing SOA, and actually impedes
change.
Vendors of SOA software make promises of strong results, but potential users of SOA should consider the
process of implementing SOA into an existing system. The best information on the steps required to
implement SOA is likely to be gained from those who have already done so. The following is a road map,
drawn from those experiences, to aid in travel from a current IT location to a final SOA destination. Be
aware before departure that this trip may not be as comfortable as advertised.
You’ll need a map – Be prepared to introduce more complexity into the IT system. It’s obvious that with
the advent of a new system architecture that there are adjustments and new concepts to
understand. SOA does not work like other systems; a service-oriented architecture is essentially a
collection of services that communicate with each other. The communication can involve either simple
data passing or it could involve two or more services coordinating some activity. A means of connecting
services to each other is needed and that usually means accessing the Internet.
2
SOA uses a universal
access mechanism to all systems via Web services and a universal data representation (or connection) via
XML.
The reason for making this trip over to SOA is because it is likely to improve business procedures and
ultimately improve profits. However, a cohesive, services definition methodology is not readily
available. The only models out there do not include the business aspect of SOA architecture. It can only
be learned from others who have gone through the transition and by adapting your business to any
changes that come along.
3
You might have to make your own map.
Potholes – Because of Service-Oriented Architecture’s use of Web services, it can lend itself to some
serious security issues that a company would not be exposed to if it were running applications offline. It
may prove more difficult to keep confidential corporate data secure. Additionally, because you may be
relying on someone else for services, performing tasks can become more complicated. The Web service
provider may not always be dependable and their services may be out of reach and beyond your control
at certain times, possibly key times.
4

There are tollbooths on this road – SOA is a continuing process. Just like a living creature it grows larger
and more capable, but its demands grow with it. With SOA, there is a direct proportion between how
much money is invested in the infrastructure and the level of results a company receives from it. For
example, for SOA to work there needs to be hard-coded connections or communication among
applications (usually through adaptors or messages). When the version of the application is upgraded,
the coding for the links must be changed as well. It may also take some extra spending to integrate the
old (legacy) and new systems effectively. Remember that since it is a new technology, it is
expensive. “HP’s Schoenrock says SOA projects carry an average price tag of $300,000 to $2
million.”
5
Plan for much more than an initial expense if you expect a substantial return on the investment.
Inexperienced Drivers – Since SOA is a relatively new and changing technology, it is difficult to find people
that are fully versed in it. Clive Longbottom of Quocirca.com wrote “… research carried out by Quocirca
on behalf of Oracle® earlier this year shows a rather different picture. From a sample size of 1,500
respondents representing a mixture of technical and business people, more than 30 per cent said they
have absolutely no knowledge what SOA or service-oriented architecture means. More than 25 per cent
more said they have minimal knowledge of it, and only 20 per cent stated they have a fair understanding
or a good working knowledge of what SOA is all about.”
6
If you are with a business that wants to implement a Service-Oriented Architecture, the SOA provider you
are buying from will likely assess your company’s situation. They may create one or more projects to
define and create the architecture in your business system. After the SOA is set-up, your business’ IT
department is responsible for the day-to-day operations of the SOA, whether they understand it or
not. The lack of onsite understanding of SOA means that you may have to go outside the company and
pay a specialist to see to any concerns that the company may come across.
New Car, Old Engine – When a business moves towards implementing a Service-Oriented Architecture,
the product is not just delivered in a box ready-to-use. It’s not simply “out with the old, in with the
new.” The reason for moving to a new architecture like SOA may be for many different reasons, but
generally speaking, companies justify moving to an SOA to reduce development costs, share data among
different systems, and enable business process change. But there is no “Tabula Rasa,” no clean
slate. Anything that is wrong with the original systems will carry over and is multiplied within a Service-
Oriented Architecture. It is the digital version of Shakespeare’s “the sins of the father are to be laid upon
the children.”
7
Implementing a service-oriented architecture does not solve the integration and data issues of other IT
initiatives. If current applications are generating and maintaining inconsistent data from many sources,
they do not disappear with the implementation of SOA. If there are data dependencies, they remain. If
there is duplicate data, it remains. Services implemented in a SOA are generally sequential – you call a
service and then wait for a response. As a result, when something changes in an earlier service, that
change has to be reflected in all subsequent services. It is a ripple effect that affects everything around it.
Consider an application that creates a product ID using three separate services likely creates data in each
step for the next service (for example, characteristics, cataloging, and approvals). Step 3 is dependent on
the data of the previous step so if a change occurs in step 1, that change needs to permeate steps 2 and
3. Likewise, inserting a new step likely means that subsequent services need to be modified, resulting in
a cascading effect.

Service-Oriented Architecture doesn’t have a mechanism to analyze data for correctness or consistency.
Nor does it avoid having multiple services that do the same thing or having one service undo what
another service has done. Transferring data into the SOA is a larger, more complicated version of a “copy
and paste” function on the desktop. It is more complicated because when the data is used within an SOA,
there is a chance that the data that is “pasted” may be slightly different than the data that was “copied.”
An SOA is only as good as the components that make it up; one of the most important of which is the
data.
Four lane highway – Implementing a Service-Oriented Architecture successfully requires a focus on four
elements: a solid design, setting standards, reducing redundancy, and delivering consistency.
A design up-front delineates how the services are assembled, which services are reusable, the rights and
privileges of each service, and how the requested data is obtained. A good SOA design identifies the
users and providers who depend on the service so that the business value of the services can be
measured. The design also accounts for the governance, management, and maintenance of the services.
Standards are meant to be enforced across all services within a company and outside that
company. Modifying standards like Simple Object Access Protocol (SOAP) to create proprietary standards
or add special features to the standard inhibit operability and mean that everything needs to be custom-
coded. Interoperability does not happen magically. Before you change or update a service, you need to
understand the business impact and understand all the interdependencies.
Before beginning to implement an SOA, evaluate applications and business processes to determine what
is working well. Consolidate applications that perform the same functions together so that the business
processes can be standardized. For example, if you have multiple applications that do invoicing for
different departments, consolidate them into a single invoicing service that can be shared among all
departments. As you integrate each application into an SOA, make sure that application leverages the
business processes that deliver value to the company. Consolidating applications reduces infrastructure
and maintenance costs and makes converting to an SOA less complex. It is much easier to make changes
in one application than it is in multiple similar applications and a consolidated application reduces the
risks of conflicts among disparate business processes. A key benefit provided by an SOA is
reuse. Multiplying the number of services produced indicates that reuse is not happening, increases the
cost and complexity of the SOA, and reduces value.
At first glance, implementing a SOA is one way to manage master data. After all, if all the data about a
customer or product is integrated together, then you have a complete view of that customer, right? Not
necessarily. Implementing rules within SOA to reconcile duplicate or conflicting data make the services
quite complex. Which data do you change? What is the source of truth? How do you evaluate whether
data is the same?
Before implementing an SOA, it is imperative to cleanse the data, defining the criteria for identifying
duplicates and consolidating duplicate information into a single record, and resolving conflicting
information. The cost of “dirty data” is high. Larry English, a leading authority on data quality issues,
writes, ” …the business costs of nonquality data, including irrecoverable costs, rework of products and
services, workarounds, and lost and missed revenue may be as high as 10-25% of revenue or total budget
of an organization.”
8
This cost is multiplied as the data are shared among services. Before driving down
the SOA expressway, the data must be complete, consistent, and correct or you will need to pull off into

the service road.
No Bicycles or Heavy Equipment – Aside from the added costs of integrating legacy systems and SOA, the
level of integration that was initially expected may never be achieved. Certain elements such as J2EE
Applications and .NET Applications may not be compatible with a Service-Oriented
Architecture. Idevnews states:
Incompatibility with J2EE Applications – J2EE-based applications’ Business Entity Objects are not simple
Entity Beans or simple Data Transfer Objects. They contain complex validation and even work-flow type
business logic which are needed by both the client and the server. This architecture delivers a sizable
payload using coarse-grained interaction to access functionality and requires tighter coupling of front-
and back-end, out of keeping with SOA – although in most cases, these objects are retrieved by Stateless
Session Beans, a function that’s partially service-oriented and preferable to data-intensive pure remote
object architecture. This will prove important to determining an interoperability solution… SOA-
Incompatible .NET Applications – Applications built in the .NET development environment can be equally
poor candidates for SOA-based interaction. Again, complexity plays a deciding role, whether in the
payload or in the interface. As in the Java example, .NET-based applications with a sizable payload do not
lend themselves to service orientation, although they may use Web services – or single call semantics or
Enterprise Services Just-In-Time-activated objects – which are partially service-oriented modes of
transfer.
9
Department of Motor Vehicles – SOA is not just a technology, it is an essential part of a business. “Good
management and governance of the projects is also a top concern. Primitive Logic CTO Pete Conner says
failed projects often result from lack of strong governance over IT and business objectives.”
10
When
deciding to implement SOA, the entire business should be onboard. It concerns people outside of the IT
department. The management must be able to spend and provide the IT people with what they need to
make the transition to SOA a success. Those who use the affected applications must also adapt to a new
way of doing things. Be sure everyone knows where they are going before you get into the car.“Are we
there yet?”
Service-Oriented Architecture is not the magic solution that it is made out to be by the vendors. It is not
a panacea and will not solve every problem. Sometimes, it even creates more problems. After
considering all of the bumps along the way to a Service-Oriented Architecture, think about if you even
want to make the trip. Your business may not be ready or even have a need for it. The brochure may
look nice, but it may be misleading. However, if you still decide to go, before departing, make sure you
are prepared. Borrow a map from someone that has been there, bring more money than you think you’ll
need, take some competent people with you (that want to come along), and keep your eyes on the road
to a Service-Oriented Architecture.

1 Ricadela, Aaron. ”The Dark Side of SOA.”• Information Week. 4 Sep. 2006. CMP Media. 10 Oct.
2006. <http://www.informationweek.com/shared/printableArticle.jhtml?articleID=192501102>
2 ”Service-oriented architecture (SOA) definition.”• Web Services and Service-Oriented
Architectures. 2005. Barry & Associates. 4 Nov. 2006<www.service-architecture.com/web-
services/articles/service-oriented_architecture_soa_definition.html>
3 Michelson, Brenda. ”Observations from the Field” The Hard Part of SOA.â€• Elemental Links. 5 May
2006. 5 Nov. 2006. <elementallinks.typepad.com/bmichaleson/2006/05/observations_fr.html>
4 LaPlante, Alice. ”Editor’s Note: The End of the Beginning of the End of Software?”• Information
Week. 7 Nov. 2006. 10 Nov 2006. <www.informationweek.com>
5 Ibid.
6 Longbottom, Clive. ”SOA is the future – but what exactly is it?”• The Register. 6 Oct. 2006. 18 Oct.
2006. <www.theregister.co.uk/2006/10/06/soa_survey>
7 Shakespeare, William. ”The Merchant of Venice,” act III, sc. V, l. 1
8 English, Larry. Improving Data Warehouse and Business Information Quality. New York: John Wiley &
Sons, 1999, p 12.
9 Gantenbein, Heinrich. ”The Challenge of .NET/Java Interop — sans SOA.” Integration Developer
News. 5 May 2005. Enterprise Developer News. 18 Oct.
2006. <www.idevnews.com/IntegrationNews.asp?ID=166>
10 Ibid.
Curious?
For more information, please call eprentise at 1.888.943.5363 or visit www.eprentise.com.
About eprentise
eprentise provides transformation software products that allow growing companies to make their Oracle® E-Business
Suite (EBS) systems agile enough to support changing business requirements, avoid a reimplementation and lower the
total cost of ownership of enterprise resource planning (ERP). While enabling real-time access to complete, consistent
and correct data across the enterprise, eprentise software is able to consolidate multiple production instances, change
existing configurations such as charts of accounts and calendars, and merge, split or move sets of books, operating
units, legal entities, business groups and inventory organizations.

The On-Ramp to Service-Oriented Architecture

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to The On-Ramp to Service-Oriented Architecture

Similar to The On-Ramp to Service-Oriented Architecture (20)

More from eprentise

More from eprentise (20)

Recently uploaded

Recently uploaded (20)

The On-Ramp to Service-Oriented Architecture