How architecture and the constraints that apply to it cannot be seen as separate things

In a previous project, I observed a typical communication mismatch. One team was demonstrating the technical details of architecture that, on first glance, was supposed to be a replacement for an existing architecture. The team demonstrated all kinds of technical solutions and showed us how much better they were than the solutions in the prior architecture. At some point the team compared a very nice and elegant implementation detail with the worst the existing architecture had to offer. On itself, the new architecture contained some brilliant ideas that the old team wished they had thought of themselves. The point however, is that the team forgot to mention how different the constraints were under which both architectures evolved. By doing so, a lot of people in the room interpreted this as bashing the old stuff. And that's a shame, because the old team could learn a lot from the fresh ideas the new team showed them.

The original architecture started almost five years prior to this meeting with best intentions. However, over those years the architecture accumulated technical debt, even though the old team keep tight control on it. Commercial pressure is a reality and forces you to take shortcuts and usually doesn't give you enough room to pay pack on that technical debt. As I've said it before; working on a system with 4-5 great developers is a completely different game then when you have 40 developers working on the same monolithic code base. And when that project started, they didn't have great technologies and tools like Git, Github, MyGet and OWIN, offering the old team less options for pro-actively breaking down complex systems in small maintainable chucks. Sustaining architecture over a long period is just a very very difficult thing to.
Anyway, I'm not trying to defend the old team in this discussion. I'm pretty sure that they've made some bad decisions over those years. But something that I'm guilty of myself is to criticize a team's accomplishments purely by comparing the status quo with your own ideas and opinions and neglecting their history. Most bad design decisions are not made intentionally, but result from political, organizational and functional constraints that may not be even be relevant anymore today. Without those constraints you'll probably come up with a completely different (and probably better) architecture. But please don't ignore that history and judge them from the looks of it. And beware of focusing too much on the technology rather than on the problems your are solving and the constraints that apply. The architecture of your solution is there to support the requirements of the problem domain and is never a goal on itself.
So what do you think? Do you agree that architecture cannot be discussed without discussing the constraints that apply to it? Let me know by participating in the Disqussions below. Oh and follow me at @ddoomen to get regular updates on my everlasting quest for better solutions.