I was speaking to my friend Andrew this weekend, who is just completing an MBA. In one breath he was saying that there was no “formula for business” because each business has been created in a unqiue set of circumstances, and so evolves as such; in the next he asked why any technology project ends up doing something so different to anything that ever went before it — why can’t technology provide standard solutions to what must be common problems?

Although I was tempted to turn his own words round on him (”because every technology solution has been created in a unique set of circumstances”) I did struggle to answer this. Equally, he didn’t claim any magic solutions. In fact he highlighted a general lack of IT awareness in business. He remarked that if an team of lawyers and accountants were overseeing an engineering project they would never allow anything so ridiculous as erecting a 1000ft girder by securing it only at one end — yet they are quite capable of making equally ridiculous suggestions on IT projects… and no-one finds out until too late.

So here’s a belated attempt to answer his question: why does any technology project end up doing something so different to anything that ever went before it?

The formula

I think the answer is that technology tends to be very complex, and while there are many components which do standard tasks in standard ways, the nature of business and the software itself means that they can be put together in myriad different ways. In other words, while there may be a technology which manages employees’ salaries, there probably isn’t one which manages employees salaries and which can be administered internationally, and takes a feed automatically from the Planning Department’s monthly forecasts, and which allows us to set up limited short term access for our temps, and runs on the hardware platform strategically chosen by the IT Department to take us through the next 5 years.

The result is almost always a system which as a whole is utterly unique, even though the individual parts may be well-known. Or to put it another way:

Business + N x Technology = Complexity

Business plus many interconnected technologies is just asking for trouble.

The consequences

There are several corollaries to this.

One is that the “glue” which links these standard components together can itself be very complex. It may in fact be bespoke and/or complex software in its own right. That’s because while technology A and technology B might be widespread, the occurrence of both technologies together is much smaller, and the coverage of both technologies working together in exactly the way you want is often miniscule. It’s likely that there are so few people using both these technologies together in exactly the way you want, that it’s not practical to find an existing glue which you can use. So you develop your own. (And for the mathematically-minded, as you bring more technologies together the complexity increases not by an order of N, but by an order of N². That’s the number of possible links between N points.)

Another corollary is the variance in that word “business”. There is infinite variety in business situations, and in the human drivers behind them. That means there are not just many drivers (cost, staff skills, deadlines, competitor pressures) but uncountably many subtleties in how they might be balanced out against each other.

Finally, there’s something which this formula doesn’t capture: time. Systems which often start out simple can easily end up being very complex. One of the reasons is that no-one knows future requirements. A small simple hack introduced in hurry, or to address a small and simple need, can quickly become a core part of a much larger system. Suddenly other systems depend on it, and at any one time the short term option (to work round it, leading to higher long term costs) outweighs the long term option (to spend more time and money now so that costs are reduced long term). In the worst cases a system may have more money pouring in to support its quirky hacks than is supporting the rest of it.

Some examples

As a sign-off, here are some things which I’ve encountered first hand, which have meant that a technology solution had to be different, and couldn’t (or didn’t) come out of a box:

• The developers needed to create a new e-commerce site for a high street retailer, and there was an existing out-of-the-box e-commerce solution. Unfortunately the result would have created a website which didn’t fit the designers’ designs, informed partly by the retailer’s brand image. There was not sufficient customisation options. So the developers built their own e-commerce system from scratch.
• The developers needed to build a second e-commerce site, for another high street retailer, in exactly the same business as the first. Now you would have thought that since we already had one such system we could have just changed the look and feel for the second retailer. And indeed, this was the theory… but inevitably practice turned out to be different. It so happened that the second retailer wanted “a few small changes”. These grew as the project progressed, and before we knew it the underlying technology had been radically changed.
• A company wanted to set up a small website with a very well-defined set of functions — in this case, for publishing. They also identified an off-the-shelf software package which would provide the exact functionality, and had an interface which the back-office team were familiar with. But neither the software nor any of its competitors supported a feature which the IT department required — that it be backed by a test system which would ensure any work could be tested before being published. So the IT department spent weeks amending the off-the-shelf software to support their requirements.
• A software developer in a large company was tasked with creating a particular system for the company. He was left alone to make decisions. One such decision was to use a database which — in isolation — might have been a good choice for the task in hand. But it just so happened that no-one else in the company was familiar with that particular database. When he left the company his former colleagues found they didn’t understand the resulting system.
• The developers needed a simple templating sytem, which took data from a database and displayed it on a web page. This is a common requirement, and at the time there were several such systems available, which fell into two camps: commercial systems and non-commercial systems. Unfortunately the boss of the company vetoed all these. The commercial systems were vetoed because he didn’t want his company’s intellectual property to be in hock to another company. The non-commercial systems were judged by him to be too immature. The company spent months developing its own system. No-one could be employed who already knew it — they had to be trained internally — and by the time the system was mature the rest of the world had coalesced around other technologies.
• A company needed to receive personal customer data collected on its website. The natural way would have been to set up a secure Internet connection from the company’s website to its office. However the company didn’t have an appropriately secure connection already in its office, and setting one up was considered slightly more costly than the alternative: the data was copied weekly onto a large tape, which was biked round to the office.

In any of these situations no-one was bad, or wrong, or stupid. But the result was always a system which — one way or another — was unique to that organisation.

I think the answer is not to seek to eliminate the complexities, but to learn how to manage it.

Tags: technology, business