anchor.diff:  is now centralized, that task might become somewhat simpler than within
   the original legacy system. At the same time, remove all commons-code from the split
   systems - reducing them in size.
  ++
  +Split the rest of the whole development team according the split systems. Make
  +one developer group responsible for one split system.
   +
   [[figure-split-reduced-commons]]
   image::improvement-approaches/cbs-4-reduced-commons.png["CBS, reduced commons", title="Change-by-split, reduced splits, optimized commons"]
  
positive.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.
  +
  [[figure-split-commons]]
  image::improvement-approaches/cbs-3-factored-commons.png["CBS, commons", title="Change-by-split, factored out commons"]
  
  
negative.code: ===== 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.
  
  
  
  
  