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
  

Rapid Releases - Chatting with Sam Newman

I'm at GOTO this week and I got the chance to sit down with Sam Newman who's doing a talk on rapid releases tomorrow, which I already expected will be really good. My chat confirmed this. When I read the abstract for the talk I got quite interested, because Sam touches of something that I've spent some time thinking about too: How does the software architecture/design of our systems effect our ability to push out software quickly?

I started off asking Sam to give the elevator pitch for why everybody should go to his talk tomorrow. Paraphrasing we should go because most people - when designing systems - start off thinking about "the traditional" set qualities (scalability, availability security, performance and so on), but ignore "ease of change". Ease of change should often be an important quality attribute though, since this is a necessity for speeding up release cycle. In the talk Sam will go into some techniques, or patterns if you will, that can help you move towards making small incremental changes to your systems easily. Which is what you need to do if you want to move to a continuous delivery (or even deployment) model.

I got the impression that Sams talk supplements most of the other talks about continuous delivery, that you might hear, because most of those talks focus a lot on the build pipeline and on automating IT infrastructure, whereas his talk goes into the architecture and design of the system. This angle is important (too). In fact in Sams experience working with clients wanting to move towards continuous delivery some of the first steps most teams need to make are around the software architecture  That is, often he sees situations where there are architectural or design problems in the system that either seriously slows down the development or which hinders doing changes in small increments, which in turn hinders doing small, focused, low risk releases, which ultimately hinders releasing rapidly.

Part of the cure for this is to go into the systems and cutting them up into small well factored services. Aka (in my words) doing SOA right. I asked Sam how this related to DDD - my thinking being that these services follow bounded contexts. The response to this was pretty interesting I think: Sam agrees that these well factored services will and should follow bounded context boundaries  but points out that the way to get there is not by focusing the services around entities or even aggregates, but rather around business capabilities. I think that is a really helpful way to put it.

As I said, talking to Sam only made me more keen on going to his talk, and if any of the above resonates I'd encourage you to go too. I'm sure it'll be both fun and educational.