Building a Software Architecture for the Future
Recently I’ve been thinking a lot about the future. Not so much in terms of flying cars or the iPhone 1000, but rather how important is it to select the right architecture components for building an enterprise system that will last way into the future – maybe 20-30 years? There’s lots of blog articles on the web about the latest architecture components and a host of their zealot followers. And it’s not just architecture components – it’s software languages, methodologies, databases, and deployment options just to name a few. Just within the JavaScript language as an example, we have dozens if not hundreds of frameworks to choose from. In a world where technology has a new “cool kid on the block” everyday, how do you choose the building blocks for an architecture that will last well into the future; knowing that some of your components were written no more than 6 months ago by a dozen people in a dozen countries who are all probably half of your age!?
Before delving too far into procedurally how I would do this, I would make the somewhat loose correlation of picking a future-proof software architecture with picking a financial allocation of right stocks and bonds and other investments for a solid long-term performance. My experience and knowledge working with financial investments is greater than most, although it pales in comparison to my years as a developer. Nonetheless, I have learned a great deal about investing and my philosophy around investing can best be summed up as “follow what you already know works.” Many investors like to pick the shiny coin and go with hearsay and gut feels and especially try to time the market. Obviously we know that this sometimes works, but most often it doesn’t. When it comes to your future retirement savings, why chance it? If you know certain strategies (albeit boring) will most likely put you in the top 20% of investors in terms of returns over the course of a long term investment, then why mess with success?
When it comes to software development, it’s not the languages and components (stocks and bonds and precious metals) so much as it is the overall strategy. In development we know the people on a project will come and go, but it’s the software that is left behind and building a loosely-coupled, consistent, highly tested, well documented/commented system will give you 80% of future-proofing. In my 25+ years of software development experience I have worked on many systems. Some are still in production for more than two decades. They were not written in Python, Ruby, JavaScript, or even Java. They were written in COBOL! (sometimes referred to as the 5 letter word for software engineers). But the amazing part of these systems were that they were built solid – consistent and documented (unfortunately not many tests, though). Somewhat even more important, is that they were built simply – any fairly good COBOL programmer could follow along with the pattern and nothing was overly complex. Nowadays we are building highly complex systems with over–architecting the system with too many components and not enough simplicity.
Of course taking the time to select the right language, components, databases, etc., is important and should be well thought out, here are my list of items that are critical to building a future-proof architecture regardless of the specific make-up of the architecture:
- Consistent – Software never goes away and is never done. You are constantly hiring new staff to work on “old” systems. When building a new system amongst multiple team members there needs to be a consistent pattern. I’m not talking about just following a pattern like MVC (Model-view-controller), but every part of the code has to appear as if one person wrote it. This is not easy but requires a steady-state of code reviews to maintain that consistency.
- Highly Tested – Every software engineer knows that a system that is tested is more likely to be successful than one that isn’t. The lack of unit testing and feature testing equates to lazy developers. Sorry, I know this to be true. Historically I have been one of those developers. I always hear developers say “There’s no time in the schedule.” Honestly that just means the developer has not done a good enough job explaining to a manager/client why testing is needed.
- Well Documented – Within all aspects of code any new developer to the team should never be scratching their head saying “I’m not sure what this block of code does.” All code must be commented well and easily understood (of course along with associated tests).
- Maintaining Upgrades – If your selected architecture is still being used next year then you must maintain upgrades and never accumulate technical debt. If your selected architecture component has fallen out of favor you must make the decision to maintain it yourself or move on. With keeping a consistent, highly tested, and well documented codebase you should not have much trouble with a swap-out.
If these are followed then no matter where technology takes us we can be ready. Software engineers should be ready for change – actually they should expect change. Now back to my financial analogy. I remember back in the early 90’s someone said “Buy Fidelity Magellan! It’s the best mutual fund out there!” Of course I moved my entire 401k portfolio fully into Magellan and from then on it was close to the worst mutual fund out there in terms of performance. At that point I learned an important lesson – I was focused on the sprint and not the marathon (or battle and not the war – choose your favorite analogy). I was looking for the shiny coin. I didn’t put everything into perspective nor use the knowledge I already had about investing for the long-term which included important concepts like diversification, low fees, and maintaining a consistent strategy. In other words I wasn’t future-proofing my investments. To me, investing or building quality software that is future-proof is easy – we all know what to do; but we’d rather look at the short-term performance rather than the long-term gains.
