Saturday, July 01, 2006

The Four Buckets of SOA Adoption

I realize that it has been a while since I've posted (as many people have reminded me), however the lack of postings is indicative of the activity in the SOA space. Bottom line is we've been busy. In the past we were busy *thinking* about SOA or *preaching* about SOA - today we're busy *delivering* SOA. And it has been busy, on the consulting side we've picked up a ton of new clients and on the training side we'll have trained over 1,000 architects & managers this year on SOA.

However, I'm noticing something really interesting about SOA adoption. You can put the adopters in 4 buckets:
1. Companies that don't do SOA and have no intention of doing it
2. Companies that don't do SOA but keep talking about it and have mastered the blame game
3. Companies that do SOA, but poorly
4. Companies that do SOA and reap huge benefits

Bucket #1
Bucker #1 companies are often busy with compliance, security, BI or other important initiatives. They had the common sense to not do SOA half-assed and have merely delayed the program.

Bucket #2
I recently attended an architects meeting of a certain industry. I witnessed 40 chief architects patting each other on the back about their lack of understanding around SOA. Only 1 in the group had done a roadmap, created a governance program and was demonstrating real results. The others made me want to puke; not because they were Bucket #1 people, but because they were bucket #2. I heard crap like, "SOA is just EAI - and we're already doing that..." - WHAT? What are you talking about?? I wanted to slap them. Honest to God. I witnessed the single biggest threat to SOA - incompetent, lazy, American, corporate architects whose skills were so dated they should go back to their 3270 terminals and program in REXX. I suddenly felt sorry for the CIO.

Bucket #3
These are the guys who have SOA programs, spend money and don't get anywhere. The problem here is almost always the same. Bucket #3 organizations have a whip-smart EA team who can rattle off every WS-* protocol (and usually do). The problem is that they live in EA land and have no ability to get application architects, developers, etc. on board. So what do they do? The EA's just keep marching blindly to the SOA drum. They act like their piece of crap SOA reference models justify their existence. They fail to actually 'realize' the models so when a line architect says, "Were thinking about doing this project using a service oriented style. You guys have been working on SOA for a couple of years; what do you have that our project can leverage?" The EA then hands them a completely non-actionable PowerPoint with a bunch of SOA diagrams that they modified from OASIS (which sucked in the first place). The recipient of this information looks at them with disgust, walks back to his project team and reports, "The jokers in EA still don't have anything we can use."

Bucket #4
Bucket #4 is the really interesting one. They succeed. The question is how? I've scratched a bald spot on my head and think I've got some answers. Here are the characteristics:
1. They have a single person ultimately responsible for SOA who leads a larger steering committee. This group also attacks organizational and process changes.
2. They created a roadmap with realistic deadlines.
3. They have an EA group where all of the members understand SOA and understand the practical needs of the application architects with regard to SOA.
4. The Application Portfolio Governance group has created a "SOA work stream" and selected new applications are sent down an SOA path.
5. The downstream teams (project managers, analysts, app. architects, designers, coders & testers) have all been trained in SOA.

Overall, I'm having a blast. As you can imagine I'm trying to focus my time on the winners. On occasion I'll take the time to let losers know that they're on a losing path, but that usually doesn't have much effect.

No comments: