Q&A: Randy Hite on the new GAO EA maturity framework

When the Government Accountability Office released August 5 a major revision to its framework for assessing the maturity of agency enterprise architectures, it was the first change to the framework since 2003. Three years in the making, the new framework could also be the EA swan song of the person whose signature is on the preface, Randy Hite, GAO director for information technology architecture and systems issues.

Hite recently talked with FierceGovernmentIT about the framework, about how enterprise architecture has evolved in recent years and the need for a new round of agency EA implementation evaluations. But, much as a new round of evaluations may be needed, Hite said he won't be able to lead it himself--he leaves government service this December after 33 years.

FGIT: So, why a new enterprise architecture maturity framework now and so long after the last update?

HITE: Frankly, it's late in coming. It's overdue. It's needed, so better late than never. The original one served a purpose, it had been overcome by events. The EA discipline has evolved, the manner in which EA, from a practical standpoint, is being implement has evolved.

And, we've learned a lot from looking at EA across the government, we've learned a lot from interacting with the private sector on the subject, so there was more information and knowledge and context to be brought to this whole question of "How do you manage such a complex endeavor?"

I've been wanting to do this literally for three years now, and because the vast majority of the work we do, and in my case, 100 percent of it, is requested by Congress, this is something I was just able to do in my spare time with others, with their spare time in getting it done. It took longer than we would have liked, but I think it's well worth the wait. I'm really happy with how it turned out.

FGIT: How would you contrast EA as it's practiced today as opposed to in 2003, when the last framework was released?

HITE: Back in the early days of EA, it was sometimes viewed as an all or nothing proposition--a boil the ocean kind of endeavor. You needed to have an enterprisewide, top to bottom, A to Z, fully fleshed out architecture before you could do anything.

In reality, it's not done that way. It's really done on an incremental basis, within the context of establishing some thin layer of policies, principals, standards for your entire enterprise. You can then architecture slivers of your organization in more detail and provide the specifics necessary to drive specific programs implementation and  systems implementation.

One of the major changes in this framework is that it recognizes that fact. You don't have to have a 100 percent complete architecture in order to implement and derive the benefits from architecture.

FGIT: How's that reflected in the new framework?

HITE: The way the stages were constructed in the past was really directed toward developing the entire architecture, implementing the entire architecture. Now there's provision in the framework for getting an initial version of the architecture, and building out parts of the architecutre and targeting parts of your organization for transformation and modernization. There's stages that recognize that, as well the continuous evolution and improvement of it.

Another thing that this version does that the other one didn't do--this is something we learned from applying the framework--is that consistently across government agencies, there were several major obstacles to making architecture a reality. Those dealt with basically a resistance to change, parochialism, lack of understanding in senior executivs in the organization about what architecture is, and a lack of resources and people with the knowledge and skills to develop and implement architecture.

And so, one of the things this version does is recognize right up front in the initial stage, past the stage of becoming just aware of what an architecture is, is that crating institutional commitment to architecture really provides the foundation for making architecture successful. The basic premise is that if your organizational leadership doesn't recognize the value and its role in making architecture a reality, then you're in for an uphill battle. We saw instances in looking at architecture across the government where program offices trying to get this done were literally the tail trying to wag the dog. They just weren't in a position to make it happen. For architecture to work, ownership has to be vested in the leadership of the organization. They have to own it, and they have to be behind it.

FGIT: EA's reputation often precedes itself as difficult to understand and even as just a bureaucratic device.

HITE: I would agree that there's probably that perception out there. What do people as a rule gravitate to? They gravitate and embrace things they understand. That's kind of the irony of the whole thing, because architecture is designed to simplify and streamline what the organization does, and how it does it, where it does it, why it does it.

On the one hand, it's viewed as a bureaucratic check-the-list, must-do-this kind of thing that really provides no decision making value to senior executives. But, in reality, it's intended to provide just that decision-making value. That's the great irony here - the purpose of the architecture is to help the organization have a better understanding of how it operates so that it can react to changes in its environment quickly, so that it can identify opportunities to consolidate and cut costs and improve efficiencies, improve mission performance and better share information.

I think I was asked one time "Where do you see enterprise architecture 25 years from now?" Frankly, I see it as a tool that sits in the boardroom. And, that when a board of directors is trying to make decisions about the strategic direction of the organization, directors consult the enterprise architecture with "what if" kind of questions to understand how would it impact the organization, and what would have to be done to make a strategic shift?

FGIT: In terms of getting from here to there, though, isn't there that constant problem that taking time to understand how a program is best optimized by fitting into EA helps the enterprise, but there's nothing in it for a program in the short run?

HITE: If you view programs as independent, isolated, individual endeavors, yes, there's nothing in it for that one program.

FGIT: Isn't that pretty much how they're funded and managed?

HITE: Not really, no. I think they are managed--and it's not consistent across all organizations--as an inter-related set of investments. There's a recognition that no program, no system, is an island.

FGIT: There's a GAO report that's barely a few months old, if that, that talks about how FAA doesn't have management tools to manage its NextGen portfolio in a multi-program manner.

HITE: There may be an absence of the tools they need to make that happen. That doesn't mean that there wouldn't be a recognition that there are those interdependencies and relationships. One of the tools to make that happen would be the architecture.

If a program is being defined and designed within the constructs of an architecture, there would be ample opportunity to identity where other services or applications already exist within the organization that will fulfill the need of my program. To the extent that I don't have to develop that myself within my own program, and I can access that service that already exists, I've got an opportunity to save money on my program, and to invest those funds in maybe expanding the kind of functionality that my program can deliver. Or, frankly, just saving money as a cost-cutting measure.

A lot of this is going to be driven by what you're responsible for and accountable for and judged on. If I'm a program, and get I rewarded and evaluated on the basis of the extent to which I act in a manner that is in the best interests of my enterprise as a whole, then I don't pursue [other efforts]. You've got to hold program managers accountable for marching in step with the architecture context of that organization.

FGIT: The new framework now has more gradations--59 core elements now?

HITE: Fifty-nine core elements now, 31 before. The comments that we received from departments on agencies on the prior version was that they were looking for more granularity and specificity in the core elements, to help them implement it.

We're always trying to strike this balance between providing the principles we wanted to have implemented, and not being prescriptive in terms of how that gets done. For example, in the prior framework, we had the need for an architecture framework, an architecture repository tool and a development methodology all rolled into the same core element. In this one, it breaks them out separately.

The reason we did that is because rarely did any organization have all three, but they may have had one of those. We wanted to break them out separately to provide emphasis and attention to all three and to spend more time explaining what we want by all three, because there was some confusion. For example, what's an architecture methodology? Agencies we would go to would describe their framework as being a methodology. They're two completely different things, so we wanted to clarify that.

Some of the other things that account for the increase in core elements is that this version recognizes the concept of architecture federation and segmentation, service orientation, and having an extended architecture across organizations. There are more processes, procedures, structured that we wanted to have in place to cover those kinds of things. Now it deals not only with the corporate architecture that the prior version dealt with--the end all, the be all, the boil the ocean type, one-of-a-kind monolithic architecture. This version recognizes that there is a hierarchy of architectures that make up the family of architectures in an organization, whether you do it on a segmented or a federated basis.

FGIT: Is ITIL influencing enterprise architecture much?

HITE: Frankly, I haven't done current work in the last three to four years on what agencies are doing, architecturally. The last time we've really looked at architecture across the government was probably about five years ago.

FGIT: Any plans for a new evaluation?

HITE: I really think there should be one. We don't have anything planned, and as I said, 100 percent of my work is congressionally requested. We don't have an outstanding request to look at this across the government. I think it should be done. Whether or not we do get a request, or whether or not GAO itself will launch something, is going to be out of my hands. I'm retiring this year. I'll have over 33 years of service, in December.

FGIT: You mentioned that one of the important parts of getting an EA operational is getting executive support. But that's been said, far as I can tell, forever as long as there's been such a thing as EA.

HITE: I have a couple thoughts on that.

In the federal government, for the most part, senior leaders are only here for a short stay. They're looking to make something happen in the near term. Architecture is a strategic asset. The return on investment in architecture is not going to be so much this year or next year, it's going to be downstream. It's a long term investment. And I would dare say that individuals that are coming into the government in leadership positions are looking to demonstrate an impact right away. They don't tend to be here for the long term.

The other thing I would suggest is a lack of understanding and awareness--education around what EA is and what it can do for you.

FGIT: Architects hardly help in this matter--there's a lot of very specialized jargon that goes along with EA.

HITE: I got to believe that there is a translation that goes on between the CIO and those leaders to remove the jargon from it and to put it in concrete business terms. One of the things we did in this framework--we not only talked about the fact that in stage one you have to have a committee made up of the business leaders of the organization and the CXOs of the organization that are the vested owners of the architecture, but that these people actually need to have been given some type of understanding of the principles and concepts associated with architecture. So that they don't come into it with a gross unawareness of what architecture is, what it can do for you. We emphasize that's something that needs to be done. In the absence of that, you do run the risk of someone in the discipline making their eyes glaze over with the kind of terminology that they've been suing to describe things.

I also believe--it's something I've never said before--that when organizations develop their enterprise architectures--and this is something John Zachman always talked about--there are differing views of the organization that one can have, depending on where you sit in the organization. I've always felt that there needs to be the most senior executive view of the architecture. If an architecture is a document, and that document is literally a thousand pages, there needs to be the executive summary, so the senior executives have a better understanding of what it is and how it represents the organization.

When Charles Rossotti was at the IRS, and they first went through putting their enterprise architecture together, he did that. Not only for himself, although he literally read the thousand pages, but for his executive team. He also wanted that to help him for those outside of the organization that were in oversight roles.

FGIT: As far as short term senior leaders, isn't that a permanent, systematic thing?

HITE: Yeah, that's a reality. What can be done? That's a tough one, I don't know what the answer to that one is. There's probably just as many cases where that's not true, that you have very experienced business leaders coming into senior positions in the government, and they realize that there's things we want to do to position this organization for long term transformation, and there those things we want to do in order to provide near term benefits and gains. I've never really queried the most senior people in government to ask them, ‘Do you understand, do you endorse it, if not, why?'

That probably would be a valuable thing to do.