5. The systems architect as a facilitator

Why it matters

If you are an Architect, you have a set of responsibilities. What differs in an Agile organization is that you will have teams around you with more in depth knowledge about the solutions than you do. Your primary task is to create alignment and engagement. This is managed by the Architect as a Facilitator .

There are two ways to create a divergent architecture when there is no alignment and when there is a lack of engagement (when teams don’t give a flying f@#*). “Ivory tower” architects try to create alignment using hard directives, but they totally fail in creating engagement, which means the “ivory tower” architecture is usually ignored anyway.

This can be avoided by shifting to Architect as a Facilitator.

How it works

The Architect’s Responsibilities

As an Architect, your job is to create alignment around an architectural frame for viable solutions.

The architectural frame has three key components:

1. A Technology Roadmap
   You have a responsibility to make sure that there is a technology roadmap. This is realized and put in place together with Agile teams. During this process, the Architect acts as a facilitator, by clarifying overall direction, pulling solution options from the Agile teams, and making sure that alignment decisions are being made when needed.
   
   
2. Principles, patterns, and tradeoffs that we follow
   There are two types of architecture, intentional and emergent. The technology roadmap is one example of intentional architecture. Emergent architecture comes from the solutions emerging from decisions we make as we build our system. Emergent architecture is guided by principles, patterns and tradeoffs.

3. Alignment and Engagement
   The third magical ingredient is achieving Alignment through Engagement.

Examples:

Principles: We build solutions using micro services. (an optional principle would be Serverless).

Patterns: In our solutions, we use Kubernetes to orchestrate containers. For communication between processes, we use REST.

Tradeoffs: We prioritize security over performance. Tradeoffs can also be used to guide technology choices, explaining which of the choices you are valuing and why. For example, we value open source and free databases (such as Postgres) over the performance and functionality that comes with vendor based (such as Oracle or SQL Server) in order to minimize vendor lock in.

With the use of the architectural frame, you as an Architect are essentially providing a guide for self-service.