Platform abstractions: Asset or liability

Slides

Fair warning: Food analogies incoming

Baseline

What do abstractions achive

  • Structure through simplification
  • Complexity made simple
  • Hiden Details, visible value

Dilemma

  1. Platform team creates abstraction
  2. Abstraction works for 10 Teams
  3. Other team requests extension
  4. Question: How do we deal with this

Possible Solutions

  • Add Config Options: Increases complexity of abstraction
  • Make One-off exceptions: Breaks standardization, introduces inconsistency
  • Require conformity: Hinders innovation, creates enemies
  • Allow bypassing: Creates shadow it, risking security and resource control

=> Debt trap: The cost of maintaining a stable platform rises and rises

The debt cycle

The abstraction cycle

  1. Simplify
  2. Adobt
  3. New Requirements
  4. Add complexity
  5. Repeat

Abstraction cycle illustration Abstraction cycle illustration

Warning signs

  • Rizing customization requests
  • Workarounds
  • Shadow IT

Impact

  • Each new feature becomes harder to implement
  • Teams lose trust in the platform capabilities
  • Platform evolutions slows down
  • New tech is difficult to incorporate

Abstraction elacity

The abstraction should stretch a bit to accommodate change without brakuing

  • Adaptability: Ease of handling new requirements
  • Transparency: Understand what your user wants and why
  • Extension PAtterns: Document ways to customize the platform behavior
  • Migration Paths: Ease of moving away from the platform abstraction

Elasticity

  • Can teams access lower level controls (when needed) while staying with the abstraction
  • Do users understand what happens underneath (when needed)
  • Are ther documented extension/customization points?

Patterns to break the debt trap

  • Layered abstraction patterns: start with low-level abstractions that get abstracted on higher levels to allow users to choose the right abstraction level for themselves without having to configure everything themselfes
  • Expert-ap: Additional api parameters that are not needed but can be set
  • Policy based guard rails: Change the guardrails based on the environment (e.g. deep access in dev, not in prod)

The end goal

  • Increase adoption
  • Eliminate shadow IT
  • Improved satisfaction
  • Reduced overhead