Steering agile architecture
Does your system's architecture appear to keep you back? Perhaps the architecture seems to not be quite as clean as it appears on the whiteboard?
We help you steer it. We capture your existing ideas and rules into executable constraints, we visualize the violations, and we get the team to incorporate all these in their daily work.
How the daily assessment works
Architecture does not just happen. Architecture is a valuable asset that requires permanent investment.
The architecture that matters is in the code. First, we need to take that reality into account continuously. Second, it follows that the main architects that matter are those that affect the code: the developers. The organization must engage everyone involved in developing the system. To this end, we employ the daily assessment process.
The goal of daily assessment is to identify concerns that are relevant for the team and for the system, to figure out the actions that need to be undertaken to fix the issues, and to integrate these actions in the daily development.
Anyone in the team can raise a concern and champion for a change. These concerns can be of various forms covering a large space from broad architectural decisions to low level usages of technology. Example of concerns can be:
- The interface of component A should only be called by component B
- All calls to the server interface should be error handled on the client side. The error handling can happen either directly, or by means provided by the used frameworks on the client side.
- Package naming should follow a dedicated grammar scheme.
- All services should specify the security policies through a dedicated annotation.
Concerns can take many forms but the important part is that they are important for someone. They do not have to be abstract or smart to be relevant. As soon as there is a stakeholder, they are legitimate because it means that the concern bares value in the context of the current project.
Once the concern is identified it is captured in an automatic checker and is integrated in the continuous integration mechanism. The checker is much like a unit test, only it's not about functionality. Furthermore, The team needs both the skill, and a technical infrastructure to do this.
Every concern is discussed with the team. This can be organized as a daily session. This session only involves the engineers because the discussion needs to be deeply technical to be effective. In this session, only people that have a concern backed up by data can talk. The goal here is not to synchronize or exchange ideas, but to reach a resolution. In most cases, when a concern is exemplified with concrete data, the resolution is found in minutes. If the conversation lasts more than a few minutes, it should be stopped because it shows the data is not clear enough and that the concern must be refined.
Anyone can challenge a concern or the insuing action. Once the agreement is reached, the team acts on it, ideally immediately.