The State of Enterprise Architecture: Vast Promise or Lost Opportunity?

Transcript of a sponsored podcast on the potential of enterprise architecture, resistance in the business community, and finding common ground.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: The Open Group.

Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions, and you're listening to BriefingsDirect. Today, we present a sponsored podcast discussion, coming to you from The Open Group Conference in Boston, the week of July 19, 2010.

We’ve assembled a panel to delve into the advancing role and powerful potential for enterprise architecture (EA). The need for EA seems to be more pressing than ever, yet efforts to professionalize EA do not necessarily lead to increased credibility and adoption, at least not yet.

We’ll examine the shift of IT from mysterious art to more engineered science and how enterprise architects face the unique opportunity to usher in the concept of business architecture and increased business agility.

The economy’s grip on budgets and the fast changing sourcing models like cloud computing are pointing to a reckoning for EA -- of now defining a vast new promise for IT business alignment improvement or, conversely, a potentially costly lost opportunity.

Please join me in better understanding the dynamic role of EA by welcoming our guests. We are here with Jeanne Ross, Director and Principal Research Scientist at the MIT Center for Information Systems Research and noted author. Welcome to BriefingsDirect.

Jeanne Ross: Thank you. It’s nice to be here.

Gardner: We are also here with Dave Hornford, an architecture practice principal at Integritas Solutions, as well as the Chairman of The Open Group Architecture Forum. Welcome Dave.

Dave Hornford: Thank you. It’s good to be here.

Gardner: We're also here with Len Fehskens, Vice President for Skills and Capabilities at The Open Group. Welcome, Len.

Len Fehskens: Hi, Dana. Glad to be here.

Gardner: Let me start with looking at this inflection point or opportunity. Many have discussed here at the conference that there's a lot to be done and gained by proper EA. But the stakes are high, because not all of these organizations seem to be rallying around this concept. So why are the stakes high, and why haven’t people gravitated to EA?

Ross: The stakes are high, because organizations are becoming more digital out of necessity. It’s a more digital economy. Thus, IT is more strategic. I think people see that, but outside of people who have already embraced architecture, there is some reluctance to think that the way we get more value from IT is basically by taming it, by establishing a vision and building to standards and understanding how that relates back to new ways of doing business, and actually developing standards around business processes and around data.

Exciting stuff

There is a piece of it that’s just not appealing. Besides, we feel like this should all be about innovation, which should be all exciting stuff. Architecture just doesn’t have the right feel for a lot of businesspeople, who are saying, "Oh sure, the digital economy is very exciting."

Gardner: We’ve also been hearing here at the conference that there is this delayed gratification effect, whereby a lot of the structure and discipline that you might bring to architecture can have a long-term and strategic benefit, but most people are focused on the here and the now.

A recurring theme for me here has been, "How we accommodate both?" How do we present something to our executives and across the organization that they can work with now, but that also will put us in a strong long-term position? Jeanne?

Ross: This is where there is a certain art in architecture. We’ve learned a lot about methodologies, disciplines, and tools, but there is an art to be able to take the long-term vision for an organization and not just say, "It’ll come guys, be patient," but rather, "I understand that starting tomorrow, we need to begin generating value from more disciplined processes."

Great organizations actually learn how to do something in the near-term that builds toward the long-term, but also delivers on some new value to the organization today.

Gardner: Len, we're looking at quite a bit of change. We're asking the organization to change how they use and perceive of IT, and to elevate the way in which they process the logic of the business itself to an architectural level. Then, we're also asking these architects, the individuals, to put on many hats and be multi-disciplined.

The question to you is, in examining the state of EA, this concept of a professional category or definition of EA, where is it at this time?

Fehskens: It’s really just a gleam in many people’s eye at this point. If you look at the discipline of EA and compare it to mature professions like law and medicine, we’re back 200-300 years ago. We’ve been doing a lot of research recently into the professionalization of other disciplines.

Most of the people studying the subject come up with a fairly short list of characteristics of professions. They usually include things like a well-defined body of knowledge, and well-defined educational program and particular degree programs, often offered by schools that are specifically focused on the discipline, not just the department within a larger organization.

There's some kind of professional certification or vetting process and often even some kind of legal sanction, a right to practice or right to bear the title. We don’t have any of those things right now for EA.

Proprietary knowledge

The body of knowledge is widely distributed and is largely proprietary. We’re at a state similar to going to a lawyer, and the lawyers try to sell themselves based on secret processes that only they had that would allow you to get a fair shake before a judge. Or similar thing with a doctor, who would say, "Come to this hospital, because we’re the only people who know how to do this particular kind of procedure."

So, we’ve got a long way to go. The big thing we’ve got going for us is that, as Jeanne pointed out, the stakes are high and so many organizations are becoming dependent upon the competent practice of EA as a discipline.

There's a lot of energy in the system to move forward very quickly on the professionalization of the discipline, and in addition to take advantage of what we’ve learned from watching the professionalization of disciplines like law, medicine, engineering, civil architecture, etc. We’ve got long ways to go, but we are running really hard to make some progress.

Gardner: Dave, we have high stakes. We have a great opportunity. This is a cake that hasn’t been baked yet, so folks can work with this. As a practitioner and someone who’s involved with the Forum, tell us where you see the current traction. Where are people who are doing this doing it well, and what is it about them that makes make prepared for this?

Hornford: Where people are doing it well is where they are focused on business value. The question of what is business value is highly dependent. People will mention a term, “agility.” I work with a mining company. They define agility as the ability to disassemble their business. They have a mine. Someone buys the mine. We need to remove the mine from the business. A different organization will define agility a different way, but underpinning all of that is what is the business trying to achieve? What is their vision and what is their goal?

Practitioners who are pursuing this have to be very clear on what is the end state, what is the goal, what is the business transformation, and how will the digital assets of the corporation the IT asset actually enable where they’re going, so that they’re able to move themselves to a target more effectively than their competition.

The stakes are high in the sense that should someone in your industry figure this out, they will change the game on you, and you will now be in a serious trouble. As long as all of your competition is struggling as long as you are, you’re okay. It’s when someone figures it out that they will change the game.

Gardner: Jeanne, through your research and publishing, you’ve identified some steps -- four that we heard about earlier today. Two of these seem to be very focused on IT, but then progress beyond IT. It’s this transition that seems to get people a little tripped up.

We often talk about the platforms that the IT people are focused on. I have project. I have a set of requirements. I’m going to install, manage, and optimize a platform, but at some point, that needs to work toward the business agility. Help us understand the role of the enterprise architect today in making that transition?

Ross: Right now, the enterprise architect would help design the platforms, but the critical thing to recognize about platforms is they represent the underpinnings of processes, which would be data, technology and applications.

Process vision

The architect is working very closely in designing these platforms with people who have a vision of how a process ought to be performed. It might be in terms of an end-to-end process. It might be in terms of a process that’s done repeatedly in different parts of an organization.

But, the architect’s role is to make sure that there is a vision. You may have to help provide that vision as to what that process is, and how it fits into the bigger vision that Dave was talking about. So there is a lot of negotiation and envisioning that becomes part of an architect’s role that is above and beyond just the technology piece and the methodology that we’ve worked so hard at in terms of developing the discipline.

Gardner: Len, when you go out and hear the requirements in the field and you see the need for a professional category, it seems that things are moving so fast that it's almost perhaps a benefit to have this as a loose concept.

So, the question for you is, if business processes are dynamic and continue to be accelerating in how quickly people need to adapt, isn’t the role of the enterprise architect in actually managing adaptability, rather than actually being a category like a lawyer or a doctor?

Fehskens: Yes, but I don’t think that changes the fact that the skills associated with doing architecture are largely independent of the domain that you're working in.

There is a set of capabilities that an architect has to have that are largely independent of where they are working.

There is a set of capabilities that an architect has to have that are largely independent of where they are working. While Dave and Jeanne were talking, I was thinking that, despite the fact that the discipline is so immature as a profession, we're still doing surprisingly well.

In terms of its maturity as a profession, it may be 100 or 200 years back, compared to law or medicine, but on the other hand, the quality of the practice is much more like where medicine and law were 50 year, 25 years ago.

So, there is a disparity between the capability, the quality of the services that enterprise architects are providing, and the maturity of the profession. That's a characteristic of architects. Architects have to be inherently adaptable.

In a lot of cases, we make a big deal about the technical expertise of architects, but in a lot of architectural engagements that I have been involved in, I didn’t actually know anything at all about the subject matter that I was being asked to architect.

What I did know how to do was ask the right questions, find the people who knew the answers to those, and help the people who actually had the information orchestrate, arrange, and understand it in a way that allowed them to solve the problem that they really had.

Dynamic environment

I agree that there is something fundamentally different about the kind of work that architects do, compared to say lawyers and doctors. It is a much more dynamic environment, but the skills to deal with that dynamism are not really dynamic themselves. They're pretty stable in terms of the ability of architects to face a whole host of different kinds of problems and apply the same skills to them in a way that produces successful results.

Gardner: Dave, we heard the need for architects to be evangelists, to rally the troops, to get people on the same page, to hasten transformation, all of which is inherently difficult. So how about leadership? We haven’t heard that word, but it seems that the role of the architect is to really be a leader above many other activities within the organization. What is it about the leadership capability that you think can make or break the enterprise architect?

Hornford: The fundamental with leadership in EA is that architects don’t own things. They are not responsible for the business processes. They are not responsible for the sales results. They are responsible for leading a group of people to that transformation, to that happy place, or to the end-state that you're trying to achieve.

If you don't have good leadership skills, the rest of it fundamentally doesn’t matter. You’ll be sitting back and saying, "Well, if I only had a hammer. If I only had authority, I could make people do things." Well, if you have that authority, you would be the general manager. You’d be the COO. They're looking for someone to assist them in areas of the business at times that they can't be there.

I learned far more about doing EA in an 18-month period, when I was a general manager of a subsidiary for a telephone company. My job was to integrate that into the telephone company. I got that role as the enterprise architect for the integration, but through transformations I became the general manager of the subsidiary.

If you do not lead and do not take the risk to lead, the transformation won’t occur.

I learned more there, because I had the balance between having authority and not having to do some of the softer leadership, and coaching myself into doing the changes that were necessary. Seeing that transformation was a great learning experience, because it highlighted that you must lead as an architect. If you do not lead and do not take the risk to lead, the transformation won’t occur. One of the barriers for the profession today is that many architects are not prepared to take the risk of leadership.

Gardner: Jeanne, what about this issue of authority? Just because the enterprise architect has the vision -- and maybe has a very good plan as to what should take place in a particular way for that particular company -- at this particular time they don’t have the budget and the authority. If they can’t marshal those people who do have the budget and authority to cooperate -- wow, lost opportunity. Let’s discuss the issue of authority, and the role of the enterprise architect.

Ross: That’s quite a dilemma. In an environment where the architect can see the possibilities and can’t get the commitment of other people, it’s really not possible to win that. One of two things has to happen. Either the architect is successful in spreading the word and getting commitment or the architect should go somewhere where that’s possible, because I just don’t think you can successfully pursue architecture alone. You can’t just go off in a corner and be a successful architect, as we’ve been discussing here.

The first thing you do, because you are in an environment where you get it and you see it and you know what needs to be done, is that you do everything you can to get commitment across managers who can make things happen. But, there are situations where that’s not going to happen, and you're better off finding an organization that’s longing for good architecture talent -- and they're out there. There are plenty of organizations looking for architects to help them down that path.

Hornford: A key point that Jeanne made this morning in her presentation was the fundamental for commitments. If those commitments aren’t there, the organization will not absorb, consume, or benefit from EA.

Compelling value proposition

Fehskens: A phrase that you’ll hear architects use a lot is "compelling value proposition." The authority of an architect ultimately comes from their ability to articulate a compelling value proposition for architecture in general, for specific architect in a specific situation. Jeanne is absolutely right. Even if you have a compelling value proposition and it falls on deaf ears, for whatever reason, that’s the end of the road.

There isn’t any place you can go, because the only leverage an architect has is the ability to articulate a compelling value proposition that says, "I’ve recognized this. I acknowledge this is promise, but here’s why you have reason to believe that I can actually deliver on this and that when I have delivered on this, this thing itself will deliver these promised benefits."

But, you have to be able to make that argument and you have to be able to do it in the language of the audience that you're speaking to. This is probably one of the biggest problems that architects coming from a technical background have. They'll tell you about features and functions but never get around talking about benefits.

My experience with businesspeople is they don’t really care how you do something. All they care is what results you're going to produce. What you do is just a black box. All they care about is whether or not the black box delivers all the promises that it made.

To convince somebody that you can actually do this, that the black box will actually solve this problem without going into the details of the intricacies and sort of trying to prove that if I just show you how it works then you’ll obviously come to the conclusion that it will do what I promise, you can’t do that that. For most audiences that just doesn’t work. That’s probably one of the most fundamental skills that architects need in order to work through this problem -- getting people to buy into what they are trying to sell.

The thing to recognize about business agility is that it’s a journey. You don’t want to start making your compelling business values something you can't deliver for three years.

Gardner: Based on what we’ve been hearing here at the conference, the metric of success and perhaps even the lever to get the authority and commitment is this notion of business agility. As Dave pointed out, business agility can be very different for different companies at different times. It could be a divestiture. It could be growing into a new market. It could be acquiring, or what have you.

So, if we need to get to business agility with our focus on the short-term as well the long-term strategy, what is it that an enterprise architect needs to do in order to assess and project business agility? Perhaps the more technical folks are not used to something like that?

Ross: The thing to recognize about business agility is that it’s a journey. You don’t want to start making your compelling business values something you can't deliver for three years. Many times the path to agility is through risk management, where you can demonstrate the ability of the IT unit to reduce downtime to increase security or lower cost. The IT unit can often find ways to lower IT cost or to lower operational cost through IT.

So, many times, the compelling value proposition for agility is down the road. We've already learned how to save money. Then, it’s an easier sell to say, "Oh, you know, we haven’t used IT all that well in the past, but now we can make you more agile." I just don’t think anybody is going to buy it.

It’s a matter of taking it a step at a time, showing the organization what IT can help them do, and then, over time, there's this natural transition. In fact, I'm guessing a lot of organizations say, "Look, we're more agile than we used to be." It wasn’t because they said they were going to be agile, but rather because they said they were going to keep doing things better day after day.

Common ground

Gardner: Because the economy remains difficult, because budgets are under pressure, this notion of cost could be really a good common ground to bind areas that perhaps have been disparate in -- in terms of IT, business, and so forth.

Len, what about that -- enterprise architects as cost-cutters or cost-optimizers? Is this a short-term, let’s do this because the economy requires it, or is that really a key fundamental point of successful architects?

Fehskens: No, it’s a long-term requirement. It goes back to what the essence of architecture is about. Architects are ultimately charged with making sure that whatever it is that they're architecting is fit for purpose. Fitness for purpose involves not doing any more than you absolutely have to.

The notion of engineering efficiency is built into the architectural concept. It goes back to an idea that that was developed in the 1980s in the business process re-engineering movement which was the best way to make things simpler is to get rid of stuff. And, the stuff that you need to get rid of is the stuff that’s not essential or doesn’t really address the specific mission that you're trying to achieve.

Architects don’t cut costs for the sake of cutting costs. They cut costs by removing unnecessary cruft from whatever it is that they're responsible for architecting and focusing in on the stuff that really matters and the stuff that’s actually going to deliver the value, not stuff that’s there because it looks keen or because it’s the latest technology widget or whatever. Again, that’s an inherent property of what it is that architects do.

Cost cutting itself is not the goal. The goal is ultimately efficiency and making sure that you're not wasting time doing stuff.

Just as agility is, in some respects, a side-effect of what architects do, we need to keep in mind that agility is a means to the end of alignment. You can have a lot of agility if you never achieve alignment. Then, you're just continuously misaligned.

Similarly, the cost-cutting itself is not the goal. The goal is ultimately efficiency and making sure that you're not wasting time doing stuff. That doesn’t matter, because you are not only wasting time, but you are obviously wasting money, and you're committing resources that are necessary to solve this problem. Actually, those additional resources sometimes just get in the way, they make things worse, rather than making things better.

The architect’s approach to dealing with the architectural way of problem solving means that agility and cost cutting sort of are not short-term focuses. They are just built into the idea of why we do architecture in the first place.

Hornford: And that cost isn’t necessary. A lot of people focus on IT cost. It is cost to the business.

Gardner: Total cost?

Hornford: Total cost, and it’s not agility of your IT infrastructure, but agility of your business. If you lose that linkage, you lose the alignment that Len mentioned. Then, you're not able to deliver the compelling value preposition.

Gardner: We talked earlier about the notion of moving from a platform mentality to a business process and agility mentality. We hear a lot from the vendors and suppliers. They have a role in this as well. The architects are beavering away in these companies, trying to change culture and transform the business, but we hear marketing from the vendors, "If you do this product, this platform, or this technology, it will solve your problems."

Is there a message to the enterprise architects that they should be taking to their organization about the role of the vendors, and is that changing from what we’ve perceived in the past as the role of a vendor or a supplier? Len?

Limit to leverage

Fehskens: Big question. The short answer is, yes. I often joke that every architect will answer the question "yes ... but." So, here comes the but. There is a limit to the leverage you have over suppliers, and the architects have to work with the material that’s available to them. Hopefully, the vendors are listening to the needs of their customers and doing the same kind of thing on their side that architects are trying to do.

Gardner: Don’t the suppliers have to adjust too?

Fehskens: Yeah. It’s a big ecosystem. If you’re selling something that nobody needs or wants, you’re going to go out of business. Suppliers have to be adaptable to the needs of the customers, who are changing. We’re all in this big dance, and everybody is trying to avoid stepping on somebody else’s feet or tripping up and falling over their own.

How does that sort itself out? That’s a difficult question to answer, because there are time-lags and some organizations misread the environment in the current business climate, and they go out of business. Other organizations are very good at anticipating future needs by looking at the trends. They happen to be in the right place at the right time, when somebody needs something they’ve got and it’s available, and they end up winning the battle.

So, yes, we all have to learn how to cooperate. One of the goals of professionalizing the discipline is making it possible for architects on both sides of that relationship to communicate with one another in language that they both understand and recognize that you can’t optimize your side at the expense of other side, because at some point that’s going to come back and bite you. We have to make it possible for architects to have those conversations and to make it apparent to the businesspeople on both sides what the business value is.

A big part of architecture work has been around the development of standards that facilitate interoperability. In many respects, conforming to interoperability standard is counter intuitive to a business, because you basically give away whatever proprietary advantage you have by locking in the customer doing it your own way.

On the other hand, the same mechanism that allows you to lock a customer in also allows the customer to lock you out.

On the other hand, the same mechanism that allows you to lock a customer in also allows the customer to lock you out -- if they decide that they get better payoff from taking advantage of interoperability amongst multiple or other vendors who’ve agreed to collaborate and adopt a particular standard. It’s all about reading the environment and responding appropriately. This ultimately goes back to the idea of fitness for purpose.

Gardner: Jeanne, the relationship between the enterprise architect, the business, and the supplier -- is this an evolving dance? What are some of the new choreography steps?

Ross: I'm not sure I know the dance yet! One benefit we get from good architecture is that we understand the process components and the underlying technology and application from data components, which allows us to take advantage of what’s on the market.

If there is a good component, we can grab it, and if there is not, then we don’t need to take it. What architecture is doing -- and I think we’re seeing vendors start to respond to this, but have a long way to go -- is spur a real developing marketplace for the components that many organizations need. I look out there and I say, "Now pretty much everyone gets it that they don’t have to provide any benefits internally to their employees, because you can outsource that." We get that component. It’s a plug and play.

Core to the business

There are things that are more core to the business that we’ll see more available. I don’t think the architects are going to also become the vendor managers. They're the ones who are going to design the components and recognize the interfaces, but they’ll be working closely with the vendors to make sure the pieces come together.

Gardner: It does seem that the vendors are appreciating that they’re elevating their role inside their enterprises. The notion of EA is elevating beyond platforms. The vendor response seems to be that, "We’ll provide everything -- we’ll merge, acquire, and provide everything at an architectural level." Do you think that’s the right way?

Ross: I should note that I use the term “platform” differently from you. There is technology platform, which I think is what you are referring to, but there are digitized process platforms that are really valuable, and many times vendors can provide the whole thing. Software as a service (SaaS) is a partial example, but actual business process outsourcing really accomplishes that. I think of these as potential platforms for organizations.

But, there is a fine line between a platform and an outsourced process, and organizations are trying to piece that together. What's our platform? What are the components for plugging into and taking out of that platform? That’s the architectural challenge. I feel like I just didn’t answer your question, but it is the thought that came to my mind.

Gardner: It occurs to me that this is another point of variability, and that the architect needs to not only consider the variables internally, but suppliers are redefining themselves, and cloud computing is pushing the envelope on what you would consider as sourcing options.

Different organizations will have different things that matter to them.

So, Dave, last question before we close up. This notion of a dynamic environment for sourcing and vendors redefining their role, perhaps trying to expand their role, sounds to me like the enterprise architect’s role becomes more critical as a result.

Hornford: I'd agree with that. If we're going to look at our sourcing options, using the word "component" as opposed to "platform," I can acquire a benefit. I can acquire a benefits engine as a service or I can build my own and manage my own processes, whether fully manual or digitized. Those choices come down to my value in the business.

Different organizations will have different things that matter to them. They will structure and compose their businesses for a different value chain for a different value proposition to their customers.

If we get back to the core of what an architect has to deliver, it’s understanding what is the business’s value, where are we delivering value to my customers? How that organization is structured, how it succeeds, how it gets its agility, and how it gets its cost may be different for different organizations. We have a larger collection of tools available to us without a clear, "This is the right answer. Everyone does it this way."

Gardner: Well, we’ll have to wrap it up there. It’s obviously a deep and interesting subject, and we will be revisiting it often, I'm sure. We've been discussing the advancing role and powerful potential for EA, and how practitioners and leaders face a vast new promise for IT business alignment improvement. But there are also quite a few missing parts, and perhaps even a lost opportunity, if you don’t do this and your competitor does.

This sponsored podcast discussion is coming to you from The Open Group Conference in Boston. We're here in the week of July 19, 2010. Please join me in thanking our guests, Jeanne Ross, Director and Principal Research Scientist for the MIT Center for Information Systems Research. Thank you.

Ross: Thank you so much, Dana.

Gardner: We are also here with Dave Hornford, Architecture Practice Principal at Integritas Solutions, as well as the Chairman of The Open Group’s Architecture Forum. Thank you, Dave.

Hornford: Thank you, Dana.

Gardner: And also Len Fehskens, Vice President of Skills and Capabilities at The Open Group. Thanks, Len.

Fehskens: Thank you, Dana.

Gardner: This is Dana Gardner, Principal Analyst at Interarbor Solutions, and you’ve been listening to BriefingsDirect. Thanks for joining, and come back next time.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: The Open Group.

Transcript of a sponsored podcast on the potential of enterprise architecture, resistance in the business community, and finding common ground. Copyright Interarbor Solutions, LLC, 2005-2010. All rights reserved.

You may also be interested in:

• Enterprise Architects Increasingly Join in Common Defense Against Cyper Security Threats
  

• The Open Group's Allen Brown on Advancing the Value of Enterprise IT Through Architecture
  
  
• Mutual Embrace of SOA and Cloud Computing Builds Into Productivity Waltz Across the IT Landscape

New Definition of Enterprise Architecture Emphasizes 'Fit for Purpose' Across IT Undertakings

Transcript of a sponsored BriefingsDirect podcast with Enterprise Architecture expert Len Fehskens recorded live at The Open Group’s Enterprise Architecture Practitioners Conference in Seattle on Feb. 2, 2010.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: The Open Group.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect.

Today, we present a sponsored podcast discussion coming to you from The Open Group’s Enterprise Architecture Practitioners Conference in Seattle, the week of Feb. 1, 2010.

We're going to take a look at the definition of enterprise architecture (EA), the role of the architect and how that might be shifting. We're here with an expert from the Open Group, Len Fehskens, Vice President of Skills and Capabilities. Welcome to the show.

Len Fehskens: Thanks, Dana.

Gardner: I was really intrigued by your presentation, talking, with a great deal of forethought obviously, about the whole notion of EA, the role of the architect, this notion of "fit for purpose." We want to have the fit-for-purpose discussion about EA. What are the essential characteristics of this new definition?

Fehskens: You'll remember that one of the things I hoped to do with this definition was understand the architecture of architecture, and that the definition would basically be the architecture of architecture. The meme, so to speak, for this definition is the idea that architecture is about three things: mission, solution, and environment. Both the mission and the solution exist in the environment, and the purpose of the architecture is to specify essentials that address fitness for purpose.

There are basically five words or phrases; mission, solution, environment, fitness for purpose, and essentials. Those capture all the ideas behind the definition of architecture.

Also from the conference: Learn how The Open Group's Cloud Work Group is progressing.

Gardner: The whole notion of EA has been in works for 30 years, as you pointed out. What is it about right now in the maturity of IT and the importance of IT in modern business that makes this concept of enterprise architect so important?

Fehskens: A lot of practicing enterprise architects have realized that they can't do enterprise IT architecture in isolation anymore. The constant mantra is "business-IT alignment." In order to achieve business-IT alignment, architects need some way of understanding what the business is really about. So, coming from an architectural perspective, it becomes natural to think of specifying the business in architectural terms.

We need to talk to business people to understand what the business architecture is, but the business people don't want to talk tech-speak.

Enterprise architects are now talking more frequently about the idea of "business architecture." The question becomes, "What do we really mean by business architecture?" We keep saying that it's the stakeholders who really define what's going on. We need to talk to business people to understand what the business architecture is, but the business people don't want to talk tech-speak.

We need to be able to talk to them in their language, but addressing an architectural end. What I tried to do was come up with a definition of architecture and EA that wasn't in tech-speak. That would allow business people to relate to concepts that make sense in their domain. At the same time, it would provide the kind of information that architects are looking for in understanding what the architecture of the business is, so that they can develop an EA that supports the needs of the business.

Gardner: So, in addition to defining EA properly for this time and place, and with the hindsight of the legacy, development, and history of IT and now business, what is the special sauce for a person to be able to fill that role? It’s not just about the definition, but it's also about the pragmatic analog world, day-in and day-out skills and capabilities.

Borrowed skills

Fehskens: That's a really good question. I've had this conversation with a lot of architects, and we all pretty much agree that maybe 90 percent of what an architect does involves skills that are borrowed from other disciplines -- program management, project management, governance, risk management, all the technology stuff, social skills, consulting skills, presentation skills, communication skills, and all of that stuff.

But, even if you’ve assembled all of those skills in a single individual, there is still something that an architect has to be able to do to take advantage of those capabilities and actually do architecture and deliver on the needs of their clients or their stakeholders.

I don't think we really understand yet exactly what that thing is. We’ve been okay so far, because people who entered the discipline have been largely self-selecting. I got into it because I wanted to solve problems bigger than I could solve myself by writing all code. I was interested in having a larger impact then I could just writing a single program or doing something that was something that I could do all by myself.

That way, we filter out people who try to become architects. Then, there's a second filter that applies: if you don't do it well, people don't let you do it. We're now at the point where people are saying, "That model for finding, selecting, and growing architects isn't going to work anymore, and we need to be more proactive in producing and grooming architects." So, what is it that distinguishes the people who have that skill from the people who don't?

An architect also has to be almost Sherlock Holmes-like in his ability to infer from all kinds of subtle signals about what really matters.

If you go back to the definition of architecture that I articulated in this talk, one of the things that becomes clear is that an architect not only has to have good design skills. An architect also has to be almost Sherlock Holmes-like in his ability to infer from all kinds of subtle signals about what really matters, what's really important to the stakeholders, and how to balance all of these different things in a way that ends up focusing on an answer to this very squishily, ill-defined statement of the problem.

This person, this individual, needs to have that sense of the big picture -- all of the moving parts -- but also needs to be able to drill in both at the technical detail and the human detail.

In fact, this notion of fitness for purpose comes back in. As I said before, an architect has to be able to figure out what matters, not only in the development of an architectural solution to a problem, but in the process of discerning that architecture. There's an old saw about a sculptor. Somebody asked him, "How did you design this beautiful sculpture," and he says, "I didn't. I just released it from the stone."

What a good architect does is very similar to that. The answer is in there. All you have to is find it. In some respects, it's not so much a creative discipline, as much as it's an exploratory or searching kind of discipline. You have to know where to look. You have to know which questions to ask and how to interpret the answers to them.

Rarely done

Gardner: One of the things that came out early in your presentation was this notion that architecture is talked about and focused on, but very rarely actually done. If it's the case in the real world that there is less architecture being done than we would think is necessary, why do it at all?

Fehskens: There's a lot of stuff being done that is called architecture. A lot of that work, even if it's not purely architecture in the sense that I've defined architecture, is still a good enough approximation so that people are getting their problems solved.

What we're looking for now, as we aspire to professionalize the discipline, is to get to the point where we can do that more efficiently, more effectively, get there faster, and not waste time on stuff that doesn't really matter.

I'm reminded of the place medicine was 100 or 150 years ago. I hate to give leeches a bad name, because we’ve actually discovered that they're really useful in some medical situations. But, there was trepanning, where they cut holes in a person's skull to release vapors, and things like that. A lot of what we are doing in architecture is similar.

What we want to do is get better at that, so that we pick the right things to do in the right situations, and the odds of them actually working are much higher than better than chance.

We do stuff because it's the state of the art and other people have tried it. Sometimes, it works and sometimes, it doesn't. What we want to do is get better at that, so that we pick the right things to do in the right situations, and the odds of them actually working are much higher than better than chance.

Gardner: Okay, a last question. Is there anything about this economic environment and the interest in cloud computing and various sourcing options and alternatives that make the architecture role all the more important?

Fehskens: I hate to give you the typical architect signature which is, "Yes, but." Yes, but I don't think that's a causal a relationship. It's sort of a coincidence. In many respects, architecture is the last frontier. It's the thing that's ultimately going to determine whether or not an organization will survive in an extremely dynamic environment. New technologies like cloud are just the latest example of that environment changing radically.

It isn't so much that cloud computing makes good EA necessary, as much as cloud computing is just the latest example of changes in the external environment that require organizations to have enterprise architects to make sure that the organization is always fit for purpose in an extremely dynamically changing environment.

Gardner: We have been talking about the newer definitions and maturing definitions of EA. Joining us has been Len Fehskens, Vice President of Skills and Capabilities of The Open Group. Thank you.

Fehskens: Thank you very much, Dana.

Gardner: This sponsored podcast discussion is coming to you from The Open Group's Enterprise Architecture Practitioners conference in Seattle, the week of Feb. 1, 2010.

I'm Dana Gardner, principal analyst at Interarbor Solutions. You've been listening to BriefingsDirect. Thanks, and come back next time.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: The Open Group.

Transcript of a sponsored BriefingsDirect podcast with Enterprise Architecture expert Len Fehskens recorded live at The Open Group’s Enterprise Architecture Practitioners Conference in Seattle on Feb. 2, 2010. Copyright Interarbor Solutions, LLC, 2005-2010. All rights reserved.

You may also be interested in:

• Cloud computing, enterprise architecture align to make each more useful to other, say experts
  
  
• Cloud pushes enterprise architects' scope beyond IT into business process optimization role
  
  
• New era enterprise architects need sweeping skills to straddle the IT-business aligment chasm

New Era Enterprise Architects Need Sweeping Skills to Straddle the IT-Business Alignment Chasm

Transcript of a sponsored BriefingsDirect podcast on the role, qualifications, and career paths of enterprise architects. Recorded at The Open Group's 23rd Enterprise Architecture Practitioners Conference and 3rd Security Practitioners Conference in Toronto.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: The Open Group.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect.

Today, we present a sponsored podcast discussion coming to you from The Open Group's 23rdEnterprise Architecture Practitioners Conference in Toronto. [See a related discussion on the effect of cloud computing on the architect role.]

Our topic surrounds 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.

So who takes on the mantle of grand overseer as IT expand 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 all of that, we're joined by our distinguished panel. Please join me in welcoming James de Raeve, vice president of certification at The Open Group.

James de Raeve: Hi.

Gardner: We're also joined by Len Fehskens, vice president, Skills and Capabilities at The Open Group. And, David Foote, CEO and co-founder, as well as chief research officer, at Foote Partners. Welcome.

Foote: Thank you.

Gardner: And Jason Uppal, chief architect at QRS.

Jason Uppal: Thank you.

Gardner: Well, let's look first at this whole issue of the down economy in the changing environment. Let me take that first to you, David. What is afoot, if you will, in the field? Why so much change all of a sudden?

Always in flux

Foote: We're always in flux. There's no doubt about it. There's no doubt about the fact that, when money is scarce, people get scared.

You have a lot of very frightened IT departments out there and a lot of frightened business lines with customers bailing out right and left. Everybody is just focused on the moment, thinking reflexively on how do we possibly save money. How do we renegotiate our vendor contracts in IT? How do we not lose customers? This is probably the thing I hear about the most.

IT does not want to be in a position of being responsible for the loss of market share in any way, because the business loves to blame IT, as you know, for a lot of things -- most recently, challenges to market share and revenues.

But, it's the greatest time possible to be talking about things like enterprise architecture (EA) and transformation, because transformation tends to happen in times like this. It tends not to happen in times of prosperity.

As I've been telling everybody, this is the greatest opportunity you'll have personally in your career, if you're a manager in the management ranks, and especially as an executive, to start raising issues that you were afraid to ask for. These are those plans that were shelved at times when you were making so much money that nobody was listening to your conversation. Right now is a tremendous opportunity. I want to be very positive about that, because you'll probably hear about some negatives today too.

Gardner: Let's go to James. Why are these forces around us forcing the change on the definition of the enterprise architect?

De Raeve: There's been a realization, hopefully a growing realization, that the term enterprisearchitect means something different to everybody who uses it. 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.

Gardner: Moving from a mismatch of definitions and application of EA, to a more standardized approach or perhaps more fragmentation?

De Raeve: I think there is increasing convergence. There is increasing realization that there is a need for a common understanding. I wouldn't say a standardized approach, because you don't have standardized problems and people aren't standardized, but there is a growing realization of the need for common core skills and competencies.

What the members wanted

We develop certification programs, but the reason we do it and the reason we have one in the architecture space is because that's what our members wanted us to do. They want us to do things for good, commercial, self-centered reasons. As organizations, they need this kind of concentration and increased commonality of understanding of skills and competencies.

Gardner: Well, if we're not moving towards a standardized definition, perhaps we're moving to a more strategic role for the architects. Is that fair?

Fehskens: That's always been the case. In many respects, strategy is sort of the lastfrontier. 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.

There are still organizations where the primary role of an enterprise architect is, in fact, to rationalize the infrastructure. On the other hand, we're starting to see lots more places where they're playing a major role in strategy development.

Gardner: As we move up the abstraction, based perhaps on the maturity of the technology and its importance and its role in the larger enterprise, do we see a stratification of sorts among the architects? If so, how do we rise up this pyramid to more of an über-architect, if that makes sense?

Fehskens: There is some stratification. Again, the people working at the highest levels are not going to be making decisions at the lowest levels, they have to pass those decisions down the chain. They may get passed down and passed down. So, just as we talk about a layered architecture, there is a layer of architecture of enterprise-wide responsibility at those various levels in the overall stack.

This gets into a lot of interesting questions about governance, as a result of this. The ideas of architecture purveyed organizational structures from the bottom to the top. Issues of governance are going to become increasingly critical. You talk about the change in the skill profile. A couple of years ago, governance was something that an architect could get by just knowing about.

Now, an architect has to have full-blown competence in the governance area -- how to turn it into decision-making and implementations that conform to the architecture, both across the enterprise and then vertically through this structure of architectures that go down from the strategy level.

Gardner: Jason, one of the least comfortable positions is to be responsible for something, but without authority. How is the role of the architect from your position as a practitioner reaching up this stratification towards a higher level of strategic overview, but gaining authority at a commensurate rate?

Protecting their turf

Uppal: Several things have happened. Especially in the economic downturn, there are a lot ofpeople who are very sensitive and are afraid about their positions and the power that they have accumulated. Or, it's just the normal nature of protecting their own turf.

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

Another layer that I saw come into architect skills in last 6-12 months is how you 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 as you're going up -- considering everything else, but having this soul who would be sensitive to the other professions that are going along.

Gardner: Is it fair to say that the skill set of an architect, at perhaps a solution level or a technology level, is quite different from the skill set at that higher strategic level you mentioned, a priest-like bearing? How do you transition when the skill sets are different?

Uppal: Well, you need those skills at lower level. Those are just part of the game. They are no longer sufficient for you to do your job. Now, you have to have all of those skills, plus on top of it, you have to have more, and that's where it's more of a challenge for the architect, as we're going up. We're being accepted when we go up, but if we don't succeed there, being insensitive to all those other issues around, we will be sent back very quickly.

Gardner: David, what are you finding in your practice in terms of how people are grasping and grappling with the transition from a high level of technical skills to this more collaborative people type of skill set?

Foote: As I was talking about yesterday, I see so many parallels between the maturation of the CIO job with what's happening in EA.

Basically, true EA is a collaboration between the company's executives and everyone who works for them -- and they pay your salaries. They tell you when you are an enterprise architect. You don't tell them. They will tell you. They will put their arm around you and say, "You are one of us."

You're one of us

At the same time, you want the IT organization having their arms around you, saying, "You're one of us." The moment they tell you you're an architect is when you are an architect. At the moment, what Jason has said is really true.

In the total group of enterprise architects I've met, to a T, 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 or über already.

You have to be über level to be an enterprise architect at this stage in the game, because there really isn't a good role description. The model would be what's happened with project managers. At some point, IT was trying to just teach them so much about project management, how good it was for the organization, much like architecture.

But, at one point the CFO learned that project management can really help me to integrate companies that we're acquiring and merging with. The moment the business discovered it, it was no longer an IT sort of discipline. It was a business corporate competency.

I would love to see that happen to architecture, to be just a natural corporate competency, so that IT could just give it away.

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.

The greatest thing in the world is when you just give something away that you introduced and the business adopts it as if you never even gave it to them or you never really were at conferences like this. Where are the business people at this conference? Well, maybe five years from now they will be here -- the MBAs are whom I'm talking about.

Fehskens: Dana, if I might elaborate on something David said. I had a real "aha" moment. Before I came to The Open Group, I was the worldwide profession lead for the architecture profession at HP Services. 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.

Gardner: I've heard IBM, in several instances, refer to the architect as having to be a team person and to have deep technical understanding and then horizontal understanding of the business. I want to put another axis on there for those people skills, and to be sensitive and effective in communication. These are very challenging roles, but if you can fill them, you might have yourself one fine career.

James, how do you position yourself to get into this? What's required, and what's the stepping-stone pattern in order to achieve this very fine challenging and well-paid position?

Community crying out

De Raeve: 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.

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.

I've come away with the firm conclusion that we're way too soon in that process. They don't yet have methods of developing, growing, retaining, and managing their people and organizing them as professionals. They've got job definitions and all kinds of stuff from HR, but nothing that actually enables them to develop their architecture practice.

I go along with the idea of, "Well, here are all these criteria that a good competent architect should have, all these things about communication skills and architecture skills and technical knowledge, this whole panoply of stuff, and all of the experience." They say, "That's great -- if I knew whether we had anyone like that, or if I knew how to develop people like that, but we haven't got all of the rest of it."

My analogy is that we've got these certification things there, the cherry on the icing on a cake, but we don't have the icing and we don't have the cake. We need the professional frameworks that help organizations attract, develop, grow, and build these people into professionals. I think it's a gap.

Gardner: Len, you had something?

Fehskens: Yeah. I think one of the real challenges for an individual who aspires to be an architect is to get past the first hurdle, which is, you're usually not allowed to be an architect until you already are one.

Often, one of the ways you can get your foot into the architecture space is by taking on the responsibilities of program manager and acting like a program manager.

In my experience, all the people who started in this profession started acting as architects before somebody was willing to call them one, and that requires networking with architects who are willing to spend some time mentoring you and stepping into the architect role in complex projects.

In the architecture group at Digital -- Digital got acquired by Compaq, which got acquired by HP -- 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.

There's a lot of symmetry between the program manger role and the architect role. Often, one of the ways you can get your foot into the architecture space is by taking on the responsibilities of program manager and acting like a program manager. Then, pushing that into the technical domain and starting to act like an architect.

When you start acting like an architect, as Dave pointed out, you're not really one until they tell you you are. But, you have to look like one before they will tell you you are one. The best way to do that is start behaving like one, and best way to do that is to learn by experience. You just put your foot in the water and go for it. As Nike says, "Just do it."

Gardner: So Jason, if this is an experience-based rather than a certification or rigorous predefined process towards architecture position, what is it that you've done in this experience side that allowed you to actually get in and convince people to give you the authority? How do you manage that transition?

Managing the transition

Uppal: That's an interesting question, and Len left it wide open for me to respond. Before Len called me an architect, about four-and-a-half years ago, I was an engineer for the longest time, and I worked as an engineer. That's your job. Nobody told you you were an architect or project manager. That was your degree and that was your title and that's what you did.

But, somewhere along the line, somebody came around and said, "Here are the performance criteria. If you pass all of these things, and we agree that you pass all these things, we'll call you an architect." That's what happened, Len called me an architect, and I became an architect that day.

Going back to "developing the skills" conversation -- how you got here -- if we step outside of the IT industry, you'll see a lot of parallels of other professionals being developed in the industry, very similarly to how we develop architects. Architect is not this nebulous thing that just grows. They are developed.

I remember when I first started working as an engineer. I worked for a French tire company.

All of that stuff that they taught you -- respect for the person who is doing the work -- still applies today as it did before.

We won't name any names, but one of the biggest challenge that they had is that it was a dirty job. Nobody wanted it. So they'd go to universities looking for engineers, bring them into the company, and teach them how to do the job. They would stay there six months and they would leave. That was not necessarily a good attrition. They had close to 100 percent attrition of the newly hired engineers.

Then, they looked at the skills of the people that they were trying to develop and they said, "We need to have people who understand our culture, our product, and our people. Then, we just need to give them some technical skills on how to do analysis."

That was an easy thing to do. So, we created an apprenticeship program. Since then, that organization has developed hundreds and thousands of industrial engineers who are continuous improvement engineers who know how to do things. I came out of that process and became an industrial engineer. From that I became an architect, because I had an affinity for applying information technology.

All of that stuff that they taught you -- respect for the person who is doing the work -- still applies today as it did before. That's one of the areas where, 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. 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.

Gardner: David Foote, we could leave this to an organic process -- willy-nilly and ill defined -- or, to Jason's point, we could follow the lead of other career tracks. In other career tracks, it's not just the people that fill the positions who are involved. We have human resources (HR) departments, recruiters, and headhunters. In fact, you might have an entire industry setup in order to find, cultivate, and place people in these jobs. Why haven't we seen that with the enterprise architect?

Lack of understanding

Foote: Again, people really don't know who enterprise architects are. As much as you try, try, and try, you haven't reached the critical mass where the average HR department person, at least that we talk to -- and we talk to thousands of them -- really understand what they are.

What they think architects are is a title that all people in IT want to have, so they will get a better job offer. They know that architect is a hot, hot item. Just Google it, or go to anyMonster site or Dice or any of those. They make a lot of money. So what's happened is, 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.

The worst thing that you ever want to have happen to you in HR is the CIO to say, "Okay, we now have a solution architect in this area, whether we had one or not, we have one now. So, go and figure it out." That lack of control in HR is commonplace today. I tell HR organizations that if that's the question they have, send the best people.

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. Then, a compensation person tries to figure out what to pay that person.

That's when they come to Foote partners, saying, "We don't know what to do?" What do we pay this person?" Call them whatever you want, but I can tell you what that solution architect should be making in your town.

You're probably going to be continuing to hire in this area. It might be a good time to just establish this as a job family, and then make sure that this doesn't happen again.

But, this is a workaround solution. Eventually, you're going to have to actually ordain this job, if you think you're going to have several of these in your company, I said, probably you will have. Let me talk to your IT department. If I talk to them I'll say, "You're probably going to be continuing to hire in this area. It might be a good time to just establish this as a job family, and then make sure that this doesn't happen again."

Mainly the lack of control is around job descriptions. Compensation is more egregious in architecture right now than it is in developers, database people, security people, and even voice engineers. They know what a voice engineer is more comfortably than an architect. So, it's just this natural progression.

But the last thing I want to say is, people still don't know what CIOs are. CIOs make anywhere from $25 million a year to $80,000, in our salary surveys. What a crazy job title. Yet, we've been able to exist very well with CIOs for any number of years.

Gardner: I was going to say, James de Raeve, this sounds a lot like what I heard in the CIO category ten years ago, where it was amorphous, and the skill and compensation scales were all over the map. But, over time, what became sort of a hot potato ended up being a very important role that most organizations seem to understand. Should we expect a similar track?

Early stage of maturity

De Raeve: Oh, absolutely. We're at an early stage in the maturity of this concept in the profession or in the industry. One of the roles of organizations, such as this, this community of people, is to try and help us evolve that, to get an understanding of what we mean by it and an understanding of how organizations should address this problem and develop their people. I think it's inevitable. We've got a long way to go. Maturity is needed, and we're in the very early days.

Gardner: Well, does it make sense then to look at the CIO role and say, "Here is what an architect is vis-à-vis it or in contrast to it. Is there a relationship that would help in this maturity process?

De Raeve: I'm not so sure that CIO is the right model. Maybe CTO would be a better match. But as the profession matures, we're also seeing enterprise architects become less technically focused and, as we talked about earlier, more strategically focused and more concerned about the business and less about the technology.

So, there is something to be learned by looking at how those professions developed, but I don't think the specific details of how they sorted themselves out apply directly to enterprise architects, because I think it's enough of a different role.

We used to joke that the best architects have their feet on the ground and their head in clouds,

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.

and they span this gap from the business side to the implementation side, regardless of what the implementation technology is, not necessarily just IT. It's that extremely broad coverage that makes it really difficult to pin this discipline down and say it's just this.

I've often told people that I've tried unsuccessfully many, many times to tell my family what it is I do for a living. After a couple of sentences, their eyes just glaze over and they say, "Well, you drive a nice car. So, you must be successful." We've got that problem in general, as David pointed out. HR can't get their arms around it, because it's such a vaguely defined thing.

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."

Gardner: What strikes me that, if the role of the architect is so different from organization to organization that the org chart within those organizations is also very different, and we might have the architect reporting to different types of individuals from enterprise to enterprise. So Jason, among the architects that you know, is there a great variability in who they report to, or am I reading this wrong?

Based on behavior

Uppal: Who architects report to depends on how they behave. There are a lot of architects who behave like technocrats who report to the CTO. There are other architects who operate at a different level and they start reporting to the CIO, the CFO and even to the COO level. I know one very successful architect, he reports to the CEO, along with the CIO.

It's more how that group behaves, and also their EA practices maturity within the organization dictates how they behave and whom they report to. It has a lot to do with the maturity of the practice. In some of these organizations, the maturity of the practice depends on the maturity of the individuals. A couple of them are leading it, because as soon as you take them out of this thing, the whole thing is going to fall apart, because there is no talent in the organization to repeat it.

Foote: Let me add one thing to that. One of the things that we're not looking at is, there are a handful of industries -- it's becoming a much larger group now -- where the CIO and the COO are the same job. You see this in banking, financial services, and insurance. You're seeing it in healthcare. You're seeing it in education, in particular. Now, you're seeing it in retail and all these other places.

Those organizations, where the CIO and the COO are basically the same person, are the ones where you really see these hybrid enterprise architects that really are business/IT. When you meet them, you can't really tell.

A couple of them are leading it, because as soon as you take them out of this thing, the whole thing is going to fall apart.

A lot of it has to do with whether you are working in a company that has this hybrid, where the operations are under the control of a CIO, whether they have that title or not. Usually, they are vice chair, or they just call them an executive vice president or a senior vice president, as we've seen it in the United States. Usually, CIO is not the title unless they're speaking at a conference, but CIOs are separate. It's really important to understand, again, what kind of organization model you have and who is at the top?

Gardner: So, if we have a hard time standardizing the job of architect, perhaps we need to start at some standardization around the organization and the org chart. Is there an accepted methodological approach to setting up the IT department in the context of the business requirements, goals, and so forth, or are we still just sort of thrashing around in a storm, hoping to grab onto some life raft?

Anybody want to take that question? How do we mature the organization, not just necessarily the architect?

Fehskens: First, I'm not sure that standardization equates to maturity, but, again, it's this question about adaptability. My experience is that most organizational structures, at least with respect to who is in what job, have a lot more to do with politics and social chemistry than explicit engineering-driven design.

Gardner: But, aren't these really too important subjects to leave to the vagaries of personalities and popularity contests?

Ability to get along

Fehskens: You'd think so, but the reality is that if you have a perfectly rationally structured organization, and the people that you put into these roles are perfect for those particular roles, but they hate one another, it's not going to work. A feature of a successful architect is the ability to get along with everybody, including people that we would call uncharitable names, and just find some way to work successfully with them.

My attitude about architecture is pretty much that most of the stuff you have to deal with, you have no control over. So, you just have to accept it and figure out how to deal with it and cope with it. You pick your battles wisely and don't waste time trying to change things that you can't change. My experience has been that an awful lot of organizational structures are pretty much cast in concrete, and changing them to be optimal is very, very difficult. So, you just have to figure out how to cope.

Foote: The most frequent question we get right now from companies that have fairly advanced EA groups, is, "Where do I promote these people to?" In other words, they usually don't want to be in management, because they are too hands-on. Their next shot is really to be a director-level manager.

We've been coming up lately with a lot of interesting cases for where they go. They have a great organization, but they never planned for these architect/analyst types, and these are companies where the architects are really doing long-range planning. They're doing a five-year plan, and, usually, we a lot of Silicon Valley, Calif. technology companies is where we find these people.

Gosh, as the challenges of the environment are just going up and up and up, the organizations rely on their architects to be sufficiently flexible to be able to change shape, to adapt, and to adjust.

They're out there doing the strategic planning. The CIO is head of strategic planning in these companies. Maybe not in your company, but they don't know what to do. We just say, "Well, you create a distinguished engineer title or a distinguished architect title, and put them on the road. They should be evangelizing. They should be helping you build market share, not just the strategic plan. Put them out as marketers for the company, and they will probably do very well."

Gardner: How about putting this in the context of some of the other impacting trends in the industry -- ITIL, for example? Changing the character of the IT department from a cost center to a productivity center, a shared-service provider, a partnership in the organization, rather than some ivory tower or dark arts center. Doesn't that provide a springboard for the role of architect, and wouldn't that perhaps lead to maturity more than we've seen in the past? James.

De Raeve: Gosh, as the challenges of the environment are just going up and up and up, the organizations rely on their architects to be sufficiently flexible to be able to change shape, to adapt, and to adjust. So, yeah, I that's the driver, absolutely.

Gardner: External forces like ITIL and shared service, Len, are these going to add to more complexity and more chaos, or is it going to be more of a focusing impact?

Just do it

Fehskens: I tend to think it's the latter. Those kinds of things are a special case of commoditization, which is that after something is well enough understood that there really are, if not just one, at least a very small number of sensible ways to do it, you don't have to spend a whole lot of time thinking about it anymore, you just do it the right way.

We don't spend a whole lot of time each morning trying to figure out how to get dressed. You put your underwear on first, hopefully. Doing it any other way doesn't work. We've gradually learned those things about various aspects of the IT organization and of the organization as a whole.

So there's a whole lot of stuff that gets standardized, because it's appropriate to standardize it, because there's really no value in gratuitous variability anymore. It just makes sense to do it, get it over with, and do it the most efficient way possible. That stuff all generally becomes candidates for outsourcing.

The really interesting question becomes, what do you keep? Where is the stuff where that variability, that customization really makes sense in delivering strategic value to your organization?

One of the things that scares me sometimes about standardization is that premature standardization can be a real catastrophe.

Knowing what stuff you can safely commoditize and ultimately outsource, and what stuff you need to keep close to the vest is a really important decision that companies have to sort out. I think it will vary from industry to industry, and people just have to make smart decisions about that set.

One of the things that scares me sometimes about standardization is that premature standardization can be a real catastrophe, where you make things the same that really can't afford to be the same yet, because that's an opportunity for competitive differentiation. Every time you take away one of those opportunities, you close down your opportunities and the space that you have to move in and you limit your options. So, you have to be very smart about that stuff.

Gardner: We have a question from our audience, and it revolves around the outsourcing word that you brought up, Len. Isn't this all similar to the old role of management consultant? It begs further question of, is this something that, perhaps in a transitionary period like we're in, is best done from the outside?

Jason, what do you think? Is the role of architect something you should outsource, at least for a period of time?

The role of outsourcing

Uppal: That's an excellent question. There are a number of organization that I'm aware of that have actually flirted with the whole idea, because they are fairly good at ITIL and they are fairly good at COBIT, PMI, and all that stuff. At the same time, when they tackle a very fundamental issue for the organization, how to reengineer their entire business process, they don't have anybody in the organization who can step up to the plate and do it.

They have a hell of a time running a million dollar project, let alone running 10, 20, 50 million dollar thing. At that point, they started thinking that perhaps they should outsource this thing and bring somebody else from outside.

Then, they have another dilemma and say, "We decided fundamentally architecture is our internal competency and we have to have somebody internally." Then, they stick in this guy who has no idea about what to do with this thing, and the next thing is the whole thing falls apart. Then, they say, "Well, we did the architecture thing, and it doesn't work.

One of the things that we found is that a number of architectural activities that they thought they were uniquely theirs, are commodity.

Some of the organizations are going to do that first part, bring somebody from outside for a short period and get them started to understand the value of it and also understand what is it going to take for them to institutionalize that practice. Then, they'll take the next step, building their own capacity and capability, only to the point that they need to build.

One of the things that we found is that a number of architectural activities that they thought they were uniquely theirs, are commodity. They didn't have to have them. If you're implementing SAPor Oracle, do you really need to own a SAP solution architect in-house? How many times are you going to implement SAP in house? That's a commodity that exists out in the marketplace.

Those are the kind of things that organizations have dealt with. Bringing somebody from outside for a short time is critical, but also understand that it's a short time. Don't turn that consultant into your staff over the next two years. Then, you're just paying a lot of money for this person who should be an employee. That consultant becomes very useless in about two years, because he knows nothing other than your organization.

Gardner: David Foote, what's your position on this insource, outsource, or hybrid approach?

Foote: There are definitely some activities in architecture that you can't outsource. I wouldn't say that you can't outsource it, but 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?"

Keeping core competency in house

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.

By the way, one of the things that we talked about when populating the panel is that I said I had an interesting experience at a conference, where they had a headhunter on that did chief security officers. But, 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.

One of the big differences between management consultant and enterprise architects is that what you put on the table, you have to execute.

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.

Gardner: To the point of the question here, that does sound a lot like management consultant. James or Len, what's your position on that?

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.

Look to the boutiques

Foote: But they are buying people with consulting talent -- management consultants, because they have consultative talent. When I said bring somebody from Accenture or IBM, I didn't mean from those companies, but rather formerly of those companies, consultants who now are on their own in boutiques.

If you want to look at how to grow a lot of the stuff -- not just architecture, but a lot of areas that are having trouble with definition -- it's the boutiques. They are excellent. Some of these people who used to work with these companies were constrained by the frameworks and programs they had to work with and they went out and created it as it should be.

If you're lucky enough to find one of these and they're not research constrained -- because everybody else wants to have them come in and help them -- you've done a good thing. Always look for the smaller firms, if you're going to bring in any consultants.

Gardner: James, for those folks who have been listening and think they've got the right stuff, where do they go to help convince the rest of the world they have the right stuff? Where do you get started on this beyond some of the traditional and organic approaches we've heard?

De Raeve: This was the very problem that we were given when developing our certification.

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.

programs. How do we determine whether someone with a business card or a title that's got architect in it actually is an architect? What do we mean by that? How do we manage and control that?

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. What those programs do and the real value of those programs is twofold.

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.

Seeing results

Then, there is the certification piece, which allows individuals to be recognized for having met those criteria at different levels. We're trying our best to and introduce the idea of certification for architects into recruitment or procurement, and we're having some results. That's an ongoing piece of work, as we're fairly new in this certification. This professional level is pretty new.

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.

Gardner: David Foote, these certification programs aren't the same as a vendor or supplier type of highly focused technical certifications. This is something quite different.

Foote: Yeah, it is. The certification industry has been on a decline lately. The reason why is that certification, for the most part, was an industry created by vendors who wanted to sell and resell their products. In that sense, the certification group is always in the marketing department of any company. Name one vendor, and I don't know any certification group that is not in the sales and marketing departments.

Then there came this whole group of vendor independent certifiers of talent, like in project management and architecture. These are extremely important. These are probably the survivors. Microsoft's certified architect program showed up very high in a recent survey of ours, and we put it on our hot list. I felt bad about that, because The Open Group also has excellent architecture certifications.

The reason a vendor can show up and create a lot of buzz around their products is because they have an enormous amount of money to sell their programs to their vendors. Microsoft evangelizes their products through all of their certification programs. This isn't to say that it's not good to have a certification, but the foundation is to evangelize the Microsoft point of view, and they're very successful at that.

The independents, if they're in competition with a vendor, won't be able to have the resources to get to market, to get the word out. On the other hand, they can create exceptional education and training programs. In architecture, though, if you create a program that caters too much to IT at the exclusion of business, and you are selling EA certification, you're not going to develop the profession.

Three people came up to me at this conference yesterday and today. They were enterprise architects who said, "Should I get an MBA?" Great question. How many of you have MBAs in the room? You're well positioned for the future of EA. You need to be able, if anything, to speak the language of business and make them feel comfortable about you.

But, in general, I'm very bullish on vendor-independent certifications, because you guys have to work so much harder. I have so much respect for The Open Group, and it's where I send anybody who talks to me about educating, training, or wanting to learn more about the profession.

I don't think there is anybody else really to go to, unless they're a Microsoft shop, and they've got a ton of Microsoft stuff. Then, I would say they might want to consider them too. I'm sure it's an excellent certification, but The Open Group has a great opportunity, and as long as they can expand, these MBAs.

Gardner: Well, thanks. I'm afraid we're about out of time. I want very much to thank our panel. We've been joined by James de Raeve, vice president of certification for The Open Group. Len Fehskens, vice president for Skills and Capabilities at The Open Group. David Foote, CEO, co-founder and chief research officer at Foote Partners. And, Jason Uppal, chief architect at QRS. Thank you to everyone.

This is Dana Gardner, principal analyst at Interarbor Solutions. We're coming to you from The Open Group's 23rd Enterprise Architecture Practitioners Conference in Toronto, the week of July 20, 2009. Thanks for listening, and come back next time.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: The Open Group.

Transcript of a BriefingsDirect sponsored podcast on the role, qualifications, and career paths of enterprise architects. Recorded live at The Open Group's 23rd Enterprise Architecture Practitioners Conference and 3rd Security Practitioners Comference in Toronto. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.