I quite liked the way the talk was laid out - Dan laid out a series of problems that he’s seen on some projects he’s worked on and then showed on the next slide where he planned to take the architecture. The rest of the talk then detailed the story of how the team got there. To begin with it was a case of SOA gone bad with clients heavily coupled to services via WSDL definitions, a lot of code duplication, a complex/flaky architecture featuring a non standard JBoss and a team where the developers worked in silos. The aim was to get to a 'good SOA' where the services were actually helpful to clients, the code would be stable in production/deterministically deployable and a happy team would now exist.

The role of an architect is to play a key role in design, to be the technology expert on the team, to act as a coach and a social anthropologist/shaman. An interesting theme for me in the talk was that so much of it centred around the human aspects of architecture. I guess maybe that’s obvious but a lot of what I’ve read about architecture comes from the technical side and providing the technical direction so it was refreshing to see a different approach.

As mentioned above, Dan spoke of the need to have a project shaman - someone who can share the history of the project and why certain decisions were made on the project and explain those to people when they join the team. It can be the architect but it doesn’t actually matter as long as someone on the team assumes the role. Another colleague of mine pointed out that this role is also about envisioning the future of the system. As with most things when we know the context in which something was done the decision doesn’t seem quite so stupid.

One of the interesting ideas which Dan spoke of was that of having a transitional architecture on your way to the architecture that you actually want. You know that it’s not the end goal but it’s a much better place to be than where you were and can provide a nice stepping stone to where you want to be. The example he gave was refactoring the architecture to a stage where the services could be accessed via a service locator. It’s never going to be the end goal but provides a nice middle ground.

Dan provided quite an interesting alternative to the 'yesterday I did this, today I’m doing that...' style of standups which I haven’t seen used before. The idea is that the team consider what would make today the best possible day in achieving their goal, and then going around the circle each team member adds in information that will help the team teach that goal - be it stuff they learnt the day before or areas that they have been struggling in. He also spoke of the idea of people helping each other rather than pairing to try and get past the reluctance of having two people working on the same machine.

The idea that you you get what you measure was also mentioned - if we measure the performance of developers by the number of story points they complete then we increase the chance that they’re just going to finish stories as quickly as possible without caring as much about the quality of the code being written potentially leading to more buggy code. I’m interested in reading the Influencer to understand more about this type of thing.

Dan pointed out that we should never write caches unless that happens to be our differentiator - they’ve been done loads of times before and there are plenty to choose from. This ties in with the Domain Driven Design idea of focusing our efforts on the core domain and not worrying so much about other areas since they aren’t what makes us special.

It was also pointed out that we won’t fix everything on a project. I think this is a very astute observation and makes it easier to work with code bases where we want to make a lot of changes. At times it can feel that you want to change just about everything but clearly that’s not going to happen.