SOA Rules of Engagement

Many organisations struggle to get their SOA off the ground. The reasons vary, but mostly stem from getting the very simple things wrong at the start. The following are my 8 simple rules for a successful SOA implementation:

• Don't forget the constructive tension. For SOA to be a success, there needs to be a tension between the desire to do things now, and the desire to do things right. This means setting up a governance function to complement (note: complement, not obstruct) your delivery function.
• Don't forget to deliver something useful early. SOA business cases are notoriously hard, because many (not all) of the benefits arrive in the longer term, and will only be realised if other projects behave as expected. By far the best way to get on in this world is to deliver some business benefit early. Your sponsors will thank you, and it's not as hard as you think - SOAs are all about managing change afterall, so you can do a lot just by delivering a sequence of relatively small incremental projects.
• Don't boil the ocean, the fish won't like it. Many many SOA projects try and 'SOA-enable' huge swaithes of their technical architecture in one foul swoop. It's a well established near-fact that it's difficult or impossible to achieve. I've only worked on one project where this worked, and that was because it was a spin-off from a large company, and so had only a small amount of 'heritage' (nee legacy) systems to contend with - most of the services were built from the ground up.
• Don't worry about the technology. Technology is usually far from the biggest risk to a large SOA programme. Weak benefits cases, poor governance, poor expectation management or a changing political/economic environment are far more likely to be your downfall.
• Do worry about the technology. Having said that technology is not the biggest risk, it is a significant risk. Keep it simple. Implement just the functionality and infrastructure you need in the first instance. Don't believe people or companies that tell you that SOA is a product, or is simply a technical problem that they can solve for you.
• Do get strong project management, but keep them in their box. As I've alluded to above, there are tons of risks waiting to consign your SOA aspirations to the great ESB Gateway in the Sky, so you'll need an excellent project manager to manage them for you. By excellent, I don't mean they're a dictator, I mean they're an enabler for your team, and a black belt in motivation, reporting, and risk management. Whatever you do: If they're running the delivery of a project, do not allow them to become responsible for your organisation's SOA governance. There be dragons.
• Do get an all star cast (at least initially). The nature of SOA is such that there is a lot of opportunity for working smarter rather than harder, which will get you to market faster, make your SOA easier to maintain, and cost you less. Get yourself a team of technical people who really know their bananas; quality is vastly more important than quantity. Seriously consider going outside your organisation to secure at least part of your core team - the people in the next room might be brilliant, but experience is everything in the SOA world. Architects, business/system analysts, developers and testers are all important, and you'll need them to work in perfect harmony for your SOA to really take off.
• Do make sure you're involved. It might be tempting at times to bury your head in the sand, and allow someone else to 'do SOA to you', but don't let this happen. While it's important to get that all star cast, it's also critical that your organisation learns from any 'outsiders', and will be capable of taking the reigns in the long term. That said, do consider keeping outsiders in the mix for the long haul - the world is changing rapidly, and keeping people who've seen other organisations make mistakes close to you will enable you to dodge the pitfalls that consume your competitors.

Comments and your rules, as ever, welcome.