For a DevOps team, one of the main goals is to provide continuous delivery of value for end users. As a result, you’re working as a team in small increments and try to deliver new features to production as soon and often as possible, and get as much feedback as you can along the way. When a team is moving at such a fast pace, continuously adding new features and refining existing ones, it can be difficult for a software architect to keep up.
How can we tackle those challenges from your experience?
For software architecture to keep up in a DevOps world, it needs to be able to move at the same pace and follow the same principles. Otherwise, the DevOps team gets slowed down waiting for architecture work to finish. This means that either the architecture work needs to be done before the team starts building a feature, or that the architecture evolves during the development process.
I prefer a combination of both models, because it allows to have enough time to calmly think about a problem beforehand, while also keeping room to keep improving the architecture while you gain new insights. This typically does mean that the software architecture work either needs to be done by the DevOps team itself, or that a software architect needs to work closely together with the DevOps team.
As long as the development work isn’t blocked by the architecture work, either way can work.
Besides these DevOps-specific challenges: What are the biggest challenges of architectural work from your experience?
I always strive to give teams as much independence as possible. Because if there’s one thing that slows a team down, it’s being dependent on other people outside the team. A challenge here in bigger organizations is to find a balance between having multiple teams work independently of each other and not having every team reinvent the wheel. This specifically can be a challenge when deciding whether to solve a problem locally in a specific way, or organization-wide in a generic way. Solving problems with generic solutions can save time in the long run, but it does create dependencies between teams which can also cost time. The hardest thing here is that the long-term gains of solving a problem in a generic way are typically hard to predict up front, while the short term higher cost of designing and developing generic solutions usually is pretty clear. This makes it difficult to compare pros and cons of generic vs specific solutions.
Up to this point we talked about challenges. Let us talk about the joyful sides of our work for a change. What do you like most about your work?
I love being able to create something from nothing; especially the creative process around thinking about the problem domain, the requirements, the constraints and possible solutions. I love helping teams make decisions by sharing my experiences as developer and architect.Staying on the joyful side: If you would have three wishes for the IT domain to make it even better — what would they be?
A final question, regarding the Software Architecture Gathering: Which other talks of the conference are you curious about?
Probably all of them It’s great to be part of such an amazing speaker lineup. I’m definitely going to enjoy all the keynotes, and I’m looking forward to the talks by Adam Bien, Eberhard Wolff, Felienne Hermans, Neal Ford and Simon Brown as well.