Todd Biske: Outside the Box

More and more, we’re seeing articles that are now questioning whether SOA is just the next overhyped thing that has come out of IT that has failed to deliver on its promises. Based on a conversation with colleagues at the SOA Consortium, I think at least part of the reason for this is that many organizations still don’t really understand what they’re getting into. At the same time, there’s been a debate on the Yahoo SOA group on SOA as a business thing versus an IT thing. All of this seems to point back to a lack of a clear definition and picture of what we’re talking about.

As I started forming my ideas to blog on this, I was listening to a Software Engineering Radio podcast, which just happened to be a discussion on SOA with Nico Josuttis, who has just authored a book called, “SOA in Practice: The Art of Distributed Systems Design”. In the discussion, I thought Nico put it very well when he stated that SOA is essentially distributed system design where the distributed components have distinct owners. He then said the essentially, there won’t be any projects where a single team has full end-to-end control. It was that second statement that is the key message.

There’s no shortage of organizations that are simply taking the same projects that they’ve been doing for years and simply producing services now as part of them. Is this SOA? It is possible that the project could have been of significant enough scope (more likely a program) to where it included the development of services along with multiple consumers of those services, potentially yielding immediate benefits. The problem with judging SOA from this standpoint, however, is that it is unlikely to scale. Not all projects have this broad of scope. Secondly, it didn’t adhere to the second statement by Nico. By being underneath a common project or program, that effort had complete control over the entire domain. Yes, that project probably had multiple teams involved, but it’s likely that ultimate authority rested with the project architect and project manager, and if they said to do something, it was going to be done that way. Funding decisions and other governance issues don’t even come into play, because it’s all controlled by the project umbrella. An easy litmus test for this is to ask what the organization will do when a new consumer outside of the project comes along and wants to use one of the services that was (or is being) built, but needs some modifications. If it occurs while the project is still in flight, the project manager is likely to raise their hand and say, “Sorry, scope creep, can’t do it.” If it occurs after the project is complete, the new project may have no idea who to even talk to, because the whole structure around that service was based upon the project, and now that the project is over, it’s now being ignored, save for bug fixes/production problems. This isn’t a good situation.

I’m a believer that if you are adopting SOA, you’re committing to a fundamental change in the way IT operates. Of course, this assumes that there are opportunities for improvement within IT. If your IT department is delivering the right things to the business at the right time and for the right cost, great, you’re in the top 5% of organizations and have probably already embraced the changes, whether due to SOA or not. If you’re in the remaining 95% of organizations, you need to give some thought to where you want to go with IT. Is the use of shared services a goal? What are the domains where you know you’ll get some sharing? Is it more about business agility and being able to change the way things are wired in a more efficient manner? How will you tackle the problem of competing priorities when two projects want to leverage a new service, but have competing timelines, or even worse, where one project has control over one consumer and the service, and the other consuming project is at its mercy? How does the organization need to be changed to support this model?

Rather than try to paint my own picture of what this future state could be, I’m going to point all my readers to Nick Malik’s series on Joe Freeflier, part 1, part 2, and part 3. This does a great job in doing this. While this may represent an extreme example, and one that could take 5-10 years to reach, it does a great job in introducing the concepts and ideas that you need to be thinking about as you go forward with SOA.