The Federal IT Papers–Part 2

Editor’s Note: The following story is taken from a book-length work authored by a senior Federal IT official currently working in government. This is one part of an extensive, firsthand account of how IT decisions are made, the obstacles standing in the way of real change in government technology management, and what one career Federal IT employee really thinks about the way government does IT.

Because the author is a current government employee and is concerned about the impact this may have on their career, we’ve agreed to publish this series of weekly excerpts under the author’s chosen pseudonym—Demosthenes.

MeriTalk has agreed not to make substantive changes to any of the weekly chapters. We will publish a new chapter/excerpt every Thursday for the next nine weeks.

— Dan Verton, Executive Editor

EA and Platforms

There are a lot of different places I could begin this discussion. I think that the best starting point is in architecture because, “If you don’t know where you are going, any road will take you there.”¹  I worry that the way we have run enterprise architecture (EA) has been an exercise in futility. It didn’t always have to be like that. In fact, I think Congress had something very different in mind when they authorized EA in the Egov Act of 2002:

‘‘(4) ‘enterprise architecture’—

‘‘(A) means—

‘‘(i) a strategic information asset base, which defines the mission;

‘‘(ii) the information necessary to perform the mission;

‘‘(iii) the technologies necessary to perform the mission; and

‘‘(iv) the transitional processes for implementing new technologies in response to changing mission needs; and

‘‘(B) includes—

‘‘(i) a baseline architecture;

‘‘(ii) a target architecture; and

‘‘(iii) a sequencing plan²;

From my perspective, section B is the important part. It asks, what do you have now, what are you aiming for, and what is the plan to get there? Unfortunately for us the only thought leader at the time was John Zachman, from IBM. He is famous for the Zachman Framework, which essentially tries to categorize the universe. I am not trying to make fun of Zachman or his work, I am certain that there is a use for it somewhere. For example, the bat cave from the 1960s Batman had labels for everything.

But we have to think about the environment in which his ideas evolved. What was IBM doing in the 1980s and 1990s? Microsoft was just getting started and IBM was still focused entirely on mainframe computing. As such, it shouldn’t be surprising that the architecture processes coming from IBM at the time were advocating processes that categorize every element and moving part before initiating development. The cost of discovering new issues after development has commenced would likely be costly in that development paradigm. In fact, the later you discovered an issue, the more costly it was to address it. As such, the Zachman Framework may make sense for waterfall life cycle development and second-generation programming languages.

Below is a graphic that outlines all of the categories by which the Zachman Framework captures data. It comes from a guy named Al Zuech who was in charge of EA at Veterans Affairs in 2002.

I’m not saying that Zuech’s work is awful, or that Zachman’s work is awful. I am saying that I have never seen any utility from it. Perhaps it is good to be aware of that work and what it is, in the same way that we still have to learn about the Pilgrims coming to America on the Mayflower; that is where governing began in America. But if someone has a question about the laws today, we probably wouldn’t go back and look at the Mayflower Compact. Similarly, we shouldn’t go back and look to Zachman’s EA work to guide current and future activities. It was made for an age that has passed. The type of development work that we do today requires a different process that produces faster results and creates a loop for learning by doing.

Thus, anyone who is still following the Zachman Framework or the Federal Enterprise Architecture Framework Version 2 is dumb. We absolutely have to stop doing stupid stuff. We award tons of contracts to support EA at agencies and what do they produce? We get binders of stuff that never get used. So the government spends tons of money on EA and the contractors produce tons of documentation that occupies shelves and never gets used. The joke was that based on the size of the contract we should expect to see X pounds of documentation. Thus a $50 million contract would be 25 pounds and a $100 million contract would be 50 pounds.

But we still need to do what Congress told us to do. It is the law. Go back to that previous page and re-read what Congress told us to do. They told us to understand what you have, figure out what it is supposed to look like in the future and make a plan to get there. In this instance, Congress was right, but we had the dumb luck of listening to the big systems integrators who sold us in the very costly IBM process. Good for you, big companies. You made a boatload of money on this useless thing, and I hope that you enjoyed the ride, because it is over.

Zachman was the false start. Think of it as the Mayflower Compact, a necessary first step. What we should have done instead is listen to Jeanne Ross. Her book, Enterprise Architecture as Strategy: Creating a Foundation for Business Execution, is the seminal work that gives us the real roots for meeting what Congress intended and for actually delivering value to government agencies. Her first significant insight is that there are four main types of operating models that organizations generally strive to be. She is mostly thinking about companies, but this logic can just as easily apply to government agencies.

• Diversification (low standardization, low integration)
• Coordination (low standardization, high integration)
• Replication (high standardization, low integration)
• Unification (high standardization, high integration)⁴

This is a key, key, killer important thing. Based on the levels of standardization and integration we can identify the organization’s operating model. If the universe of organizations can be whittled down into these four general categories, where do you think most government agencies should be?

If you said diversification, coordination or replication, go back to California. Most, if not all government agencies strive to be in the unification operating model. This is because of a few key reasons.

1. If we are buying the same type of thing (standardization), then we are able to pool our acquisitions together and gain an economy of scale. This is strategic sourcing and I’ll talk more about that in Chapter 5.
2. Also, if we have the same stuff (standardization), then it is easier to secure. I’ll talk more about that in Chapter 6.
3. If we are able to share tools (integration) across business units then we save money by building once and leveraging what we have already built. More on that in Chapter 5.
4. If we are able to share data (integration) across business units then we are able to be more effective in delivering value. Think about HealthCare.gov and the aforementioned Electronic Health Record. More on this in Chapter 12.