All Posts in Technology

|In: Industry Commentary|Last Updated:

Microsoft could have prevented this mess.

No, not by buying Lehman Brothers, pumping cash into Fannie and Freddie, or counter-lobbying for increased regulation. An Excel model of the financial sector would have done the job — a model of the various financial instruments used to create the trillion or so dollars of sham wealth that vanished last week.

An accurate model would have flagged the whole mess as a circular reference.

I can’t prove this. I’m pretty sure, though, that a whole bunch of financial instruments owned by the failed former financial titans included each other in their portfolios — fundamentally no different from a spreadsheet that has the formula =B1+1 in cell A1 and =A1+1 in cell B1.

Their assets increased every time they pushed F9.

In addition to possible circular references, inside this crisis are lessons — not only for the future of the financial sector, but also for IT organizations that want to prevent problems instead of dealing with frequent crises. Among them:

Excessive deregulation is as bad as excessive regulation. Maybe worse. In spite of all the bleating about the awful bureaucracy of it all, I know of no company that failed because of Sarbanes/Oxley, PCI, HIPAA, or building codes.

Lesson for IT: When developing IT policies and procedures, establish a healthy balance between a free-for-all and excessively tight controls. As is so often the case, danger lives in the extremes.

Wishing doesn’t repeal arithmetic. The core premise of recent financial instruments: Aggregating a thousand loans, each with a one percent probability of failure, creates a very safe investment.

Risk calculations don’t work that way, as anyone who has taken Statistics 101 knows. The only difference is that with one item a one percent chance of failure constitutes risk. With a thousand, it’s nearly certain that ten or so will fail.

Lesson for IT: Entrepreneurial start-ups live on risk. They run thin, and hope nothing goes wrong. That only lasts so long — after awhile, hope becomes a very bad strategy for managing risk.

No matter how implausible, logic that rationalizes what we want to be true is compelling. Conversely, no matter how airtight the logic and evidence, anything that debunks what we want to be true is implausible. See “wishing doesn’t repeal arithmetic,” above. It’s one of the two reasons anyone believed this nonsense. (The other: The greater fool theory — I don’t believe it, but as long as I can sell the junk to a greater fool before it falls apart, I don’t care.)

Lesson for IT: Just because we’re technical doesn’t mean we’re immune. We’re just as vulnerable as anyone else.

The bigger we let companies get, the more unstable the economy becomes. When small companies fail, policy makers see it as capitalism in action. When AIG was about to fail, the alternative to Paulson buying it was serious risk of total economic collapse.

Maybe unfettered mergers and acquisitions weren’t such a good idea after all. Size might have improved efficiency and economies of scale, but it also decreased overall economic stability.

Lesson for IT: This is the theory behind using distributed systems instead of mainframes — each component has a lower level of performance, but the impact of one component failing is much smaller.

The desire to blame is stronger than the desire to survive. We got lucky — Paulson and Bernanke took care of business, including themselves out of the blame-fest. They might have been the only two in Washington who did so.

Lesson for IT: Same as the lesson everywhere. Blame doesn’t matter. Taking responsibility does. If the root cause of a problem happens to be a personnel problem, take care of it after you’ve dealt with the crisis.

When principles and practicality conflict, it means the principles aren’t practical. I’m not the first to point out the irony of a Republican administration effectively socializing the world’s biggest insurer and mortgage companies. Irony notwithstanding it was the best available choice.

Lesson for IT: Be as principled as is practical, and no more so.

And finally, if you think you’re smarter than your predecessors, you’re probably more foolish. To prevent a recurrence of the Great Depression, the Glass-Steagall Act kept investment and commercial banks separate, creating a firebreak between the high risks of the former and the requirement for safety of the latter.

We’re approximately the length of the Roaring ’20s after the act’s repeal. Draw your own conclusions.

Lesson for IT (and everyone else): Before you tear down what your predecessors built, be certain you don’t need it anymore.

Comments

|In: Industry Commentary|Last Updated:

Imagine corporate headquarters is an operating system, each business unit is an application, and the departments within corporate and the business units are threads.

If you can successfully imagine this, you have some nerd in you and fit right in here at KJR Club Central. But never mind that. It’s time for some serious analogizing.

Next, imagine corporate puts the nerds in charge of organizational design. Working the analogy, the nerds will list such issues as:

  • What services should be provided by corporate and which should be left to the business units.
  • How corporate should allocate resources among the requesting business units.
  • How business units should request services from corporate.
  • How corporate should evaluate requests and set task priorities.
  • Where business units must conform to centrally-established standards and where they are free to make whatever decisions they like.

These are standard information technology design issues, translated into business terms. Chalk one up for the nerds.

Since both information technology and businesses are systems, it’s unsurprising that they have similar design challenges. Because information systems are processed in silicon while businesses are run by human beings, it’s a good bet those questions will have different answers.

For example: In an information system it usually makes sense to build sharable services into the operating system, increasing consistency while making application development easier. If too many applications are open, demanding too much in the way of system resources, the task scheduler and virtual memory share available physical resources among the applications according to a parameter-driven algorithm.

If, on the other hand, too many departments in too many business units demand more of corporate shared services than corporate shared services can handle, the situation is very, very different.

First, system memory and CPU cycles can be allocated to any and all tasks with equivalent efficiency. The same can’t be said for the staff at corporate: Generic employees can’t move back-and-forth between Accounting and Marketing to accommodate shifts in demand.

Second, the question of how to allocate system resources is algorithmic. The question of how to allocate business resources is, in contrast, algorithmic only in theory. In practice it is inescapably political. The word is governance. The specifics are budgeting, capital project evaluation, and the day-to-day under-the-radar exchange of favors.

And third, in business, questions of consistency are more ego-laden than in information systems.

While it’s surely true that (for example) some applications generate bursty network traffic while others transmit steadier streams of data, and each would benefit from a network interface tailored to its unique pattern, few would argue that each application should roll its own.

Compare that to a business — maybe one that has one business unit that sells through an ecommerce retail channel and another that sells the same products, in quantity, to business customers. They can make a very plausible case for owning their own marketing departments, probably independent websites, and possibly even their own distribution facilities, since fulfillment (pick, pack and ship) has very different properties from logistics (pallet- or truck-level) shipping.

Which is why the idea of hypervisor as operating system makes little sense (“Microsoft, operating systems, and organizational architectures,” Keep the Joint Running, 8/11/2008), but the organizational equivalent — decentralization — can be exactly the right choice.

There’s another argument in favor of decentralization, and that’s speed. Every good project manager knows the difference between putting tasks on a project plan and putting them into a request queue served by people who aren’t on the project team. Being served through a request queue causes unpredictable delays.

Whenever a business unit depends on corporate to get something done, it’s in the same situation. It’s a built-in trade-off between the more economical choice of shared services and the more nimble one of owning your own resources.

Business design and system design do have this in common: When an information system responds slowly, end-users and technical professionals frequently confuse unnecessary services with important but badly written services that use more resources than they should. And, for that matter, with well-written and important services, installed on an underpowered machine.

The same is true of organizations. The managers and employees in business units frequently complain about corporate, much as the Taxpayer’s League complains about the federal government: “Everyone knows” corporate/the government wastes a lot of resources without anyone knowing whether the waste comes from frivolous services or from important services run inefficiently.

Or, for that matter, from important services that run efficiently but we’d rather avoid the bill.

Comments