% fortune -ae paul murphy

SAB vs IEED

Although both sample companies discussed so far, IEED and SAB, are start-ups there's a critically important difference between what we know of their IT requirements. That difference amounts to this: with IEED we know what we have to do, but don't know how to do it; while, with SAB, we know how to meet any reasonable set of requirements, but don't know what the actual requirements are.

Thus with IEED we have no idea what the detection algorithms are going to look like and very little trustworthy information about what the instrument data stream will look like -but we do know quite a lot about the structure of the information flows involved and the business processes that will have to evolve to support the mission.

With SAB the situation is almost the opposite: we know a lot about certain key algorithms the company will be using and there are likely to be no real surprises in the data management part of the process, but we're pretty much clueless about the detailed functional requirements.

That difference extends to the financial manipulation side of the two companies: we know where IEED is getting its money, we know about how many people it needs, and we know what its financial agenda is; but we don't know where SAB's founders got the cash, we don't know how big the company will get, and we don't know what the ownership group's long term agenda is - and as frequent contributor Ross44 pointed out that has implications for IT. Basically IEED's founders can be expected to measure IT's success first on how well it works and secondly on what it costs - but that would only be true for SAB's owners if their long term agendas are actually the controlling agendas (i.e. it's their money) and they're are focused on building and operating a successful company.

Those assumptions would typically not hold if, for example, most of the money came from venture capitalists focused on an eventual IPO or if the owner's personal business plans consist of building the company, selling it to a former employer, and buying a yacht to retire on.

As Ross44 mentioned, people who plan to own and operate the company over the long term are typically going to treat IT as a long term investment and value the combination of effective operation with low long term costs over political correctness and low start-up costs. Conversely people planning to sell out, whether privately or via the market, are likely to value low start up costs and political correctness while devaluing long term costs and entirely discounting long term strategic issues like systems flexibility.

In other words the assumptions we make about SAB's owner motivation and degree of control could largely dictate our software choices - because the job to be done can be interpreted in more than one way, and people looking to sell their share of the company want it to look good to potential buyers but don't care whether it really is good or not. To them the system known to be the worst long term choice could be the most attractive simply because it has seemingly low entry costs and is what their buyers expect to find - while adoption of the system with the greatest flexibility and lowest long term cost could raise questions when the time comes to sell.

What's appropriate here, I think, is an analogy to flooring choice during home remodelling. If you're fixing up a house just to sell it, then laminate flooring is an obvious winner. It's really a form of fraud, but it looks good enough to fool most customers, comes in cheap, and the real costs won't show up until months after the house is sold. Conversely, if you want to live in the house for a long time, then engineered or solid floor is the way to go: it costs more and is harder to install to start with, looks about the same, but you get years of wear before it costs another nickel.

That situation does not apply, however, on the IEED side. There the technology challenge dominates: we're working at or past the bleeding edge of what can be done now - and, sure, T2/Solaris looks adequate to the ground side job today and the Cell/linux combinations seems a likely winner for orbital processing - but we don't know any of these things for sure and won't know whether the technology will prove out fast enough to meet our needs until it has, or has not.


Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.