Isn't it time for CIOs to more consistently attempt to learn from, rather than repeat, their failures?

Sydney-based information technology and services consultant and contractor Chris Jones certainly thinks so.

Jones says the enthusiasm for off-the-shelf products to solve immediate business process issues seemingly shows no end. As cost effective as this might be, Jones says, it is placing the cart before the horse in that it attempts to get a generic solution (or even worse, another company's solution, framed as a general solution) to solve a particular business or corporate need. The end result is typically project blow-outs, cost overruns, time exceeded, functionality not provided, expectations not realized and elevated risk levels. "What is needed is a return to some of the basics: development of strategy (that is aligned between business and IT), joint (business) product and (technology) road-maps, architecture," Jones says. "We seem to have gotten caught up so much with trying to solve yesterday's problems (in some cases when we knew them a year or two ahead), that we accelerate the creation of modern legacy so fast, we have no idea how to maintain or control, leading to more issues, higher support overhead, increased risk profile, upset business, unhappy customers. "Maybe it's time to try and catch our breath a little, and look forward, whilst remembering what we have and where we have been. Otherwise, we are bound to repeat what George Bernard Shaw said: 'We learn from history that we learn nothing from history', and George Santayana: 'Those who cannot learn from history are doomed to repeat it'." And on the subject of failures, Jones asks: If there are so many architects and equivalents around, why is IT so immature? Why is it so hard to get Business and IT to work together? Why isn't IT brought to account honestly and transparently for the provision of business services?

One problem Jones sees lies with the connectivity of Architecture to the other processes and/or domains. Unless Architecture is solidly tied solidly into strategy (business and IT), it floats like a ship in the ocean without a rudder, he says.

"Another is how to establish, quantify and validate business service requirements: the long sought after business services catalogue. If done accurately and honestly, this can be used to define applications, information, SLAs and even governance/audit requirements/points. This also can and should be used to establish IT costs.