Notes from “The Architecture and Modeling Learning Event”, Part 1

Vaughn Vernon Signature Series Live in Action (May 12, 2023)

Mirko Stocker
ZIO’s Blog
4 min readJun 2, 2023

--

The authors of Vaughn’s book series at Addison Wesley teamed up for a free online conference. “The Architecture and Modeling Learning Event” covered not only software architecture, domain modeling and API design but also business strategy and modeling, product management and loosely coupled messaging. The morning talks are featured here, Part 2 covers the afternoon.

Note that these are personal impressions; we do not aim to be complete.

“Domain Storytelling — Understanding Your Users by Drawing Pictures”

What a nice start to the day with stories at the fire pit told by Henning Schwentner! He introduced us to Domain Storytelling, a collaborative modeling technique comprising two main elements:

Domain Storytelling = Pictographic Language + Workshop Format.

The pictographic language is deliberately kept simple (actors-activities-work objects), so it is easy to pick up and one doesn’t get lost in the details of choosing among different arrows and forms of boxes. This simplicity is essential because while the domain experts tell their stories, the listeners (or artists?) draw these pictures on the fly in the workshop, applying active listening to minimize misunderstandings.

“The Idea of Product Architecture”

Steffen Hartmann ‘s talk was all about product-centricity. Products are a vehicle for value exchange, meaning customers get value (for instance, new capabilities) and companies get money. So thinking about products helps to align the technology with the business side. Product architecture then provides a shared mental model that allows:

  1. “The arrangement of the functionality of a product.
  2. The mapping from product functionality and features and their connection between each other and to business outcome.
  3. The specification of the required dependencies and the interaction between technology and product.”

We learned that this is not a new methodology, nor a roadmap, but rather a high-level representation of what’s important. This representation can serve as a strategic tool and starting point for domain modeling.

“Adaptive Socio-Technical Systems with Architecture for Flow”

Susanne Kaiser asked, “How to design systems that can evolve and thrive in the face of constant change?” She suggested a combination of approaches:

  1. Understanding the business landscape, for example with Wardley Maps.
  2. Team topologies to align teams for a fast flow of feature deliveries, supported for instance by platform teams.
  3. Strategic Domain-Driven Design (DDD), Bounded Contexts in particular to decompose big balls of mud.

This was a highly-paced talk supported by fantastic illustrations — definitely looking forward to the release of Susanne’s book “Adaptive Systems With Domain-Driven Design, Wardley Mapping, and Team Topologies: Architecture for Flow”.

“A Conversation on Continuous Architecture”

Eoin Woods talked about how architecture has become much more fluid and faster evolving in the past decade, with shorter release cycles, clouds, microservices and so on. But how can an overall architecture of a system be maintained without slowing down or blocking autonomously acting teams?

Traditional upfront software architecture might be of less value today, but of course, architecture is still needed, for example, there are overarching quality attributes (security, scalability), stakeholder concerns to balance and complex tradeoffs to make.

Continuous Architecture is one of the emerging responses to these challenges.

Continuous means that it’s not a one-off architecture but a stream of decisions.¹ The book’s six “Principles of Continuous Architecture” include:

  • Architecting products² and
  • Delaying design decisions until absolutely necessary.³

The four other are:

  • Focus on quality attributes
  • Architect for change
  • Architect for build, test, deploy, and operate
  • Model the organization of your teams.

“The Impact of Managed Services on Modern Software Architecture”

Joe Emison opened his talk with a slide that read:

There are no continuing education requirements in software development.

You may be wondering, and I certainly was, how this relates to the managed services mentioned in the title of this talk. Joe continued to talk about the impact that managed services have on how we build software. Managed services, for example, serverless offerings such as AWS Lambda or DynamoDB, have the advantage that server operations and preserving the uptime of services are taken care of by the cloud providers. Using managed services, scaling infinitely and never going down can make teams more productive.

The catch is that teams must learn and understand how these new technologies work to take full advantage of them. And that brings us back to the opening slide: Continuing education is essential, even if it is not officially mandated, for instance, by professional associations. Joe’s upcoming book “Serverless As a Game Changer: How to Get the Most Out of the Cloud” teaches us how to use managed cloud services effectively.

“Balancing Coupling in Software Design”

Vlad Khononov ‘s talk was about coupling. Coupling often has a bad reputation and everybody knows that it’s not good, so we want to decouple everything. For example, we might want to break large things apart into smaller units that can evolve independently. But without any coupling, there are no relationships between individual parts of a system. So what’s essential about (de-)coupling is that it doesn’t prevent us from making the changes that we need.

Coupling defines the relationship between components and limits components’ degrees of freedom.

Vlad continued to present different kinds of coupling, which is the topic of his upcoming book: “Balancing Coupling in Software Design: Successful Software Architecture in General and Distributed Systems”.

Mirko hands over the note-taking to Olaf at this point, see Part 2.

Notes

  1. Recorded using Architectural Decision Records (ADRs)?
  2. Does that ring a bell? Hint: see one of the previous talk summaries. 😃
  3. Maybe to the most responsible moment?

Originally published at https://ozimmer.ch on May 26, 2023.

--

--

Mirko Stocker
ZIO’s Blog

SE Prof (Cloud, Web, Programming Languages) @ OST; Partner @ Institute for Software; Co-Founder @ LegalGo