Information Age (IA): You have one of the most high-profile CIO jobs in Europe. What do you see as your core role?

Dr Sinclair Stockman (SS): First, to deliver continual transformation of the company at pace. Second, to ensure that the capability that we have currently works. Third, that the investment in technology is fully aligned and optimised with business strategy. At one stage the

CIO was part of the strategy team, but now the role is more about driving business change. As well as having overall responsibility for systems across the company, I am also directly responsible for a number of our major change initiatives.

IA: What is the key focus of those change initiatives at the moment?

SS: In the way that communications switches are becoming computers embedded in the network, computers are becoming information switches – their job is to manipulate, translate and then switch information into another context. To enable that, one of the key goals that we are pursuing is to fully integrate the architecture of our systems and technology. To do that, you have to ensure the integrity of the architecture and you have to continuously manage complexity out. Left to their own devices, legacy systems get more complex but if you fit them within an overall architecture then you can control and exploit them.

IA: How are you going about that?

SS: We are taking the CTO team and the CIO team and we are sticking them in the same space and getting them to have one meeting rather than two for their architecture work. And then what you do is get them to focus the architecture work on problems rather than domains.

IA: Have people found that a liberating process?

SS: For some people that is a liberating experience. For other people it is frightening. I think what it does do is throw up a challenge.

Where we are now with information technology is back in the early 80s. Back then, in the days of software engineering, people could not only write code, they understood what was behind the machines. They understood what a PCB was, what microprocessors were, and from that they were able to develop various solutions. But over a period of time, computing became so complex that we put a physical separation between the hardware boxes and the software boxes. It was around the same time that the discipline of computer science died.

But now today, particularly in a large distributed environment such as the communications world, you need to understand the nature of the device and how that device communicates – say via a WiFi interface, down through a pipe into a computer somewhere else where it manipulates information, fires off processes in maybe one or two different places, comes back with a result and then delivers that to somewhere else. You have to understand how you monitor that, the nature of the services possible, what could go wrong in that world, and what needs to happen to make it all work. In short, you need to understand something about information systems, about information, about technology and what it is capable of, and about the topology of the system.

A popular issue at the moment is web services, which has a lot in common with the way that hardware used to be developed. The expertise was understanding the capability of the components, understanding which multiplexer worked with which board in which position. The role of the software engineer now is to understand the capability of the objects used and how they integrate with each other. What does a mediation system do for an IP network? What does this box do that is going to interface with it? It is to understand the capability of the hardware, the software and the communications components that make up the overall solution.

The challenge is that there is a whole generation of people who have been brought up largely in the world of wonderful lifecycle-type models. Well it’s not like that anymore. The way you do software engineering is that you don’t start with a blank sheet of paper every time. You actually have to come with some knowledge. In this world, the role of architecture is becoming very key.

IA: Does a unified architecture mean a more unified supplier base?

SS: You need to rationalise your supplier base and you need to understand sources of complexity. One big driver of complexity is uncertainty. If you don’t know exactly what you are doing, you start off doing one thing, then you have to change and do something else. Trying to be too generalist also adds to complexity – trying to take something that wasn’t meant for the job and using it nonetheless. But one of the biggest causes of complexity is the refusal to take decisions.

As part of the engineering and design process, you develop an architecture that gives you a framework within which you make decisions. Your knowledge then tells you what the technologies can do. You apply that knowledge to solve a specific problem, and to solve a problem you make choices. If you avoid making choices or you aren’t able to make very good choices then you end up with a very complex solution, and I think one of the big challenges for the whole industry is how one develops the type of skills that are needed in this new world of web services and highly distributed systems – systems that support a high degree of interaction with the customer base.

Software engineers have been used to designing systems for companies that work within processes. Life doesn’t work in processes, it is much more random. Understanding how customers will exploit technology is a massive challenge.

IA: Do you think the cost constraints many companies are currently working within are good for that challenge?

SS: Yes I think they are. I think writing software became so fashionable that everyone was doing it. People stopped using their brains and just churned out code. Now we are saying the only reason you are doing it is for the business, and it has to be efficient and effective.

For me to be efficient is about your cost of production, the cost of running stuff. Being effective is about producing something that is actually of some use to the business. A sales system that doesn’t help anyone sell anything, even if it has been developed in the most cost-efficient way in the world, is still completely ineffective.

I think the focus on efficiency makes you think about the nature of the types of solutions you build. “Having built this, I may want to re-use this in the future. Actually, wouldn’t it be good if I could make use of components that already existed and, if I could do that, that would allow me, first, to deliver for less cost and, second, deliver it more quickly, because all I have to do is the integration.”

Web services from an architecture point of view can give you the same sort of productivity increase as third, and fourth, generation languages gave you over assembler and machine code – it’s a massive jump.

IA: In this on-demand, web services world, what are the CIO’s core skills? SS: First, understanding the business priorities, and then the ability to map those business priorities onto the system capability. It is also very important to be able to communicate the art of the possible. Part of my job is to think about the services and products my company can offer as a result of technology advances and to think of ways to make it easier for people to work. You need to understand what the points of competitive differentiation may be in the future and then plot intersect strategies to that.

Another big challenge that often gets overlooked is understanding what you have to turn off. A really good measure of progress in information system transformation is what you are turning off rather than what you are turning on. If you are generating a whole load of new systems and you are not turning anything off then your world is becoming more and more complex, and that just adds costs. You live under an illusion of progress.