anchor.diff:  ===== Consequences
   
   
  +
  +* Instead of having to manage one single (but large) system,
  +you will have to manage (develop, change, operate) several (smaller) systems.
  +This might be especially relevant for operations effort.
  +* Instead of having to manage one single development team,
  +you will have to manage several.
  +
  +* All "things" you are dealing with (code, data-structures, data,
  +  processes) will become smaller, reducing complexity of these "things".
  +* "Time-to-market" of your split systems will be lower (as development
  +  will be faster) - maybe coordination and management effort might increase.
  +
  +
  +
   ===== 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.
  +* Try to to identify potential _neuralgic sections_ within the code,
  +that do not belong into the factored-out commons and will likely affect
  +several of the split systems. Try to minimize the effort required
  +to analyze and untangle such sections by gathering people from various
  +split-teams.
  +* Don't try everything at once: Spread out step 5 (optimize splits) over
  +several, possibly many, development iterations or releases. Let the split
  +teams become comfortable with their reduced split systems.
  +
   
   
   
  
positive.code: 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
  
  ===== Applicability
  
  
negative.code: +
  [[figure-split-final]]
  image::improvement-approaches/cbs-5-final.png["CBS, final", title="Change-by-split, all split systems reduced/optimized"]
  +
  This final step might need extensive preparation, e.g. by creating user-category
  specific unit-/integration-/acceptance tests. Reducing unneeded code
  can be quite difficult, if the original code has (extremely) high cyclomatic complexity
  or is very difficult to understand for other reasons (configurability, strange
    technologies, using strange/outdated/proprietary frameworks etc.).
  
  
  Steps 4 and 5 might be interchanged or done in parallel.
  
  
  ===== Experiences
  