As enterprise architects we often find the solution to major business problems using bespoke development. That seems like a curious choice given how often bespoke development fails to live up to expectations or even just fails. No matter how we approach that bespoke development — internally developed, outsourced or configuration of an enterprise-class system — failures can and do happen. The most obvious examples are the number scandals surrounding government IT projects that burn through billions of pounds but deliver nothing useful.

There are lots of reasons that a major bespoke development can fail but, as it’s the job of an enterprise architect to improve capability and oversee that development, surely some of the blame must lie with the architect? That somehow, the architecture wasn’t right which led to the bespoke development failing?

Yet giving the same architecture to a different set of developers can lead to an entirely different result. Sometimes just a change of project or programme managers is enough to make the difference between failure and success. So is the problem the architecture or the personalities? Having seen both good and bad development, there’s a good chance that the answer is both.

Perhaps the biggest shortfall of many architecture methodologies is that they fail to communicate the philosophy of the architect. While we build elegant structures of artefacts that are designed to be robust, we need to remember that there are others in the programme who need to understand the philosophy. Without the philosophy, there is a risk that they will misinterpret the architecture and its intent.

One of the most successful metaphors when working with development teams is to explain that we don’t want to build a Ferrari, we want to build a bus. There are going to be lots of people using a system and there is no room for something highly strung. The metaphor works just as well if you replace the word bus with just about any type of object that needs to take a beating and still work. So it can be tailored to any environment or industry. Here at ClassiQ, we call it the Routemaster Philosophy after the famous bus.

Most organisations focus on the functional requirements to get the software they want. After all, they describe what data the software needs to process and how. However, the whole design and development approach may well change if the development team understands the Routemaster Philosophy.

Ask a development team if their software is going to be reliable and they’ll cheerfully point out that the QA team is there to make sure of that. However, the bespoke development itself is only part of the stack. It almost certainly rests on all kinds of middleware. The choice of stack tends to change significantly when the development team follows the Routemaster Philosophy.

Essentially, the whole thing can be described as a set of non-functional requirements that are appropriate for all development work. Metaphorically, if there are lots of passengers, there should be lots of buses, not one big bus; people will be getting on and off all day; it must be reliable; it must be difficult to break and able to take abuse; it must be easy to maintain; if part of it breaks, as much as possible of the rest should carry on working; a replacement bus should be available as quickly as possible; and so on.

All of these things become intuitively obvious when the development teams understand the Routemaster Philosophy. It means they interpret the requirements differently. From an architecture point of view, it improves the chances of getting something you can use to get from one process to the next.