5	The Off-Balance Sheet Asset

And as every present state of a simple substance is naturally a consequence of its preceding state, so its present is pregnant with its future.

—Leibniz, Monadology

That which rules within, when it is according to nature, is so affected to the events which happen, that it always easily adapts itself to that which is possible and presented to it.

—Marcus Aurelius, Meditations

Enterprises face a very different set of challenges than startups in an environment of rapid change. Startups have no need to transform—what is there to transform? They have no history and few external expectations, other than those they set for themselves. They haven’t yet perfected the craft of bureaucracy—that delicate art of constraining themselves through rules and policies and gatekeepers. They’re generally funded and owned by investors who are interested in aggressive bets and understand that entrepreneurs need to test their ideas in the market and pivot frequently until they perfect their offering.

Enterprises, on the other hand, have baggage—or to use the current term in IT, a legacy estate. Their challenge is to unstick themselves from their legacy and move forward into the digital world. Imagine for a moment an enterprise that serves a market well. It has optimized its costs; established great relationships with suppliers, distributors, and customers; has passionate employees; manages risk; and complies with government and industry regulations. It’s a paragon of S&P 500-ness and has even had a Harvard Business School case written about it.

Such an enterprise has perfected its way of doing what it did yesterday. It has structured itself to deliver yesterday’s value and has hired people who are ideal for yesterday’s competitive strategy. It has developed a culture suitable for yesterday’s delivery, and its processes allow it to reliably create yesterday’s business value. By definition, it is perfect at its legacy.

It follows logically that this perfect enterprise isn’t prepared for what it needs to do tomorrow. This is all the more true the better it is at doing what it did yesterday. And the change to tomorrow is not accretive—to morph into the company it’ll be tomorrow, it will need to undo some of the doing it did yesterday, not just add more doing.

This perfect enterprise needs to not only slip gracefully into the future, but learn to dance the dance of the digital age, to dubstep or pop and lock to whatever music comes up—all while the psychotic DJ with a short attention span can’t settle on a style. The digital transformation requires that the enterprise embrace nimbleness as a daily dance move.

To make things more complicated, enterprises find that yesterday’s doing wasn’t just a set of individual practices, but rather a complex network of interrelated processes. Of course it’s hard to unstick! It’s not a piece of bubblegum stuck to its shoe—it’s an entire vat of bubblegum that the enterprise is trying to dance Gangnam-style in. If bubblegum is made in vats.

To focus only on the difficulties enterprises face, though, is to miss an important point. Large enterprises also have advantages in the digital world—including global distribution, worldwide support systems, brand recognition, extensive ecosystems, strong balance sheets, and predictable cash flow.1 They have strong market positions because at one time they were innovators. If the enterprise can free itself from its legacy while taking advantage of these assets, then it’s in a strong position to compete in the digital economy. But to ask it to change is to recommend it stop doing that which has made it successful.

Sticky legacy is especially apparent when it comes to IT, for the company’s systems were also designed to fit yesterday’s business. There is an unfortunate law of IT system entropy: as changes are made to systems over time, they get tangled, complex, ugly, and less maintainable (unless energy is exerted to prevent that outcome). They may be based on technologies that few IT employees remember.* They were probably designed for a day when infants weren’t taught to hack into computers before their first taste of organic baby food, a day when the hacking group Anonymous was also Unknown and Unpresent.

Over time, IT systems diverge from what the company really needs—let’s call that functional debt; as a result, legacy system users develop workarounds or simply adapt themselves to the systems. And over time, IT systems diverge from the ideal internals to support what their users see—system functions work but the code is messy, the design confused, the technological underpinnings outdated. Bugs lurk, even if they’re trapped under a rock for the moment; system changes risk letting them escape to bite users. This is called technical debt.

The debt analogy is apt. Functional debt costs the company “interest;” workarounds are inefficient and prevent the company from seizing opportunities as they arise. Technical debt also has a cost; system changes are made increasingly more difficult and take longer to implement—never mind the risk of springing loose those bugs. Eventually such debt overwhelms the systems and prevents the company from changing. That is, at least until the debt is retired, or is paid off by investing in remediating internal flaws and bringing functionality up to date. This is what companies usually mean by “modernizing.”

The debt wouldn’t be a burden if nothing was changing in the business environment. The company could just keep running the systems as they are, since they’re adequate for supporting the status quo. But in a dynamic business climate, the enterprise feels the effect of its bubblegum vat.

Let’s define agility as an organization’s ability to respond quickly—and at low cost—to new circumstances. In an uncertain environment, that ability is extremely valuable. It will increase the company’s revenues while reducing its expenses; it will reduce its risks and enable it to turn surprises into opportunities.

This is, simply put, the definition of an economic asset. It’s not one that appears as such on the balance sheet, but nevertheless it’s an intangible asset. Whatever increases the organization’s agility increases the value of this asset; whatever reduces agility impairs it or creates a liability.

IT has been one of the greatest sources of enterprise non-agility. This is ironic, because computers are general-purpose machines: the same piece of hardware will let you run financial systems, play Solitaire, catch up on the Kardashians, and email your lawyers. The difference between your financial system and Grand Theft Auto V is a few bits and bytes here and there. A set of directions to a computer; how hard can it be to change? Certainly not as hard as building a new factory.

The more that the company runs on software, the easier it should be to change. And even for the stuff of IT that is not software—infrastructure and networking hardware—the cloud has given us speed. Why then have IT initiatives always taken so long?

I find it helpful to think of an enterprise’s total IT capabilities as a single economic asset—the IT asset. It includes the organization’s software systems, its infrastructure, and the devices it puts into the hands of its employees. The IT asset enables a company to conduct its business—to generate revenues and to manage costs. By definition, it perfectly performs exactly what it does today, even if that means enthusiastically generating errors; functionally, it is what it is.

The IT asset’s functionality that the business sees is one thing, but its inside is another. The design of the code might be elegant and simple, or convoluted and confusing. The code might be composed of reusable building blocks that can be combined in new ways, or limited to doing only what it does today. It might be rugged and resistant to hackers, or have hidden flaws that someday will become targets.

These qualities determine how agile the IT asset is, and consequently its value. As the company tries to adapt to changing circumstances, to seize opportunities and avoid hazards, the asset’s agility translates into costs and lead times. Its value isn’t only in what it can do today, but also in the latent value it has in its ability to adapt to the company’s future needs.

Some aspects of this asset appear on the balance sheet, but some do not—the IT asset I’m proposing is a tool for managerial decision-making, not for financial reporting. Some of the software and hardware might have been capitalized, but this asset’s real value—its influence on future profits or mission accomplishment (the present value of its future cash streams)—is probably not captured as such in financial statements.

What does your enterprise do to maximize this latent value? In your governance process, is there a way to justify investments that increase agility, even if they’re neutral with respect to immediate functionality? Is IT encouraged to take time when building a new capability to perfect its internals and make them more flexible? In a digital world, these questions become important to your success.

IT asset quality depends largely on technical considerations—its design and overall architecture, the code’s style, and its resilience when used in unexpected ways. Some of its software components might have been bought off the shelf, some developed in house by IT, and some created by contractors working from documented requirements. Assembled piecemeal over time, some components are aging while some are new. That’s to say that some are immature, while others appear now and then at family gatherings and no one quite knows what they’re muttering about any more.

All of these pieces fit together to support the company’s day-to-day operations. The fit can be seamless and elegant, or it can be patchwork and awkward, glued together with integration code IT had to develop. Some parts of the IT asset work well; the others are unreliable, buggy, or insecure.

Even if code is written to be agile and elegant, technical debt steals in and degrades it. This decay can be reversed by refactoring the code to make it more agile. This is the process of improving the code without changing what the code does. A good deal of refactoring is occurring all the time as software developers groom their IT assets. They sometimes begin creating a system with one design in mind, then alter it as needs evolve. They then go back to the code that’s already working and refactor it to reflect the new design. This is an everyday part of system development.

It might not have been obvious in earlier days that these asset qualities affect its value—after all, the asset did what it needed to do, even if using it annoyed its users. It therefore made little sense to invest in retiring technical debt. Enterprises often—and quite reasonably—have preferred not to invest much in maintenance spending. This might be good reasoning in an era of stability and slow change, but in times of uncertainty, such quality improvement investments can be important for future cash flows. If the asset is well structured and its architecture is simple, then it will be easier for the company to innovate and change. But if it’s convoluted and coming apart at the seams, and IT spends too much time patching it, fixing emergencies, executing manual workarounds, and sitting in meetings to discuss all that’s wrong, then IT won’t have the focused time available to do whatever becomes important to the business. And the asset will continue to deteriorate over time.

Some of the technical factors that influence the value of the asset are straightforward. Code should be readable and understandable so a developer who is unfamiliar with it can quickly determine how to change it. It should be built using contemporary tools and practices.

Some large enterprises have mission-critical IT systems written in that antique curiosity of a programming language, COBOL. They can keep those things running and believe it’ll be risky and expensive to try to bring them up to date. But those old systems are also holding the company back, making it difficult to innovate and serve a digital market. That in itself is a cost and a risk.

Loose coupling is an important IT design concept with business implications. Given that IT systems are a conglomeration of many component pieces, how closely together are they bound? How much difficulty would there be in removing one piece and replacing it with a similar but better one? Would you have to make many changes to other components? If so, it will be expensive and risky to make them, as the consequences of a change will ripple through other parts of the system.

By allowing developers to work quickly, automated tests also add agility into the IT asset and provide a safety net. Without them, developers must work slowly and carefully to make sure their changes don’t break previously deployed functionality. Automated tests are so important to today’s software development techniques that one author, Michael Feathers, has proposed we simply define a legacy IT system as one that doesn’t have them.2

Organizational agility is determined by nontechnical factors as well. A second intangible asset, the organizational asset, consists of the nontechnical resources the company has for rolling out IT capabilities. It includes its investment management, budgeting, and governance processes, for example, and the people who use or create its technological capabilities.

Outsourcing has tended to impair the value of the organizational asset. During the outsourcing wave, companies believed it would make them more agile since they could add or subtract technical talent as necessary. But the need for technologists is constant, rather than project-driven. An organization that outsources critical skills must face the overhead of the contracting process whenever it needs talent, which impedes the flow of innovation and lengthens lead times. Having the right employees with the right set of skills is critical in being able to quickly respond to change.

The organizational asset includes HR capabilities and policies that make it possible to move people between roles and retrain them, along with the ability to form people into teams to work across functional silos. It includes the company’s IT investment decision process. If all such investments are overseen at a coarse level, in large batches of requirements treated as a monolithic whole, then it will be hard to change course once a given investment is underway. If the governance process is slow and involved, or if the budgeting cycle locks in decisions well in advance of execution, then agility is compromised.

The company’s risk posture—not its risk tolerance, but the way it perceives, prioritizes, and manages risks—is another important factor in organizational agility. An enterprise that perceives a high risk in stasis will tend to be more tolerant of change, whereas one that perceives a high risk in the new and unknown will change much more slowly.

An organization’s structure also affects its agility. Functional silos slow change down, as they require cross-silo communication and handoffs. Deep hierarchies can reduce innovation. It’s the front line that tends to have the ideas, because they interact with customers; it’s they who experience the pain and frustration of ineffective internal processes. Even innovations formulated at the top of a hierarchy still require information to percolate upward from the front line; this takes time and risks being out of date, as with Napoleon at Borodino.

As we erase the boundary between IT and the business, new possibilities open up for improving the organizational asset. Take T-shaped people, for example. An Agile IT team has skills in coding, testing, and securing—why shouldn’t it also have business skills? These can come from people who have broad technical skills but go deep into a business realm, or people who are deep in a technical area but whose broad skill set includes business savvy. Conversely, why shouldn’t business teams have technical skills?

There is a third intangible asset to consider: the company’s ability to use the data in its databases. There is value in those data, but only if they can be extracted and made available to employees and managers. In the old days of IT, data were used mainly to conduct transactions and were therefore organized into the types of databases that most efficiently supported transactions. But data increasingly have informational value. The agility of your data asset, then, is yet another source of future profits and mission accomplishment.

Let’s say the company can only access its data through reports that the technologists have prepared. The data are then useful, but if employees want to pose new questions to the data, to research new topics, they have to wait until a new report is available. The data can be made more agile by setting up a flexible analytics or business intelligence system so that employees can create their own reports or conduct ad hoc analyses—perhaps using visualization tools or artificial intelligence.

As the cloud reduces the cost of storage, enterprises are able to store lots of data even before they know exactly how they’ll use it. Instead of predicting how the data will be analyzed and organizing it to support those analyses, we can now take the simpler route of dumping all kinds of data into a type of repository called a data lake.

The data can be in virtually any form—data from Oracle databases, ERP systems, internet data sources, scanned documents, and video feeds, for example. Software tools can automatically search through text, determining what sentiments it expresses and extracting relationships between the people it mentions. Machine learning software can even scan images and ascertain which famous people appear in them.

With these increasing quantities of data come questions of privacy and security. What I’m calling the data asset includes the controls the organization puts around its data. This asset is agile to the extent that it both restricts access from those who shouldn’t have it and enables access for those who should.

The IT world has been talking about “big” data for a few decades now. But what I am getting at is that big data has both an immediate value and a latent value. There is what we can do with it now, and also the agility we can build into the asset by making it available in a flexible way to support innovation and discovery.

Each of these three assets—technical, organizational, and data—has immediate value in generating cash flows today, and latent value in generating cash flows in the uncertain future. Together these assets reinforce one another to provide nimbleness that enables organizations to seize opportunities as they arise and to create opportunities through innovation.

The three assets work together in reducing lead times. The organizational asset determines how long the enterprise will spend in planning, formulation, and investment management. The technical asset determines how quickly it can create and deploy capabilities. And the data asset determines how easily it can access the data that those capabilities depend on.

Unfortunately, our traditional IT approach has often reduced the value of these assets. Agility comes from the coordination of the three assets and suffers when there are arms-length handoffs between IT and the business. There are also a few persistent beliefs we’ve held that have worked against agility.

The first is the conventional wisdom that using commercial off-the-shelf (COTS) software is preferable to building capabilities in house. The theory held that building software was risky; it took longer than planned, cost more than planned, and resulted in inferior products. By buying pre-existing products the company could save money, reduce its risk, acquire software that already implemented best practices, and deploy its capabilities more quickly.

But . . . the value equation has again changed as we move into the digital era, where uncertainty, complexity, and rapid change force us to think differently about that tradeoff. To understand why, we have to more closely examine what it is we’re getting when we buy COTS software. In The Cathedral and the Bazaar, Eric Raymond makes the case that with software, its sale value (value as a final good) is much less important than its use value (value as an intermediate good).3

Although we often think of off-the-shelf software as if it were a final good—having the characteristics of a manufactured product like a car—all evidence shows that its value is primarily in how it’s used. COTS software must be adapted to the company’s needs—through configuration, customization, and additional code integrated with it—before it becomes valuable. It must also be constantly changed to keep up with changing circumstances. Raymond points out that:

When a software product’s vendor goes out of business (or if the product is merely discontinued), the maximum price consumers will pay for it rapidly falls to near zero . . . the price a consumer will pay is effectively capped by the expected future value of vendor service.4

He concludes “software is largely a service industry operating under the persistent but unfounded delusion that it is a manufacturing industry.”5 Buying off the shelf commits us to an ongoing stream of payments to the vendor and to higher costs for making changes when we try to do it ourselves. And the vendor’s roadmap for the product is unlikely to match our future needs. COTS products make our IT asset less agile.

What is really happening here is that when we buy off the shelf, we don’t really own the same kind of asset that we do when we build it ourselves. We don’t own the internals of the COTS product, so we cannot change them at will to keep up with changes in our business, and we can’t use pieces of it as building blocks to create other capabilities. Building and buying are not two choices that refer to the same kind of product.

On the other hand, changes in software building techniques have reduced its costs and risks. When we now build software, we do so by incorporating third-party building blocks—usually open-source components or cloud services—that reduce the amount of code we have to write. We organize our code using well-understood design principles and test it using powerful test tools. We build in increments to reduce risk and gain speed.

The balance has therefore shifted to make building more attractive. But this is not to say that COTS is never appropriate. There are things that companies do that are so standard and unchanging that buying software to automate those functions is relatively low risk. Accounting software is a good example; the rate of change in accounting techniques is slow, but accounting functionality and principles remain complex.

A second area where we have often sacrificed agility is in outsourcing the delivery of IT capabilities. In many ways, outsourcing software development combines the worst characteristics of both building and buying. The elegance and simplicity—read, the agility—of the IT asset suffers as parts are created by different organizations. It’s the contractor’s employees who become familiar with the code and are most able to make changes to it. The contractor’s incentive is not to worry much about technical debt, especially since any slowness in changing the system in the future will probably bring more revenue. According to Forsgren and her Accelerate coauthors, low-performing companies are more likely to report that their software has been developed by an outsourcing provider.6

Perhaps the root cause of the COTS and outsourcing mistakes is that we often think of IT systems as if they were products or, as Raymond says, “manufactured goods.”7 We look at our IT asset as a collection of independent products with some glue that binds them together. We then readily think we can buy some of these products or outsource their creation, rather than building them internally.

This is one reason I suggest thinking of the entire collection of IT capabilities as a single, unified asset that lets your company run its business. When you compose this asset from independent products, you get an overall architecture that lacks the coherence, simplicity, and elegance that makes change easier. You can’t reuse pieces from one of these products to create another. Each component product changes independently—there is high overhead in trying to coordinate changes. Simply put, they limit your choices.

The trend instead is to design the entire IT asset as a collection of very small, custom-built components called microservices, each of which can be reused as part of a number of IT capabilities. Just as DevOps lets us manage a seamless flow of capability creation, our IT systems architecture now consists of a seamless blend of components. It has become difficult to say where one product ends and another begins. The digital world is one of continuous, rather than discrete, elements.

IT strategy, then, is a matter of incrementally investing in these three assets—rather than one of investing in projects or products. That older way of thinking led us to make large commitments rather than seeing the value of small, incremental changes to the IT estate. It also led us to ignore the complex interactions between IT systems. Finally, it took our attention off a very important source of business value—the agility of our infrastructure and its ability to meet emerging business needs in a fast-changing environment.

Instead, digital transformation requires you to take a holistic view of your enterprise’s IT and organizational states. When you do, your transformational process becomes low risk: it’s incremental and consists only of improvements to assets you already own.

* Someday, perhaps offshoring will have to be replaced by outsourcing to a retirement community (please don’t steal that idea before I pitch the venture capitalists).