Service catalog
 A service catalog yesterday. Argos recently got rid of them, interestingly.
|
A service catalog, per someone’s lovingly curated original research on Wikipedia, is:
- “...a means of centralizing all services that are important to the stakeholders of the enterprises which implement and use it. Given its digital and virtual implementation, via software, the service catalog acts, at a minimum, as a digital registry and a means for highly distributed enterprises to see, find, invoke, and execute services regardless of where they exist in the world. This means that people in one part of the world can find and utilize the same services that people in other parts of the world use, eliminating the need to develop and support local services via a federated implementation model.
- “Centralizing services also acts as a means of identifying service gaps and redundancies that can then be addressed by the enterprise to improve itself”[1]
In other words, you write down everything each machine, system, application or employee[2] is meant to do. It is a way of atomising, articulating and mapping every function in the organisation, with a view to operationalising every role.
This exercise will do two things: (1) excite the management layer who will regard it some kind of master key that unlocks all unrealised “efficiencies”, and (2) licence those at the coalface who are so disposed, on loyal grounds of preserving the integrity of the control environment, to decline any invitation to take action or responsibility not explicitly assigned to them in the catalog.
A service catalog, that is to say, is the jobsworth’s charter.
It is hard to fault this logic, should logic be your constant and only frame of reference. All my “services” cost something, and must be allocated back to a cost centre. The starting assumption must be that all valuable services have been catalogued and assigned to a particular group in the organisation. One should not carry out an uncatalogued service: it is either (Q.E.D.)[3] unnecessary and as such unshreddible, or it is shreddible, but only because it is in someone else’s service catalog and therefore it is their problem, not yours. By all lights, going “off catalog” is wasteful at best and liable to trigger turf-warfare between risk controllers, all of which will be meat and drink to the censorious wagging fingers of your internal audit folk when they come to visit. Self-inflicted wounds, all.
The point at which a service catalog becomes irresistible is the tipping point where your organisation has become so sprawling that the potential economies of scale outweigh the costs of disenfranchising all your local subject matter experts by jamming them into a universal model that won’t quite fit any of their day-to-day experiences, and depriving them of the autonomy to use their subject matter expertise to make pragmatic decisions on the hoof to keep the organisation moving. That autonomy of course, is exactly the sort of risk management you need to manage a complex system like a multinational financial services organisation. Yet again, we find that greatest of management follies: like a playbook, a service catalog speaks to the aspiration to manage a complex operation as if it were a merely complicated, or even simple one.
This is part of a wider thrust to operationalise the organisation and eliminate — by which I mean make — redundancies. You, dear subject matter expert, cannot fight it, because you are the redundancy the thrust is designed to eradicate. Your time will come, O subject matter expert — but, like most things in the unknowable henceforth, it may not be in time to save your bacon. “In the long run”, as Keynes had it, “we are all dead”.
Come the apocalypse
The service catalog is also of a piece with the risk taxonomy in its conviction that the forward needs of the organisation are perfectly understood, anticipated, and pre-determined. There is nothing new under the sun. Unless we are on the brink of apocalypse — the Apocalypse that is; the one with a capital A, four horsemen and so on, not just any old calamity — logically, this view is wildly mistaken. As the JC never tires of reminding us, risks, challenges and opportunities present themselves from undetected crevices in the space-time continuum. They are not languishing in plain sight within the pages of your playbook.
It is at just this moment, when these existential, Apocalyptic threats emerge — unbidden as they will be, tearing through the badly-stiched seams of your risk taxonomy — it is at exactly this point that you don’t want your risk controllers going, “Ah, sorry, champ, but according to the service catalog, that’s not my problem”.
Machines, not meatware
As that earnest collaboration on Wikipedia quoted above notes, the idea of a service catalog originated in the realm of software management. In any decent-sized organisation, pitches for new software will come in from all sides, and carefully curating the the IT “estate” is profoundly important.
But software is dumb. It follows rules. It can only do what it was bought to do; it usually disappoints even at that. To augment or change the application to which your software is dedicated, to meet a new challenge or opportunity — that requires judgment. An executive decision. Only a person can make an executive decision.[4]
Though at times it might not seem like it, your human employees are not dumb animals however much tethering them to a service catalog might make them feel like it. But you have employees precisely because they can make judgements, and take executive decisions, and do imaginative stuff you weren’t expecting them to when a tricky situation calls for it. Software cannot do this. Not even Deep Mind.
This is the profound difference between humans and machines. In the hive mind’s evangelical fervor for AI, this distinction has been lost. We overlook it at our peril.
Humans catch the bits that the service catalog didn’t anticipate.
Lawyers. A special case.
If there is one bunch of employees who are uniquely unsuitable for a service catalog it those, like the legal eagles, whose job is to sort out edge cases. The common belief that the legal department exists to own and answer all legal issues is a canard. Each business owns its own legal issues. It is expected to understand and answer, without help, all legal questions that arise in the course of its ordinary daily operations.
The legal department is there to advise should the playbook run out of road; should new or unusual issues arise. Legal comes in when an exception is thrown. It is an escalation. Inside the normal science of the paradigm, you should not espy your young attorneys abeam the tilled and and tended fields of existing practice: they should keep away. Those the business people and operations staff must understand themselves. These risks one can catalog easily enough, but they are not owned by legal.
That is, the legal department is there to answer the questions the organisation was not expecting to to be asked. By definition, they will not cleave to joints at which your risk taxonomy has purported to carve nature.
Legal owns the legal risks you can’t catalog in advance.