Architect – What Will My Cloud-Native System Look like?

Before we actually embark on the journey towards “Cloud Nativeness”, the following section aims to provide an understanding of how this journey will unfold.

It is also certainly interesting to know when the journey should commence (the question of whether it should commence is de facto no longer relevant in 2023 😉). The CNCF provides a reference overview that can be accessed via the following link:

https://github.com/cncf/cartografos/blob/main/reference/prologue.md#when-is-the-right-time

General Information on the Journey’s Flow

As already described in the introductory post, the starting point is a “Discovery Workshop”. The goal of the workshop is to gather sufficient information on the following topics to plan the next steps:

Overview of Domain-Specific Challenges
Architectural Goals
The current System Context
Security-Governance-Risk-Compliance
CNCF Maturity Model

Based on the workshop results, a plan for the sequence of individual topic blocks / waypoints of the Cloud Native App Journey is developed. An assessment based on the CNCF Maturity Model is optional but significantly aids in prioritizing the waypoints.

Naturally, only the waypoints that are actually required to elevate the desired dimensions (according to the CNCF Maturity Model) to a new level will be “visited”. The waypoints serve only as a rough guideline; it is understood that topics from other waypoints will be flexibly addressed if it is sensible or even necessary at the respective time.

If no assessment has been conducted, we have two general recommendations for the order of the waypoints:

Greenfield Projects: Architect – Experience – Exchange – Interact – Communicate – Protect – Observe – Deliver

Brownfield Projects: Observe – Deliver – Protect – Experience – Architect – Interact – Communicate – Exchange

Greenfield Projects: Architect – Experience – Exchange – Interact – Communicate – Protect – Observe – Deliver
Brownfield Projects: Observe – Deliver – Protect – Experience – Architect – Interact – Communicate – Exchange

Now that the journey’s process is known, we can proceed to the first waypoint of our journey 😉: The Architect Waypoint.

What Can I Expect from this Waypoint?

The Architect waypoint includes the following topics:

Requirements & Architectural Goals
Domain Model
Teams & Collaboration
Constraints & Conventions
Cross-cutting Concepts
Solution Strategy

Based on requirements and architectural goals, the system’s architecture is designed and documented. We differentiate between strategic design and tactical design.

Strategic design can be imagined as planning a city (the system), where it is important to have a rough understanding of the districts (the subsystems) and how they are interconnected (applied to a software system: it is about determining which subsystems will exist and how they will communicate with each other).

Tactical design, in turn, focuses on the internal structure of a subsystem. It is crucial that the code representing the business logic never mixes with technical specifics. We therefore generally advise opting for a lightweight adaptation of the Clean Architecture.

From the strategic design, in combination with the architectural goals, a solution strategy for the overall system can then be derived.

However, the development and documentation of architecture is not a one-time event. It is not about defining everything in advance; rather, decisions should be recorded at the time they are made. The architecture then emerges from architecture-relevant decisions, which are continuously made and iteratively revised.

Through this approach, the documentation is not a static “paper” that quickly becomes outdated after publication, but rather a collection of documented principles and decisions that helps to understand and communicate the structure of the software system.

Why should I Make a Stop at this Waypoint?

The architecture of a system is usually difficult to change without significant effort. Therefore, the effort invested in architectural development and documentation, not only initially but throughout the entire lifecycle of the overall system, typically pays off multiple times. The overall system remains maintainable, developer motivation stays high (as they do not have to work with a “legacy system”), potential pitfalls can be identified early, and quality continuously improves.

Furthermore, in many companies, peak loads are often cushioned with the help of external developers, systems are subjected to external reviews, or the company is exposed to increased fluctuation and, in the worst case, the “loss” of knowledge silos. Without transparent and traceable documentation of decisions, these challenges cannot be adequately addressed.

The architecture must not only be incorporated into the software but also align with teams and their collaboration. Otherwise, one will quickly be caught up by Conway’s Law, and the “beautiful new architecture” will either not be adopted at all or, in the worst case, lead to a Big Ball of Mud.

This means that not only the software system undergoes a transformation, but also the team and communication structures must evolve. Otherwise, teams will be overloaded and/or further development will be paralyzed by unadapted structures and processes.

How Does this Waypoint Proceed?

Regardless of whether an existing system is re-architected or a new system is implemented, it is essential, as already mentioned, that architectural development and documentation are carried out collaboratively and iteratively from the outset. We recommend relying on the concepts and ideas of the following de facto standards:

arc42 provides a traceable and transparent guideline for the process model and documentation.
Domain Driven Design for the development of a cloud-native software design based on domain-specific problems, as well as the introduction of a truly ubiquitous language model (consistent and context-dependent naming of terms from the domain problem to the code).
Team Topologies for optimizing team structures, including their interactions, in mutual coordination with architectural development.
Architectural Principles and/or Architectural Decision Records in combination with a “Community of Architecture Practice” (CoAP) to ensure collaborative, iterative, and traceable architectural development in the long term.
- When and how architectural principles are applied often depends on the company’s size and structure. A possible scenario, for example, would be for the CoAP to deal with architectural principles, and the teams, derived from this, independently make concrete, tailor-made architectural decisions for their team.

The list outlines the proposed process:

1

To gain a common understanding of the domain-specific problem (domain), we start with an Event Storming Workshop.
2

The workshop results are documented using the arc42 template; the template can subsequently be used as a guideline for further architectural development.
3

Based on the workshop results, adaptations within the teams are initiated using the ideas from Team Topologies.
4

Establishment of the “Community of Architecture Practice”, so that every architectural principle and/or architectural decision is collaboratively defined from the outset.
5

Once the initial decisions have been made, they can already be incorporated into the code, and the feedback from this can, in turn, “flow back”.
6

The further process is essentially a repetition of the previous steps, where the system and the teams are continuously refined (refactoring toward deeper insight).

Thus, we are ready to proceed to the next waypoint. In line with the motto of individuality, I would be pleased to receive suggestions for the next waypoints 🤓.

Simply by email to: konrad.renner@fullstacks.eu