Technology Watch, why bother?

The Data Room is about to release its 1999 Technology Watch Annual Report. Editor Neil McNaughton runs through some of the rationale behind technology watch, and in particular tries to get to grip with the thorny question "how much do you need to know."

In this world of ‘buy not build’ and massive layoffs it is quite unfashionable to claim an interest in technology. Knowledge Work, Business Process perhaps, but C++?, Java? – are you kidding? A little knowledge of either of these is a dangerous thing indeed – and may result in your getting ‘restructured.’ As a technology watch (TW) company, we are uncomfortable with this radical view of the world. But it does raise the question – how much does each member of the organization really need to know about technology. In other words, should the CEO ‘do’ C++?.

S Curve

One popular paradigm for technological evolution is the S Curve.

A you can see from the figure above, the assumption here is that a given technology has a flat lead-in – when the ‘early adopters’ leap in onto the ‘bleeding edge’. Then a steep part of the curve where everyone jumps on the bandwagon. And finally a flattening off as maturity is reached and only a few old diehards flog the dead horse. The S-Curves interlink and ‘build’ on each other – progress being a one-way trip – onward and upward.

stone age

A counter example to the ‘fast-forward’ view above is evident in HTML, which should by rights belong in the IT stone age. HTML has nonetheless created the biggest IT revolution of all time – the web. Similarly, the <tagged> data formats of XML are fuelling the e-commerce revolution, and are set to resolve many niggling residual issues of HTML documents such as universal formats for bitmap and vector images. Now these two powerful new technologies can hardly be said to have ‘evolved’ from arcane predecessors such as client/server and object middleware! They are more like throwbacks. Which leads me to an alternative representation of the S-Curve shown below.

Here we have some technologies (notably ASCII) living more or less for ever, while others may fail and return later in another guise.


Technologies do not really build on each other – they can co-exist over long periods of time or come and go. Old technologies can come back with a vengeance as with HTML. But new technologies may have several bites at the cake. The object database is a case in point with early failures of Epicentre on UNISQL, but with some real money being bet today on Oracle 8i. Technology watch is important because of this. You never really know where the next ‘key’ technology will come from.

core competence

We are still a long way from the buy not build ideal and in the meanwhile, core competences such as UNIX scripting, SQL and VBA can be major added value activities. You need to know what to do when and where and technology watch allows you to steer a critical paths through the IT maze. So OK, the CEO may not really need C++, but if you don’t know what the options are, then you won’t have an IT strategy, there will be no fixed points and every vendor will fill your shop with their own, non interoperable, isolated tools. Even if you really do buy not build – then you need to keep up with developments to ensure that the technology you buy is current and viable.

Click here to comment on this article

Click here to view this article in context on a desktop

© Oil IT Journal - all rights reserved.