In the discussions last week on governance of information technologies (see my previous post), points were inevitably raised about the specific responsibilities of different actors, none more than the ubiquitous “Chief Information Officer” or CIO.
Having been so heavily involved in semantics for the last years, it is inevitable that I would turn my attention sooner or later to this title: what does it actually mean? or what is it intended to mean and convey?
Ask most people who have an opinion on the matter (and admittedly it’s a rather marginal sport) and they would probably answer that the CIO is the person in charge of an organisation’s information technology infrastructure. It seems a more senior version (or at least more important sounding title) than simply “IT Manager”.
This got me thinking: well, if that is the case, what then is a “Chief Technology Officer”? Are they the same? If not, what is the distinction? And is it important?
I want to argue that they are not the same; that there is much confusion of roles; and – yes – the distinction is important, as I hope to show.
I think that there is a clear distinction between a CIO and a CTO and that it is about time that the distinction is considered maturely in discussions about governance of large organisations. Some internet start-ups (or should that be up-starts?) play around with new titles such as “Chief Wisdom Officer”, “Chief Laughter Officer” or other such amusing and attention grabbing titles. Any serious and mature organisation will expect that the titles of their senior executives correspond to clearly defined and delineated executive responsibilities. CEO, CFO, and COO are the most commonly used and understood. CIO has entered stage alongside the development in the role played by technology in an organisation’s health and development and as such it would seem logical to include that function in the “CxO Suite”. But what exactly does it involve?
If the responsibilities of managing technology and managing information were so clear cut, there probably wouldn’t be such an issue: if, as a manager, you are “only” responsible for the machines, as arbitrary pieces of hardware – with value as physical assets – you would be forgiven for managing them in the same way as you would for any other physical asset, like buildings, furniture and other machinery and equipment. In former days, such a CTO job probably fell under the responsibility of a COO.
Likewise, if you were responsible for the data, information and knowledge that your organisation generates or manages – with value as intangible assets or “know how” – then you would manage those assets too in a manner appropriate, irrespective of how they are generated or kept. Even before technology pervasiveness, this was an important ‘CIO’ function even if it didn’t carry such a title.
However, it is inherent to the nature of “information technologies” that the lines between the two are blurred. “Before IT” (and I know that I’m addressing a dwindling proportion of the living when I say that), organisations managed content in paper files, folders, with filing clerks, documentalists and librarians. As IT starting to encroach into our daily organisational lives, there was a period during which programmers and developers were relatively indifferent to “content” or data – it was the application that was important and emphasis was on doing something to arbitrary data coming in, processing it and pushing arbitrary data out the other end. How the data came in or went out was very much subservient to the needs of the processing. What that data was, was essentially someone else’s issue.
Then came SGML and XML that – by capturing or ‘encapsulating’ data in a structured manner – intentionally promoted the importance of the actual content, allowed it to be repurposed and re-used and gave explicit value to the content by treating that content as distinct artifacts and thus as assets with distinct business value (I actually explore these themes in more detail on my book, Information Architecture with XML, which – although a little dated as regards specific technologies – nonetheless stands the test of time as regards information management).
Despite this disinction between the “contents” and the “container” (the hardware and software that uses, manages and disposes of the content), the term “information technology is still used to embrace both – and the function of CIO generally aligns with that.
And I think that this is wrong. Here’s why.
The way that we manage technology and consider it as a business asset involves a very different skill and set and sense of priorities to managing information as a business asset.
I think that there are two very different and distinct functional roles:
- responsibility for managing information technology as a corporate asset (the emphasis thus on the technology) – this is the function and role that I would chiefly ascribe to a CTO;
- responsibility for managing whatever content runs on that technology, also as a corporate asset (the emphasis here being on information) – this is what I would ascribe to a CIO.
Organisations that are starting the process of migration to cloud-based computing environments are starting to see this more than others, precisely because there are different types of cloud environment and because of the more explicit and logical separation of content from its processing.
An example may make things clearer: take customer relations management (CRM). When the whole of the “CRM system” is managed and hosted in-house, “it” can be seem wholly as belonging to the IT department as a service. The IT people decide on which software to buy, lease or build; and which hardware to use and how it is configured; and how much the whole thing will cost to deploy and maintain. If “users” (and see my caveat on this term) are unfamiliar with the software or find it difficult to use, they were criticised as being stupid and the IT gods wend unquestioned.
Once CRM is ‘outsourced’, or leased to an organisation from a third party, offered as “software as a service”, the dynamics change radically. The service is chosen based on cost, usability, efficiency and effectiveness. As a client you don’t have to worry about the technology infrastructure but neither do you get a say (except through the power of the purse) about how that technology is configured or deployed. You worry, obsess even, over where “your” data is stored, managed and accessed and by whom and according to what rules and processes.
More than that. It actually provokes – or ought to provoke – a thorough re-assessment of who is actually responsible for what. And that’s not as easy as it looks.
It may be easy enough to argue that “post cloud migration, we don’t have any technology to manage as such, so we don’t need a CIO any longer” but many technology issues still remain. What (client) devices are your staff using? How is content secured, both in the cloud and on local devices? How is authentication and authorisation of access performed? By whom? How and where is the content actually ‘domiciled’ and hosted? Some of these may be broader management and governance issues but some are clearly technology ones.
It isn’t so clear cut either when your “content” itself includes home-made software, business processes, models or schema that are not strictly speaking content but are nonetheless business assets and need to be managed as such. So who is responsible? The CIO? Should there be a CIO as well as a CTO? Where do you draw the line?
What I have found useful is to think about what are the distinctive roles of each which – even if performed by the same person as part of the same, rolled-up function, can nonetheless help separated out into distinct responsibilities. Doing this makes it much easier for everyone to understand the complexity of what is being dealt with and ensure that the right questions are asked by governance bodies charged with oversight of an organisation’s “IT”.
The two diagrams below are from a slide deck that I had prepared for our work last week in Tokyo and in which I highlight what I think are the main differences between a CIO and CTO function.
My conclusion at present, for what it is worth, is that while the two job profiles are very different, there is no clear demarcation between the two: what is important is that a distinction be made in terms of the types of assets being managed and the relative importance of them to an organisation. If your business is building software, you would treat the software builds as valued assets but any data generated or used by the software (in testing, for example) would be considered irrelevant. On the other hand, if your business is tracking stock information, the information is a valued asset whereas the software being used may be secondary (as long as it performs according to your needs). As the diagrams show, the transition is gradual and each organisation needs to determine how much of which role is necessary for their own good governance.