The current status quo: 'service averse architectures'

My ebizQ colleague Elizabeth Book nailed it when she identified the architecture we see evolving across many enterprises these days: "Service Averse Architectures."

Anne Thomas Manes, in her keynote speech at last week's InfoWorld SOA Executive Forum agreed, calling SAA the current "status quo."

SAA is:

• An architecture that is built without having first consulted the people who will use it.
• An architecture that is unreliable or does not deliver on its promise.
• An architecture that is so secure and complex that it discourages people from using it comfortably.
• An architecture that is so insecure that its data is compromised, corrupted, lost or stolen.
• An architecture that, in short, is averse to the services it is expected to provide.

What can an organization do to free itself from SAA and move more boldly into the Service Oriented kind?

Through a good diet, lots of exercise, and changing bad behaviors -- figuratively, that is. I recently joined Anne Thomas Manes and Elizabeth Book for an interesting chat on the reasons why companies end up with SAA, rather than SOA. (Podcast is here.)

The root of the problem for organizations stuck in this rut is that they treat SOA on a project-by-project basis, rather than as an enterprise effort, Anne said. "You can always supply service oriented architecture concepts and principles in every single project that you do. The thing is, if you're only doing so on a project-by-project basis, then you're not going to get significant value out of it. Organizations end up with service-averse architectures because they treat SOA as a project-by-project, rather than enterprise, effort

You're just going to get small incremental value -- and that's not necessarily a bad thing. But if you really want to do service orientation, you want to reduce the redundancy that you have in your environment, reduce the number of systems that you have to integrate. You need a cross-project perspective to figure out where your priorities are and what it is you need to do first."

However, not every IT department or enterprise is ready for the kind of changes SOA requires or brings about. Just as lifestyle changes are often necessary to improve one's health, enterprises and their IT departments may also need "lifestyle" changes to successfully leverage SOA, Anne noted. "I think of SOA being a lifestyle. You have to start thinking in a completely different way if you really want to make your systems more agile and more flexible."

Part of this lifestyle overhaul is to think in terms of business needs, not technology needs. "You have to work with various folks in the business organization, to understand what the business is," Anne said. "What are the things that the business has to accomplish? Then you figure out how IT can support it."

Click here for access to the full podcast.