Three Unusual Places to Find Enterprise Architects

Loraine Lawson

Enterprise architects-and architects in general-are the hot ticket item in IT these days. Theoretically, enterprise architects should understand your IT infrastructure and your business, inside and out, so they can help make business functions more efficient and build an infrastructure to support it.

 

And, hopefully along the way, they'll solve some of your more business-debilitating integration problems.

 

That's the theory. The reality is businesses know enterprise architect is a hot title now, but they don't really understand what it means. So, they're handing out the title as a recruitment tool, without defining the job function or setting the right requirements, according to David Foote, who heads Foote Partners, an IT research firm focusing on IT staffing and benefits.

 

Foote was part of a recent panel discussing the evolving role of enterprise architects at The Open Group's 23rd Enterprise Architecture Practitioners Conference in Toronto. Dana Gardner, a consultant and blogger, led the questions for the panel and published the discussion recently both as a Briefings Direct podcast (complete with full transcript) and as a column for IT-Director.

 

The panel members also pointed out that even when companies do define the role, the EA job description and responsibilities varies wildly. Some EAs still only handle infrastructure rationalization, which is where the job started, but others have evolved into more strategic roles. Others report to CIOs, CFOs and at least one even reports directly to the CEO, according to Jason Uppal, a chief architect who participated in the panel.


 

So you can see why the EA community is trying to nail down its job description a bit more. By doing so, they hope to cut down on people holding the title without actually being able to do the job, which obviously would help hiring companies.

 

And not to put too fine a point on it, but it could help EAs keep their jobs, an issue alluded to by James de Raeve, vice president of certification at The Open Group:

In this time of increased pressure and constraints on budget and focus on results, there's ever-increasing need to have more coherence and more commonality and the idea of what EA is as a discipline, what it should be as a profession, and what skills and competencies enterprise architects need to display in their job to succeed.

And they'd like to see the job evolve into a more strategic role that can step outside the bounds of IT, much the way project management begin in IT but evolved into a useable function across the business. Since yesterday I vented my frustration with that aspect of the EA conversation, today I thought I'd focus on the positive.

 

A number of immediately useable tips emerged during the course of the discussion. In particular, the panel-along with a recent list by Gartner-cautioned that social skills are a requirement, not a "nice to have." I know you're always being told this, and it's hard to find techies with people skills, but seriously. This is not optional with the EA position. Enterprise architects should spend a good amount of time talking to business people, even executives. The panel agreed this is a key part of the EA job description.

 

But it's not just about being able to explain things-they also have to be likeable when they do it. They need to be able to be a team player, put people at ease and listen. Uppal said EAs need to be "almost a priest-like sensitive person so that you don't trample on somebody's feelings." It may veer a bit toward hyperbole, but it's still a valid point.

 

Obviously, IT has had a hard time finding these people in the past. You could try to hire them in, but that's not necessarily the best approach, since a key requirement of successful enterprise architecture is understanding the business.

 

The group offered three unexpected ways you might find your future enterprise architects:

 

  • Check your program mangers. It turns out, there's a lot of skill overlap in program managers and EAs, according to Len Fehskens, vice president, Skills and Capabilities at The Open Group. "In the architecture group at Digital ... we used to joke that if you had a program without a program manager, the architect filled that role. If you had a program without an architect, the program manager filled that role," said Fehskens.
  • You might also find a future EA among your consultants-but make sure it's a consultant you've worked with, not someone you just hire in. It's an approach many companies have successfully used, according to Foote. And it makes sense, because in many ways, EAs act like internal consultants, looking not just at the technology, but the entire process the technology will support.
  • Look outside of IT. Many EAs come from engineering. Uppal also recommended you consider looking internally in other areas, then develop your enterprise architects. He compared it to a similar, successful program used at one of his previous employers. The company found people who had the skills it was trying to develop in engineers, established an apprenticeship and then trained the workers in the technical skills.
... if we want to develop architects in IT, we have to step outside of IT into some of the other areas and learn from it," Uppal said. "If you can somehow figure out how to show respect to the person who is doing the work today, we have a much easier time in developing the architects.

And what all these EA titles companies are creating? Foote suggested you partner with HR, rather than letting HR lead on hiring EAs. To stop the title EA from being used as a recruitment tool, work more closely with HR to develop a proper job description.

 

"You should have a representative to the HR organization that was selected by the CIO or the IT management there to represent them to HR," Foote said. "That person should be the person who advocates also for HR, so that they never are handed job descriptions that do not exist in the company. Then, a compensation person tries to figure out what to pay that person."

 

Frankly, I think that's good advice no matter what IT role you're trying to fill.



Add Comment      Leave a comment on this blog post
Oct 5, 2009 9:14 AM Bradley Shoebottom Bradley Shoebottom  says:

I agree with your discussion about requirements. I am an information Architect, a related field concerned with user design, usability, intranets, websites, document and information suite layout and organization, single sourcing, and semantic languages. However, I am not an engineer or programmer. I am have degrees in International relations, 2 in History and part of a degree in engineering and Masters of Education. I worked in E-Learning, as a Military Officer, and Technical Documentation. I found the common skill was my research ability, interview skills, and expression skills (reports, presentations).

I work with Enterprise Architects and they do tend to come from a programming background, and have great people skills.

Reply
Oct 8, 2009 1:33 AM Chris Hull Chris Hull  says:

A Enterprise Architect needs "priest-like" sensitivity so they can talk to the business executives. EAs also need a "god-like" understanding of technology in both depth and breadth so they can talk to the technical people in the IT department. It is rare to find both is a person but this is what the role requires. The EA title has been used so loosely lately that many individuals in that role are lacking one of the two essential elements given above.

Reply
Oct 8, 2009 7:02 AM William Chung William Chung  says:

Could you please refer me to sources where I can find (empirical) data providing proof that EA is of any added value for the company? It could be me (auditor working for a B4), but I have yet to find a company with EA which actually brings tangible benefits. Don't get me wrong. I've seen many useful IT-architectures (mostly infrastructure and application architectures), but I don't see the point in structuring the rest of the business like we structure our IT.

Reply
Oct 8, 2009 7:24 AM Loraine Lawson Loraine Lawson  says: in response to William Chung

Good question - did you see my rant from the previous day? I'd love to talk to someone with empirical data, but I suspect it's still too early for that. And, really, does such data exist for any job?

Reply
Oct 8, 2009 10:48 AM Bill Schirf Bill Schirf  says: in response to Chris Hull

What about an MBA plus 20years IT experience in a variety of environments... and 5+ as an IT Implementation Architect?

Hmm... how might someone find a company with a posting for this? 

Reply
Oct 8, 2009 12:07 PM Tom Tinsley Tom Tinsley  says: in response to Bradley Shoebottom

You are right about how business is currently using the title of Enterprise Architect. Job posting are all over the map.

None of us can guarantee that the title will survive, but the need for this level of position in the corporate office is becoming more apparent. I present this in my latest book, "Enterprise Architects: Masters of the Unseen City".

Hopefully, the Center for the Advancement of the Enterprise Architect Profession (CAEAP) will bring clarity this situation.

Reply
Oct 9, 2009 3:40 AM Tom Graves Tom Graves  says:

The real problem here is that the title 'Enterprise Architect' is used for two fundamentally different roles, and the respective skillsets are rarely to be found in the one person.

The two different meanings are:

- enterprise architecture as 'the architecture of the enterprise'

- enterprise architecture as 'the architecture of enterprise-wide IT'

The former requires very high 'big-picture' skills, very high ability to connect ideas and requirements across different domains, and very high ability to communicate across all levels and all domains. The latter requires a broader scope than most IT roles, but is still essentially an IT-related role, and may only need to connect to the broader scope through what TOGAF calls 'business architecture' (i.e. the aspects of not-IT that impact on IT).

In effect, IT has been using 'enterprise architecture' for the past couple of decades as a shorthand for 'enterprise-wide IT-architecture' - which is misleading, because the latter is only a small domain-specific subset of the literal 'architecture of the enterprise'. Sure, it's a legacy issue, but it's one that's starting to cause serious problems as we finally get to grips with architecture at the whole-of-enterprise scale.

From now on, we need to reserve the title 'enterprise architect' solely for those who work across all domains at the whole-of-enterprise scope, and use an alternate title such as 'enterprise IT-architect' for the continuing IT-related roles.

Reply
Oct 9, 2009 7:40 AM Mike Rollings Mike Rollings  says: in response to Loraine Lawson

I think your question about empirical data existing for any job is a great point.

I commented on your rant so I won't duplicate it here, but I have been calling for a focus on business outcomes, influencing decisions across business and IT, and a move away from the notion of an EA devotee society'.  Focusing on 'EA' is just a part of the brokenness of EA.  I would much rather discuss how to correct EA-related fractures in organizations and describe competencies or practices (e.g. business optimization techniques, dependency analysis) that heal the patient, rather than first convincing someone that they need EA.  It is the competencies that bring value.

My response to the rant is more complete http://www.itbusinessedge.com/cm/blogs/lawson/can-enterprise-architects-align-it-to-the-business-yeah-right/?cs=36310#cf

Mike Rollings

Research Director, Enterprise Architecture

Burton Group

P.S. Previously you referred to our document "EA is more than Engineering" as a good discussions of EA problems. Here is a free download for your readers http://www.burtongroup.com/Guest/Ea/MorethanEngineering.aspx

Also check out "What to do when waking from an EA-induced coma" and other posts with the tag EA at http://eapblog.burtongroup.com/executive_advisory_progra/enterprise_architecture/

Reply
Oct 12, 2009 12:51 PM Stephanie Quick Stephanie Quick  says:

A good Enterprise Architect is a business process analyst with an IT focus.  An IT BPA understands the recursive relationship between IT and business; understands the goals and objectives of the organization, how it functions day-2-day and applies logic to strategically define and model both business processes and IT components to create synergy that will support the goals and objectives of the organization. I'm a BPA and have successfully work on an EA project.

Reply

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.