In a microservices architecture, services shall be as loosely coupled as possible. Still, they need to communicate with each other in order to fulfill business requirements. Now there are so many questions around this communication (synchronous vs asynchronous, event-driven? what is the influence on the coupling of your services? ...?). This talk will help you answer these questions for your project. You will better understand not only the architectural implications but also the effect on the productivity of your teams.

Target Audience: Architects, Engineers, Developers
Prerequisites: Basic experience with distributed systems
Level: Basic

Extended Abstract:
In a microservices architecture, services shall be as loosely coupled as possible. Still, they need to communicate with each other in order to fulfill business requirements. Now there are so many questions around this communication:

1. What are the general possibilities to communicate? For example synchronous, asynchronous, or event-driven communication. What are the tradeoffs and which communication style should you prefer?
2. What is the influence on the coupling of your services? For example, asynchronous communication reduces temporal coupling between services.
3. What do I have to consider when selecting a certain communication style? For example, you need to apply certain resilience patterns if you want to use synchronous communication.

This talk will help you answer these questions for your project. You will better understand not only the architectural implications but also the effect on the productivity of your teams.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/bernd.ruecker

**TL, DR;** Embrace no-code to explore more models and throw most of those models away. You will quickly discover what works, and what matters, in the business process that you are automating. If it matters enough, you can extract it into a high-fidelity design in code.

Target Audience: Everyone with a stake in the software production process
Prerequisites: None
Level: Basic

Extended Abstract:
Many software projects still consume considerable resources, and take a long time before anything material is put in the hands of the end-user. At a smaller scale this happens with teams that have the ambition to adopt Domain-Driven Design principles but that lack the expertise and experience in how to approach the design process. There is a spectrum of mistakes. On one hand there is the lack of producing a meaningful and shared model that is able to unify the conflicts and handle the complexity that the messy world will serve the system. On the other end of that spectrum there is analysis paralysis: a model that never sees the light of day, because there is always a new case it cannot handle. If the team doesn't produce a meaningful model, or if it fails to put that model in front of experts early on, then the team robs itself of precious feedback. "Judge models by their usefulness" is a mantra that is difficult to live by, if the model isn't being used...
Despite warnings, teams design big architectures early on, to support even bigger ambitions of the organization they work for, but they forget that it's not the architecture that the end-user cares about. With every bit of structure that is added early on, the team reduces the degrees of freedom to evolve the system at a later point in time. In order to support long-lasting design that is attuned to the environment, teams should set architectural principles that allow for a helpful structure to emerge, regardless of the platform.
> **No code** has entered the chat...
For a while now, no-code vendors have been telling organizations that they shouldn't be limited by expensive software engineers to build systems that are useful. No-code aims to commoditize the software production process. Commodification of technology leads to value if it removes a limitation, but successful adoption only works if the rules and policies that initially helped us overcome the limitation are replaced as well. Practices such as DevOps have to be adopted in order to reap the benefits of the commodification of compute and storage in the cloud. In order to benefit from serverless, system components need to be decoupled through message-driven designs. In order to benefit from no-code, people have to organize around the software production process in a different way.
Within software engineering communities no-code has been dismissed as a fad, saying the need for writing code will never go away because the needs of most software systems are too complex to capture in a visual design environment. This viewpoint ignores the argument that software engineers act as a gatekeeper, a limitation for the stakeholder to get what they want. It is reductionist to say that no-code means no-code. No-code is as much about no-code, as wireless is about the absence of wires, or serverless is about the absence of servers. No-code means less boilerplate. And no-code does NOT mean no-model.
The inability to deliver meaningful results in a reasonable amount of time is never out of bad intent, it's the consequence of rigidity in the system of work. If there is no room for experiments, for error, for trying again, then we shouldn't be surprised if people attempt moonshots. But if we can reduce the cost of experiments, then we should be able to iterate more, learn faster, and as a consequence produce more value.
Let's explore how no-code is able to remove the time to market of our ideas to explore new models. Join this session to uncover which rules, policies, and practices around modeling and design need to be replaced in order to reap the benefits that no-code has to offer.