I’ve seen a repeated pattern that plays out in many companies. Delay, or more accurately, the perception of delay induces the creation of “extra” layers in the architecture. The pattern goes like this:
- A component or subsystem needs to add a capability to serve some end-user need.
- It will take “too long” to implement that capability in the component. (This is where the perception part really steps in.) Maybe the team is stretched too thinly. Maybe the capability is low value relative to the rest of the pipeline and gets scheduled out in the future. Maybe the team has a lot of technical debt to contend with. Or maybe it just really does take a long time to implement in a particular layer.
- The requestor then moves up the call stack and looks for a component at a layer closer to the end user, so the capability can be added there. Often this means introducing a new layer between the end user and the “slow” component. This might be a kind of strategic maneuver to engulf and extinguish the other component. In a strongly political environment, you will see this play out as executives jockey for position against each other. It might be a good faith effort to create a new “orchestration” layer to bring together diverse capabilities.
- If the effort succeeds, there is a loss of coherence: the new layer never implements the same interface as the one it decorates. So callers must decide which layer to invoke. Behavior differs. Maybe even the data available differs.
- If there is more than one community of end users, they are likely to pick different layers to interact with. Legacy users may prefer to stick with calls to the lower layer, as they see only cost and no benefit to switching. Newer users may prefer the newer layer, especially if it’s interface style is more contemporary.
The net result is:
- Increase in complexity and technical debt.
- Increase in “organizational debt” (measured by the number of teams needed to effect a user-visible change.)
- Customer frustration once they experience channel disparity.