Interact – how Can I Imagine Interactions with the System?
At the Architect stop, we dealt with software and team architecture; this stop is an ideal transition to more technical topics.
On the one hand, this stop deals with architectural topics in greater detail (e.g. service-oriented architectures) and, on the other hand, it defines how to get from the considerations of the Architect stop to concrete implementations.
At this point, the distinction from the Communicate stop is probably also interesting. As the name suggests, the focus of this stop is on the interaction with the overall system or the subsystems with each other; it is not about how systems communicate with each other in detail.
The delimitation becomes concrete using the example of the topic “API Design”. Among other things, this stop focuses on how the interaction between systems is designed via APIs. This includes, for example, the development of an API Design Guide. The definition of the communication or communication technology between systems is not the focus here.
Or to put it another way:
It is about describing how, for example, APIs are designed (i.e. how to interact with a system), but not about what the specific communication technology (e.g. “HTTP”) will be.
Although these two stops usually complement each other, practice has shown that, especially in brownfield projects, the topics of one stop are often already predetermined and therefore the focus makes perfect sense.
What Can I Expect from this Stop?
The Interact stop includes the following topics:
Thanks to the results from the Architect stop, it is clear which types of interaction a system and its subsystems must support. This means that the fundamental question of whether a system is designed for interaction with people and/or machines, for example, has already been clarified.
Therefore, this stop can focus on which type of interaction has the higher priority and how the system is structured internally.
If, for example, a system serves almost exclusively as a backend system and only minimal administration interfaces are required, the main focus will be on API Design and Management.
Furthermore, in the course of this stop, it will be decided what the concrete form of a service-oriented and/or a data-oriented architecture will look like.
Why should I Stop at this Stop?
An experience with the system that fulfills the needs of the user is essential for the success of the system and therefore crucial for business success. This applies regardless of whether the primary user group of the system is machines or people.
The internal structure of a system, in turn, has a massive impact on the resilience, scalability, interoperability, availability and performance of a system and must therefore be kept/brought in line with the architecture goals.
How Does this Stop Work?
The Architect stop forms the starting point of this stop. In particular, the following topics of the Architect stop must be clarified in order to successfully complete this stop:
The concrete target architecture is defined on the basis of the architecture goals to be achieved. The verification – whether the goals have been achieved – is possible using quality scenarios.
A strategy for interaction from the outside is derived from the system context and a strategy for interactions within the system is derived from the context map.
The read models, which were “discovered” in the course of Event Storming workshops, provide information about when and how a user interacts with the system.
The API design takes place in accordance with the ubiquitous language. An API-first approach usually pays off, as it enables, for example, the implementation of API consumers and producers in parallel.
At the end of this post, there is a little teaser for the next blog post 😎:
In order to make the contents of this stop even more tangible, in the next post we will delve into the topic “Interact: ServiceMesh and MultiCloud demystified“.
More Blog Posts
Vienna, October 1, 2025 – FULLSTACKS, the leading provider of DevOps, Observability, Cloud-Native, and Security in the DACH region, is presenting its new brand image as of October 2025. [...]
In modern IT landscapes, transparency is the key to stable, reliable, and efficient services. Lack of visibility often leads to critical incidents being noticed only when they are already [...]
What is Changing? Bitnami is changing the way container images are published and used: Instead of managing dozens of immutable, version-specific Docker tags in the public Bitnami registry, [...]
Vienna, July 25, 2025 – FullStackS has reached an important milestone in its corporate development: As the only partner in the German-speaking region, FullStackS now holds the Splunk [...]
The financial industry is under immense pressure to change. Regulatory requirements such as DORA, the constant demand for digitalization, and the increasing need for cybersecurity and compliance challenge the [...]
Full Transparency. Real-time Overview. Proactive SAP Monitoring. Our SAP monitoring solution combines Splunk ITSI with the SAP-specific monitoring engine CSMon and customized dashboards from our partners Consult/R and [...]
Why are Standardized Pipelines a Game Changer?Maintaining CI/CD pipelines can quickly become confusing and redundant in larger organizations, especially if each project uses its own templates or manual pipeline [...]
FinOps as a Long-Term Lever, not a One-Off Project Many companies have successfully implemented FinOps and realized initial savings potential. However, the real challenge begins afterwards: How can [...]
Orlando, March 11, 2025 – FullStackS is pleased to announce that they were awarded the title of "Cloud Elevate Partner of the Year" at the SUSE Partner Summit [...]
Intro: how FullStackS Sustainably Operationalizes the Topic of "FinOpS" in Companies. Many companies recognize the importance of FinOps, but the real challenge lies in its implementation. Theory and [...]