There's a tension in agile project/program management about product architecture: when do you make the architectural decisions?
If you make lots of architectural decisions early, you can create a brittle system that needs to be rearchitected. If you make the decision too late, you might be creating lots of technical debt. Is there a "Goldilocks" moment that is just right?
Maybe.
Part of the problem is you need to know what a minimally acceptable system is. Note that I said acceptable, not rejectable. Sometimes, the tolerance between minimally acceptable and not acceptable is quite small, as is the tolerance between minimally acceptable and fabulous.
Minimally acceptable is still acceptable. If you have minimally acceptable product, you might have a lot of technical debt, but still an acceptable product for this release. The real question is what happens for the next release? That's when the project/program team, and management needs to acknowledge the technical debt and put the debt into the backlog to manage and deal with.
If you have a product owner who only wants to deal with features, you have an unacceptable product owner. Product owners need to manage the technical debt as well as the desired feature set.
To discover your "Goldilocks" moment, you need data about the architecture. To get the data, you need to implement something: a walking skeleton, several features, alternative prototypes, something that provides you information about the potential system architecture.
So the way I know how to make these decisions is:
- Know what minimally acceptable product is. This might be reflected in project release criteria or in success criteria.
- Acquire some data about the proposed architecture.
- Postpone the final decision until the last responsible moment. Sometimes that moment is earlier than you might like. Sometimes, if you're like me, it means you live with ambiguity longer than you might find comfortable.
Whatever you do, avoid making final architecture decisions at the very beginning of the product based only on pretty pictures. That's a fast way to create architectural technical debt.
Instead, consider decision-making based on data, and to see what problems this architecture resolves and which problems this architecture leaves open. Then, you'll have the least technical debt and it will be transparent to you, so you can continue making decisions about it.
