Answers to Three Basic SOA Questions

Loraine Lawson

In the eight months I've been reading and writing for this blog, there are three questions about service-oriented architecture that keep popping into my mind and never seem to be answered. Possibly due to some cosmic alignment caused by the space probe Rosetta, I found answers to all three this week.

My first is simply: How do you know if you need SOA? People like to warn that "SOA is no panacea," but that seldom gets followed up with an explanation, and I always inevitably wonder, "OK. So when isn't it a panacea?"

I've been told previously that SOA can be overkill for some simple data-integration tasks, but I suspected even then that was too short an answer. My suspicions were confirmed when I read Dave Linthicum's column, "When Not to SOA."

You can read on Linthicum's blog guidelines for when SOA night work for your organization. But I found it more unusual that someone finally stepped out and said you probably do NOT need SOA if:

  • Your organization doesn't change that much.
  • The architecture is homogenous.
  • The value of change is low.

Honestly, I would think this would mean SOA isn't a good option for many small or mid-sized government agencies, which in my experience don't change that much. Granted, that's a bit of a stereotype and won't apply across the board, but I do personally know of several IT government organizations that fit the stereotype. And by Linthicum's guidelines, all-Microsoft IT shops also would be among those who would want to think twice before investing in SOA.


My second reoccurring question is where companies are going to find employees with SOA and integration skills or experience. Obviously, if you haven't built an SOA, you won't have that skill set on staff, and you'll either need to retrain your developers and architects or you'll have to hire in those skills. WhatPC ran a lengthy article Thursday addressing this problem. Unfortunately, the answer to this question is more complicated than Linthicum's answer.


The article looks at both developing SOA and integration skills. In short, where you find help depends on the level of integration work you're doing. For lower-level technical integration, the technology and tools are pretty easy to use, according to analyst Steve Craggs of Lustratus Research. And if you're buying a vendor solution, you can expect some training and assistance from the vendor.


Craggs told WhatPC that finding the needed skills becomes a problem when you're looking at higher-level integration, such as when you're building a service-oriented architecture. For the most part, you'll need someone with architecture know-how, but that means knowing not just the technology, but also being able to understand the needs of the business - and we all know what a bugaboo that is for IT.


The article also discusses other areas where it will be hard to find the needed skills, such as CRM or business intelligence integration. In fact, you'll find a whole list of jobs and market sectors where you can just bet on trouble.


As I said, there's no easy solution, but the article does offer a few pointers. For instance, you can hire consultants or seek help from vendors. You also can do what the head of information systems and development at one government agency is doing: Train people in the needed skills.


I know: It's a crazy idea, training workers to do their jobs, particularly when the skills are in demand and they might well leave you for a better-paying job elsewhere. But as the IT director points out in the article, you'll probably hang onto them longer than you expect - and in the meantime, you'll be getting work done.


The final question that bothers me - and I'm sure it bothers many of you as well - is how you can determine whether your SOA is a success. Pundits occasionally address this topic, but often it's in generic terms such as return on investment, reuse or something that really isn't very concrete. I mean, ROI can vary from project to project, company to company, and it seems to me a bad ROI could be attributed as much to an inability to implement SOA efficiently as it could be to a failure of SOA.


So, that's why I liked Joe McKendrick's column this week. McKendrick shares how Hub Vandervoort, CTO of Progress Software, measures SOA success by measuring the level of IT backlogs.


Now that's concrete! Plus, it's very understandable, not just to IT, but to the business. It also has the added value of being something you can at first just notice, but then apply to your ROI. For details on how that works, read the original post.

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


Add Comment      Leave a comment on this blog post
Nov 17, 2007 12:39 PM Steve Craggs Steve Craggs  says:
Great post as usual, Loraine.On the skills issue, I would like to add one point. I wrote a post at the Lustratus Litebytes blog a couple of months ago about the 'SOA Revolving Door' - http://blog.lustratusresearch.com/litebytes/2007/07/the-revolving-d.html. The nub of it was that (large) users tell me it takes 6-12 months to train a programmer to be truly productive in designing and building SOA, and once they are trained, because of the level of interest in SOA and the lack of skills, they walk off to a higher paid job. Then the user has to train new people, who then walk....hence the revolving door.Steve Craggs Reply

Post a comment





(Maximum characters: 1200). You have 1200 characters left.




Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.

Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.