How to Avoid Common SOA Pitfalls
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 challengeskeeping an eye out for common pitfalls.
In our years tackling SOA engagements for clients, weve 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 Apaches WSS4J with Infravios 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 spacebut the .NET service expected xmlds.
Its 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
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. Heres 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 serviceusing different terms. Thats why its 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 weve 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.,
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 inthey 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 monthsnot 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 doesnt 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.