As I mentioned in the last article, Selling SOA to the Business, it is important to gain buy-in from the stakeholders for your planned SOA initiatives. However, at some stage you will need to expose the business to the technology and demonstrate the specific value it will have to them. In parallel you will also want to get a good handle on what is actually possible to deliver as opposed to the hype you have been fed by the analysts.
Many people at this stage will jump straight into a Proof of Technology supported strongly by the tool vendors who are keen to get their products embedded as soon as possible in your organization. This consists of installing the products (ESB, Process Engine, etc), running a few tests, comparing the tools to choose the best/cheapest/one that works, and then declaring it to be the strategic SOA solution from now on.
This would be a mistake if you have not demonstrated how SOA will benefit the business, preferably quantified and validated against the business processes it needs to support. I have found that the best way to achieve this is an SOA Proof of Concept.
So what constitutes an effective SOA Proof of Concept? Based on our experience of dozens of PoCs, I propose that the following characteristics are essential to success:
- Clarity of Outcome. An effective SOA PoC needs to provide each of the stakeholders with a clear benefit from taking part in the exercise. So for business sponsors specific, preferably quantified business value (increased revenue, reduced costs, improved agility); for users an easier life; for architects a clear understanding of the impact of SOA on their standards; and for IT experience of how service orientation will impact their development and support processes.
- Rigorous Scope Management. One of the most difficult challenges with this type of PoC is that during the discovery phase of the exercise a number of additional potential benefits from the approach will be identified. The temptation is to add these to the scope to increase the overall benefit of the PoC. Our experience is that unless you aggressively manage these additional benefits (with the additional effort and implications that come with them) you will lose control of the project and are likely to disappoint one or more of the stakeholder groups and therefore have failed in the key objective of reaching a successful conclusion to the PoC. If any of the discovered potential benefits are overwhelmingly candidates for inclusion, remove other objectives to stay within the time and budget parameters you agreed at the outset.
- Tight Timeboxing. The most effective SOA PoCs we have seen have lasted somewhere between 4 and 13 weeks, with a sweet spot around 6 weeks. Too short a time, and you cannot deliver enough value for anyone to take any notice of the exercise. Too long and the world will change around you and the stakeholders will either lose interest or be dragged onto other more important activities.
- Stakeholder Management. This means involving the right people for the right amount of time. This will include the business sponsor, business problem owner, real users, business analysts, architects, IT management and SOA experts. You will need a mixture of ruthlessness and pragmatism to ensure the right people are engaged at the right time in the project – push for the best people, but be aware of competing requirements on their time by providing flexibility in the project plan.
- Control the Technology. Make sure that you don’t try to change too much in one go. I have yet to come across a successful ‘Big Bang’ SOA PoC where a complete new architecture is implemented in one go. Look for ways to incrementally introduce the specific architecture or tool that can add the most value to the PoC, and show it working with your existing systems before moving onto the next component. Incremental, or evolutionary, adoption of SOA is proving more successful and sustainable than implementing the whole stack in one go.
- Play to Win. Your primary objective is to ensure all participants gain value from the exercise and see the outcome as a success for them personally. Don’t get deflected by fancy technology or a bullying sponsor. If any of the stakeholders don’t perceive sufficient value, you will have great difficulty in translating the PoC into mainstream production.
When we have followed these rules, the PoC has invariably been successful. You may end up doing a number of these PoCs for different stakeholders or technology components, but the approach remains the same. This will build confidence in your sponsors that you know what you are doing. It will also lead to an effective adoption of SOA using the right technology for the right business problem at the right time. Sounds easy doesn’t it?
