DCOIThe big mistake is asking agencies to identify aggregate cost savings over time. GAO will never be satisfied with what OMB and the agencies are reporting for cost savings. This is generally because agencies pick savings targets out of thin air and then are held accountable to achieving these made-up and arbitrary goals. But FITARA requires us to identify the cost savings. Instead of trying to arbitrarily identify the cost savings, why don’t we just go with how much it costs (or in this case, how much we budget for something). Then, if the number decreases over time, that is a cost savings. If it doesn’t then there is no savings. I feel like this is describing rebounds6.

This is a big gripe that I have with OMB. They try to go through this exercise and develop these hard targets for cost savings and data center closures. Instead, measure at the detailed level and see if the number decreases over time. When you do this, you are reporting both the budget data and the performance data and you shouldn’t include data center budgets in any of the other business cases (major or non-major). That would lead to double counting. But doing it this way creates a bottom-up data point that can be validated easily.

But then, most of the data collected in the IDC can follow this same approach. Add three budget columns for mobile devices and then remove mobile devices from all business cases. Work with GSA to get Networx/EIS budget and performance data and then remove them from business cases. Do the same with cloud infrastructure services. Do the same thing with laptops and desktops 7. If you did that then all of the most expensive things in the IT portfolio will now only collect a Budget and Performance Package that is relevant to the specific commodity. We will also be eliminating the concept of the General Support System (GSS), which was a catch-all investment that included everything and the kitchen sink. Additionally these packages, the roots of the tree, can be connected, or linked to enterprise IT capabilities, business systems and/or applications.

Wouldn’t it be great if we could look at a mission application, like the Consular Application at the State Department? It has been in the news lately for all the wrong reasons. Wouldn’t it be great if we could peel back the onion to look at the data centers that are supporting it? Shouldn’t we be able to look at the platform things (authentication, document management, collaboration systems) that support the investment? Finally shouldn’t we be able to look at the application, mission investment, which tells us who the sponsor (business owner) is and why we need it. This is the traditional major exhibit business case (exhibit 300)8. But by separating the different parts we can see the performance of the parts and make changes independently when the performance is bad or when the costs are too high.

Then OMB wouldn’t need to be performing the analysis of who is running data centers well and who isn’t. This would democratize the data and anyone who is running a data center would be able to compare the performance of their data center against the performance of every other data center in their agency or even the entire government portfolio. Additionally, the data that is currently submitted in the infrastructure summary table would be achieved by summing up the budget for the individual components instead of a top-down estimate.

Shared Services

When you look at the performance of financial systems today, the differences in performance on the financial system are very difficult to isolate. So much is dependent upon the performance of the underlying infrastructure. But then an agency like HUD, which is transitioning to a shared service provider (Treasury), should be able to include this reporting among the benefits from that service. The service provider should develop the budget and performance package on the behalf of the customer agency. This is part of the service you should get from the provider. They develop the package and send it to you, the customer, and then you review, change what you want to include the capabilities and services and perhaps oversight elements that are outside of what the service provider delivers and send that to OMB.

All service providers should be doing this for their customer agencies. But they don’t, and that is weird. Payroll, HR, all of the shared service capabilities should do this. Some of the quicksilver ones do, like Regulations.gov, Grants.gov, IAE/SAM do. But all shared service capabilities should develop a single case that identifies the contributions from all the customer agencies.

This is related to the other big problem I have with how we budget for IT. There are certain capabilities in which we should only have one. The things in the Enterprise IT Capabilities, and Business Systems should only have one of most of them. If you think about email, financial system, HR system, acquisition system, authentication, you should only have one of these for the enterprise. If an agency has more than one, then there must be analysis to figure out which one will be the one for the enterprise going forward and which one will be decommissioned.

 

Discretional Versus Mandatory

The other aspect that must be addressed from a revised budgeting structure is the notion that IT permeates everything. You can’t run a program without IT. You can’t give a grant without IT. You can’t catch terrorists without IT. IT permeates every aspect of agency business and missions. But according to the current CPIC process, we need to conduct Investment Review Boards on all the investments in the portfolio.

tree2That is a false choice. An investment review board seems to indicate that the board could make a “no” decision on certain investments. The false choice is that there are some investments that have any choice at all. Do agencies have a choice about funding the network and telecommunications capabilities? How about email? Or the Security Operations Center? I would argue that there are certain capabilities that absolutely must exist if you are going to have a viable agency. As such, empaneling an IRB to try to decide whether the investment is a priority is a waste of time. We need to stop wasting time making pointless decisions.

Referring back to the tree analogy, when water and sunlight are scarce, the leaves on the tree fall off leaving only the roots, trunk, and branches. As water and sunlight again become plentiful, the leaves grow back. As such, I would argue that the applications are the ones in which IRBs should be making decisions on. Business Systems, Enterprise IT Capabilities and Infrastructure are necessary for the operation of the agency and thus are mandatory.

There can still be arguments about the level of funding and the extent to which we are pushing new development (DME) into those capabilities, but the O&M for these capabilities is not a topic for discussion. This is why I would say that this is mandatory spending within the agency.

Part of the reason I say this is because of the term “technical debt.” When you look at OPM, FRTIB, GSA (SAM breech), VA, and other agencies that are failing to secure the information they need to protect, one common thread is that they suffer from technical debt. The IT leadership claim, rightly or wrongly, that the problem is one they inherited. The problem is that the IT capabilities in question suffered from a lack of funding over a prolonged period of time.

You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy-you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place.

 

Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.9

We can make this trade sometimes, but we can’t make it every time over the period of 10 years. That is what we say at OPM, FRTIB, GSA and VA. We chose to make the quick and dirty change instead of the foundational and fundamental changes. We chose to make fast changes instead of the changes that take longer. Most importantly, we chose to make cheap changes over the more expensive changes. In government agencies that is what it comes down to more than anything else. We budget for the bare minimum because IT is seen as discretionary and when you are making discretionary decisions, a smaller number is more likely to be accepted than a bigger one. We absolutely must break out of this cycle, and it starts with budgeting for IT in a more responsible manner.

We think that “keeping the lights on” is not a discretionary decision. Similar to that is keeping the network running. I think many people would argue that the network is just as critical to operating the agency as the lights. But then that means that we need to protect the network. We also need the hardware (computers and mobile devises) to access the network. We need the services (email and authentication) that run across the network so that we can communicate. These things must be funded at a consistent level year over year.

If CIOs need to go begging for dollars for these capabilities that are necessary to operate a viable organization then there is no way they are going to be working on the business systems or applications that rely on these services. But that is what agencies do on a too-frequent basis. They prioritize the application over the platform or the network. This forces CIOs to make those tradeoffs on the critical capabilities necessary to sustain the agency and increase the level of technical debt until it all breaks down. We address this issue by acknowledging that some IT capabilities are mandatory and we are required to support them as such.

 

1 http://clinton5.nara.gov/OMB/memoranda/m97-02.html

2  https://www.whitehouse.gov/sites/default/files/omb/memoranda/2011/m11-29.pdf

3  http://catalog.data.gov/dataset/fed-data-center-consolidation-initiative-fdcci-data-center-closings-2010-2015

4 https://itdashboard.gov/drupal/data/datafeeds?format=csv

5  https://whitehouse.github.io/datacenters/ProposedDataCenterOptimizationInitiativeMemo.pdf

6  https://www.youtube.com/watch?v=P6A2ZgKV6n0

7 https://www.whitehouse.gov/sites/default/files/omb/memoranda/2016/m-16-02.pdf

8  https://www.itdashboard.gov/currentPDF/1132

9  http://martinfowler.com/bliki/TechnicalDebt.html

 

In This Series:

The Federal IT Papers–Part 1

The Federal IT Papers–Part 2

The Federal IT Papers–Part 3

The Federal IT Papers–Part 4

The Federal IT Papers–Part 5

The Federal IT Papers–Part 6

The Federal IT Papers–Part 7

The Federal IT Papers–Part 8

The Federal IT Papers–Part 9

The Federal IT Papers–Part 10

The Federal IT Papers–Part 11

The Federal IT Papers–Part 12

Read More About
About
Demosthenes
Demosthenes
Demosthenes is a pseudonym for a senior Federal IT official.
Tags