SOA: Looking inside IT

Usually when we talk about SOA, we talk about two distinct groups: Business and IT. With that, we discuss how SOA impacts and applies to each of these groups and further go on to try and figure out who is more accepting or less accepting etc. The more I see SOA initiatives first hand, the more I start to wonder if these groups are too course grained.

Its very natural for us to settle on only two categories. Its easier to talk about things as if they were black and white, on or off, your fault or my fault. Most of the time this is done to simplify a problem so we don't get bogged down in the minutia of the gray area. For this topic though, I feel that polarizing the participants into two categories obscures a very important piece of the puzzle.

We use the term "Business" to refer to all non-technical functions and resources and "IT" for everything and everyone else. While Jeff Schneider did a good job of breaking down the Business for the purposes of SOA interaction, I feel that IT needs some breaking down of its own.

Within the IT category we have two distinct roles. The first role is that of the enterprise architect although they need not have this title to be in this role. The folks in this role typically see the big picture. They understand the value of design and architecture and strive for consistency and foresight. This group usually sees the value of SOA much in the same way the Business does, although they see it with technical goggles on.

The second role is that of the project teams. This usually consists of project architects, project managers and developers. This group is firmly based in reality and even if they see or could be made to see the value of SOA, they would point to the 3 projects they have going that all have to be done yesterday, shrug their shoulders and laugh about the crazy SOA guys over a beer.

Of course it takes both of these groups working together in some fashion to make any progress towards a Service Oriented Enterprise. It means nothing to have your EA group creating SOA strategies and processes if they don't have the means with which to realize any of it. Implementing registries and documenting business processes are a great start, but unless the project teams are integrated into the process, all you'll be left with are nice diagrams and a bad case of ERS.

So when you are addressing the issues of your SOA initiative, don't blindly look at IT as one big group that needs to get their act together. Rather you need to focus on how you can facilitate the coordination of these two distinct IT roles.