Another great SATURN (the Software Engineering Institute (SEI) Architecture Technology User Network) conference in Baltimore this year. The setting was a bit surreal – due to social unrest and a curfew(!) we couldn’t really explore the city during the conference, and were pretty much confined to the conference hotel. After three days of intense knowledge exchange, it was a pale, squinting collection of software architects that emerged from the Lord Baltimore Hotel – tired but satisfied. As predicted by George Fairbanks at the start, it was also the “most annoying SATURN ever” – in the sense that there were four parallel tracks, and whichever one I chose to attend, I always knew that there was at least one other very interesting thing going on in one of the other “salons”. Fortunately, many sessions were videotaped and can be viewed on-line.
Finally, software architects on the streets of Baltimore #SATURN15 pic.twitter.com/kDKnns1FG9
— Eltjo Poort (@eltjopoort) May 1, 2015
Last year‘s most prominent topic was DevOps, and it was still prominent on this year’s event. Another topic that keeps attracting attention is the interplay between architecture and agile delivery, the topic of my own two contributions. The rest of the sessions could roughly be divided in coding-oriented (in which MicroServices was the most discussed topic) and business-oriented subjects. I mostly attended the latter.
The conference opened with a great keynote address by Mary Shaw about the progress of Software Engineering as an engineering discipline. Mary had studied various engineering disciplines and abstracted a simple and elegant lifecycle, highlighting the growth of a discipline from art to production, commerce, science and eventually engineering. According to Shaw’s model, something is a real engineering discipline if the combination of science, art, production and commerce allows “ordinary” trained people to be systematically successful (as opposed to an art that can only be masted by virtuosi). Mary’s conclusion was “we aren’t quite there yet”.
Right after the keynote it was my turn to lead a participatory session on “Maximizing your business value as an architect“, and I felt priviliged that the room was packed with 50 practicing architects from all kinds of organizations. The discussions were lively, most participated vigorously in the exercise (“prioritize architectural concerns by risk and cost”), and almost all participants indicated they would be able to use the approach immediately in their daily work. I’d like to thank all participants for making this such a gratifying session.
On Wednesday morning, InspearIT’s Jochem Schulenklopper gave the presentation that would win the Architecture in Practice award: “Why they just don’t get it: communicating architecture to business stakeholders.” Jochem made some excellent points about the need for architects to learn and communicate in business stakeholders’ language. Learning a language is not trivial and requires exposure. And using a modeling language like UML or ArchiMate to communicate with business stakeholders is useless: you will quickly find yourself explaining the language in stead of explaining the architecture. After the session, even Len Bass indicated that he had learned new insights from Jochem’s talk – a true compliment! Wednesday afternoon started with another great keynote, by Gregor Hohpe: “It’s good to be architect”. Gregor had some very interesting insights into the value of architects to organizations, such as “If you make architecture a second class citizen, you will attract second-class architects who build a third-class architecture”. His metaphor of the “architecture elevator” immediately struck a chord: the value of architects can be measured by how many levels of hierarchy and abstraction they can traverse quickly. Good architects talk to technical engineers and translate their concerns in such a way that they get the attention they deserve at C-level. Conversely, they make the translation of policy and business goals all the way through to the levels below. Gregor posted his own SATURN impressions here.
Value of architect is measured by # of levels of abstraction and hierarchy they can cross quickly #SATURN15 G.Hohpe pic.twitter.com/DNQE8OONSj — Eltjo Poort (@eltjopoort) April 29, 2015
Thursday morning we discussed Fast and Slow Thinking for architects with Rebecca Wirfs-Brock: apart from “be aware of all your biases”, Rebecca had a valuable tip about using pre-mortems at the start of projects to fight some of the more dangerous biases. A pre-mortem is a group exercise in which attendants imagine they are in the future: the project has failed, and everyone describes the scenario that led to failure. A great remedy against WYSIATI (What You See Is All There Is), availability bias etc. I also gave my presentation “Agilizing the Architecture Department”, about our experiences implementing RCDA at ProRail.
In the closing keynote, Mark Schwartz of the US Citizenship and Immigration services gave a fascinating and very frank account of a large governement organization’s struggle to find the right architecture organization form to balance agile delivery with cross-system architectural reasoning. Is it Architect as Teacher? Architecture as a Service? The final verdict is still out…
Thanks to all participants who were cooped up together and made this another great SATURN. And it’s not over yet: we still have to watch the recorded trackes that we didn’t attend, so we’ll be busy for a while yet. Next year: San Diego.
Thanks for the great briefing this year. I just wanted to let you know that I’ve been thinking about your approach to agile architecture a lot since attending your workshop at SATURN 2015. Your message about shifting from documenting architectures to documenting architectural decisions really resonated with me, and I’ve been finding that that shift is very valuable to front-end architecting when you don’t have sufficient time to do it all — regardless of whether or not one is applying agile processes.
Thanks, Jane. You’re right, “agile architecting” does not just mean “architecting in an agile development context”. It also refers to improving the ability of an architect to respond to change in more traditional, waterfall-like contexts. Using “just enough anticipation” in maintaining your architecture runway is key to that agility, as is prioritizing your architectural concerns by risk and cost impact on stakeholders.