Skip to content

ADR-0010: Ecosystem Service Classification Model

  • Status: accepted
  • Deciders: ConnectSoft Architecture Team
  • Date: 2026-06-10

Context and Problem Statement

The SaaS Ecosystem Catalog enumerates ~1,500 candidate products, services, and components. Without a shared vocabulary for what kind of thing each item is, teams would default to treating every item as a microservice, leading to fragmentation, duplication, and unsustainable operational cost.

How should we classify ecosystem items so that delivery shape and runtime topology are explicit and consistent?

Decision Drivers

  • Avoid service explosion and operational overload.
  • Reuse platform capabilities instead of re-implementing them.
  • Make domain ownership and deployment model explicit per item.
  • Keep the catalog machine-readable for tooling and backlog generation.

Considered Options

Option 1: Treat every item as a service

  • Pros: Uniform. Cons: ~1,500 deployables, massive duplication and ops cost. Rejected.

Option 2: Free-form description per item

  • Pros: Flexible. Cons: Inconsistent, not machine-readable, no shared rules. Rejected.

Option 3: A fixed classification taxonomy (Selected)

A closed set of delivery shapes applied to every item, stored in the catalog.

Decision

Every catalog item is classified as exactly one of: Platform Product, Bounded Context, Microservice, Module-in-service, Shared Library, Infrastructure Component, Connector, Portal/UI Module, AI Agent, Workflow Template, Vertical Solution Pack, Documentation Pattern, Future Research.

Each item records deliveryShape, implementationUnit, and runtimeCandidate. The full model is documented in the service classification model.

Rationale

  • A closed taxonomy makes topology decisions explicit and reviewable.
  • It is machine-readable, enabling backlog and planning automation.
  • It is the foundation for the anti-fragmentation rule in ADR-0011.

Consequences

Positive

  • Consistent, reviewable classification across 1,500 items.
  • Enables tooling, backlog generation, and Azure DevOps planning.

Negative

  • Requires discipline to keep classifications current as understanding evolves.