This question is always flying around when you start with Test Driven Development (TDD). It can come from two different sources : either we didn’t followed it “by the book” – and it punished us, or we are trying to use TDD on an existing code. For both cases, you will have to rethink your design.
(more…)

The Information system is a corporate asset, providing a competitive advantage, seen as a critical commodity.

What matters with Information system? Is it an asset or a commodity?

IT as an asset

A cross-business lines customer database gives a competitive advantage in cross-selling operations. A exotic trading tools brings to the bank new hedging opportunities.

Many examples illustrate the business advantages of the information systems.
IT as a commodity

For many business, information management and processing become vital, like electricity, capital, etc. The Information system has to be robust and cheap.

For example, back office banking system have to be cheapest as possible to allow low operating costs. Many examples illustrate the advantages of a low cost information system.

Actually, The IT is both an asset AND a commodity; each application of the Information System may be either a commodity or an asset.

The principle of the pyramid

How to use the pyramid?

While you are defining your IS strategy or benchmarking your IT, remind of the pyramid of applications to be sure to have the right vision and the right key drivers.

Un version française de cet article est disponible ici

This is the story of a project, neither more complex nor simpler than others: an application that communicates with a database and two other systems. Something quite mainstream from a technical and architectural side, something standard from the management side: all must be done for yesterday and there is a lot to do…In short, “it’s gonna be hard” as often say the developers but nobody screams it out too loud.
So we build the team. 40 persons are staffed, people are specialized. The teams are organized in pools, so that a kind of contract is setting up between the different pools. Each pool is responsible for treating certain kind of demands. A flow of demands appears. Certain pools are under pressure and become the bottleneck: a stock of demands is created upstream whereas the downstream pools are waiting…Therefore and for these under pressure pools, important things are becoming urgent things. Choices must be made among urgent things to treat the immediate ones. Task switching is becoming the way of working and in the end, the flow slows down.

Then the deadline of the “go live” comes: it is in two months. The user acceptance tests are just starting but have been delayed by the tedious and painful integration between the different components. Maybe the built contracts between the teams have complicated the integration: some mandatory parameters are missing, the dates do not respect the proper format, the error codes are partially interpreted…
In any case, the user acceptance tests detect more bugs than what the development team can resolve and all is not still tested. (more…)