Getting Real About What Enterprise Architects Can Offer


Back in the good old days, when the newspaper still carried more than six help wanted ads, my husband and I had a Sunday morning tradition of reading the technology section out loud, with an eye toward mocking the ones obviously written by IT-clueless human resources people.


You know the ads I'm talking about: They're often for something like a business analyst, net admin or Web programmer, but they include a hodgepodge of requirements that made you wonder if this person would singlehandedly be doing everything in the IT department. Usually it went something like this:


Wanted: IT professional with 10 or more years of experience programming in COBOL, Java, C++, .Net, HTML, PHP, PERL, Adobe (whatever that means), Palm OS or LegoScript, and Unix. Five plus years experience in network security, Cisco, SQL and Oracle. Must be proficient in Microsoft Word and Excel. Black belt in Six Sigma or TQM experience. Web design a plus. Preference given to candidates with MBA or engineers. Pay scale $36,000 to $40,000.


I'd read it aloud and we'd laugh and laugh.


After seeing that IT Business Edge had posted a sample SOA enterprise architect job description (salary: $55,000 to $63,000-'nuff said), I spent about 15 scanning Monster.com's EA classifieds, just to get an idea of what companies are asking for these days. Based on my totally unscientific survey, I surmised that:


  1. For some reason, being proficient in Microsoft Word and Excel remains an essential job requirement, no matter where you work in IT.
  2. Although there's a hodgepodge of requirements for enterprise architect jobs, they tend to fall into either requirements that are more business- and research-focused or more technically focused.


I've been thinking about the enterprise architect job since last week, when I did a podcast with David Linthicum, who blogs about SOA for InfoWorld. Since I'm definitely not trying to be any kind of "thought leader" and I'm accustomed to being the one asking questions, I was pretty uneasy about the whole experience.


As it turned out, he kindly stuck to subjective questions, such as what's surprised me and what's disappointed me in my two years of covering integration. As I told Linthicum, integration is one of the most difficult topics I've covered, and that includes my time covering planning and zoning issues in Kentucky and Oklahoma. It's not as exciting as IT security-or covering the police in the Twilight Zone-esque Edmond, Oklahoma - but it is always challenging and there are still unexpected twists.

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.

Who wouldn't?

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.