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.

1. Empowerment & ownership: I believe that lots of software teams underperform because they don’t have the freedom to make choices (about technology, for example) to the best of their ability. Give a team freedom and they will take responsibility.
2. Diversity: IT is a complex creative domain, so having people from lots of different backgrounds with different angles really helps when solving problems.
3. And finally.. more fun! Take time to hang out as a team without talking about work. Take time to do research and hack on new technology. Take time to relax. The best performing teams are teams that know how to have fun together 😉

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.