Tuesday, January 13, 2009

Traversing the Stack



Today I was in a meeting where project prioritization for 2009 was being discussed. There were four projects that are looking for funding in an environment where capital is not as abundant as it was prior to the economic meltdown. There are already a lot of projects approved. Several of them have to do with infrastructure as varied as data center requests to integration engines to desktop virutalization. They wanted to better understand these requests to see if they could be re prioritized as well.

Infrastructure is tricky because it's the foundation on top of which everything else runs. It's "lower in the stack". That's geek code for "close to the machine" and "close to the machine" as explained in Tracy Kidders The Soul of a New Machine. I had a computer science teacher once point out that the communications and hardware ancestor for all computers was the telegraph. It was an electrical device that communicated information by changing between two states, off and on, so it was binary. All you needed to know about the state of a telegraph at any point in time is if the wire was "hot" or "cold". A computer is like this too and at the lowest level, close to the machine, the state of a computer can be described in terms of the state of it's circuits signals and the contents of it's memory, registers and cache.... The next layer "up" in the stack is machine language, the binary codes stored in memory that are decoded by a CPU to trigger the different circuit signal states. The next layer up from that is assembly language, pseudo human readable codes that correspond nearly one to one to machine language. The next layer up is a compiler that takes a conceptual language like C or Fortran and compiles it into assembly language to be assembled into machine language to be decoded into circuit signals. Every layer up takes a set of hot or cold signals on a set of wires and translates them into something more and more understandable to people. These are the layers of abstraction that turn what are fundamentally electronic abacuses into clinical applications that might make sure I don't get a transfusion of the wrong blood type.

Infrastructure is lower in the stack than applications so describing it's value in business terms is more challenging because it isn't the technology touch point that a nurse uses to make patient care happen. It's out of sight/out of mind (unless it fails!) so requested investments seem a little bit suspect to the lay person. It's also EXPENSIVE and once you buy it it needs to be upgraded, updated, maintained and replaced.

That's where the foundation analogy fails. Usually a house's foundation is poured, cures and doesn't ever have to be touched again. Imagine that you constantly improve and update your foundation or else parts of your house might come undone. If you got behind you'd have to run around putting braces and temporary fixes in place to make sure you had a place to live! Then imagine that every time you mentioned the work that needed done your spouse suggested buying say, a new kitchen appliance. Depending on your relationship that might be a tricky conversation!

So over the course of the next week I'll be preparing for exactly that same conversation with our hospital leaders to help them traverse the stack and understand what will happen to that kitchen remodel we worked so hard on if the foundation doesn't get re poured.

No comments: