SATURN 2017

Leave a reply

Another great SATURN (SEI Architecture Technology User Network) Conference in Denver last week. The cast of interesting and directly applicable topics was led by two main characters: microservices and event sourcing. Apart from those leading roles, there were supporting roles for functional programming, and of course the popular returning role for good old uncle agile architecture. Below is a day-by-day account, with links to the video recordings for each of the sessions discussed.

Tuesday: details and crowdsourcing architecture

A great start with a keynote from @KevlinHenney, stressing the need for attention to details – even (or especially!) for architects. As Edsger Dijkstra wrote, “The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.” Sometimes architects hide behind the “architecture as an abstraction” definition as an excuse not to go into details. However, sometimes the devil is in the details, meaning a tiny detail may have substantial risk and cost impact – meaning it is architecturally significant (according to Risk and Cost Driven Architecture).

The highest impact speaker this year was undoubtedly Sebastian @vonConrad, whose first session had some great tips about being an influential architect among 23 fully autonomous teams. If you have no decision authority, influence the decision makers (in the teams). And people are most likely to be influenceable when you help them. Sebastian did this by setting up an architecture guild, facilitating inter-team knowledge sharing and peer reviews based on very light-weight architecture documentation for projects (“project docs”) and architectural vision (“light on the hill”). Especially his approach for setting technology standards without stymieing innovations (“sensible defaults”) was refreshing. (I unfortunately had to miss Sebastian’s second session on event sourcing because it coincided with my own session on architecture life cycles – but I will certainly watch the recording once it is published.) Later that day, Stefan Toth (@st_toth) spoke about more or less the same topic under the title “the distributed architect”. Stefan presented a very nice model to decide how “crowd-sourced” your architecture can afford to be, with four levels of central roles: fully crowd-sourced (no architect), architecture marshalls, an architecture owner or the classic architect.

Wednesday: microservices and functional programming

This year’s highlight in terms of usefulness to me was Chris Richardson’s (@crichardson) keynote “There’s no such thing as a microservice“. I have seldom seen one of the field’s rockstars explain a concept so clearly, pragmatically and especially objectively.

Architectures are made to fulfill quality attributes. The quality attributes a microservices architecture is optimized for are all related to development velocity. The price you pay for this velocity is complexity – and it’s not cheap. Making the microservices themselves loosely coupled and simple means that all the remaining essential (coordination) complexity will end up in the surrounding architecture. Chris then went on to introduce his pattern language – a set of architectural tactics meant to address this complexity concern. The most interesting of these patterns was event sourcing, a tactic to avoid microservices having to access common data or using two-phase commits on transactions (often required by business logic). Chris also gave a very pragmatic rule for optimizing the size of a service in a microservices architecture (because “there’s no such thing as an individual microservice”):

  • small enough to be delivered by a small team
  • big enough to have meaningful business functionality

George Fairbanks (@GHFairbanks), one of SATURN’s organizers, won this year’s new directions award for his talk on functional programming, which appears to be coming back in fashion (remember LISP?). George explored the ramifications of this programming paradigm on the architectural level, in a fun way (which included a marbles game).

At the end of the day, I presented at a very interactive session in which we went looking for the common ground between architecting in an agile versus more traditional, project-governed context. Organizations sometimes can be rather sensitive about the words they use to describe elements of architecture work (e.g., “is the solution defined in a project intake form, an epic or a saga?”). In order to stay away from this loaded terminology, I used the metaphor of a human lifetime to analyze how architectural activities and decisions evolve over a solution’s life cycle. I am considering using the response I got in that session to write a little dictionary to help translate between “agilese” and “projectese” language…

Thursday: event storming and architectural decision records

The final conference day started with @RuthMalan‘s acceptance speech for winning this year’s Linda Northrop Software Architecture award. My successor made a passionate plea for visualizing designs that should be based on objective reasoning.

After a hilarious bout of slide roulette, I attended @ThePaulRayner‘s session on event storming, a workshop form for soliciting requirements from stakeholders built on the concept of events (rather than business objects) as the primary entity. It resonated nicely with my plea for time as a first-class citizen in architectural design. Paul’s method seems to be mainly focused on business scenarios, it would be nice to try it out as a way of soliciting change scenarios for architecture roadmapping.

Later, @michaelkeeling gave a nice report of his work introducing architectural decision records (ADRs) in his team at IBM Watson. He observed that modules that have documented ADRs appear to have less rework and greater general design awareness. He gave a series of nice tips in software development teams: — Store with the code, use plain text — Delegate ADR creation — Peer review as you would code — Foster a documentation habit — Make a decision, then document it — Not everything is an ADR! My own experience with ADRs is mostly in a higher level solution architecture context, but points to the same general principles: the threshold to documenting ADRs should be as low as possible, so try to store them in a tool or platform that your team is accessing on a daily basis already – and then coach them.

This was my fifth SATURN conference, and just like the previous years I returned home full of new ideas and inspiration, and with many useful new contacts. You can find recordings of all sessions on the SATURN YouTube playlist.I am already looking forward to the 2018 edition in Plano, TX.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.