Service catalog: Difference between revisions
Amwelladmin (talk | contribs) No edit summary Tags: Mobile edit Mobile web edit |
Amwelladmin (talk | contribs) No edit summary Tags: Mobile edit Mobile web edit |
||
| Line 4: | Line 4: | ||
:“''Centralizing services also acts as a means of identifying service gaps and redundancies that can then be addressed by the enterprise to improve itself<ref>In other words, firing people.</ref>” | :“''Centralizing services also acts as a means of identifying service gaps and redundancies that can then be addressed by the enterprise to improve itself<ref>In other words, firing people.</ref>” | ||
In other words, you write down everything each machine, system, application or employee<ref>One of these kids is not like the others. One of these kids is not the same.</ref> is meant to do. It is a way of atomising and articulating every function in the organisation as a means of measuring, costing and [[operationalisation|operationalising]] every role | In other words, you write down everything each machine, system, application or employee<ref>One of these kids is not like the others. One of these kids is not the same.</ref> is meant to do. It is a way of atomising and articulating every function in the organisation as a means of measuring, costing and [[operationalisation|operationalising]] every role. | ||
A [[service catalog]], that is to say, is the [[jobsworth's charter]]. | This will do two things: (1) it will excite the [[middle manager|management]] layer who will regard it some kind of master key that unlocks all “[[redundancy|efficiencies]]”, and (2) it will licence [[jobsworth|those at the coalface who are so disposed]], on loyal grounds of the preserving the integrity of the control environment, to decline any action or responsibility not explicitly assigned to them in the catalog. | ||
'''A [[service catalog]], that is to say, is the [[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 expert]]s 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. | 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 expert]]s 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. | ||
| Line 12: | Line 14: | ||
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''. | 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''. | ||
===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 horsemen, not just any old calamity - it is logically mistaken. As the [[JC]] never tires of reminding us, [[Risk]]s, 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]]. | 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 horsemen, not just any old calamity - it is logically mistaken. As the [[JC]] never tires of reminding us, [[Risk]]s, 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]]. | ||
Revision as of 08:45, 31 August 2019
|
|
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 do two things: (1) it will excite the management layer who will regard it some kind of master key that unlocks all “efficiencies”, and (2) it will licence those at the coalface who are so disposed, on loyal grounds of the preserving the integrity of the control environment, to decline any action or responsibility not explicitly assigned to them in the catalog.
A service catalog, that is to say, is the 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.
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 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]
Though at times it might not seem like it, your human employees are not dumb animals. Tethering them to a service catalog, of course, might make them feel that way. 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.