Should architecture be constrained by reality?

During a conference that I attended last month, I was part of an open-space discussion and observed two architects who were trying to agree on a technical strategy for some imaginary project they were working on. After observing the arguments for a while, I started to realize that they didn’t actually disagree on what needed to be done, but more on when and by whom. One architect argued about some overarching strategy that required certain things to be done in parallel, whereas the other felt he was constrained by the available capacity in the team. The first architect didn’t think like that. He apparently decides on a strategy with the assumption that development capacity is unlimited. As I’ve discussed before, you could say that he’s more of a strategic architect. The other guy approached decisions like this by considering the available capacity within the group of contributors and prioritizing the work that would give him the best return-in-investment. In my opinion, that would qualify him as a tactical architect.

Now, which is better? A strategic architect might take decisions which development lead time will not give the organization any benefits for a long time. But if it will, it will be substantial. He might also propose to have developers work on multiple parallel tasks, which has the same characteristic. Even worse, this assumption that capacity is not a problem might cause the developers to take design decisions that result in over-engineering or projects-that-never-end. If you ever read about the story of the Boeing 747 Jumbojet, you’ll recognize my point. On the other hand. A tactical architect might not even consider certain long-term options, even if that would result in much more significant changes. In a way, such an architect might only take safe or conservative decisions and never make any substantial differences until it’s too late.

Then what about predictability and release planning? Most agile methodologies promote restricting the work in progress in some form and have teams swarm on work as much as possible. Scrum does that by having the teams deliver real product value in short periods, where Kanban has an even more restrictive work-in-progress (WIP) limit. The main goal is to build up some historical metrics so that the team can better estimate the amount of work they can do in a certain number of iterations or sprints, and use that to continuously change plans and priorities. Having your team of 5 developers work on 5 different things will not give you that predictability. However, you could decide to assign two developers to work on a long-term improvements and keep the rest on short-term work that better fits the agile methodology. That could work, but you won’t get any predictability for those two developers. Maybe you’re in a position that this is perfectly fine, but in most organizations, management would like to know how long that work is going to continue, or what the organization will gain from that.

Another aspect to consider are the developers in your teams. Some people are just better suited for long-term research-style projects. Quite often, they are allergic to the ceremony software development methodologies introduce and prefer to work alone. More often, they also don’t care too much about writing maintainable code as long as it is solving the problem, is high-performant and they can read it. On the other side of the scale, you’ll find developers that love working together to incrementally build tangible stuff that can go into production right away. They don’t mind or even welcome the structure Scrum or Kanban brings, and they acknowledge that code tends to stick around much longer than anybody expects.

What do I think? Although people are usually not that black-and-white, I do think we need both types of architects and both types of people in every organization. Maybe they should be working in separate teams with a different focus. Depending on the phase the organization, that focus might be different. E.g. a startup needs actionable minimum viable products and act fast, whereas an enterprise must invest much more in long-term strategies. But all of them bring enormous amounts of value. If I look at myself, I’m pretty sure I lean towards a tactical mindset and will prefer emergent architecture (@) over Big Designs Upfront. This is also matches nicely with the kind of work I’m best at. However, I do acknowledge the potential pitfals of that mindset and greatly respect some good strategic discussions and insights now and then. That’s why I love going to conferences and talk with other architects…

Now what do you think? Should architects make decisions with the constraints of available capacity in mind? Or should they strive to ignore the reality and pursue only the best solutions? Love to hear your thoughts by commenting below. Oh, and follow me at @ddoomen to get regular updates on my everlasting quest for better solutions.