Shared Service Catalog¶
Artifact — instantiates Shared-Input Variety Platform Design
Lists available common services, eligibility rules, service levels, ownership, cost model, and onboarding path for varied outputs.
A Shared Service Catalog is a published, browsable listing of the shared services available for reuse — each entry stating what the service does, who owns it, its service levels and interface, who is eligible, its cost model, and how to onboard — so that output teams can discover what to reuse and on what terms without asking around. Its defining move is being the discovery-and-terms artifact: the labeled index of the shared shelf. It is neither the shelf itself nor the decision to use anything on it; it answers "what shared services exist, and what would I be signing up for?" and leaves the choosing to others.
Example¶
A large retailer's internal engineering platform offers dozens of shared services — payments, an inventory-lookup API, feature flags, transactional email and SMS sending, an image CDN. A new store-fulfillment team, unaware these exist, starts building its own SMS integration from scratch.
The platform org publishes a Shared Service Catalog. Each service gets a standard entry: a description, the owning team, a service-level statement (uptime, latency, support hours), the API/interface contract, an eligibility note, the cost model, and a step-by-step onboarding guide. The fulfillment team searches "SMS," finds the sanctioned sending service with its 99.9% availability target and a self-serve onboarding path, and adopts it in a day instead of a sprint. Outcome: reuse becomes discoverable and self-serve, and the terms and ownership of each service are explicit before anyone commits to it.
How it works¶
- List every shared service in a standard entry — owner, service level, interface, eligibility, cost model, onboarding — so entries are comparable and complete.
- Make it browsable and searchable, so discovery is self-serve rather than tribal knowledge.
- Bind each entry to a service-level and interface contract, so a consumer knows the guarantees and the integration surface up front.
- Keep entries current through their owning stewards. A stale catalog that advertises retired or degraded services is actively misleading.
Tuning parameters¶
- Entry richness — a minimal index versus a full specification per service. Richer entries inform better but cost more to maintain and age faster.
- Service-level formality — informal "best effort" descriptions versus contractual targets; formal SLAs build trust but bind the owning team.
- Curation gate — what qualifies to be listed (production-ready only versus everything in flight). A permissive gate advertises immature services.
- Self-serve depth — browse-only versus one-click onboarding wired into the entry.
- Freshness discipline — how aggressively entries are re-verified against reality.
When it helps, and when it misleads¶
Its strength is solving discovery: teams cannot reuse what they cannot find, and a catalog turns the shared layer from tribal knowledge into a self-serve menu with explicit ownership and terms. It is the ITIL service catalogue[1] idea — a customer-facing list of live services with their levels and request paths.
Its failure mode is the archetype's own caution: a catalog without variation boundaries or benefit measurement "is just an index" — listing a service does not make it fit a given output or worth using, and a stale entry advertising an SLA the service no longer meets erodes trust in the whole platform. The classic misuse is treating publication as governance, where being listed is read as being endorsed and appropriate, without the fit and benefit discipline behind it. The guarding discipline is to keep entries current and to pair the catalog with a fit gate and a benefit measure rather than letting it stand alone.
How it implements the components¶
reuse_onboarding_path— each entry's onboarding guide is the documented path from "found the service" to "using it."interoperability_contract— each entry publishes the service's interface and service-level terms, the contract a consumer integrates against.shared_layer_stewardship— each entry names an accountable owning steward responsible for the service and for keeping its entry honest.
It does not decide whether a given new output should use a listed service (variation_boundary, local_fit_exception_path — that is Reuse Intake and Fit Assessment) nor prove a service saves money (scope_benefit_metric — Cross-Output Cost Attribution Model); the catalog advertises and states terms, it does not gate fit or measure benefit.
Related¶
- Instantiates: Shared-Input Variety Platform Design — the catalog is the discovery surface of the shared layer.
- Sibling mechanisms: Common Platform Roadmap · Cross-Output Cost Attribution Model · Joint Procurement or Tooling Pool · Modular Capability Library · Platform Governance Board · Product-Line Architecture · Reuse Intake and Fit Assessment · Shared Data or Feature Store · Stovepipe Retirement Migration Plan
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Shared Service Catalog operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it lists available common services, eligibility rules, service levels, ownership, cost model, and onboarding path for varied outputs.
Independent corroboration: The frozen evidence defines Shared Service Catalog as 'Lists available common services, eligibility rules, service levels, ownership, cost model, and onboarding path for varied outputs', so its operative form is Representation, Specification & Plan.
Nearest alternative: Organization, Role & Governance — Shared Service Catalog includes features of an enduring role, team, authority, channel, or governance body that allocates responsibility, but its defining operation is a static representation, map, specification, schema, or prospective plan that externalizes information.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Publishing common services, eligibility, ownership, levels, cost, and onboarding is service-portfolio management.
Related originating lineages:
- Accounting & Auditing — Cost models and service ownership support chargeback and accountability.
- Computer Science & Software Engineering — IT service catalogs and API portals operationalize digital offerings and access paths.
- Library & Information Science — Cataloging and controlled descriptions make services discoverable and comparable.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: lists available common services, eligibility rules, service levels, ownership, cost model, and onboarding path for varied outputs.
Review resolution: The blind reviewers agree that organizational_management is the primary origin and differ only on alternate origin disagreement, origin mode disagreement, encyclopedia synthesis disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain cross_disciplinary_synthesis because the combined evidence shows material contributions from several lineages. The broader reach of multi_domain records portability separately from historical provenance; encyclopedia_synthesis=true preserves the affirmative synthesis judgment where either reviewer identified one.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The catalog and Reuse Intake and Fit Assessment are complementary: the catalog is the menu (what exists and on what terms), intake is the ordering decision (whether this output should take it). A catalog read as an endorsement, with no intake behind it, is exactly the "just an index" trap.
References¶
[1] AXELOS. ITIL Foundation, ITIL 4 Edition. AXELOS (2019). Describes the ITIL service catalogue as a current audience-facing service list with service-level and request information. registry ↩