You deserve explainable systems. Read the whitepaper.

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.

Perhaps even more important, we guide you to explain the architecture to non-technical people, too. Like this they can invest in it as the asset it is.

How it works

The value of your system today is provided by its functionality. Tomorrow, its value is given by how well you can adapt it to tomorrow's needs. What might prevent that? Architecture. As it is architecture that can prevent the creation of business value in the future, it follows that you should treat architecture as a business asset.

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.

The roles: stakeholder and facilitator

Steering agile architecture relies on two distinct roles: the stakeholder and the facilitator.

The stakeholder owns the problem and knows how to interpret the results. The facilitator construct the custom tools and ... facilitates the decision making.

Who is a stakeholder? Anyone related to the system. Architecture must be a continuous conversation involving all perspectives. Tools are essential to make current the situation explicit and accessible, but the most important part is what you do with the information once the cost of getting it drops to almost zero. The facilitator role is necessary, but it is the stakeholder that makes the difference. You want to internalize both of these skills.

What you get

You internalize the skills needed to know what your architecture is at any point.

You learn how to explain architecture to non-technical stakeholders.

You invest in architecture consistently by integrating in the development process on a daily basis.