If you read this column and listen to my podcasts, you know that I call SOA what SOA is…an architectural pattern. In many instances, SOA is a vital component of healthy enterprise architecture. Indeed, I’ve provided some keynote talks around this very topic at about half-a-dozen enterprise architecture conferences to date. However, generally speaking, the enterprise architects out there still don’t “get” SOA, and they continue to do a poor-to-average job of creating enterprise architectures that…well…support their enterprise.

By the way, those of you who will respond to this column and tell me that you’re doing well with your architecture, that’s fine. Unfortunately, dozens of you can be an exception to my observations, and it still doesn’t mean I’m wrong here. This is a systemic problem; however, there are clearly islands of success out there.

What’s core to the issue is that many enterprise architects don’t have the political will, or the authority, to solve many of the core problems. It’s very difficult to make changes in enterprises today. There is a certain amount of job risk that comes with those types of actions, risks that many enterprise architects are unwilling, or unable, to take.

Here are the issues, the way I see it:

EAs don’t understand SOA. The largest issue is that the majority of enterprise architects (EAs) do not understand what SOA is and what SOA is not. Either they just don’t bother, or they want the definition of SOA to fit some preconceived and incorrect notion in their minds. Are you listening…you guys who use the terms “SOA” and “ESB” interchangeably?

EAs don’t understand their own issues. The other problem is that many enterprise architects can’t tell you the cost of inefficiencies within their existing IT infrastructure and enterprise architecture, any value they would get from reuse, and any metrics around the value of agility within the enterprise. In some instances there is no central record/artifacts around data semantics, APIs, processes, workflow, etc. If you don’t have a clear understanding of what the current issues are, you cannot know how best to correct them over time.

EAs fear change. If things are bad, then change is typically good. Unfortunately, change also means risk, and risk is something people typically don’t like. The fact is that people are rewarded for maintaining more than they are rewarded for improving. This answers the question about why so many of the enterprise architectures out there are now layers upon layers of tactical one-off solutions designed to “keep things going a few more years.” Somebody needs to have the political will to figure out a long-term solution using sound enterprise architectural approaches, including SOA.

Those enterprises that have clear architectural issues typically don’t understand how to approach fixing the problems. Indeed, it’s often overwhelming to most architects, and thus – like anything else that’s overwhelming – it’s easier to ignore the core issues and go about your daily routine.

If you have a problem, you know the symptoms. It takes two months or more to change any major business process. You have no holistic understanding of your data, your services, or your business processes. You have redundant and dysfunctional data, without any consistent integration strategy, nor common interfaces into the systems. You get the idea.

Unfortunately, I’m not sure that guys like me shining a light on these shortcomings will have much impact. I think it’s going to take some well-published disasters that almost kill a company or two before the powers that be understand the real problem here. Hopefully, a few of you will be more proactive.