Have you ever endured “ivory-tower architectures”?
In belief #3 we looked at the need for a business purpose-driven approach. We also explained how the opposite approach with technology- or vendor-centric architectures, drive us to “IT projects” and solutions with no clear business ownership and low flexibility. All too often, we build “software capabilities” instead of “business capabilities”.
In belief #7 we looked at the value of keeping together what is common and separating what is not through “right-sizing” our architecture building blocks according to the unique and non-overlapping business purposes in the organisation.
Our belief #9 is closely related, but it specifically addresses the risk of building ivory-towers. Best architectures require top-down scoping and bottom-up validation. We believe that architects can only do best architectures, when we have a feed-back loop from the people implementing the change. The feedback is needed, since in most case the team(s) have the deep knowledge based on practical experience with the subject matter of our architecture.
This means that best architectures are validated against real life feasibility. They are informed about significant business logic hidden in the details and other types of restrictions. The bottom-up also ensures that best architectures are inspired by the opportunities arising from new development approaches and technologies.
But it goes both ways. If we don’t define architecture top-down the individual change initiative or team will often end up separating concerns that are local or “current problem specific”. Instead the top-down ensures we take steps in solving the strategic concerns for the organisation.
Often when top-down guidance is missing in agile implementation, the result is lots of rework as the scope adds on sprint by sprint. The rework then eventually slows down the value adding work. It is true that agile implementation means that continuous refactoring is part of the approach. But we sometimes forget that while refactoring is needed at the lowest level, we want to minimize rework at the “architecture level”. That is because architecture is concerned with the parts that are the hardest to change, and hence the costliest piece of change. This was the topic of our belief #5 – best architectures enables organizational agility by defining elements of the design that are stable, and elements that require a flexible structure.
So, the key to being effective – and not just efficient – with change initiatives, regardless if agile or not, is to have a strong practice for working with top-down intentional architecture. This should never be a big-design-up-front as some agile evangelists would fear. Rather it is the opposite, a just-in-time and just-enough approach to developing intentional architectures iteratively as laid out in our belief #2.
In our mind the sweet spot is where there is an out-side-in approach to deal with context, and a quick feedback from implementation (bottom-up) to continuously adjust the gaps based on real-life learnings.
What is your experience with top-down bottom-up architectures?