anchor.diff:  several business domains, rendering this approach useless.
   * The required team-split might pose organizational challenges,
   as a currently productive (albeit large) team has to be disrupted.
  -* The various user groups
  +* It might be difficult to define appropriate interfaces for the
  +factored-out _commons_. If these commons are overly scattered
  +throughout the legacy code, this extraction might be impossible,
  +making the resulting split systems more complicated than they should be.
  +* If business code is overly tangled, having very high cyclomatic
  +complexity, it can be arbitrarily difficult to remove those parts
  +that are not required for a single user type/category. Analyzing such
  +code segments should be performed my members of several split-teams.
  +* Associated processes (like requirements, test, documentation and operations) of
  +the split systems might become more difficult to manage in the first
  +phases of a split. Due to the reduced sizes of split systems, it might
  +be likely such processes will become simpler over time.
   
   ===== Applicability
   
  
positive.code: ===== Consequences
  
  
  ===== Proposed practices
  
  * Find a relatively small user-group and _pilot_ (try-out)
  this approach.
  * Involve the affected user groups as early as possible to
  facilitate possible required changes on their side.
  
  
  
  
negative.code: those might be pdf-generation, user/role management or the like. Factor out those
  commons into a separate module/subsystem, which is used by (likely all) other split systems.
  +
  Make part of the whole development team responsible for the commons.
  +
  [[figure-split-commons]]
  image::improvement-approaches/cbs-3-factored-commons.png["CBS, commons", title="Change-by-split, factored out commons"]
  
  