News Stay informed about the latest enterprise technology news and product updates.

Having trouble with SOA? Pay attention to the architecture

There are some anecdotal claims out there in cyberspace that some companies are struggling with SOA. Mind you, we never really hear who these companies are or much about the details of what kind of trouble they’ve had.

That makes it hard to assess what the problem is. Are these users actually pursuing service orientation or are they buying products with an SOA label and expecting them to work miracles? I suspect the latter is a common trait of those who feel they haven’t gotten enough bang for their SOA buck.

Here’s one thing I can tell you: I’ve lost count of how many slide show presentations I’ve seen on SOA, but in every success story presentation I’ve ever seen there is an architecture slide. For instance, when I saw a presentation in April by State Street Corp. centered around how it’s using an ESB for the messaging involving the $15 trillion in assets in has under custody, the slide show did not proclaim ESBs are great and everyone should have one. Instead it delineated where the ESB fit inside State Street’s architecture, what role it served and how it played with other critical functionality in achieving the scalability, reliability and high performance that State Street desires.

If you can’t produce a representation of your architecture and then demonstrate that you’ve actually built systems in accordance with that architecture, then you can’t claim to be doing SOA. You may have undertaken a Web services project or bought some product that might be able to help you with an SOA if you had one, but there is no getting around the primacy an architectural blueprint. Those who lack it are begging for trouble.

Interestingly, in our user survey last fall, readers reported that the top SOA development challenge they are facing is a lack of internal skills or training (30.5%). Nothing else even came close. It’s no secret that the supply of architects who actually understand SOA is lagging behind the demand. Yet the discipline involved with service orientation is far from obscure.

Recently we ran two articles from Thomas Erl about the difference between service orientation and object orientation (second part here). We also recently published some architect best practices. And if you need an example of what can be achieved by adopting a service orientation perspective and paying attention to your architecture, look no farther than this case study from ING Card. ING adopted exactly no new technology when it first waded into the SOA waters and was able to streamline its international credit card business. They were able to do this because they had an architecture at the core of the business plan.

Analysts often wear themselves out reminding users that SOA isn’t something you buy, it’s something you do. Well, architecture is the something you do.

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

This says it all - "Are these users actually pursuing service orientation or are they buying products with an SOA label and expecting them to work miracles?" etc. Unfortunately, very few (if any?) companies are looking SOA but technology. Don't they read about and the definition of SOA. Should be not too difficult. Or, are they confused about business and ITs role in business? The reasons definitely may be vendors and consultants pushing technology as SOA but it can't(?) be the whole story. No company normally buys tools before they have strategy and business plans for a product - or do they? It really seems to be the case in SOA today? Fortunately there are more and more articles like this which are asking the right questions. We can only hope that they get through, otherwise SOA sooner or later is seen as another failure trying to connect business and IT. Maybe we should start explaining SOA more for business side, people, management, blogs, etc - maybe(?) they are more open and more used to business solutions than technical (which are nothing new in case of SOA, no matter how much snake oil some vendors are trying to sell, bits are still bits and messages are still messages!)