The other day I learned about the "boiling frog syndrome", and it got me thinking about how we deal with architecture - particulary troubled architectures.
For those of you who are not familiar with the boiling frog syndrome, it goes like this: If you boil a frog, it dies (duh). However, let's say you put the frog in a pot of water at room temperature. In this case, the frog will think this is a lovely way to spend the afternoon, and it will just sit there in the water. Now, start slowly increasing the temperature of the water, and the frog gets a little aggitated, but still remains in the heated water. Keep doing this until the water is at a boil, and the frog heats up too much and dies. Now, boil a pot of water, and then put the frog in. What happens? The frog immediately jumps out of the water, and therefore does not die.
In many ways this is how we deal with our architectures. Whether it be tight coupling, reliability issues, performance issues, scalability issues, deployment challenges, etc., we certainly recognize these issues (like the water increasing in heat), but due to tight budgets and tight project deadlines, we simply don't have the time or budget to deal with it at this time - so we live with it until we finally start boiling. That boiling for us is something that finally causes our architectures to finally stop working.
Maybe that frog that jumps into the boiling pot of water and jumps right back out is an architect external from the project or system that can come in and have the motivation to identify the issues, formulate a plan, and get the ball rolling on refactoring the architecture to resolve the issues.
Alternatively, maybe it's simply understanding the boiling frog syndrome, and as an architect on the project, take the initiative to recognize that the heat is increasing, and do something about it before the water starts to boil.
As architects, let's try to be the latter frog.