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.¹   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.²  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.³  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.⁴

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.” ⁵ 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.” ⁶

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.” ⁷

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." ⁸   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.⁹

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.”¹⁰ 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.

---