One of the big questions I hear asked is “How do I go about implementing an SOA?”

If you do a google on “Service Oriented Architecture” (use the quotes to be fair) you will find that Google lists 11,500,000 documents related to SOA. If you go to Amazon.com and do the same search, you’ll see 609 books on the subject.

The majority of these documents and books basically tell you to do the same five things to transition your organization’s information technology infrastructure to one based upon SOA principles: 1) have governance, 2) have a roadmap, 3) take one bite at a time, 4) train your staff for SOA, and 5) use open standards.

I don’t want to dispute or debate any of what they have to say; I’m certain it’s all good. Instead what I thought I would do is mix things up a bit and share with you what I consider to be the top ten things you can do to really screw-up up a move to SOA. Let’s begin…

1. Run and tell your CEO or Agency Executive that SOA is going to save the day by solving all of their IT problems. Tell them it’s easy. Show them the glossy brochure your vendor gave you; that’ll really impress them.
2. While you’re at it, tell them that you won’t need all the money they gave you this year. With all this stuff about reuse you’ve been reading, SOA is going to save them a boatload of money.
3. Treat moving to SOA just like any other IT project. It’s still just hardware and software, no use getting all excited. You just need SOA requirements, and then it’s coding, testing, and deployment.
4. Keep the “operator” folks away from the effort. You know that as soon as they get their fingers on the project, they’re going to want to muck it up with business needs and process diagrams.
5. Plan to convert all of your applications to SOA all at once. In fact, go ahead and announce the date you’re going to shut-down the mainframe. That will illustrate your commitment to SOA.
6. Inform the mainframe COBOL programmers and DB2 admins that they need to find new jobs and then immediately put in a request with HR to hire a dozen XML and SOAP programmers.
7. Don’t waste your time on developing a plan or roadmap (aka enterprise architecture) to move to SOA. No one really reads all those documents; and after all, you have the functional specifications from your existing applications.
8. Immediately go out and buy an ESB from your favorite vendor. Don’t know what one is? Don’t worry, your vendor will know, and they will be glad to come in and just plug everything together. SOA, done.
9. Also make sure you develop as many services as possible. You’ll be able to justify your move to SOA based on the number of services you develop; the more you develop, the better you’ll look.
10. Finally, if all else fails screw-up up your SOA project, then try this – take your best techie and put them in charge of the effort, then sit back and enjoy the fun!

I hope that you enjoyed my little diversion from the serious side of SOA, and I also hope that you were able to see through my satire and recognize some of the silly things organizations do to torpedo what should be a fun and beneficial experience for every organization.

BTW, no vendors, programmers, or other techies were actually harmed in the writing of this blog, at least none that I know of.