How to Avoid Common SOA Pitfalls

By Mukund Balasubramanian

(Back to article)

In a perfect world, the implementation of a service oriented architecture (SOA) in your organization will help better align IT services with those day-to-day business processes in which your colleagues, customers, and partners engage. Yet, in order to reap the promise of SOA, the prudent CIO must wrangle both organizational and technology oriented challenges—keeping an eye out for common pitfalls.


In our years tackling SOA engagements for clients, we’ve learned a lot about what to watch for. Here are some of the most common sticking points:


1. Overlooking security inconsistencies. To assume vendors’ and developers’ security products will work together is to risk the safety and security of the corporate data around which you are building your SOA.

Case in point: in the course of a project integrating Apache’s WSS4J with Infravio’s SOA governance stack for a large client, we were asked to enable Web Services Security (WS-Security) for a range of services, from encryption to signature verification.


WS-Security, as you may know, is broadly accepted among open source developers as a security framework, and WSS4J is a popular implementation of WS-Security. We successfully enforced security at the intermediary level until we routed to a secured .NET service. It turns out that service expected an encrypted message. While we had the required certificate, every time we hit the service it returned a fault. Why was this? Well, WSS4J, in compliance with WS-Security, uses “xmldsig” in the name space—but the .NET service expected “xmlds.”


It’s but one example of a small inconsistency with big implications.


2. Assuming standards are in place. Yup, another “Gotcha”. Not all open source products comply with Web Services Interoperability (WS-1), though it is the broadly accepted industry standard. This is problematic, because the basic concept of SOA is built atop a foundation of standards compliance. Until the day comes when true adherence is the law of the open source land, be on the lookout for clashes.


Another example: in one of our SOA projects, we used IONA’s WS-1-compliant Artix Advanced SOA Infrastructure Suite as the SOA backbone to expose a layer of business services to be consumed by other applications including the open-source SugarCRM/Jira for bug-tracking. Note that SugarCRM and Jira both expose their Web services using Remote Procedure Call encoding. All well and good except Artix neither supports nor enforces RPC-encoded services. Designing a method to handle RPC-encoded services meant we fell six weeks behind.


Pay close attention to the evolution of SOA specifications by reading trade journals and talking with peers at other organizations also working on SOA implementations. Such research will tip you off to potential problem areas.


3. Using poorly thought out naming conventions. Here’s another one where thinking ahead can save time down the road. In an SOA, multiple versions of the same services are consumed simultaneously by users all over the organization that may refer to one business process, e.g., one “service”using different terms. That’s why it’s critical that you decide early on how you will include the following parameters in the name-space of a service and propagate your chosen naming conventions across the development team handling your project:


       The business domain the service belongs to;

       The service name that explains the business function; and

       The major version of the service.


4. Relying on sub-par data. Many of the failures we’ve observed in SOA enablement projects originate from poor quality data. Careful cleansing of data sources would alleviate many of these issues and ensure information is accurate and standardized (e.g., “New York,” not “NYC,” “ny,” “New York City,” etc.)


5. Cutting corners on planning. In SOA as in other kinds of complex technological projects, the devil is in the details. As CIO, you need to:


       Talk with stakeholders. Cull business users’ wishes for the finished solution. Give all departments a chance to weigh in—they know better than anyone how day-to-day processes really work, what problems need solving, and what business services are most essential.


       Translate between the two sides. You or someone you tap may need to translate business requirements into “developer-speak” your team can understand. Expect to serve as referee as business and IT strive to get the project done right.


       Enforce application testing. Test early and often to make sure that line of business folks’ wishlists are being translated into workable code.


       Set realistic deadlines for integration with partners’ applications. Insist that everyone on your team adheres to them.


6. Rushing to deployment. The best SOA projects go live after a period of months—not when the proverbial switch is flipped. Start within one department so you can keep tabs on service granularity (which we guarantee will change over time), and flush out risk along the way. Enterprise-wide SOA enablement doesn’t happen overnight, but the benefits it engenders will generate many positive effects for your organization, from IT to business stakeholders to customers and partners.


Mukund Balasubramanian is CTO of Photon Infotech, a next generation Internet consulting firm specializing in cutting edge business solutions utilizing Web 2.0, SOA, Open Source and Mobile application development. Mukund also served as VP of Product Development for WebMethods before joining Photon. Prior to that, Mukund was the founder and CTO of Infravio, a company he co-founded in 2000 based on his Stanford University research thesis while still a student.