The Intersection of Cumulative and Cyclical Knowledge in Agile Architecture

The Intersection of Cumulative and Cyclical Knowledge in Agile Architecture

Reading old finance articles often gives us the impression that the ancient past was not so different from today. However, when we delve into old medical commentary, we realize that knowledge in certain fields is cumulative, while in others, it is cyclical at best. This distinction becomes particularly evident in fields guided by human behavior such as money management, philosophy, and relationships. Unlike physics and math, which can be approached with formulas, these subjects cannot be solved with a one-size-fits-all approach.

In the realm of architecture, there has been a rise in the concept of agile architecture. This approach embraces the idea of messy, inconsistent, and emergent architecture. It acknowledges that applying consistent architecture or fast autonomous teams individually may not be the most optimal solution. In fact, it often results in increased operating costs instead of reducing them. There is a delicate balance that needs to be achieved, considering both consistency and alignment, while also valuing the time to value.

Rather than structuring our architecture first and fitting our teams into it, we should be structuring our architecture around our teams. Microservices, a modern software architecture pattern, aim to break down applications into smaller, decoupled parts that can be loosely bound together to create a complete application or product. However, the challenge lies in dividing the application into logical pieces that can act as Lego blocks. Versioning becomes crucial in this process, allowing teams to build on top of existing microservices while creating new versions. This approach prevents a snowball effect of changes, where one team's modifications leave another team using an outdated version.

In the pursuit of agile architecture, there is no perfect solution. It becomes a trade-off between different values. Do we prioritize cost, reuse, and consistency, or are we willing to tolerate some messiness and inconsistency in order to enable autonomy, adaptability, and faster time to value? This question parallels the competition between being the cheapest company or being the best. These goals are often conflicting, and one cannot be achieved without sacrificing the other. While it may be easier to opt for the cheaper route, true value realization, responsiveness, and adaptability require a different mindset and behavior.

To navigate this complex landscape, here are three actionable pieces of advice:

• 1. Embrace the balance: Recognize the importance of consistency and alignment, but also value the time to value. Strive for a balance that allows for autonomy and adaptability while maintaining a certain level of consistency in your architecture.

• 2. Prioritize communication: As Melvin Conway stated, organizations that design systems are constrained to produce designs that mimic their communication structures. Foster open and effective communication within your teams to ensure that your architecture reflects the needs and capabilities of your organization.

• 3. Don't shy away from iteration: Iteration is a natural part of the agile architecture process. Embrace the messiness and inconsistency that may arise during development, knowing that it is a necessary step towards creating a more adaptable and responsive system.

In conclusion, the intersection of cumulative and cyclical knowledge in agile architecture highlights the challenges and trade-offs involved in creating effective and efficient systems. By understanding the need for balance, prioritizing communication, and embracing iteration, we can navigate these complexities and build architectures that align with our teams and enable faster time to value.