Enterprise Initiatives

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:

1. 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.
2. 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.
   
3. 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.

These are some of the reasons for the "failures". Most failures can be attributed to people, not the technology. But it is not all doom and gloom like the recent discussions on the web is leading us to believe. If you make the proper business case, SOA can transform your company and lay the foundation for future wins in the area of agility, flexibility, quality, extendability, and even profitability. Here's how.

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).

• Strategic
  
• Improve customer satisfaction
• Reduce time to market for new products
• Operational
• Enhance productivity and efficiency
• Improve quality
• Financial
• Control and manage costs
• Enable revenue generation

These are all objectives that the business can understand and are easy to measure. Measuring IT objectives such as agility and flexibility are extremely challenging and not tangible to business people. With key business drivers like the ones I mentioned above, the business gets on board and starts championing key BPM/SOA initiatives. In our case we built a three year road map of projects that aligned with one or more of these objectives. Each project had its own business plan and was blessed by the CFO. This translated into three years worth of capital that was set aside for our BPM/SOA initiative. That's focus and that's commitment from the top.

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.

If you read the numerous technology blogs daily like I do, you soon realize that most people still don't understand SOA. Today I read this article from Joe McKendrick called Why even the best SOAs are stalling. In this article Joe discusses an article by Anne Thomas Manes where she discusses how she has only come across one company that has realized any value from SOA. In her article she referred to an article from Ron Schmezler at Zapthink called Why Service Consumers and service providers should never directly communicate. Apparently this article caused all kinds of heated debate on the message boards. Her conclusion is whether you agree or not with Ron that SOA and integration are two different things, the discussion is irrelevant.

....this technology discussion is irrelevant.....It has become clear to me that SOA is not working in most organizations.

So why are so many organization struggling with SOA? And why are even the organizations who are building SOA the "right" way not realizing the value? In my opinion, I don't think people truly understand SOA and its value proposition.

Business Value
The business gets value when SOA is used as an enabler of BPM. You can reengineer your process all day, but you need to allow these business processes to communicate with your legacy systems. The business can't wait for IT to blow up legacy applications in order to create new user interfaces with robust workflows under the covers. Instead IT must abstract the legacy layer and make it easy to build composite front end applications that leverage years of investments in the legacy applications. This allows IT to deliver huge amounts of value to the business in a relatively short amount of time (if done right).

IT Value
The value for IT is in reuse and speed to market. As your SOA matures, the amount of reuse grows exponentially. As Jason Bloomberg explained in Zapthink's architect boot camp, if you architect SOA correctly, you will move from creating services to consuming services. Once you have built a good baseline of abstract services, you can quickly meet the business's demands by assembling business services rather then building them from scratch each time. Think of it as Lego building. If you start with a hand full of white and red Legos that are rectangular in shape, you can create a few nice structures out of them.


Then you add more colors, followed by new shapes (circles, squares, arcs, etc.), followed by custom pieces (parts for trucks, trains, buildings, boats, etc.) and soon you can build an unlimited amount of structures.



The Real Problem
What I see as the real problem preventing companies from successfully deploying and realizing value from SOA is they don't fully understand SOA and they underestimate the amount of change to the culture. So here are the list of non technical issues that will kill your SOA project:

• If you don't align SOA with a key business driver, you greatly reduce the odds that you will ever reap the rewards of SOA.
  
• If you don't include BPM in your SOA implementation, then SOA becomes just another IT buzzword for the business and not an enabler.
  
• If you don't take a proactive approach to change management, resistance will prevail and you will spin your wheels dealing with change (been there, done that).

Key take away
The problem with SOA isn't SOA, it's people. People must understand SOA and the importance of aligning their initiative with a key business driver. BPM is the killer application that can get your business sponsors on board. And finally, you need strong leadership with a focus on change management to pull it off.