SOA Initiation Patterns
As I talk to companies about SOA projects and getting started, they are, as you can imagine, at widely varying stages. It would be nice if all had mature, well managed IT departments, huge budgets, and business managers who understand the value of IT and are engaged in using it. Sadly, that's not the case. This matrix identifies four places the business might be and characterizes the approaches that are likely to succeed at introducing SOA to the business.
The lower-left quadrant is what Bret called "process projects." In this quadrant, there is no CIO-driven plan for rolling out SOA or managing it's use. Further the business has very little engagement in SOA. If this is where you're at, you're probably going to have to introduce SOA from the grassroots, even employing a skunkworks. The key is to identify a service with an opportunity for reuse and then design it, build it, and prove it out. Pick carefully--the goal is to show what SOA can do and convince the skeptics.
When the CIO is involved and the IT infrastructure is mature, you can have more complex projects. Bret calls these IT-led projects. Because the business isn't engaged, you're not going to be doing business process reengineering. Even so, there are plenty of infrastructure-based services that you can work on until the business is ready. In this quadrant, you start by creating an enterprise reference architecture. Infrastructure-based SOA projects are rolled out using in a multi-period roadmap. An enterprise architecture group is a prerequisite to this work.
High business sponsorship and low IT complexity results in business-led projects. In these cases, the IT team doesn't typically have the confidence of the business; maybe they messed up the last big project. Also, in these cases the budget is usually limited and ROI is a focus. The CIO and team should enthused about SOA even if the IT infrastructure isn't all that it could be. In this quadrant, start by finding a key business project. It's important to identify a project with SOA needs. Use an service oriented architecture by specifying services and use the project to demonstrate SOA capabilities.
The final, upper-right quadrant, Bret characterized as the area of mega-projects. Mega projects result in sweeping business change and have significant IT impact. These kinds of projects don't happen very often and requires big budgets. I have a different view of this quadrant. I don't think you need mega projects and in fact, I don't think a mature IT organization would want to do them in any event. I do think that this quadrant is characterized by a comprehensive approach to SOA, but that the projects themselves would probably roll out over a long period according to a well-planned roadmap.
A lot of what you hear about SOA starts by assuming you're in quadrant four and then goes from there. Bret's approach gives a more realistic approach to initiating SOA in your business no matter what state you find yourself in.