Software Architecture Lifespan

Okay, I want to coin this new term.. "Software Architecture Lifespan"

This idea has been in the back of my mind for many years now. I have worked in big companies, startups, and startups that grew into middle-size companies. I have seen lots of software grow and change. It gets tweaked and tweaked and refactored and refactored until it could bear no more then finally, it gets rewritten. I use to think this is bad, that somehow software engineering as a science and discipline has failed. Now, I actually think this is a very useful and practical exercise.

I would now argue that rewrite is not an failure but a sign of maturity in the business and technology. It should be a key requirement for any application development strategy and product roadmap plan. Instead of being a painful business and organizational crisis, it should embraced. One of the software architects job should be to plan for the various major architectural changes and all the rewrites involved.

The technical team should in tendum with the product team to develop a product roadmap and an architectural roadmap. The product roadmap defines a set of functionality and level of performance necessary to achieve a business goal and customer requirements. The architectural roadmap will parallel the product roadmap. This set of features can be easily and efficiently implemented using this set of architecture. As the business and software matures, a new architecture is needed to better manage the new set of functionality and requirements. Each architecture has a fixed lifespan where it's optimal for certain conditions, then it's gracefully put aside and a new generation will step in. Each generation of software will have its own "Software Architecture Lifespan".

Recently, I used this concept in a technical evaluation for a client's software. The client wanted to assess if a rewrite was necessary. Instead of providing direct yes or no, I took their product roadmap to the existing architecture and demonstrated its strength and weakness, and show how the architecture must evolve. This method allowed me to be specific, I can show the architecture has a lifespan of maybe an year then an rewrite would be highly recommended. Since the timefrae is only a year away. They should start planning for the rewrite now so some of the new components can use the new architecture and minimize the future rewrite cost. And we know where the existing architecture is effective, they can still plan for rapid development of new features to keep up with customer demands.

I have another personal example how of this model is useful. The client was an early stage startup with a big business plan. They wanted all these bells and whistles in the software. They wanted this sophisticated J2EE, N-tier architecture that can scale to hundreds of thousands of users. I blunted told them that's silly. I wrote the software using PERL and MySQL in about 3 weeks instead of the 6 to 9 month they budgets for. This was over an year ago, the business is growing nicely but has not even come close to maximize the capacity of the current system. The major advantages of the current system are it's easier to change, and easier to hire people to do the work. I saved them a TON of money.