James Greenwood has a post that raises an interesting question. His premise is that having a good architecture can actually be bad since it makes it difficult to justify migrating to new architecture. Now there is a bit more to his post then that, but this is an interesting point. When I do the architect role, the goal is to develop something that will pass the test of time. So, do I architect in the capabilities to migrate to the next sexy architecture of the day? Of course not. How can I if I don't know what that architecture will look like. If I look at a system that I might have worked on say 5 years ago, did I lay the groundwork to migrate to SOA? No because SOA wasn't the thing to do at that time. Few if any had even heard of the term SOA so how could I possibly design a migration path. James makes the point that a good architecture should support change. Nobody can nor should argue that point, but what change should it be able to support? Should it be the ability to migrate to a newer and possibly better architecture or to be flexible enough to solve an evolving business need? If the business need is met, is a newer architecture even required. I look at one of my responsibilities to be making the best use of the business area's money. They want certian problems resolved by the systems that I build. The business doesn't care how that happens. And they certainly don't want to spend more money and not have anything new to show for it just so that I can say we do SOA or whatever architecture is popular at the time.