What would George Carlin say about the Ten Mistakes Companies Make When Implementing SOA?

In Paul Callahan’s recent eWeek article he lists ten mistakes companies make when they implement SOA Projects. It’s a pretty good list, and I’ll summarize it here, but I’d like to do some tweaking.

Do you remember George Carlin explaining how the Ten Commandments could be boiled down to two, with another added for good measure? If not go take a look. That’s what I think about this list. It isn’t bad, but it needs some tweaking.

Let’s take a quick look at the ten first, and then I’ll discuss how I would consolidate.

1. Taking a Shotgun Approach. That is, SOA-enable everything, regardless of whether there is a business need for the resulting services. LogicLibrary’s Brent Carlson likes to call this A Bunch of Services. (ABOS) and is one of the most common pitfalls of Big SOA.


2. Failing to Involve Business Analysts. Technologists tend to think of SOA as a technology initiative rather than a business initiative. When that happens, not only do the wrong things get built, but it is unlikely the organization will ever see the sort of ROI promised by these technologists.


3. Spending More Time on SOA Products Than SOA Planning. Given lack of business direction, IT will tend to think that SOA is something that you buy rather than something you do.


4. Tackling the Largest Projects First. Sure it is inviting to make a big splash with your SOA initiative. But isn’t it better to try to walk before you run?


5. Forgetting that SOA is a Business Problem. It’s not about the technology; it’s about the solution to a problem.


6. Treating Identity as an afterthought. Readers of this blog will know that this is one I take very seriously. Security and identity are the soft underbellies of SOA, and we need to build for security and identity up front.


7. Buying New Products When Existing Investments Suffice. This is a special case of thinking of SOA as a technology rather than a business solution. You don’t always need to buy new stuff, no matter how much you are told to do so by vendors.


8. Misunderstanding Company Key Players. We live in a world of silos, and if you want to play in a sandbox belonging to someone else, you’d better ask first. Don’t assume you will be allowed to SOA-enable legacy systems, deploy to servers or install clients. Find out first, ask, and then get to work.


9. Expecting the SOA Project to Spread Quickly. This isn’t just an issue for SOA, but for any enterprise project where the success or failure of a project is tied to ‘the enterprise’ rather than to a specific project.


10. Lacking Necessary Elements. Embarking on Big SOA without Big SOA resources.

Here’s how I would rework the list. Numbers 1, 2, 3, 5, 7, 9 and 10 are actually different manifestations of the same problem: Treating your SOA rollout as a technical rather than a business problem. If you focus on your business issue, you won’t have ABOS, you will include business in the discussions, you won’t try to ‘buy SOA’ rather than solve your problem, you won’t think it’s a necessity to buy new stuff, you will tie the success of your SOA rollout to a specific business problem and you won’t go down the Big SOA path if you won’t be able to carry through with it.

So now we have four remaining issues.

Numbers 4 and 8 belong together as well. Both are saying the same thing: Start small. Organizations that start small won’t try to tackle the big, high-profile problems first. They also won’t run into the problem of stepping on somebody’s toes. Or at least the likelihood will be much less.

That leaves number 6, treating identity as an afterthought. I’d like to expand this a bit and say that treating scalability, security and identity management as an afterthought is the real mistake.

I’d also like to add an additional mistake. Forgetting your consumers. Effective SOAs will have multiple consumers, and multiple types of consumers. Design your SOA so it can be used by composite applications developers, BPM process gurus, portal programmers and mashers. Then you will be able to get the ROI you need to make your SOA investment an unqualified success.

So like George, I’d like to restate the items in a positive light.

1. Always remember that you are solving a business problem.


2. Start small and scale up as you learn.


3. Design for scalability, security and identity management up-front.


4. Remember your consumers.

Of course, if I really wanted to be true to George I’d add a 5th to the effect that I should keep my &^%$# opinions about SOA to myself.