SOA Architecture, Governance, and Industry Standards in the Enterprise

Paul Lipton

Subscribe to Paul Lipton: eMailAlertsEmail Alerts
Get Paul Lipton: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal, SOA & WOA Magazine, VITO Report

Article

Eight Things SOA Is Not; What Not To Do In Your Next SOA Web Services Rollout

What not to do in your next SOA rollout

Sometimes when we're faced with addressing a complex engineering problem it's helpful to reflect on antipatterns. Doing so does more than track wrong solutions to common problems; it also focuses the mind on the interaction of the most important elements of the problem domain. This is true for all engineering, not just software engineering. Suspension bridge designers know to be on the lookout for torsional oscillations because of the collapse of the Tacoma Narrows Bridge, but they also better understand the importance of stiffening the structure in general. The goal is to limit the number of times the antipattern emerges and to notice it when it comes around again. SOA uptake is at a point where such a treatment of antipatterns is helpful.

In my job I work with Fortune-500 clients on SOA enablement. Like everyone else who works in this space, I have to try to cut through both the hype and the FUD (fear, uncertainty, doubt) surrounding SOA to right-size solutions for individual business problems. Sometimes the requirements are very narrow, e.g., "We would like to federate with external partners." Sometimes they are very broad, as in, "We would like to re-tool the entire enterprise for more efficient and agile execution." I like to think of SOA as the synergy between WS standards and tools, and an adaptive organizational structure that can leverage the technology to manage complexity better. In fact, when it comes to complexity management, I tell my clients that with an SOA approach we can fashion an architecture to get to their end state that can be wholly contained on one whiteboard.

Here are some fallacies about SOA that keep architects from being able to concisely contain their SOA solutions on that whiteboard.

1. It's Not a Platform
SOA can't be purchased solely from a platform vendor. IBM, BEA, Oracle, SAP, etc. actively market to their customers the premise that more from their product lines = more SOA. This is not to say that these vendors don't have good products that fit into an SOA quite nicely. We are starting to see serious BPEL, WS-ReliableMessaging, and WS-Addressing implementations from platform vendors. However the concept of the platform, which has gained acceptance over the last two years, serves to tie customers into a one-stop shop for both infrastructure and development. This is antithetical to SOA, whose standards make it possible and advisable to pick the best tools available for the task at hand (and no more). Throw in the marketecture avalanche and customers are reluctant to incorporate needed SOA infrastructure elements outside of the platform. By way of example, if you are planning to implement a partner federation model, you can't get there with a platform alone. Worse yet, we are also seeing stuff like BPELJ out of platform vendors, which is a recipe for tie-in masquerading as an unnecessary standard. The moral of the story: take a holistic approach to SOA infrastructure and avoid platform tie-in. A great place to start is at your favorite open source infrastructure project. Work your way up the food chain from there.

2. It's Not Just a New Name for an Old Development Paradigm
There is a lot of FUD being spread by my fellow Java developers and architects that SOA is just a new services architecture like CORBA or Java remoting. While it is certainly true that loosely coupled RPC service architectures have been around for at least 15 years, SOA is a deceptively powerful simplification of the paradigm. The use of XML and SOAP's realization of an intermediary framework finally gave us true extensibility. Microsoft's signing onto the standards gave us a shot at interoperability - imagine if Microsoft had not signed on and we had a world with XML and SOAP versus MS-XML and MS-SOAP. If it isn't obvious the power that these improvements brought to the table, tell me how to develop a federated security domain of thousands of partners around the world to run a global logistics business, for example, with Java and CORBA. We can do it today with WS security standards and tools, and express the architecture on that one whiteboard.

3. It's Not Custom
Almost all standards are built on other standards and add their own functionality. Standards are the life blood of SOA, even though many are still evolving. The evolving part scares people, but in fact there are very few standards that are truly final. SOA is best served by maniacal adherence to standards. Deviate from them only when they just don't get the job done. As an example, UDDI is probably the most prevalent case in SOA of an often avoided (or at least augmented) standard. However even in this case, registry vendors I am aware of take care to render standard UDDI on demand, and support UDDI as it evolves. So when the time comes to federate registries with other departments or partners via UDDI evolved, you're good to go. If you are eschewing UDDI for a shared Java properties file or other similar service location mechanism, you're on the wrong track. In general, finding a way to support standards in your SOA will keep you healthy in the long run.

4. It's Not Just Hype
Granted, there is more hype around SOA than anything we've ever seen in IT before. A year or two ago a perfect storm of research firms, infrastructure and platform vendors, and integrators emerged under the SOA banner in a post-boom business climate that demanded more functionality from less investment. Throw in the media coverage and the effect was to all but obscure the real technology revolution that was happening in the form of emerging standards and tools.

It is easy to dismiss the hype as "the next big thing," but real value is being experienced, especially by medium and large enterprises. The value comes in two flavors: the ability to address problems that were previously intractable with the new standards and tools, and the ability to become more agile and better manage enterprise entropy. A good example of the former is the use of SOA security standards to build application security frameworks in a much easier way that support things like digital rights management and portal security. Once you cut through the hype and apply the technology in its pure form to your problem domain, real value is easy to find - and lots of businesses are realizing it now.

5. It's Not a Data Integration Panacea
There is a limit to the amount of data source dissonance that can effectively be managed in an SOA. If you have a bunch of different data sources that have evolved over time into a frayed network, SOA is not going to derive a better integration mechanism for you. It's not going to make it any easier to combine result sets into a workable view, and it might make it much worse if you get the XML translation or granularity wrong. It's bad news to see a bunch of services exposed against different customer data sources, for example, with business processes trying to combine them into a unified customer profile. Look to a virtual data service to generate a holistic view of the data and then call that service from your wider SOA. You can either construct this service yourself or purchase it from one of the emerging EII vendors.

More Stories By Paul O'Connor

Paul O'Connor is SOA Practice Director and Chief SOA Architect for e-brilliance LLC (a leading NE SOA consultancy), and is currently doing major SOA architecture and implementations for Fortune 100 clients across the US. Previously he was chief architect for Damascus Road Systems, specializing in security architecture.

Comments (4) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Paul O'Connor 07/14/05 01:36:59 PM EDT

Hi Nigel, both Microstrategy and Business Objects expose XML interfaces for their metadata-driven data views. I am currently using Biz Objects at a client in NYC for this purpose. Take care.

Nigel Charman 07/13/05 05:45:11 PM EDT

Thanks for the article Paul. Would you be able to list some implementations of "virtual data services" ?

Marylene Delbourg-Delphis 06/29/05 02:22:24 PM EDT

Your article is simply remarkable. Can we talk to you? Congratulations for your straightforward clarity. Marylene

Paul O'Connor 06/28/05 12:28:36 PM EDT

Eight Things SOA Is Not. Sometimes when we're faced with addressing a complex engineering problem it's helpful to reflect on antipatterns. Doing so does more than track wrong solutions to common problems; it also focuses the mind on the interaction of the most important elements of the problem domain. This is true for all engineering, not just software engineering. Suspension bridge designers know to be on the lookout for torsional oscillations because of the collapse of the Tacoma Narrows Bridge, but they also better understand the importance of stiffening the structure in general. The goal is to limit the number of times the antipattern emerges and to notice it when it comes around again. SOA uptake is at a point where such a treatment of antipatterns is helpful.