Todd Biske: Outside the Box

James McGovern posted some comments on what “the real problem” is in adopting SOA.

The most important thing that he called out is that “SOA is a paradigm shift.” I couldn’t agree with this more. While he went on to apply this to IT staffers that have worked in legacy environments, I would go even further than that. Anyone who hasn’t had the opportunity to work on a large scale program that impacted a significant portion of the enterprise falls into this category. Why? They simply haven’t had to look outside of the boundaries of the project they were handed. I think this probably impacts the average client-server developer far more than the legacy developer. A VB6 developer has probably built a lot of point solutions for a small set of users. The legacy developer has been the one having to stretch their system to integrate with the demands from the changing business.

Independent of any individual developer, an enterprise wide SOA implementation absolutely requires a paradigm shift. It is a culture change, plain and simple. As long as we continue to define projects in such a way that it is difficult to see outside of the boundaries of that project, we won’t be successful. Think about the case studies that have been published regarding SOA. How many of them are service-oriented applications versus service-oriented applications? Don’t get me wrong, there is nothing wrong with service-oriented applications, and it absolutely is a step in the right direction. It is not service oriented architecture, however. If you look at a case study for service oriented architecture, you will find that the culture change was directed from the top down. Without this culture change, the path to a service oriented architecture will be far longer, and probably far more painful.

I’ve said this before, and I’ll keep saying it. In order for SOA to achieve the goal of accommodating business change, IT has to be willing to change first.