Service catalog
|
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 and articulating every function in the organisation as a means of measuring, costing and operationalising every role. This will excite the management layer - it is a master key that unlocks all kinds of efficiencies, and it will licence those at the coalface, on grounds of the preserving the integrity of the control environment, to do nothing that isn't specifically written down in the catalog.
It is a jobsworth's charter.
The point at which a service catalog becomes irresistible is the tipping point where your organisation has so large and 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 local 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.
This is part of a wider thrust to operationalise the organisation and eliminate redundancies. You, dear subject matter expert, cannot fight it, because you are the redundancy the thrust is designed to eradicate.
The service catalog is also of a piece with the risk taxonomy in that it is a product of the conviction that the forward needs of the organisation are perfectly understood, anticipated, and set in stone. There is nothing new under the sun. Unless we are on the brink of apocalypse - the apocalypse that is: the one with horsemen, not just any old calamity - it is logically 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 the moment when existential threats emerge, unbidden, from the poorly-sewn seams of your risk taxonomy, that you don't want your risk controllers going "sorry, but that's not my job".
Machines, not meatware
As that earnest collaboration on Wikipedia quoted above notes, the idea of a service catalog originated in the 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. 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.[3]