Technical Debt Analysis

by

This is a set of conversations I had with Dave and Andrey about Technical debt, where we have been trying to explore the use of Estuarine Mapping.

Session 1, starting the exercise

We have defined some assumptions:

  • The context we are figuring out is a software development environment.
  • The context have business and compliance requirements.
  • We admit changes on the requirements can be aligned with the original type of requirements, and the fact that the speed of changes and type of changes that can go beyond these initial range that was accepted as valid. All this condition the already existing design definition the architecture and the dependent elements.
  • We differentiate the practices as a key element, where processes could be manual or more automated: DevOps, DevSecOps, etc.

We have started with a list of classic technical debt reasons, but after reviewing it, we have defined a Wardley Map to identify needs and capabilities: basically agree on a specific context with certain levels of abstraction.

The conversation related to constraints and constructors started when we started to move components from the Wardley Map into the Estuarine Map.

The addition of dependencies drove us to differentiate the type of constructors we have used.

Leave a Comment