Note: this is one in a series of posts under the category of “agile architecture”. In an earlier post, (Six Principles of Agile Architecture) we identified six principles that we can apply to help us reason about the challenge of architecting systems of scale in an agile enterprise.
In prior posts, we’ve discussed the first five principles (see thumbnail at left). In this post, we’ll discuss #6 – System architecture is a role collaboration.
In this series of posts to date, we’ve focused on the central role the teams play in designing and architecting systems of scale. For example, in Principle #1, we proposed that the teams that code the system design the system, so there could be no ambiguity about who had the responsibility for architecting the system – the team that is accountable for implementing it. If we stopped here, it wouldn’t be obvious that there is a role at all for those senior, domain experienced, system architects that play such a key role in many larger enterprises. This topic gets particularly entertaining, when as an agile proponent, I meet these people and hear their strong views about imposing architectural governance on the natural entropy of all those newly empowered (and sometimes relatively inexperienced) agile teams.
Most typically, these folks have deep technical and domain experience as well as the seniority, competence and authority to back up their opinions. Indeed they have a lot to add to the vision and implementation and it would be downright foolish of us to leave them out of the mix of what “makes an agile team a team”. Moreover, they have a strong influence on the process models the teams will adopt and if they are not supportive of an agile transformation, one may or may not take place!
Fortunately, enterprise agility is not a zero sum game and there is room for all who can contribute to the best possible technical solutions. After all, we are building systems of enormous complexity (even when we keep them as simple as possible), why would we not leverage the skills of those external team members who have the experience to match the challenges the teams face?
So leveraging their expertise is to the benefit of the team and the enterprise, but how do we incorporate them in our team-centric agile model? I’m reminded of the parallels between organizations and the systems architecture that organizations create. Conway’s law states that: “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations” While this law may seem to imply a negative, that needn’t be the case. For example, in object oriented systems development, we design systems of collaborating objects, structured around well defined interfaces, which work together to create an output that is greater than the sum of its parts. The same approach can be applied as to how we work together to develop systems architecture (see Figure 1).
In this figure, you can see that system architecture can be seen as role collaboration between the system architect and tech leads of the component teams that write the code. These system-level teammates work together with the component teams to decide what the architecture needs to be. And when in doubt, they code it out (principle #3) though a series of design spikes inside iteration or release boundaries. With the support of the product owner, these spikes are mixed in the backlog based on whatever priorities the team feels is appropriate, (this is one of the primary reasons we like to see product owners with a high degree of technical experience) and over time, a consensus emerges as to how to build the system they are about to deploy.
Ok, that’s pretty theoretical, perhaps an example will help. In the last post, I noted a Single-Sign-On (SSO) architectural consideration that came from a real world experience. In this application, the component teams needed to implement SSO from their system to an external web service. The component teams had little experience in web SSO, having had no prior need (and they weren’t following the market trends for a need they hadn’t presently have!) The system architect had broader experience, and perhaps more importantly, had been researching SSO options prior to the release planning session where the discussion was initiated. There were certainly many options available to the team – from lightweight open source protocols, to higher security, SAML standards-based implementations, to a variety of vendor proprietary solutions. The system architect had formed an opionion based on prior investigation. Even with that input, a lively discussion ensued.
So who is to pick – the team closest to the implementation or the architect with more experience but who is further from the implementation? The answer must come via collaboration and agreement between the parties, supported as necessary by evaluation matrices (footprint, recurring cost, level of security, etc.) and where necessary, a series of design spikes to test each proposed solution. After all, if a design spike or two couldn’t prove the feasibility of one choice or another, then it’s unlikely that the solution chosen is likely to be the simplest architecture that could possibly work (Principle #2).
In summary, it is only by working together and by maximizing the contribution of all team players that we can hope to beat the competition by mastering systems of the complexity that we are crafting today. To do so, let’s engage the system architects in our solution via Principle # 6 – system architecture is a role collaboration.