But, to get back to my main point, one of the topics we discussed is how hard SOA is to explain and write about. Of course, it's been said before, but SOA is an architectural approach, not a technology you buy - yet, IT departments still tend to embrace specific technology solutions-say, an ESB or Web services-at the expense of the SOA's full potential.
I ventured to offer my theory on why this happens:
We all know IT attracts people who like to solve problems. While technologists certainly can and do think abstractly, they've always got an eye on moving that abstraction into the concrete. So, for instance, they understand the concept of SOA as loosely coupled and all the other things we know about SOA-but they also know they've got to build it and make it work. And when something new comes along-like SOA did-the working IT guys out in the trenches don't know how to make it work. Why would they? They didn't invent it, they're not at IBM or Microsoft making this stuff up and being trained in the very latest and greatest. Likewise, most of what they read about SOA is too focused on the strategic view and, I'm sure, frustratingly vague.
So when a vendor comes along, offering a specific solution that promises to bridge that gap, they embrace it.
I think this is where a good enterprise architect can make all the difference. The criticism of EAs is that they tend to be stuck in their ivory tower-and from some of the job descriptions I've read, I can see how this would happen. Many of the jobs required someone who can do research, develop a strategy, and map out a plan. But only a few enterprise architect job descriptions asked for someone with leadership skills or experience in translating those plans into specific, tangible deliveries.
IT needs and has tactical people. And it also has and needs someone (the CIO, for instance) who can see the strategic big picture.
But what's often missing is someone who can translate between the two. I think this is where EAs could offer an invaluable service.
After all, the EA's namesakes, traditional architects, don't just draw plans. They have to know about concrete, bricks, roofing material, insulation. They have to go to the job site and work with the builders to ensure their blueprints are being translated into brick-and-mortar buildings. They don't get to sit on the 50th floor, surrounded by picture windows, envisioning new skyscrappers and environmentally friendly home designs all the time (and, really, it's never like that, according to my architect friend). They have to manage the project and oversee the actual building as well.
Companies and IT divisions need enterprise architects to do more than sit in a tower, issuing plans and edicts. I know it's a crazy idea, but maybe-just maybe - companies should stop worrying so much about proficiency in Word, Excel and the quality-initiative-of-the-month, and focus instead on hiring EAs with project management experience and leadership skills.
You can hear me blather on about this and other integration topics, as well as hear Linthicum's response, in the InfoWorld podcast published, appropriately enough, on April Fool's Day. I'll let you be the judge of whether it was a worthwhile podcast.