IT: to protect and serve

The motto "to protect and serve" is a good one for IT. OK, "to protect and serve" has acquired some negative baggage but the US police slogan still resonates as far away as where I live on The Last Rock On The Planet. There seems to be this expectation that IT exists only to create new IT in response to the demands of the business. It's not true.

The Finance department doesn't exist solely to find the money for whatever the business needs ("serve"). The Finance department also exists to look after the health and safety of the organisation's wealth ("protect"). Sometimes the Finance department will resist new initiatives simply because the organisation can't afford them. This then becomes a decision escalated to the Executive or the governors (the Board) to decide whether to proceed against the advice of the CFO.

In exactly the same way, the Information Technology department exists to protect the IT interests of the owners of the organisation whilst also serving IT's customers and users. The two don't always align. The current fixation on customers - the Cult of the Customer - is wrong and dangerous... but that's another blog post. IT is entrusted with custody of the organisation's IT assets. These include:

  • the information itself: its confidentiality, integrity and availability
  • the investment in existing systems to manage, support and use that information (people, processes, hardware, software, connectivity, suppliers...)
  • the capability to deploy new or changed systems: architecture, analysis, design, development, deployment

(Did I miss any big organisational IT assets?)

Sometimes it is not in the best interests of the organisation to abandon those investments or to increase the risks to the confidentiality, integrity and availability of the information, in order to meet demands for new IT from the customers. In that case IT should resist (advise against) the change and the decision should be escalated to the Executive or the governors (the Board) to decide whether to proceed against the advice of the CIO.

As Steve Romero said recently

IT should not be accountable for approving the building and use of IT systems and IT solutions, the business should – in partnership with IT.

The key part of that partnership is consultation: IT are or should be the experts who provide advice on IT, just as the Finance department provides advice on money.

Finally, it is also the role of Finance and IT to provide delegated governance fulfillment: that is, we exist to ensure the directives of the governors (and the resulting directives from their delegates, the Executive) are understood and complied with. It is emphatically not our role to grovel at the feet of the customers regardless of any negative consequences for the organisation. Sometimes we have to be the cop.

Put another way, IT's role is to balance extracting maximum value from existing investments against facilitating the generation of value from new investments. Protect and serve: it's a tough gig and sometimes a thankless one.

The "balance" stuff from ITIL Service Operation (3.2) says the same things:
- balance between internal and external focus (no Cult of the Customer)
- balance between stability and responsiveness (protect and serve)

I’m a big fan of cops and there is an analogy there with IT people: cops come in for a hard time at the moment, but most of them are decent people trying to get a job done in an embattled state where they’re battered into a corner by the environment in which they exist.
So you can actually draw some interesting parallels between the mental state of cops and traditional IT people I think.


ITIL says the same

I should have mentioned the "balance" stuff from ITIL Service Operation (3.2) which says the same things:
- balance between internal and external focus (no Cult of the Customer)
- balance between stability and responsiveness (protect and serve)

No issue

I don't really have such an issue with the cult of the customer. IT has spent much of its existence building walls to keep its customers at arms length. The exertion of a greater opposite force is needed to bring about the balance between internal and external focus. It inevitably means an unequal focus for a while until the education sticks and the pendulum settles.

I do find those proponents of Agile on here to be equally as cultish but without the obvious end of balance. And in Agile's case it's the balance of risk which one might consider of a little more import than the care afforded to it in some of these comments.

Back to your post, I do think IT has a unique challenge - after all, in what company does everyone think they're financial experts? Or legal experts? Yet everyone is an expert in IT, and this means that control takes on a greater meaning - and governance helps define those controls in an organisation.

I learned in the oil and gas industry just how key - and how central - information can be to an organisation, and dependence on exploiting information in the right way at the right time is growing all the time. Unmanaged risk to information [and data] management therefore is increasingly unmanaged risk to the business. I wonder if there's even been more apt description of IT's role than 'protect and serve' - not sure the balance or the maturity is there yet, of course.

Plus of course, whatever the motto, there will always be a Rodney King and a queue as big as an organisation ready to throw the baby out with the bathwater.

Comparable to TOC

I compare the current hype around agile methods to a similar hype around Theory of Constraints a decade ago. Their proponents discuss them with almost religious reverence and fervor. This is not to say they are wrong or useless. It simply suggests none of these methods are silver bullets that will solve all problems believed by their adherents.


Agility is not sacred

On twitter @cveira said " orchestration/control can't mean loses in agility", to which i replied "level of agility vs risk is a governance decision. Agility is not sacred."


Installing stop signs and street lights in cities can mean losses in agility.

It sounds just as stupid in an IT context.

Nice analogy

Nice analogy.

In a small town with wide streets, you can have nothing but roundabouts, to gain some control with minimal loss of agility, but big cities can't afford the real estate, and besides legacy street layouts don't have room for roundabouts. In addition, big cities need more sophisticated computer-controlled lights to allow advanced traffic pattern management, and to facilitate emergency services.

And so it is in IT. A cute little Agile development team is one thing; a major corporate with a complex of legacy systems is another.


Agile is done in a far larger scale that you think. With legacy systems, at one point a decision has to be made - replace the legacy system or not. I'm not advocating for either - it depends on the circumstances, but size is not the only thing that matters. Nor is age. On occasion you can play Sim City in your organization, demolish the inefficient parts and replace them with more Agile ones - if it makes sense business-wise. Just that the potential demand for replacing legacy systems is now coming from more directions than it used to, and "expensive/risky to maintain" might not be the top one.

Syndicate content