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.