Service catalog: Difference between revisions
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| (44 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
A [[service catalog]], | {{a|devil| | ||
[[File:Argos catalog.jpg|450px|frameless|center|A [[service catalog]] yesterday. Argos recently got rid of them, interestingly.]] | |||
}}It is strange what the service catalog — a work of utter science fiction dreamed up by a someone who has taken one too many Six-Sigma workshops — omits. It won’t mention “answering stupid questions,” “trying to forlornly to recover documents because [[Microsoft Office]] unexpectedly crashed”, “retyping them once you give up looking for them”, “attending ‘the future of legal’ transformational journey workshops”, “covering one’s own arse”; “trying to ''look'' like one is covering someone else’s arse, to make them go away, while not actually doing so”, “sitting on pointless [[committee|committees]] designed to cover ''everyone’s'' arse” or “attending pointless [[conference calls]] to save the time of one lazy arse who would rather waste twenty hours of other people’s time rather than one of his”. Yet these activities, and ones like them that also won’t be in the service catalog, occupy the lion’s share of a modern professional’s working life. | |||
:“''Centralizing services also acts as a means of identifying service gaps and redundancies that can then be addressed by the enterprise to improve | A [[service catalog]], per someone’s lovingly curated original research on Wikipedia: | ||
:“''... acts 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”<ref>In other words, by firing people.</ref> | |||
So, 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, articulating and mapping every function in the organisation, with a view to [[operationalisation|operationalising]] every role. | |||
This is part of a wider thrust to [[operationalise]] the organisation. You, dear [[subject matter expert]], cannot fight it because ''you are the redundancy the thrust is designed to eradicate''. | This exercise will do two things: | ||
{{ | :(1) excite the [[middle manager|management]] layer, who will regard it some kind of master key that unlocks all unrealised “[[redundancy|efficiencies]]”; and | ||
:(2) licence [[jobsworth|those at the coalface]] who are so [[inclined]], on grounds of ''loyal preservation of the integrity of the control environment'', to decline any invitation to take action or responsibility not explicitly assigned to them in the catalog. | |||
:(3) cultivate a behaviour pattern of catalog parsing, to construe one’s own service commitments as narrowly and atomically as possible, even where — as all activities within networked enterprise do — they form part of a wider process that can't be meaningfully articulated. These people will spend a large part of their day not checking the production line for themselves, but obtaining attestations from upstream neighbours that everything is in order, the line does not need to be checked for imperfections and, importantly, should any arise, they are categorically someone else’s fault. | |||
A [[service catalog]], that is to say, is a jobsworth’s charter. In this way so we see comprehensive operational responsibility for a process recede like an outgoing tide on a mudflat. As available human resources have been trimmed and it has become increasingly hard to carry out these roles, it is no wonder people should behave this way. They hardly have a choice. | |||
It is hard to fault this logic, should logic be your constant and only frame of reference. All “services” must cost something, and so must be [[shredding|allocated]] back to a cost centre. One should ''not'' carry out an uncatalogued service: it is either ([[Q.E.D.]])<ref>Ironic use of [[Q.E.D.]] here, by the way.</ref> unnecessary and, as such, unshreddible, or it ''is'' shreddible, but only because it is in someone ''else’s'' [[service catalog]] and is therefore ''their'' problem, not yours. | |||
By all lights, going “off catalog” is [[waste]]ful at best and liable to trigger [[turf-war]]fare between [[risk controller]]s, 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 [[tipping point]] at which a [[service catalog]] becomes irresistible is when your organisation has become so sprawling that the potential [[redundancy|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 day-to-day experiences, and depriving them of the autonomy to use their [[subject matter expert|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 approach needed in a [[complex system]] like a multinational financial services organisation. | |||
Yet, again, we find that greatest of management follies: the [[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 [[John Maynard Keynes|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, [[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]]. | |||
It is at just ''this'' moment, when these existential, [[Apocalypse|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.<ref>[[AI]] freaks who beg to differ : [mailto:enquiries@jollycontrarian.com mail me] if you want an argument. I’m game. </ref> | |||
But your human [[employee]]s are ''not'' dumb animals, however much tethering them to a service catalog might make them feel like it. You have them precisely ''because'' they can make quick value judgments, based on imperfect information and amid unknown contingencies, and still take executive decisions: ''to do imaginative stuff you weren’t expecting them to, when a sticky situation calls for it''. Software ''cannot'' do this. Not even [[Alpha Go]]. | |||
Humans catch the bits that the [[service catalog]] didn’t anticipate. | |||
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. | |||
===[[Lawyer]]s. 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, and must be able to answer, its own legal issues. It is expected to understand without help, all legal questions that arise in the course of its ordinary daily operations. | |||
The [[legal department]] is there to advise only where this business-as-usual understanding runs out of road; where 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 [[carving nature at its joints|joints at which your risk taxonomy has proposed to carve nature]]. | |||
[[Legal]] owns the legal risks you ''can’t'' catalog in advance. | |||
===Service catalogs and the [[high-modernist]] approach to management=== | |||
Service catalogs and risk taxonomies also suffer from the folly of [[reductionism]]. For what is a service catalog if it is not an attempted atomisation; an attempt to reduce an ineffable whole to a series of articulated, effable, components, each of which can be understood on its own terms, in management theory, by management, without loss of fidelity? | |||
This will to trifurcate [[Legal services|legal services]] into the “bespoke” (a proper subject for a real lawyer) the “standard” (legalish, but not ''hard'': suitable for outsourcing to some para-legal operational business with common sense but not possessing the higher sense of taste and style of a learned fellow) and programmatic (outright [[Chatbot]] fodder) — blame {{author|Richard Susskind}} for this easy categorisation; it was his idea — notwithstanding that almost ''any'' legal service worthy of a name has components of all three in it, and teasing them apart is often more trouble than it is worth. | |||
And, we think, risks missing something that [[Emergence|emerges]] from their confluence. You lose the big picture when you descend into the weeds. At one level, you lose simple ease of processing: to save a “bespoke” lawyer twenty minutes of a twenty-five minute job, you might carve the something as dreary as a [[confidentiality agreement]] negotiation into its articulated parts: contract policy formulation; fallback creation; document assembly; web-service creation and maintenance; negotiation, dialogue, drafting, accord, execution, data capture and document storage and of course the secondary range of bureaucratic quality control measures: procurement, management information and statistics, internal audit and so on. You could do all these things, intellectually, but to what actual point? It’s a goddamn ''confi''. | |||
Say you do it “old school”: sure, the dispatch of an [[NDA]] takes an expensive lawyer twenty minutes longer, but comes along once a month, and often provides a convenient diversion during that stakeholder check-in call. and that one, over-qualified lawyer, while handling all that micro-bifurcation, might just see something in the intersection of two roles she, according to management theory, ought not be doing. It does happen: sometimes it is just easier to think while typing than hand it off to a minute secretary. | |||
And is that lost twenty minutes sacrosanct anyway? Is it a machine-edged unit of productive value? Any of you, my dear readers, who have ever ''met'' an experienced lawyer, let alone happened to, you know, ''be'' one, will know it is not. Only a management consultant — or a legal futurologist — could imagine that one day the world’s corporations might sweat their senior lawyers like pieces of industrial machinery, that their productive output would remain unstintingly constant throughout the day. And only a management layer not notice far more reliable, and significant, source of unproductive downtime amongst its senior counsel: all the time they spend pissing around on [[operating committee]]s, filling out forms, approving stationery requests, trying to get the blessed skype to talk to your sound card, attending innovation workshops and transformation journey seminars, completing [[computer-based training]], and — above all — answering idiotic questions from management. | |||
{{sa}} | |||
*[[Complexity theory]] | |||
*[[Playbook]] | *[[Playbook]] | ||
*[[Turf-war]] | |||
*[[Service line]] | *[[Service line]] | ||
*[[Operationalisation]] | *[[Operationalisation]] | ||
*[[Outsourcing]] | *[[Outsourcing]] | ||
{{ref}} | {{ref}} | ||
Latest revision as of 10:16, 16 June 2022
|
It is strange what the service catalog — a work of utter science fiction dreamed up by a someone who has taken one too many Six-Sigma workshops — omits. It won’t mention “answering stupid questions,” “trying to forlornly to recover documents because Microsoft Office unexpectedly crashed”, “retyping them once you give up looking for them”, “attending ‘the future of legal’ transformational journey workshops”, “covering one’s own arse”; “trying to look like one is covering someone else’s arse, to make them go away, while not actually doing so”, “sitting on pointless committees designed to cover everyone’s arse” or “attending pointless conference calls to save the time of one lazy arse who would rather waste twenty hours of other people’s time rather than one of his”. Yet these activities, and ones like them that also won’t be in the service catalog, occupy the lion’s share of a modern professional’s working life.
A service catalog, per someone’s lovingly curated original research on Wikipedia:
- “... acts 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]
So, 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 inclined, on grounds of loyal preservation of the integrity of the control environment, to decline any invitation to take action or responsibility not explicitly assigned to them in the catalog.
- (3) cultivate a behaviour pattern of catalog parsing, to construe one’s own service commitments as narrowly and atomically as possible, even where — as all activities within networked enterprise do — they form part of a wider process that can't be meaningfully articulated. These people will spend a large part of their day not checking the production line for themselves, but obtaining attestations from upstream neighbours that everything is in order, the line does not need to be checked for imperfections and, importantly, should any arise, they are categorically someone else’s fault.
A service catalog, that is to say, is a jobsworth’s charter. In this way so we see comprehensive operational responsibility for a process recede like an outgoing tide on a mudflat. As available human resources have been trimmed and it has become increasingly hard to carry out these roles, it is no wonder people should behave this way. They hardly have a choice.
It is hard to fault this logic, should logic be your constant and only frame of reference. All “services” must cost something, and so must be allocated back to a cost centre. 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 is therefore 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 tipping point at which a service catalog becomes irresistible is when 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 approach needed in a complex system like a multinational financial services organisation.
Yet, again, we find that greatest of management follies: the 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]
But your human employees are not dumb animals, however much tethering them to a service catalog might make them feel like it. You have them precisely because they can make quick value judgments, based on imperfect information and amid unknown contingencies, and still take executive decisions: to do imaginative stuff you weren’t expecting them to, when a sticky situation calls for it. Software cannot do this. Not even Alpha Go.
Humans catch the bits that the service catalog didn’t anticipate.
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.
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, and must be able to answer, its own legal issues. It is expected to understand without help, all legal questions that arise in the course of its ordinary daily operations.
The legal department is there to advise only where this business-as-usual understanding runs out of road; where 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 proposed to carve nature.
Legal owns the legal risks you can’t catalog in advance.
Service catalogs and the high-modernist approach to management
Service catalogs and risk taxonomies also suffer from the folly of reductionism. For what is a service catalog if it is not an attempted atomisation; an attempt to reduce an ineffable whole to a series of articulated, effable, components, each of which can be understood on its own terms, in management theory, by management, without loss of fidelity?
This will to trifurcate legal services into the “bespoke” (a proper subject for a real lawyer) the “standard” (legalish, but not hard: suitable for outsourcing to some para-legal operational business with common sense but not possessing the higher sense of taste and style of a learned fellow) and programmatic (outright Chatbot fodder) — blame Richard Susskind for this easy categorisation; it was his idea — notwithstanding that almost any legal service worthy of a name has components of all three in it, and teasing them apart is often more trouble than it is worth.
And, we think, risks missing something that emerges from their confluence. You lose the big picture when you descend into the weeds. At one level, you lose simple ease of processing: to save a “bespoke” lawyer twenty minutes of a twenty-five minute job, you might carve the something as dreary as a confidentiality agreement negotiation into its articulated parts: contract policy formulation; fallback creation; document assembly; web-service creation and maintenance; negotiation, dialogue, drafting, accord, execution, data capture and document storage and of course the secondary range of bureaucratic quality control measures: procurement, management information and statistics, internal audit and so on. You could do all these things, intellectually, but to what actual point? It’s a goddamn confi.
Say you do it “old school”: sure, the dispatch of an NDA takes an expensive lawyer twenty minutes longer, but comes along once a month, and often provides a convenient diversion during that stakeholder check-in call. and that one, over-qualified lawyer, while handling all that micro-bifurcation, might just see something in the intersection of two roles she, according to management theory, ought not be doing. It does happen: sometimes it is just easier to think while typing than hand it off to a minute secretary.
And is that lost twenty minutes sacrosanct anyway? Is it a machine-edged unit of productive value? Any of you, my dear readers, who have ever met an experienced lawyer, let alone happened to, you know, be one, will know it is not. Only a management consultant — or a legal futurologist — could imagine that one day the world’s corporations might sweat their senior lawyers like pieces of industrial machinery, that their productive output would remain unstintingly constant throughout the day. And only a management layer not notice far more reliable, and significant, source of unproductive downtime amongst its senior counsel: all the time they spend pissing around on operating committees, filling out forms, approving stationery requests, trying to get the blessed skype to talk to your sound card, attending innovation workshops and transformation journey seminars, completing computer-based training, and — above all — answering idiotic questions from management.