David has an impressive trackrecord in this sphere, having set up the original content managed site for Harvard Business School almost ten years ago. At the heart of his talk was an exploration of two different approaches to software projects in industry: the classic large-scale, big impact approach on one hand and the gradual, Japanese Kaisen style on the other. His message was that the second method actually works, and Drupal is a software platform that fits with that approach.

Developing the idea of two approaches to software development, David explored the underlying philosophies of both. The classic approach aims for step-change with a software introduction leading to a major change in process or profit. Introducing the new system is typically disruptive The gradual approach aims for incremental change with minimal disruption. The classic approach mimicks traditional competitiveness theories such as the way to grow is change by a takeover or vertical integration. In practice, the profitability curve when making these step changes usually shows that profit drops before recovering to a level somewhere below what had been predicted before the change. On the other hand, a gradual approach avoids major steps but tries to achieve a steady growth by minor changes to the existing system such as inventory reduction or feature enhancement.

David used the example of General Motors' project in the 1980s to switch to using robots for auto manufacture as the classic 'big' IT project that goes horribly wrong. The project costs spiralled to $45 billion, which at the time would have been enough to buy both Toyota and Nissan. Company profits dropped drastically. Meantime Toyota continued with its programme of incremental improvement, investment in its people and its technology partners, and a long-term business strategy. Over the intervening years through to 2005, Toyota outperformed General Motors, Ford, and Volkswagen.

He went on to use another example from the Japanese banking industry, looking at the Long Term credit bank of Japan. The LTCB collapsed in 2000, exhibiting many of the characteristics that would later appear in Western Banking such as huge over-investment in high-risk lending decisions. Following the collapse it was taken over by the Japanese government before being sold to a venture capital group that relaunched it as Shinsei Bank. From the start, Shinsei exhibited the characteristics of the gradual or 'path' based model rather than the big step-change. It focused on the needs of existing customers, focused on small, experimental 'break-out' initiatives for new stuff, and used its very limited capital base as both rationale and driver of 'small' iniatives - faced with reality of not having money to burn, it was left with the need to make small-scale experiments. In implementing this approach, Shinsei emphasised modularity, rapid development cycles, and progressive displacement of existing systems - underlying all of these a principle that they should find the simplest solution that worked. Applying modularity, Shinsei had an aggressive policy of outsourcing development of various components/modules to a number of partners in South-east Asia, so the outsourcing policy both reinforced the modularity requirement, in enforcing the need to push parcels of work to different places, and also protected the business by decentralising the software development.

Taking these examples and applying them to the issues for the Business School, David made the case that the examples demonstrate alternative principles both for business in general and software development. As the future is constantly uncertain for software development, having some guiding principles makes sense, and the principles he identified that both derive from these examples and make the case for Drupal are:

aggressively open architecture and standards

modules that are bolted together not welded

flexibility as a necessity

vendor independence

development guidelines

continuous improvement

reusable tools all web based

rapid prototypes

It's these principles that led the Said Business School to choose Drupal, and interestingly they echo many of our own experiences. Time and again we find that these simple ideas, and the ability to take an incremental approach that comes with them, lead to more successful projects, bringing better business value to the client.

We don't just use Drupal because we like it, but because this approach to software development is fundamentally sound, and far more likely to deliver effective results.

We’re Code Enigma

We’re one of the most experienced Drupal teams in Europe, best known for our work on large, technically challenging projects for all kinds of clients.

Our team is passionate about Drupal and open source software. Our whole company spends at least four weeks per year working on Drupal modules or other open source projects. We’re also strongly committed to putting design first, taking a mobile-first, content-out approach to creating websites. This ensures that the sites we build combine the power of Drupal with best practice design and development.