SOA has a better sales pitch than its architecture strategy predecessors. But it has lacked a clear, useful proof of concept to get it started--until now.

I got a chilling letter from a reader this week--one of those, "uh oh, we're doing technology for technology's sake" anecdotes. I'm sure the CIO in question has a much more compelling story for why he/she is hell-bent on building an enterprise architecture than depicted here, but there's nothing like hearing it from someone in the trenches to get to the core issues. Here's a quick excerpt:

"My organization recently hired a new CIO who is 100-percent bent on getting us into EA with no looking around or looking back. I am of the belief that a system will work in an organization if the organization is ready for it, as opposed to forcing it upon them. We have great IT people in place who know the staff, who know the personality of the organization and right now, no one believes EA will be a benefit for us. Yes, we could use some better organization in IT and more structure and accountability. But that is a management problem, not something a $1 million-dollar-a-year program will cure."

Even among IT staffers, EA is a tough sell. The core issue the writer is getting at is this: What is the business value of EA?

Based on my research and conversations with CIOs there is very little intrinsic value to EA itself, as I wrote in this story. Some 20 years after the movement began, EA is still basically city planning for IT, an overarching plan of the total data, business processes and IT assets inside a company, how they're used, and how they should be built and shared. This has always been a big, difficult and expensive undertaking, and its ROI has often been opaque to the business. Standardizing, mapping and controlling IT assets does not make the business obviously more flexible, capable or profitable. As a result, IT architecture efforts often fail or become completely IT-centric.

The business value of EA only becomes truly clear (beyond simply reducing costs in the IT infrastructure) when you begin to think of SOA as a strategy for implementing EA. Then the architecture effort has a built-in business goal: create an architecture designed to deliver services to the business in terms it can understand. Simply put, it's the first technical concept I've seen in ten years that actually drives alignment between IT and the business.

CIOs have long been flummoxed by alignment. They often give up after yet another consultant comes in to force select groups of business and IT people to build sculptures out of pipe cleaners at yet another touchy feely offsite. I think SOA gives IT the opportunity to drive alignment with technology--I mean, that's why IT people get into this business, right? It's code, not pipe cleaners, that excites them. And business people get something called "get customer record" that they can reuse in their processes over and over--and that they can understand--and they are happy. They are finally getting IT from their own IT department the way they get IT from iTunes or download.com--"to go." That "get customer record" service can be "downloaded" quickly (if it's designed correctly) and plugs right into their business process.

I know I am glossing over some of the difficulties of creating services and SOA, but when is IT ever simple? At least SOA makes sense to everyone who hears the spiel.

The spiel works as long as it stays focused on business capabilities. As another reader, Dave Youkers, a former consultant, points

You do not have flash or javascript support.

Average (0 votes)

Reply