Impressions from Software Architecture Open Space 2013

We ran the 2013 edition of the Software Architecture Open Space conference (SAOS) this past Thursday, and once again I am amazed how well the open space format works. Everybody there were both highly knowledgeable and keen to share. The combination is a goldmine of learning opportunity.

Topics
The topics covered this year were quite diverse. Ranging from the particulars of Docker.io to the most effective place in an organization for an enterprise architect to work.

Since there were up to 7 seven sessions running in parallel I did not participate in all discussions. Even so just looking at the topics I had the chance to discuss paints a broad picture: "Event Sourcing in practice", "Modeling in NoSQL DBs", "How to Build an Architecture that Enables Flow in Development", "Reactive Manifesto", "NoProcess Development", "Architects and Organizations" og "The Value of Contributing in Open Source".

Take Aways
What one takes away from an event like SAOS obviously vary a lot lot from person to person. Personally the main points I came away with were:

• I am not the only one that thinks that lean thinking can be applied to software architectures, not just organizations and processes. Hallelujah I am not alone :-P
  
• Confirmation that Continuous Delivery is slowly but steadily becoming mainstream
  
• A better understanding of the role of Enterprise Architecture in large organizations (and confirmation that EA is not for me)
  
• Lots of new good contacts
  
• Insights into concrete experience with introducing event sourcing to a team and which type of common hiccups to expect
  

Eyes Forward?

Over next couple of weeks I'm attending two conferences. Two very, very different conferences. The first one is the Software Architecture Open Space 2013 (SAOS) and the second is GOTO Aarhus.

• GOTO is a traditional conference where there is a divide between those who contribute content - the speakers - and those who consume - the attendees. SAOS is not traditional and completely erases that divide by demanding all attendees to contribute.
  
• The GOTO format is well known: The speaker prepares a talk based on his/her experience and expertise. The attendees flock into a room, sit down and listen for an hour - all facing toward the speaker. The SAOS format is less well known: Nobody prepares content beforehand, but everybody contributes to it during the conference. Session topics are found through brainstorming and agreed upon progressively throughout the day. For sessions attendees flock into a room, sit down and discuss for an hour facing each other.
  
• GOTO is big - lots of people, lot of tracks. SAOS is small - about 50 people, as many tracks as emerge.
  
• GOTO is well publicized. SAOS is invite only.
  
• GOTO focuses on teaching attendees about ideas or technologies that the speakers already know about. SAOS focuses on finding and developing ideas and techniques.
  
• At GOTO the networking happens in the proverbial hallways and at the social events. At SAOS networking happens just as much during the sessions.
  

It will be interesting to get to go these events almost back-to-back. I expect the two to be very different, but I also expect to learn a lot at both.

It is also interesting that GOTO has a fish bowl session on Tuesday. A fish bowl is in the same vain as the open space format used at SAOS. Whether it really works in such a large setting will be interesting to see.

And, by the way, in case you are wondering, SAOS is the successor to the Agile Architecture Open Space Conferences I've run the last two years. This time around I've had the good fortune of getting invaluable help from some awesome partners in crime (Nikola Schou-Pedersen, Jeppe Cramon and Jakob Bendsen), and I think the conference will even better this year.

Code and Lean

I've been toying around with an idea for a while. It's sort of half baked, but inspired by some good conversations about it at AAOSConf and GOTO I'm going to go out on a limb and sketch it out below.

Lean
Lean software development (LSD) has been around for a while. The Poppendiecks book took the teachings of Lean Manufacturing and turned them into a set of principles and tools for thought that made sense for software development processes. In contrast to most writings on software development processes the "LSD" book does not prescribe (or even describe) a particular process. Rather it describes a number of principles and a number tools, that can be used to analyse your current process in order to find out where it can be improved. LSD provides a framework for developing your own process that is efficient in your particular situation. The point is to continuously optimize the process towards faster delivery and shorter cycle times.

Software Architecture
What is a good software architecture? That's a hard question to answer. The following is an answer I've used for a few years now in connection with an architecture training course:

"A good architecture shortens the time between understanding user needs and delivering a solution. It does this by eliminating rework and by providing a de-facto standard framework based on the end user domain model." --James O. Coplien.

It's from Cope's Lean Architecture book, and it's about optimizing for cycle time and for fast delivery. But how? How does a software architecture help optimize for fast delivery? I think some of those tools for thought from LSD can help us out not only if we apply them to process, but also to the software architecture and to the code.

Value Stream Mapping in Code
First and foremost I think we can learn a lot about what makes a good software architecture by applying value stream mapping to our code bases. What I mean by this is: Map out what needs to be done in the code for a typical feature/user story/use cases - whichever is your unit of work - to be implemented. Then take a look at which steps takes about which amount of effort.
Note that when I say code here I include config-files, tests, deployment scripts, migration scripts and so on. Mapping this out gives us insights into which parts of the architecture needs to become better: Is most of the time spent dealing with a particularly hairy integration? Maybe that needs to be better isolated. Is a lot of time spent writing and rewriting data migration scripts? Maybe we aren't using the right persistence solution. Is it very time consuming to build out the GUI? Maybe that part of the code isn't testable enough. These are just made up examples. The point is that I think value stream mapping is a good tool to find those hot spots within the software architecture.

Seeing Waste
Another tool I think we can apply to the code is seeing waste: Basically this just says that we should be on the look out for anything that creates waste - in terms of effort or in terms of resources. Applying this to software architecture means asking questions like: Do we have methods or even whole classes or layers that just delegate to other parts the code without any additional logic? 'coz that's just wasteful. It takes time to write, it takes time to debug through, and it's takes (a little bit of) time to execute. All of that is waste. We then need to ask ourselves if that waste is justified by some other goal fulfilled by those delegations. If not they need to go.
Another useful question is if there are parts of the architecture that are only really warranted for a few features in the systems but impact all features. E.g. if 80% of the features in an application is basic CRUD, but we do all data access through repositories because there are 20% of cases where more than CRUD is needed. Then isn't it wasteful to funnel everything through those repositories? -Even simple code takes time to write and test. Any code that isn't clearly justified is wasteful.

Options Thinking
Options thinking - in my mind - applies pretty directly to code. Options thinking is about keeping options open while not just stalling. It's about finding ways to postpone decisions until more information is available without slowing down progress. This - in code - is done pretty directly with well designed abstractions. That's the obvious one. I also think techniques like feature toggles and a/b testing along with looking for minimal viable implementations support options thinking. These techniques can help with trying out more than one direction in parallel and getting real world feedback. If this is done quickly - e.g. by focusing on only doing minimal implementations - this allows us to postpone deciding between the different directions a little while and gather more information in mean time.

Pull Systems
Coding pull style: TDD. That's it.

Summing up these are not fully formed ideas. But now they are out there. Any feedback will be much appreciated.

Agile Architecture Open Space Conf 2012 - Impressions

I ran AAOSConf Thursday and Friday this week. This is the second year. And this is the second year my employer, Mjølner Informatics, has been kind enough to sponsor it all. Based on last year, going into this one I had huge expectations. Happily my expectations were met. Once again, I got to spend two days with a bunch of sharp minds and dedicated software professionals. That alone is great. But combining it with the fact that they are there to share, discuss and push their and each others understanding of that surprisingly complex activity called software development, and you get a very unusual opportunity for learning.

This years conference really confirmed to me that there is very real and very broad push for simplification going on. This includes trends like

• CQRS and ES
• Using document stores
• Cutting down on layering
• Chopping systems into thinner simpler slices
• Moving towards continuous delivery

Which were all hot topics that drove some very interesting open space sessions.

On the process side of things there were some very good discussions on the finer points of topics like adopting TDD, the value of co-location, DDD, the value of business alignment vs. the value of efficiency in software development and on managing technical debt.

On the one hand there are the broad trends, and on the other there are the detail pesky details of some of the really hard stuff: That's what makes the open space format great, it's so thoroughly tied to the actual practice going on in real projects, and people are so honest and sharing about their problems and successes that you get the inside track on both the direction things are moving and on which details are the problematic ones.

Enough on my experience with the conference. Here are a few of the tweets from other attendees:

Was pleasantly surprised by my first open space conference, #aaosconf. Great people, great discussions.
— Kristian Langborg-Ha (@klangborg) September 15, 2012

Thanks to all that participated in #aaosconf It was the most fun and educative conference in years. Thanks to @chr_horsdal for arranging it
— Jeppe Cramon (@jeppec) September 14, 2012

On my way home from #aaosconf. Great conference. Had som very interesting discussions, and feel very inspired. Thanks to @chr_horsdal
— Thomas Jespersen (@thomento) September 14, 2012

Seems we all had fun learning a lot. Thanks for that! Hope to see you next year!