Enterprise Initiatives

Everyday as I sift through the articles in my Google Reader, I see countless debates about the relationships between SOA & BPM, IT driven vs. business driven, and top down vs. bottom up. There is so much debate about these topics that I sometimes wonder if anyone is getting any work done. Glance at these headlines and ask yourself how confusing this must be for somebody who is in the research stages of SOA.

* The proper relationship between SOA and BPM
* The awkward dance between BPM and SOA
* BPM Driven SOA
* BPM Without SOA: 'Like One Hand Tied Behind Your Back
* Why BPM Screws up SOA

* Business Driven SOA
* Who's in Charge of your SOA?

* Another view: avoid bottom-up SOA like the plague
* Bottom-up SOA is harmful and should be discouraged
* Should SOA be Top Down or Bottom Up

I have mentioned it in the past and I'll say it again. There is no single answer to these questions. There are many factors that can influence these decisions such as:

• Whether you have strong executive sponsorship or not
• Your IT staff's capacity to change
• Your EA maturity level
• Your staff's talent level
• Budget
• How much time you are given to deliver
• The main driver for the initiative

These are in no particular order. I am not going to tell everyone how I think you should run your SOA projects. I will give you insight into the decisions we made on my project.

In this article I tell the story of how we got the business to support a BPM and SOA initiative. IT had been pushing this for a while but could not get the funding. Once we convinced the business to reengineer their business processes we were able to come up with the justification to buy BPM for operational efficiencies and SOA as the technology to enable BPM.

We then launched into a process reengineering exercise which produced a portfolio of a dozen or so initiatives with an extremely attractive ROI. This determined the bottom up approach for us. We were funded specifically for delivering the projects identified from the process reengineering exercise. We then analyzed the projects and identified the services that would be required to support the new business processes. We did this for each project. Then we recommended a priority order which was based on two factors:

1. Business benefits - ROI, operational efficiencies, customer service, etc.
2. Architecture benefits - Service reuse and speed to market

We performed a three week "SOA roadmap" exercise that took these two factors into consideration. There were huge advantages of moving certain projects to the front of the priority list because of the number of services contained in the project that would be shared by the other projects. To figure this out we mapped out all of the services for each project and identified projects in the portfolio that would give us the biggest bang for the buck from the standpoint of service reuse.

The other constraints we had to deal with was time and money. Each of these projects in the portfolio had to be justified individually. They each had very specific funds and very aggressive timelines. The first project which included implementing the stack and delivering a beta version of a B2B portal in 10 weeks really constrained us from a governance standpoint. For this first project it was critical that we delivered quickly to deal with the perception that SOA initiatives take forever to implement. Funding for the other projects in the portfolio were also dependent on the results of the first deliverable. Due to these constraints, we did not have the luxury to establish a governance model up front. We alerted everyone of the risks of not establishing our governance model and agreed that we would be allowed to implement our governance model for the next projects.

As we sit now, we are wrapping up the first project and getting the funding to tackle several projects concurrently. We are gearing up with our implementation partner to start establishing our governance model that will help us grow our SOA with the release of each new project.

So for us, we are building SOA from the bottom up, the business and IT are working together to drive the initiatives that drive SOA adoption. The business is the owner of this multi year initiative. We are focusing on a specific area of the business that has 20 year old processes. Other business units are seeing the benefit and lining up to launch their own initiatives. The company is changing the way they think because of BPM and SOA. Twelve months from now we will be a different company because of this.

To sum it up, I can't tell you how you should address top down vs. bottom up, BPM driven SOA or SOA driven BPM, business driven or IT driven. I don't think there is a silver bullet. I believe the decision should be based on the environment you work in and the constraints that you are faced with.

I would love to hear from others who have been down this road.