Agile Architecture:Thinking ahead within Dev lifecycle (Part 1)

Most of the dev teams don’t want to overbuild the system based on future platforms/requirements/changes etc but they do want to think about the future. Thus the question comes to fore is what is the right balance.

Some principles :

1) Keep it simple : Engineers loves complexity but this is really opposite. But it’s the wrong approach. Its often easier to think deeply about the problem or challenge and then finding the “simplest thing” that could satisfy the customer. One way is to create MVP. whether they’re internal customers, external customers, or both and especially the UX.

2) Treat Arch like a Product: Put these arch stories into your backlog. The stories are different than functional / feature work. The might be in different layers or infra based. Note that everyone becomes a stakeholder in the architecture. That means they understand the details, agree with the business case/investment, understand the impact/value and more or less agrees when it’s done.

3) Allow Arch to Emerge : When working with emerging arch from the Big Design Upfront or layered designing, think of how much to look ahead and rework,

• Define some architectural runway and then code and learn from it if it works at all. Engage experts to less experience devs for coding and if possible a distributed one.
• Emerge, do a bit of design, then prove or learning or coding and redesign if required ie in small iterations.
• Try building the app in vertical slices that can be integrated together.
• Think of significant decisions that are typically related to technology choices and structure i.e. decomposition strategies, modularity, functional boundaries, etc

4) Don’t use UML: This is pre agile era concept. The common advice is to “just use boxes and lines on a whiteboard” as a way to communicate ideas or use C4 ie Context, Containers, Components and Code. It’s about creating a set of hierarchical, zoomable maps to show a software system. First create a system context diagram that describes how the system fits into the ecosystem. One can then zoom in to the system boundary to show the containers inside it — a container is a deployable, runnable thing, like a SPA running in a web browser, a server-side web app, a microservice, a database schema, etc. One can zoom further into each container to show the components inside it. Finally, one should be able to zoom into each component to show the code level elements such as classes, interfaces, functions, objects, etc it’s composed of. The C4 model is notation independent.

5) Modularity: The core characteristics of a good architecture relate to modularity arrived at with an appropriate decomposition strategy. A software architecture that enables agility, will help to implement change; that change could be from requirements, business processes, infra, layers, future dev, etc.

Modular Design allows the Dev to confine his changes to one or a few modules and speed up the build and testing of changed parts. What this means is If changes are made to only a few modules not violating API and interfaces, the risk of going live could be reduced. In most cases modularity is taken to the level of microservices.

To be continued