There has been a lot of talk about SOA failures lately. There are many pessimists who haven't even dabbled in SOA who have simply wrote SOA off as the next buzzword that carries no merit and will soon be displaced by the next big technology fad. These are obviously people who either did not do their homework or simply have deep scars from past experiences working on new technologies that promised to save the world. This time it is different. SOA is all about fixing business issues, not technology issues, if you chose the right goals.
As Todd Biske wrote, many companies are heading down the SOA path to "increase agility" and "reduce costs". Those are great goals and totally achievable but if you don't tie your SOA goals to business goals, nobody outside of IT will care. This presents a few problems:
- With all of the projects that are on IT's plate these days, it can be extremely challenging to get funds and focus for another IT project.
- Although these are good goals, it may take years to achieve these goals. There is a huge upfront cost in software, architecture, and ongoing labor. Management may not have the patience for another multi year effort without any near term pay back.
- Business priorities usually take precedence. When a new critical business opportunity comes up, it may take priority over SOA. Staying focused could be a challenge.
Although SOA done right can achieve great things for IT, it is the combination of SOA and BPM that does great things for the business. If you can get the business excited about BPM, you can leverage SOA as the technology that makes BPM work. At my company, we convinced the business to go through a business process assessment. We mapped out both the current and future state business processes and identified a multi million dollar opportunity with the following business objectives (not IT objectives).
- Improve customer satisfaction
- Reduce time to market for new products
- Enhance productivity and efficiency
- Improve quality
- Control and manage costs
- Enable revenue generation
I believe that the reason for many of these "failures" is that the original goals of these SOA initiatives are not focused on business drivers. We rarely even discuss the IT benefits with the business. Our ROI on the business side is so compelling that there is no need. We try to keep all discussions focused on the business so they see these projects as business projects and not IT projects. The key take away from this is that the business can see benefits of BPM/SOA as soon as you deliver the first project. It can take IT 2-3 years to achieve the technology benefits. The reason for this is that you will spend the first couple of years creating services. Eventually you will reach a point were you are consuming more services then you are building. Once this happens, then IT starts achieving its goals.
This seems to be a much debated topic so I would appreciate some feedback.