SATURN is the leading international conference for software architecture practitioners who look beyond the details of today’s technologies to the underlying trends, techniques and principles that underpin lasting success in our fast-moving field. SATURN offers a unique mix to learn, exchange ideas, and find collaborators at the leading edge of modern software architecture practice.

2017 marks the 13th edition of the SATURN conference, organised by the Software Engineering Institute of Carnegie Mellon University. This edition was held at the Hilton Denver Inverness in Englewood, Colorado, set against the backdrop of the majestic Rocky Mountains.

Pragmatic Architecture, Today

I was honoured to talk about Pragmatic Archtecture at SATURN 2017. I had done this talk a couple of times at developer conferences, so I was very anxious to compare the feedback to certain statements at an architecture conference. As it turns out, feedback was (surprisingly) similar:

• Architects nor developers are very fond of UML. Both emphasize the importance of communicating the architecture of a system to stakeholders, in a clear and understable manner.
• Virtually all architects have a developer background and want to be actively involved in code.
• Architects understand the necessity to play the political game. Developers might also understand this, but prefer not to participate in these, sometimes frustrating, discussions.

In general, I am very happy with this feedback and it shows that the two communities can (and have to) really work together nicely.

Software is details (Kevlin Henney)

On the first day of SATURN 2017, Kevlin Henney presented a very interesting keynote on details in software stating that everything is a detail, depending on the level of abstraction of a certain problem.

Marissa Mayer

Geeks are people who love something so much that all the details matter.

And these details can be very important. In Architecture, abstractions are necessary to focus on specific parts of a system. Modern software systems are often too complex to grasp all at once so we restrict our attenton to a small number of the software system’s structures. To avoid the obvious discrepancy between abstraction and detail, Kevlin quoted Tom Gilb stating that Architecture is a hypothesis, that needs to be proven by implementation and measurement. This illustrates the importance of collaborating as a team.

We will need to make decisions, given our current understanding of a certain problem. Implementing these decisions, might lead to new beliefs and insights for the architecture. If a plot works out exactly as first planned, we might not be working loosely enough to give room to imagination and instincts. This encourages looking at things from more than one point of view.

An in-depth look at event sourcing with CQRS (Sebastian von Conrad)

While Event Sourcing is not new, it never gained wide adoption and often is a source of confusion. However, now that microservices really have become mainstream, Event Sourcing is back on everyone’s radar.

Event Sourcing ensures that all changes to application state are stored as a sequence of events. Not just can we query these events, we can also use the event log to reconstruct past states. So event sourcing offers a different way of storing information, by expressing data as events. Sebastian went to great lengths to explain that this is how the real world works.

Sebastian von Conrad

Delete sucks.

Event sourcing is commonly combined with the CQRS (Command and Query Responsibility Segregation) pattern by performing the data management tasks in response to events, and by materializing views from the stored events.

Zooming in on CQRS, we can use the following definitions and best practices:

Reading with Queries

• Clients never query the events directly.
• Clients query denormalised projections that are optimised for querying.
• Projections are build with projectors that process the event stream.
• Projectors are decoupled from each other and don’t share any state.
• Projections are cheap and easy to build and rebuild.

Writing with Commands

• Clients never write the events directly.
• Clients express an intent to do something via commands.
• If replaying gets slow, performance can be improved by snapshots.
• Commands are validated by Aggreggates, which is a concept borrowed from DDD.
  • Aggregates fetch events from the Event Store, and replay them to reconstitute their current state.
  • If the Aggregate accepts the Command, it results in an event.

Event Sourcing with CQRS

• Event Sourcing makes you store business facts as the source of truth.
• Event Sourcing makes the system deterministic.
• CQRS and the Circular Architecture work well with Event Sourcing.
• Asynchronous reactors process the event stream and react to events according to business logic, outputting more events.

Conclusion

Event Sourcing potentionally brings a lot of value, but it’s important not to impose Event Sourcing on a team that:

• Lacks buy-in to try it
• Lacks stakeholder support
• Lacks intestinal fortitude

A related talk at SATURN, by Paul Rayner, provided a way to visualise large scale complexity using EventStorming. In EventStorming, developers and business experts use sticky notes to map out an event-based story of how a software system behaves. He recommended Alberto Brandolini’s book on EventStorming, to learn more on the concept. Paul’s slides are available here.

How to Gain Influence as a Software Architect (Adi Levin)

As a software architect, you need to deal with people: it’s important to encourage collaboration. As such, a software architect will need leadership skills and will need to know where he or she is on the leadership journey. John C. Maxwell talks about this journey to great length in his book “The five levels of leadership”. A nice summary is also available on his website. Adi shared a couple of really great tips:

• Express your trust in people
• Show your commitment
  • Never say I don’t care
  • Share responsiblity
• Admit your mistakes
• Let people know you understand them
  • Seek first to understand, then to be understood
  • Acknowledge people’s position
  • Encourage others to contribute to the design
  • Listen to people who disagree