The architect is possibly the most disputed and poorest understood role in software. We do not even agree what architecture is, so how could we possibly agree on what an architect is supposed to do. Developers frequently challenge the idea that we need architects at all.
If we do not really know what an architect is, and we are pretty sure we do not want one, then why do I still think an architect can add value to our organization?
Instead of trying to make generic claims about architecture, I will use the context of NRK TV and Radio. I will write a series of blog posts that explain what architecture is – and why having a dedicated architect might be useful – for us. In the role of architect of NRK TV and Radio, these are questions I should be able to answer. This first post does not contain any concrete examples, but the follow-up post will be case-studies of our day-to-day work from an architectural perspective.
A strategic approach to understanding architecture
Rather than trying to define what generalized software architecture is, I approach software design from a product/strategic perspective. In the context of NRK TV and NRK Radio’s strategy, I see architecture as the systems engineering that ensures that our software teams can efficiently deliver on our product development managers goals. Our systems are built over time, and the current systems are always an attempt to answer the challenges of yesterday. In an evolving landscape being capable to adapt our systems to the ever changing field of online TV and Radio is critical for success. Some define architecture as the decisions that are hard and costly to change, I add the strategic perspective and claim working with architecture is taking responsibility for the fundamental parts of our system that we have to change in order to succeed in implementing our business strategy.
This is not only related to our technical systems, but the architect should also give managers input when we see organizational issues with respect to efficiently dealing with technical concerns. I think Conway’s dilemma, phrased by a colleague Einar W. Høst, opens some interesting questions.
In domain driven design we strive for having a well defined relation between the problem domain and the solution space. In LEAN we aim for autonomous teams that fully own and maintain their solutions. Designing an organization for these goals is challenging. Teams will form necessary ad-hoc relations to other teams in order to achieve their goal, but when more structural changes are required we need a more structured approach. The architect should assist with system- and domain-documentation and help present this perspective to management on how to improve the organization.
But this is very vague – how do I use this…?
Mixing the vague term architecture with the even less understood concept of strategy doesn’t exactly make things much clearer. There are some good resources on the topic in literature from Domain Driven Design (Eric Evans) and from Lean. I believe Lean Enterprise is the one book that made most pieces fit together for me.
I recommend this book to anyone in IT. Summing it up in a short blog post will not do it justice. I rather leave a few quotes from the book to serve as an inspiration to go and read it:
“An innovation culture is created by harnessing people’s need for mastery, autonomy, and purpose — and making sure people are deeply committed to the organization’s purpose and the users they serve.”
”given the strong coupling between systems architecture and communication flows observed by Melvin Conway and codified in his eponymous law, we also need to evolve a systems architecture that supports this kind of decentralized organization.”
”Autonomy — combined with an enterprise architecture that supports it — reduces dependencies between teams so they can get changes out faster.”
Another interesting view on how to understand strategy as it applies to IT is presented by Simon Wardley in his Wardley maps.
A fascinating topic from the Lean literature is the “Mission Command Philosophy”, or “Auftragstaktik”. I will revisit this in future blog posts. One of the important topics from a systems perspective is creating shared understanding between autonomous teams. This shared understanding of architecture is a mix of maps (documentation) and how we talk about our systems (folklore).
The how-section unfortunately just ends up with suggestions to read a few books, visit a few websites and think really hard about them. And I think that is as far as one can come on a generic level, even within the context of NRK TV and Radio. The challenges we face are diverse. The best one can do is read a lot and try to apply the theory in practice, and that is what my future posts will do. I will present case-by-case discussions on architectural changes we do to better deliver on our strategy and hopefully illustrate how these principles can be applied in practice. For a concrete example, jump to the next chapter in this series.