DSGs are those people (sorry ladies, I'm including you with "guys" as well) who seem to have the political power within the IT organizations, but don't have a clue as to what a SOA is, nor how to go about building one. The core issue is that the "guys" within the organization, those who understand what SOA is and how to build it, typically don't have the political skills to gain control of the projects. And, the guys who have the political skills and are the chosen ones for the new SOA work, don't have a clue as to what SOA is so they deal with it as a technology or system, and not what it is...architecture. I bet some heads are nodding as you're reading this column, right?

Again, the technology around SOA is simple, and I never worry about how we're going to leverage the technology to solve a problem. However, the people issues are more worrisome and more difficult to fix. DSGs are out there and will, I think, continue to grow as increasingly SOA becomes the "important project" with high visibility to corporate leadership. I've noticed that when that occurs, the DSGs move in quickly to control the projects.

Many DSGs attempt to oversimplify the process, rapidly moving through or even foregoing the planning steps. Their main focus is the selection of the technology, or, in some cases, they attempt to force-fit a problem with a predetermined technology solution. This can never be good.

The fact is that SOA is a complex distributed system and thus complex to plan, design, build, and test. The time spent in planning will pay huge dividends later. There should be a very rigorous process/methodology defined that, at a minimum, provides you with a semantic-level, service-level, and a process-level understanding of the problem domain, not to mention the governance model and security strategies. Trust me, you can get SOA right the first time, but with more planning and sweat than you expect.

At issue is the fact that many people in the planning stages of SOA do not get the proper advice and guidance as to how to proceed, or even what a SOA actually is. Thus, the larger tragedy is that many of these projects will hit the wall, and do so with an impact that will reflect poorly on the notion of SOA, when it's not really a SOA issue at all.

The problem is that many DSGs don't understand the difference between JBOWS (Just a Bunch of Web Services) and a true SOA, and accept JBOWS as "experience." In reality, it's an indication that the DSGs don't understand the core value of SOA, and thus could send you off in all sorts of dangerous and costly directions. So, make sure to hire people who understand that SOA is really about configuration, agility, and changeability, and not just about service enablement. It's very easy to expose services; turning those services into solutions is another level of sophistication.

Not sure how to solve this one, other than to shine a light on the problem. Leadership within the Global 2000 will have to understand it and fix it.