Welcome to a special sponsored podcast discussion coming from The Open Group’s 23rd Enterprise Architecture Practitioners Conference in Toronto. This podcast, part of a series from the event, centers on the issue of the enterprise architect (EA)—the role, the responsibilities, the certification, and skills—both now and into the future.

The burgeoning impact of cloud computing, the down economy, and the interest in projecting more value from IT to the larger business is putting new requirements on the enterprise IT department. [See a related discussion on the effect of cloud computing on the architect role.]

So who takes on the mantle of grand overseer as IT expands its purview into more business processes and productivity issues? Who is responsible? Who can instrument these changes, and, in a sense, be a new kind of leader in the transition and transformation of IT and the enterprise?

To help us sort through who takes on the mantle of grand overseer as IT expand its purview, we're joined by James de Raeve, vice president of certification at The Open Group; Len Fehskens, vice president, Skills and Capabilities at The Open Group; David Foote, CEO and co-founder, as well as chief research officer, at Foote Partners, and Jason Uppal, chief architect at QRS. The discussion is moderated by me, BriefingsDirect's Dana Gardner.

Here are some excerpts:

Fehskens: One of the things that I've seen over my career in architecture is that the focus of architects has moved up the stack, so to speak. Initially the focus was on rationalizing infrastructure, looking for ways to reduce cost by removing redundancy and unneeded diversity. It's moved up through the middleware layer to the application layer to business process, and now people are saying, "Well, the place where we need to look for those kinds of benefits is now at the strategy level." That's inevitable.

The thing to understand, though, is that's it's not moving forward in a linear front across the entire industry. The rate of progress is locally defined, so to speak. So, different organizations will be at different points in that evolutionary path.

Uppal: As the role of the architect starts to ascend in the organization ... it makes a lot of other professionals very nervous about what we do. In this day and age, you have to be very good at what you always did in the rationalization technology, but you also have to be very much almost a priest-like sensitive person, so that you don't trample on somebody's feelings.

You have to make sure that you don't trample somebody else along the way, because, without them, you're not going to go very far. Otherwise, they're going to throw a lot of stones along the way. So that's another a huge challenge that we have from skills of the architect ... having this soul that is sensitive to the other professions.

Foote: In the total group of enterprise architects I've met, every one of them was a great communicator. They were able to really make people feel comfortable around some very abstruse, very abstract, and, for people who are not technical, very technical concepts. They just could communicate. They could set people at ease. They were nonthreatening, and by the way, most of them, I think, were really close to genius.

Fehskens: One of the architects who I worked with on a fairly regular basis told me that the most satisfying moment in her career was when one of her clients told her, "You make me feel smart." That for me really encapsulated the communications goal for an architect—to make points about these complex issues so clear that people understand them and feel comfortable with them.

Foote: People really don't know who enterprise architects are. ... [The average HR department person] thinks "architect" is a title that all people in IT want to have ... without really grabbing hold and defining the architect. They've let the IT organization simply hand out these titles to people as a way to attract them to the organization.

... That lack of control in HR is commonplace today. I tell HR organizations that ... 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. 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. ... Mainly the lack of control is around job descriptions.

De Raeve: The other thing is that architects are, by their nature, extremely adaptive, and they redefine themselves to fit into where there are gaps in the organization where there are needs. They reshape themselves to address those needs. So, we're sort of like chameleons or shape-shifters, depending on what the organizational context is.

If you've got a whole bunch of people doing that, it's very hard to say, "You people are all basically performing the same role, because it will look different in some respect. See one person do it. It's even worse. So the only thing you could do is say, "Oh, shape-shifter, some kind of a magician."

... I think what you're asking for is the universally agreed professional framework for the enterprise architect, and I'll give it you the moment we have it. ... We're at an early stage in the maturity of this concept in the profession or in the industry.

... This was the very problem that we were given when developing our certification. We've got some documentation, which defines what those skills and experience levels are. You can look at that, if you're practicing architecture or you are in the architecture space. You could look at that stuff and say, "These are really good things that I ought to be drawing from as I work on my definitions of roles, or as I look at recruiting people or developing or promoting people." The certification is a separate piece of value.

So, we provide a lot of material that enables you to actually come to grips with what best practice things are, a set of core skills, competencies, and experiences that are needed by successful architects. In response to that, we developed our IT Architect Certification Program (ITAC) for the skills and experience, the ITAC Program, and we also have the TOGAF program, which is more about knowledge.

The community is crying out for it. They may not know that they're asking for it, but they're asking for it. One of my things is that I have to go and sell our certification programs to people. So I visit a number of different organizations and explain what we're doing and what it means.

So, we've got the two things: tools to enable organizations to start understanding what best practice is in the space, and then the certification program that allows people to communicate to their customers, their employers, and their next employer that they actually possess these skills and competencies.

Uppal: If we step outside of the IT industry, you'll see a lot of parallels of other professionals being developed, very similarly to how we develop architects. Architects are not this nebulous thing that just grows. They are developed.

Foote: There are definitely some activities in architecture that you can't outsource. ... Most companies that we talk to say, "We like our architects. They've done very well, because we trust them. The business trusts them. We trust them. They are good channels of communication. They've opened up a lot of thought in our company. We'd really like three times more of these people. How do we accelerate the growth internally?"

They want to know how they can develop architects internally, because they know that they're not going to get that same quality. Now, these are people who are architecting out of that very delicate core competency, strategic level that you don't want to share with outsiders—for a lot of reasons.

... I've never met a recruiter who specialized in architects. I don't know that those recruiters exist. They probably don't, because there isn't a lot of demand on the outside for hiring architects.

I do think the architects that I see that are brought in from outside are often consultants, formerly of Accenture, IBM, CSC, or one of the large houses. They are brought in basically to calm down the chatter, to educate, and train. They're there to cleanup a fire, to calm things down, get people on the same page, and then go. Sometimes, that's the best way to bring in an architect.

Fehskens: In a couple of conversations that I've had with people about where we seem to be evolving the role of enterprise architect, they have said basically, "Yeah, these people are going to become in-house management consultants and they're going to be better for that. They're going to know your business intimately, because they're going to have participated in strategic evolution over time."

There is a lot of merit in that analogy and a lot of similarity. I think the only difference is that what we're trying to do with EA is bring more of engineering rigor and engineering discipline to this domain and less of the touchy, feely, "do it because I think it's the right thing to do" kind of stuff—not to disparage management consultants and the like.

Uppal: One of the big differences between management consultant and enterprise architects is that what you put on the table, you have to execute. The management consultant says, "You should do this, this, and this," and walks away. At the end of the day, if you, as an architect, put something on the table and you can't execute this thing, you have basically zero value. People are no longer buying management consultants at face value. They want you to execute.

Read a full transcript of the discussion. The full podcast is also available on iTunes.