“We cannot change the wind, but we can adjust the sails.” This 2,300-year-old sentence is often quoted and is said to be from Aristotle. But there’s circumstantial evidence that Aristotle never said or wrote this sentence.

Nevertheless, this aphorism can be appropriately abstracted to projects in software development, especially in medium and large companies. As a software architect, every day I experience a solution whose success depends on countless factors. In addition to the classic magic project management triangle—budget, time, and quality—a team’s skillset and corporate culture also determine the success or failure of a digital project. The underlying software architecture can also have a major influence. In many projects, this is viewed more from a technical perspective. But if we take a closer look, there are other interesting, relevant issues for software development.

Where does architectural work begin and where does it end? Who is responsible for the architecture? What project status must the architecture become finalized and available to software development? Or can software development even influence the existing architecture? How should feedback be handled? What additional challenges arise when working on architecture in distributed systems?

We’ll show you how to set sail for software development success by better aligning your software architectur

Agile Architecture

The Society of Computer Science defines software architecture as the “ fundamental organization of a system, represented by its components, their relationships to one another and its environment, and the principles that govern the design and evolution of the system ”. Therefore, architecture decisions have a high impact on the software product and are difficult to change later. This description could mislead us to believe that architecture is created top-down—once at the beginning of the project. But the opposite is true!

In the context of agile projects, architecture is also created iteratively in increments. Similar to Scrum or Kanban in agile software development, the architecture can also be built up, consolidated, and specified in more detail in increments. Architecture decisions are evaluated through iterations and adjusted, if necessary. Architecture work and software development remain close together and coordinate well. Ultimately, a decision must be made for each requirement about who should be responsible: architecture or development. The following graphic—commonly known as the “architecture pretzel”—visualises this process ( Fig. 1 ).

Fig. 1: Agile architecture work

Fundamental issues and corresponding risks are in the hands of architecture. The architecture creates a framework for implementation. Distinguishing between micro- and macro-architecture helps correctly classify requirements. For macro architecture, relevant requirements have to be supported by all or several teams simultaneously. The macroarchitecture provides a scope for decision-making and sets guard rails for further decisions. These can then—at the level of microarchitecture—be decided in individual teams. Now, we’re at the microarchitectural level. Usually, problems at the macroarchitecture level are discussed by team leads or by interdisciplinary teams in regular “Communities of Practice” while working on solutions.

But architectures aren’t created behind closed doors; instead, they’re created and communicated in close consultation with development teams. Feedback from development is essential and must be incorporated into future iterations of architectural issues so newly gained insights can contribute to the architecture’s optimization. Accordingly, architects shouldn’t find themselves in the captain’s role, but should be part of the crew.

There are issues I’d never leave to individual teams or an architecture Community of Practice. These include selecting enterprise middleware or a cloud provider. This is where enterprise architecture comes into play, or more specifically, technology architecture. Here, the staff unit is tasked with selecting technologies and platforms on the basis of company regulations and framework conditions. For example, a German financial services provider is bound by specifications of the German Federal Financial Supervisory Authority (BaFin), which restricts their cloud provider choice. These cost-intensive architectural decisions have to be made strategically and in the long-term. Therefore, they do not belong in the software development process or at the macroarchitecture level. Nevertheless,

Architecture works in distributed system landscapes

Over the past few years, literature, magazines, blog posts, and many other kinds of media in the IT scene have vigorously promoted distributed systems. Architectural styles like self-contained systems and microservices are very popular. Again and again, I notice that my customers have high expectations about working towards a “renovated” system landscape. After all, they’ve invested a lot of money. Therefore, many clients get nervous when the software development process takes longer than they expect. With cloud-native software, operations costs become transparent, while a large cost center is created in a company’s data center and individual products and resources usually can no longer be allocated.

In distributed systems there are also a lot of artefacts that need to be maintained, making the solution more complex. Things like this don’t exactly have a beneficial effect on speed when developing a software product. Although applications themselves become more small-scale, the amount of moving parts and multiple dependencies increases, and the overall complexity along with it.

To clarify: Evolutionary architectural styles like microservices are intended to reduce domain complexity. But this doesn’t reduce the overall complexity. Rather, it shifts some aspects from maintenance and operation around deployment, orchestration, monitoring, integrating individual applications into existing, surrounding systems.

The service cut of distributed service-oriented systems shouldn’t be underestimated for its importance for software development. System boundaries which are just arbitrarily designed, or simply cut along the corporate organizational structure can lead to unspeakably bad, unmaintainable software design. I’ve experienced this often! Consequences and the extent of them often only become visible in the project later. The later a bug is found in a system, the more costs increase. The same is true for incorrectly designed service cuts in a distributed system. Large-scale refactorings at this level are costly and time-consuming.

Exorbitant interface communication can be the first indication that the service cut was not correctly chosen. Collaborative methods like Event Storming or Domain Storytelling can help work out the service cut.

In my teams and in workshops, I always work iteratively with collaborative methods to ensure I achieve a future-proof, resilient level of detail. We anchor these in the agile software development process. This means that over iterations and increments, knowledge about the technicality gains detail and becomes more specific. In addition to improved service design, Event Storming and Domain Storytelling also contribute to a better understanding of the business being implemented. Take the following as an example:

With two competing groups in the e-mobility environment, we needed some discipline before we developed a feel for the right service cut in distributed architectures. In the end, this discipline was rewarded with a promising software product that all sides could be proud of.

Both groups used a similar technical environment. Group A established Event Storming as a fixed component in its software development process, which greatly simplified coordination between development teams. Its advantages are obvious:

• Communication effort decreases: Both verbal communication between teams and technical communication between individual services are reduced.
• Faster time to market: If individual services are developed quicker, it accelerates the digital product’s time to market.
• Cost-saving: Since less technical communication is required between individual services, operating costs are significantly lower.
• Fewer errors: The less technical communication is required, the smaller the potential for errors is.

Making the right choice as an architect

Architecture work often involves weighing many options. With the amount of technological diversity and heterogeneity defining the market (which is constantly increasing), it’s not always easy to make the right choice. As I said, intuitive decisions can quickly backfire, especially since it’s difficult to justify decisions to project stakeholders. So how do we make a correct, well-founded decision when selecting technology so we can confidently defend it against other project stakeholders’ opinions?

Let’s take a look at the DNA of a decision. A decision is based on criteria, framework conditions, actionable options, and subsequent evaluation:

• Criteria are the goals we want to achieve with the decision.
• Framework conditions are things that have an influence on an action and are not changeable.
• Actionable options are the possibilities available to us.
• Evaluating the actionable options takes place with regard to our criteria.

So much for our theory. But what does this decision-making process look like in practice? I’d like to give a typical example:

• Criterion: With one of our customers in the e-mobility environment, two teams needed to exchange data about their services. For the specialized department, a reliable exchange was more important than a fast response rate.
• Framework conditions: We received a brief request that the new solution use the company’s existing technologies.
• Actionable options: Two courses of action were up for discussion. Variant A: Interfaces communicate asynchronously via middleware (Kafka broker). Variant B: Interfaces communicate synchronously via HTTP (REST).
• Evaluation: Since a highly available middleware like Kafka is more reliable than a synchronous call, we decided to use asynchronous communication via a Kafka broker in this project.

Document decision-making paths

To have it written in black and white, architecture decisions can be recorded and published in decision logs. Here, the decision path is fully documented and made accessible to project participants. This way, we prevent decisions from being influenced too much by personal experience and knowledge. In retrospect, maybe you would have made a different choice, but based on the level of knowledge at the time, the decision was understandable. We have to keep reminding ourselves of this. We often make assumptions about unknowns to reach a result quicker. Decision logs help us reflect upon our decisions and re-evaluate them from time to time so we don’t get stuck. This increases our flexibility and we can respond to changes at all levels better. The principle of “solution before perfection” applies.

Accuracy in statements

To the same extent, a reliable exchange was more important for our customer’s specialist department than a fast response rate. At first, similar requirements from the specialist department are specified sparingly. We need more precise statements for architecture decisions and software development. Working out these kinds of quality characteristics (standardized by ISO 25010) together with specialist departments is the art of software architecture. Values ​​product managers expect from a software product can be derived in workshops or interviews. These values, or quality features, like reliability, efficiency, security, and performance (to name only the best known), are what ultimately decide the architecture.

Conclusion

Architecture work is required at various levels in order to build software solutions that are effective for the future. In this article, I’ve explained why this is and what it can look like in practice.

I’d like to summarize the most important points again as a reminder and guideline for action. The more points you can tick off, the better your architectural work will be:

• We should firmly anchor the topic of architecture in our software development teams, through interdisciplinary teams, for instance.
• Far-reaching and cost-intensive decisions like choosing a cloud provider should be made by enterprise architects.
• Cross-team exchange in the form of communities of practice and collaborative methods should be encouraged.
• Specialist departments should be involved during the software product’s creation process as early as possible.
• Architects should support the requirements specification by developing quality characteristics together with Product Owners.
• Architecture decisions should not be given top-down to development teams. They should be specified iteratively, with feedback from development teams, verified and documented in decision logs, and made available to all stakeholders.