The Business of Government Hour


About the show

The Business of Government Hour features a conversation about management with a government executive who is changing the way government does business. The executives discuss their careers and the management challenges facing their organizations. Past government executives include Administrators, Chief Financial Officers, Chief Information Officers, Chief Operating Officers, Commissioners, Controllers, Directors, and Undersecretaries.

The interviews

Join the IBM Center for a weekly conversation about management with a government executive who is changing the way government does business.

Mark Kneidinger interview

Friday, June 4th, 2004 - 20:00
Mark Kneidinger
Radio show date: 
Sat, 06/05/2004
Intro text: 
Managing for Performance and Results...

Managing for Performance and Results

Complete transcript: 

Friday, May 7, 2004

Arlington, Virginia

Mr. Lawrence: Good morning, and welcome to The Business of Government Hour. I'm Paul Lawrence, partner in charge of the IBM Center for The Business of Government. We created The Center in 1998 to encourage discussion and research into new approaches to improving government effectiveness. You can find out more about The Center by visiting us on the web at

The Business of Government Hour features a conversation about management with a government executive who is changing the way government does business. Our conversation this morning is with Mark Kneidinger, the Deputy Assistant Administrator for Management at the U.S. Agency for International Development.

Good morning, Mark.

Mr. Kneidinger: Good morning.

Mr. Lawrence: And joining us in our conversation from IBM is Kim Hintzman.

Good morning, Kim.

Ms. Hintzman: Good morning.

Mr. Lawrence: Mark, let's start by finding out by USAID. Could you describe its mission for our listeners?

Mr. Kneidinger: USAID actually provides a very unique set of services throughout the world ranging from providing education programs, agriculture; also to the point of supporting reconstruction within, like, Iraq and Afghanistan; dealing with the HIV-AIDS epidemic throughout the world. And it's an opportunity in regards to being able to have the United States presence to be able to support critical democratic growth within underdeveloped countries.

Mr. Lawrence: And what's the mission of the Management Bureau and how does it support the mission?

Mr. Kneidinger: The mission of the Management Bureau is actually multifaceted. As a bureau within the Agency itself, it's responsible for the technology agencywide, as well as the human resource management activities, recruiting, as well as, obviously, taking a look at the various needs of the Agency as new endeavors come forward that the Agency needs to be able to address. It's also responsible for all facilities, all missions worldwide from a building aspect and security. It also incorporates the CFO's office Chief Financial Officer's office as well as procurement activities for the Agency and is basically responsible for effectively and efficiently being able to support the emerging needs of the Agency as they come forward both from the Department of State as well as from the administrator himself of USAID.

Ms. Hintzman: Mark, can you tell us what your role as Deputy Assistant Administrator for Management is?

Mr. Kneidinger: Basically as Deputy Assistant Administrator for Management, I have a cross-jurisdictional responsibility within the management bureau primarily in regards to supporting the assistant administrator, John Marshall, for management, but the primary focus that I also have been responsible for is within the CIO for policy range, which incorporates basically implementing and ensuring that Clinger-Cohen Act is fully complied with, ensuring that the Agency has a capital investment process and methodology in place, standards or software development, as well as ensuring that there's an underlying business process correlation to technology basically to be able to apply and understand the business of the Agency and how technology can best support it through the development of an enterprise architecture for the Agency.

Ms. Hintzman: Can you tell us how you got started with the federal government and your appointment as Deputy Assistant Administrator?

Mr. Kneidinger: Basically my appointment to USAID is really based upon my previous experience both in state government and it actually it probably goes back as far as when I was a teacher. I've always looked at technology as a medium to be able to excite individuals in regards to being in the educational realm; to be able to represent complex business activities, be it in state government or in the education arena; and, basically, to have technology to be able to support to the complexity of the various agencies that have worked. So, starting from the education realm, looking at how technology back in the '70s could actually be able to provide a new medium for teaching and for learning with the students to the point of taking very complex regulations, state government both in New York, as well as in Virginia, and be able to translate those in business process terms that can then be applied within technology to where we are today, which is really a composite of that, of taking a look at our technology investments across the Agency, and see how the decisions are being made along those lines from strictly a business perspective, from our different program services that we provide, and have that entity, the program service area, really the driver for making decisions as to how IT investments occur and, in essence, ensure that that investment is actually making a change and making a difference in their different bureaus and helping them provide the services worldwide that they're responsible for.

Mr. Lawrence: Give us a little more. You kind of tease us there. You've been in a couple different sectors in the state government and academia. Give us a little bit of the history.

Mr. Kneidinger: Sure. In the academic area, basically I was a teacher in -- usually in the urban settings and cities both in actually in Virginia as well as in New York, and I actually applied technology back in the '70s. One of the first sets of computers that came out, which are now in museums, were used in regards to having my students, who were usually underprivileged, be able to see for the first time how technology can be used to help them learn in mathematic equations and basically an easier way to be able to write compositions and actually started writing some very simply programs back at that point.

Growing out of there actually with IBM, I was one of the coordinators of a large national program back in the '80s when IBM was first moving computers, PCs into the education market, and set up a training program for superintendents and teachers statewide in New York. That led, then, to my state government activity whereby the state government asked me brought me up to do that on a larger scale but beyond just the academic side but to start taking a look at case management and management at the superintendent's level and at the higher education level. Put together systems that would be able to help these entities address and comply with very complex regulations and be able to give them a means to address this.

Building from that, then I basically took a look at how technology can be further pursued in regards to addressing other critical business within state government ranging from the Health Sector to, again, education, to tourism, and in doing that really got much more involved from a CIO's perspective in helping the business area define their needs and really setting up various processes and offered several investment processes to help the business representatives of state government be able to understand technology in simplistic terms, as well as be able to give then tools to make decisions as to what future investments would come about, then building from that a composite of taking a look at using technology to leverage an understanding of all the different business processes that a specific government Agency may have work processes, technology support, policies, distribution of staffing, all these elements and bring them together from an interrelational perspective to help the Agency identify where there may be gaps or efficiencies that could be gained, and that's at that point where I began getting involved with enterprise architecture.

Ms. Hintzman: Later in this interview, we're going to be talking about your work with the Bureau for Global Health at USAID. Can you provide a brief overview of this Bureau's mission, including the President's HIV-AIDS initiative? Also, can you tell us about the Bureau's leadership?

Mr. Kneidinger: Yeah. Basically, the area in USAID we began delving into in developing the enterprise architecture we focused on the HIV-AIDS area primarily for several reasons. One is that the leader in that arena, the Assistant Administrator for Global Health that's responsible for HIV-AIDS, is a person who has a breadth of knowledge and understanding in regards to the concepts of enterprise architecture from her experience, and actually my interaction with her when she was Commissioner of Health in Virginia, and so leveraging what I call a business champion in USAID was one of the first steps I needed to move forward with to introduce enterprise architecture, since it is a very complex concept, and again overlooking that as being able to drive the enterprise architecture activity from a business-focused perspective.

So, the HIV-AIDS area was the first focus area because of the leadership, also in regards to the mission of the Agency, which has a very high competency and credibility in the area of providing services in HIV-AIDS. So, it's a very high, visible area of the Agency, a very high an area that has a very high importance in regards to the type of services that are being provided, as well as an area that crosses over multiple agencies. Even though the enterprise architecture that we've developed at USAID is focused right now in regards to USAID and we can talk later on as to how that's sort of expanding out it gave us an opportunity to be able to establish a framework that can not be able to address the HIV-AIDS arena and be able to assist and identify any areas of further efficiencies that they can be able to leverage, but also a means by which we can take a look across multiple government agencies and entities that may also be involved with the HIV-AIDS area and provide, in essence, a foundation or a platform that ultimately could be used to take a look at the type of services being provided across these agencies and, in essence, take a look at a true comparison as to how these services are being provided, the success of those services for more than just a single-agency aspect.

Now, that's something that we would like to strive to, but in selecting the HIV-AIDS area, and with the leadership at USAID with Anne Peterson, we were able to put that cornerstone in place, and as we are able to mature this and basically be able to broaden out the degrees of information that we can collect, I think there's a great opportunity to take a look at other agencies and be able to help support them along those lines as well.

Mr. Lawrence: Fascinating point.

What exactly is enterprise architecture and how is it relevant to USAID? We'll ask Mark Kneidinger, USAID, when The Business of Government Hour continues.


Mr. Lawrence: Welcome back to The Business of Government Hour. I'm Paul Lawrence, and today's conversation is with Mark Kneidinger, Deputy Assistant Administrator for Management at the U.S. Agency for International Development.

And joining us in our conversation is Kim Hintzman.

Ms. Hintzman: Mark, since enterprise architecture, or EA, is complex, could you describe enterprise architecture from an IT perspective and then from a programmatic perspective?

Mr. Kneidinger: Basically what I'd like to do is actually describe enterprise architecture primarily from a programmatic perspective because from the use of an enterprise architecture or the purpose of the enterprise architecture, it really is a business-focus concept.

I guess in a short definition of an enterprise architecture at one time I was asked to define enterprise architecture in an elevator between six floors. I was reaching one time for a stop button to see if I could do it by I wasn't fast enough. In simple terms, the enterprise architecture is a blueprint of an organization's workflow, underlying policies, technology support, services that are provided by that government agency or other organization, and how they interrelate, and that aspect is, in essence, termed as the as is. It's a snapshot picture of how the organization operates in significant detail, as well as the enterprise architecture, how all this the work flow, underlying policies, technology supports and services and such how they may better related and that perspective is from a to be.

we are, in essence, the organization that would like to go as such, as that blueprint � and basically it's capturing information in a very standardized format that basically defines those elements and be able to draw interrelationships between all this to see how it all works, and that's the concept of enterprise architecture. Given all that information brought forth, and given common understandings of that information in other words, an apple's an apple in regards to translation and then apply an enterprise architecture, what occurs that applying the EA. You then derive various areas, initiatives, that need to take place; a project that needs to take place; policy changes; work process changes. It could be IT investments.

And why I wanted to focus on it from a business perspective rather than IT is because historically enterprise architecture has really been seen as an IT-focused concept, IT architecturing and such.

I began my career with enterprise architectures back in 1983, and at that point it really was pretty much heavily influenced along those lines in taking a look at how technology works together but also later on how given a portfolio technology, how, in essence, an organization can be more efficient or more effective in regards to its investment. What was missing at that point, though, is the rationale why the technology was in place in the first instance, which is to support the business or the organization's goals, and as technology has matured and as the organizations have become much more sophisticated and also relying upon technology, the business area now has become much more involved and, quite honestly, needs to continue to be involved in it and encouraged to be involved in the enterprise architecture development, and this is, I think, one of the primary focuses that O&B was looking at, and it's development of federal enterprise architecture in not only taking a lot of IT investments in efficiencies there but also in regards to where government can be more efficient from a business process perspective.

And that's the exciting piece of the enterprise architecture in how it's being used to date, because at this point I think there's a cultural revolution going from just an IT- specific focus to really embracing the business perspective. And from that I think then you really have an opportunity to have a larger opportunity for change because for change in essence it will have, I think, a larger impact on an organization because now you're looking at change within the way that an organization operates. First it's just the technology. The technology needs to reflect those changes, but taking a look at the organization and helping the organization understand how it may change, be more efficient is a great tool, benefit of the enterprise architecture even though we didn't go down six floors. Hopefully, that's a simple enough explanation there.

Mr. Lawrence: Well, you mentioned that EA is primarily thought of as an IT tool but yet you're using it as a business tool in the case of the HIV-AIDS, and I'm curious, like, what's the business area behind the HIV AIDS initiative?

Mr. Kneidinger: Well, basically, the HIV-AIDS initiative, or HIV-AIDS, in essence, s services the focus there is to provide services and to have success in addressing and attacking the disease and measuring that success. The HIV-AIDS, what I call segment of the enterprise architecture, which was just the first piece of developing this architecture, incorporates not only, as I indicated in a definition from enterprise architecture, not only a specific service area in this case, the administration of services and items to combat the disease but it also crosses over other areas within the Agency budget, policy, procurement, and the like.

In looking at the HIV-AIDS area, what we also have the opportunity to do is see how that sort of touches all these other entities and organizations within the Agency, and what that allows you to do is draw a composite of basically what will change, be able to have, in this case, HIV-AIDS area, service providers in the organization be more efficient, be able to leverage efficiencies in regards to policies; be able to leverage efficiencies in regards to technology; better to take a look at how they may be able to better deploy information from other areas that they're involved with, such as in the budget area and procurement. It gives a larger picture of, in essence, the success of the HIV-AIDS area.

Ms. Hintzman: So, what did the HIV-AIDS program area learn about their business as a result of using this EA methodology? It sounds like there are a number of findings that they could use to benefit themselves.

Mr. Kneidinger: Yeah. I think there are several major findings that had occurred. I think one of them was basically taking a look at the degree of heroic effort and information that was needed to determine the degrees of success, levels of success; to be able to provide reporting information out; and take a look at why it was a heroic effort. Sometimes heroic efforts are brought about because basically what you're doing is reaching out. You have to reach out to numbers of different areas and take a look at different data sets and bring those together and, in essence, reach out to maybe areas that you don't have a mechanism to be able to collect information. So, the enterprise architecture sort of takes a look at the entire mapping of that information and areas that there may be some data gaps for one reason or another. How do we address that? Is it a policy change? Is it a work process change? Is it a contractual change?

So, the architecture helped set a data model that, in essence, would help the Agency, specifically in regards to HIV-AIDS, be able to effectively and efficiently be able to pull all this information together and bring it together not only in regards to addressing current reports that we're aware of but also to be creative as to how we can interpret this information because we'll have a venue of being able to, like, slice and dice the data as opposed to just bringing it together for a specific, say, report perspective.

I think that it was a critical success. It also provided an underlying foundation for what we're terming the gain of an executive information system. And what the executive information system will eventually do is be able to, again, apply information from enterprise architecture from multiple facets within the agency and take a look at comparative information across the agency and be able to have a very effective tool for managers to build decisions from. The exciting thing that I think was a result of this in regards to the data model and such was that, in essence, when we were looking at the enterprise architecture, a key element for success for this to occur, given the complexity of an enterprise architecture, is that we had demonstrated results. Oftentimes enterprise architectures are created to first capture all the information of an organization and then you apply it. The amount of time that it takes to do that is usually enormous, and you usually lose your audience by then if you were able to get your business champions in place and people excited about it, because it just takes too long.

The approach that we took with this was basically to take a specific segment of the organization, one that, in essence, had a great deal of credibility, a lot of high-level skills ever associated with an area that also, as with many of our service areas, actually have a major impact worldwide on the populations that we support and provide services to. Take that and show, as a result of applying enterprise architecture, an immediate result in this case, a data model; in this case, the ability of supporting the agency from not having to put forth heroic efforts to address these critical data needs, but, in essence, a data model that can address that.

So, as we go forth in the enterprise architecture development, what will be occurring then is that we will be taking a look at the next slices, maybe a further expansion of global health or into other areas, and then, again, build a quick result from there to keep on capturing the imagination of the organization as this goes forward.

Mr. Lawrence: What are some of the other challenges and lessons learned from using enterprise architecture? We'll ask Mark Kneidinger, USAID, when The Business of Government Hour returns.


Mr. Lawrence: Welcome back to The Business of Government Hour. I'm Paul Lawrence. This morning's conversation is with Mark Kneidinger, Deputy Assistant Administrator for Management in the U.S. Agency for International Development.

And joining us in our conversation is Kim Hintzman.

Well, Mark, in the last segment you were taking us through the enterprise architecture for the HIV AIDS project, and I'm curious because how the project managed. I imagine the two bureaus, the two offices the Global Health Affairs Bureau and the Management Bureau performed different functions and yet they work together on this. How did you facilitate communication?

Mr. Kneidinger: Well, as I indicating earlier, a key element in regards to enterprise architectures is making sure that the business segment is truly driving the activity, and in regards to managing this activity, obviously we had a strong leader who understood enterprise architecture. But I think more importantly along those lines is that we had a team of individuals within the HIV-AIDS area that we were able to leverage and use and have them participate in identifying the critical work processes and challenges and needs that they were facing so that we needed to be able to capture those business issues and the current business processes. So, to support that, what the relationship was was really the business area was driving the information to us. The IT area or the enterprise architecture team provided basically a medium by which to collect this information, a means by which to standardize this information, and a repository to place this information. And then basically the repository itself is the enterprise architecture repository, and we applied that repository then to come up with a variety of projects and initiatives then that would address, in essence, fill in those gaps that were identified by the program specialist, by subject matter experts. So, the criticality of the success in this whole thing was having those individuals who understood the business be the key element to be able to make sure that we were capturing the true essence, the true picture of the HIV-AIDS area. And we did this through guided interview sessions. We did this through review of documentation.

One of the areas of challenges I think that agencies and organizations have in regards to enterprise architecture is how do you obtain that information and how do you leverage the time element of making sure that you have availability of the business of subject matter experts and, in essence, a way of being able to capture this information and a means that you can then apply later. That framework was a cooperation between, again, the leadership in the HIV-AIDS area to say that this the results of the enterprise architecture will help us and the enterprise architecture team which provide that framework and an opportunity to capture this information.

So, I give, you know, the bulk of the credit for this success because it was not just an IT organization asking questions and putting it into an enterprise architecture, but it truly was a partnership of interaction between HIV-AIDS area and a team that could take this information and be able to place it within an enterprise architecture environment that then we can apply to help that organization. So, it was a true partnership with the business sector being the primary partner in this case.

Mr. Lawrence: What's the timeline for the project finishing and for where you've described?

Mr. Kneidinger: For the work on the HIV-AIDS segment itself, we actually began the initial review of documentation and setting up other various meetings with the subject matter experts and actually beginning the development of the repository in August of '03, and it had culminated in early February '04, which it, quite honestly but it was a tremendous effort given the complexity of enterprise architecture. And not only were we able to capture that component, but one of the key elements, as I indicated before, in regards to growing enterprise architecture and growing the interest and the champions at the business level within an organization is that we also were able to demonstrate the result of the enterprise architecture and that data model that I talked about earlier. That was the time frame for that segment.

One of the things that we focused on was, again, to make sure that we had a success at the end of that segment, and, in making sure that we were able to cash in this information in this short time frame, we also had to make sure that people understood what the results were going to be of the enterprise architecture. So, a key element during that time was collecting information, but also a key element was education, education of the individuals that were involved so they understood what was going to occur with that data and what the potential was but also education in regards to those individuals that would have to take the next step in other words, take those initiatives and move them forward. Also education in regards to servicing the platform for understanding the enterprise architecture as we move into the next segment. Now that we have a framework, we'll be moving into the next business area. So, we wanted to set it up like a snowball effect. We wanted to leverage the excitement and the positive results so we can go immediately into the next segment. Basically we were able to accomplish that within that time frame. I think we were quite successful with it.

Ms. Hintzman: In addition to the excitement and the good working relationships with the business areas, what would you say are the critical success factors to making EA work?

Mr. Kneidinger: I think there's two points there. There's enterprise architecture can be claimed as a success at two different levels. It can be claimed as a success by just virtually collecting these levels of information I was talking about so that you have, in essence, a document that gives the entire story of the organization and how it operates. You can claim the second level of success and then taking that and applying it. And that's where AID USAID had evolved to because with that you then need to be able to restructure a repository whereby the enterprise architecture information can be basically used where all these different interrelationships and the complexity of that can be applied so that results initiatives be it levels of competencies are needed; projects can materialize versus just a document that you then review and you come up with high-level recommendations. What the repository allows you to do is actually then go back to the specifics as to what drove that recommendation and why. What business need was being met? What gap was being filled? What are the risks? What are the costs? What are the capability changes, skill changes that need to occur?

You have all that available within the repository so that it makes decision making - it gives a much more solid basis for decision making to occur as opposed to, again, just capturing it and just playing it as maybe a contextual document because from there you would have to a lot of deep reading and then draw those comparatives to yourself. What makes enterprise architecture successful is going to that next stage. But I think from a historical aspect, given that enterprise architecture is perceived as very complex and it usually takes a great deal of time because we look at complete, entire architecture before we see results and looking at the architecture focusing more in regards to the tentacle realm so you don't have the visibility of a success of enterprise architecture beyond the IT walls. I think in the approach that we took we were able to have this success in a short time frame because we were able to collect this information, apply it, and see immediate results within the HIV-AIDS area.

Ms. Hintzman: Can you tell us, what were your biggest challenges in establishing and managing this EA project?

Mr. Kneidinger: I think one of the major challenges, and it will continue to be a challenge, because enterprise architecture is complex, is education because given all the different given the way that enterprise architecture operates, it's difficult for an individual to relate it to their daily lives. Though in the education sessions that are provided at the Agency and in other areas, what I try to do is take a very simple process that a person's involved with on a daily basis and sort of bring that to the forefront as to okay, what need is this action addressing; what are some of the value-added aspects that are needed to make sure that you can be successful in this activity; what are the competencies needed. Now, for you to go to where you want to be, what are the differences?

To try to bring it down to simplistic terms and simplistic, I guess, actions and then basically relate that to all this sort of happens within the enterprise architecture. Education is always going to be a challenge because it's difficult to imagine what an enterprise architecture can do for you. And I think the continuation of the education will also help people understand that the enterprise architecture itself is going to be able to provide some major benefits to them. But at the same time, it's a long-term investment. Enterprise architecture is never done because processes change, policies change, work processes change, technology investments change, and you need to refresh that. And as you refresh it, there are going to be other considerations that are going to be coming out of the enterprise architecture as to other things that you need to consider. So, for it to be accurate, for it to be refreshed, the ownership of the enterprise architecture really needs to be within the bounds of the business area because they're the ones who understand that changes are occurring. So, education in regards to how it's applied but also, in essence, how it's being implemented.

Mr. Lawrence: Will EA catch on, or is it just too complex? We'll ask Mark Kneidinger of USAID for his perspective when The Business of Government Hour continues.


Mr. Lawrence: Welcome back to The Business of Government Hour. I'm Paul Lawrence, and this morning's conversation is with Mark Kneidinger, Deputy Assistant Administrator for Management in the U.S. Agency for International Development. Joining us in our conversation is Kim Hintzman.

Ms. Hintzman: I understand that OMB has asked State Department and USAID to merge their enterprise architectures. Mark, from a policy perspective, what is advantageous of doing so?

Mr. Kneidinger: OMB is really even as a great opportunity here to take the work that was done with USAID in regards to the enterprise architecture and the framework that we set up there because any agency AID obviously included here � when it develops an enterprise architecture and all agencies are required to do this they must, in essence, ensure, and rightly so, that they align with what's called reference models to the federal enterprise architecture that OMB has established. What this allows, in essence, and there's different reference models there's business reference models and service reference models and technical reference models and so on and so forth but basically what it allows the federal government to do in a very efficient and effective way is that over a period of time as these enterprise architectures are established to be able to share and grow up information, again, from a governmentwide perspective, leveraging the same capabilities of an enterprise architecture as at the agency level in regards to the efficiencies and work process, potential changes, IT investments. So, in essence, in the collaboration that's being pursued with the Department of State and USAID on this, what is occurring is that we're taking two enterprise architectures again, both are referencing the federal enterprise architecture, the FEA, and for I think one of the first times that this has been done in regards to the federal government itself is bringing these two things together two different agencies' enterprise architectures. And so basically what it allows us to do is to take a look, then, once it is complete and this is an effort that's just beginning at this point but leveraging common frameworks.

With it complete, it will help our agencies to be able to look across the agencies and see where there may be areas that we can further partner and have maybe joint investments and be able to take a look at how we can best leverage jointly our resources since obviously the Foreign Service influence and emphasis that both agencies have. So, it's really a great opportunity to sort of demonstrate the model of the FEA between two agencies. So, we're very excited about it.

And this is also part of a larger effort between our agencies that's supported by what's called JMC, or Joint Management Council. Department of State and USAID have a joint strategic plan, and enterprise architecture is part of that and obviously a tool that will help support that. So, the Joint Management Council, which I co-chair several of the workgroups, the enterprise architecture being one of those areas, is actually the responsible party to take a look at the work of bringing these two architectures together.

What's important about that is that basically as these two come together we need to ensure that there's commonality of language, commonality of understanding of, say, what the repository looks like, commonality of the way we collect information, definitions, and such, and having these formalized groups in place we have means by which we already have key subject matter experts between agencies working together. So, this adds additional support to a very successful activity that we're moving forward with at this time and basically from that perspective be able to take a look at the federal enterprise architecture and primarily focusing on, as we bring these enterprise architectures together, what can be learned and how can we be able to support OMB as the FEA matures to that point as well.

Ms. Hintzman: What advice would you give to other policymakers and IT managers in government about adopting an EA approach?

Mr. Kneidinger: I think the key thing there goes back to the whole premise that I brought on at the front end here with regards to our business focus. As different agencies develop their enterprise architectures or refresh or expand them, I think one of the great opportunities is if your business area had not been involved extensively is to do that. I think one of the opportunities there in bringing that forth is also sort of putting the I was going to say floodlight but, in essence, it could be even a stronger light beam on this in regards to how the IT shop can best support the business area, the organization, and from a structured fashion as opposed to being perceived in maintenance to back off this function. Building those partnerships and having the enterprise architecture and having a business focus certainly encourages that, and we're certainly seeing that at USAID.

Mr. Lawrence: Critics of EA would say that it won't catch on either as an IT tool or a business tool in the federal government because it's just too complex. How do you respond to such criticism?

Mr. Kneidinger: Well, I think primarily in regards to the perception of complexity, yes, I mean, everyone I talk to when we talk about EA, enterprise architecture, it usually takes them three seconds before their eyes start rolling back. It is complex, as I indicated earlier, and I think the key thing here for enterprise architecture to catch on because, in essence, every agency needs to have an enterprise architecture in place as a requirement as part of being OMB and such, but for it to catch on itself and for it to be embraced wholly within the agencies, education, education, education. And as part of the education is ensuring that we can define enterprise architecture, we can define the processes associated with it in very simple terms.

We had an opportunity to basically test our education models not only internally in AID but also to our missions in a number of different countries but to basically staff out in the missions that had very little understanding as to okay, EA, what is that type thing. And in preparing for that we have a very, very good team that was able to do that translation for us from complexity of EA to English. And we keep on putting those programs out there; we'll continue that as part of the education. So, I think for it to catch on is education, education and, also, for it to be viewed as something that will help the Agency's business area as opposed to just something that has to be done or something that is IT focused.

Mr. Lawrence: You've had interesting experiences in public service, and so I'm curious, what advice would you give to someone interested in going into public service?

Mr. Kneidinger: Well, I think there's great opportunity in public service. What I mean by that is that I think from day one when I began my career in government � state government level there and then I obviously into the federal side the one thing that I've always been optimistic about is that I come into the government realm because I feel like I can make a change, and I think that basically there is that opportunity, and there's that opportunity to be able to, you know, have an impact in regards to be at USAID in regards to the missions that we have throughout the world. I don't think it matters what level you come into in the public sector or what you're doing because I guess if we were to take a look, I guess, again from an architectural aspect, everyone has a critical piece of the success of the organization, and I guess one of the selling educational advantages that we have in regards to a demonstratable enterprise architecture is that you can see whatever a person is doing, what his impact is on the organization to be able to be successful, and so a person coming into the public sector has an opportunity to have an impact no matter where they are. It's a great opportunity.

Mr. Lawrence: That'll have to be our last question, Mark, I'm afraid we're out of time. Kim and I want to thank you for squeezing us in your busy schedule.

Mr. Kneidinger: And if the audience would like to find more information on enterprise architecture itself, as I indicated the Office of Management and Budget has set up a federal enterprise architecture and the associated reference models and standards aligned to that. That information, plus information in regards to the CIO activities across the board in enterprise architecture, can be found on

Mr. Lawrence: This has been The Business of Government Hour, featuring a conversation with Mark Kneidinger, Deputy Assistant Administrator for Management at the U.S. Agency for International Development.

Be sure and visit us on the web at There you can learn more about our programs and research and get a transcript of today's conversation. Once again, that's

This is Paul Lawrence. Thank you for listening.

Mark Kneidinger interview
Mark Kneidinger

Broadcast Schedule

Federal News Radio 1500-AM
  • Mondays at 11 a.m. Fridays at 1 p.m. (Wednesdays at 12 p.m. as
  • available.)

Our radio interviews can be played on your computer or downloaded.


Subscribe to our program

via iTunes.


Transcripts are also available.


Your host

Michael Keegan
IBM Center for The Business of Government
Leadership Fellow & Host, The Business of Government Hour

Browse Episodes


Recent Episodes

Bob Rosen
Author of Grounded: How Leaders Stay Rooted in an Uncertain World
Jin-Oh Hahn and  Monifa Vaughn-Cooke
University of Maryland
Assistant Professors, Department of Mechanical Engineering
Vice Admiral Raquel Bono
United States Navy
Director, Defense Health Agency

Upcoming Episodes

Michael McKeown
Executive Director, Homeland Security Advisory Council
Department of Homeland Security