Being a software guy myself, I often find that I dig a little deeper into the successes and failures of the software-oriented startups that I work with than I do with the non-software oriented ones. When I do, I suppose that I shouldn’t be surprised, although I routinely am, at how often I come across some very consistent and basic technical errors that are made by these companies. Chief among these is the lack of thorough thinking about the architecture of the end product prior to the start of coding. It’s, of course, natural to start hammering out code as fast as possible in order to get a product to market but, inevitably, the Piper needs to get paid and fundamental problems with the architecture will eventually require a wide-spread rewrite of the system or, even worse, will be a serious resource drain and time sink to in every future release.
You’ve probably read dozens of books that have discussed the importance and value of planning and how time spent in architecting a system is a drop in the bucket compared to the time it saves on the back end. I neither have the skills nor the eloquence to drive that point home any better. What I’d like to do, though, is to present a high-level view of how you might think about the architecture of your product so that it provides a framework for you to make rapid changes to the application and makes it easy for others (partners, customers, etc.) to extend the product in ways you may not have considered.
There is nothing revolutionary here. Let’s just call it a reminder that you will end up rewriting your application or, at least, its framework, in the future if you don’t adopt something like this early on. You may not see it yet, but like I’ve already said, that rewrite is going to be very expensive and painful and will ultimately cost you customers, competitive advantage and money.
The idea here is that there are are two programming interfaces. One separating you’re application from your core libraries or base layer of functions and another separating your application, as well as the lower-level programming interface from the outside world. The lower level, base programming interface, allows you to build an application virtually independent of the core functionality of the end product. Architected this way, you can build and test the application and the base code separately and make incremental changes to each part far easier. In fact, one can be changed without affecting the other as long as the base programming interface remains the same (it needs to be well thought out to start with, of course).
The higher-level programming interface gives you the power to add functionality to your product quickly, using the code in the base programming interface as well as code in the application layer. Using the application programming interface, you can prototype new functions rapidly and get quick fixes for bugs to users faster. Perhaps even more importantly, it enables easy access to most of the guts of your system to partners and customers so that they can extend it as they see fit. This access can be provided without having to publish hooks to the internals of your core system and exposing a boatload of potential problems that foreign calls to those components can create. If you’d like, though, you can also expose some of that base functionality to the high-level API as is shown in the “optional” architecture slice in the image above.
Simple, yes. It requires more work up front – both in planning and in coding – but with such an architecture, you’ll be able to roll out new functionality quickly and to fix mistakes as fast as you find them (well, almost). Ultimately, you’ll get the functionality your customers want into their hands faster than if you hadn’t adopted such a system. You’ll also be able to continue to roll out enhanced and improved functionality without getting bogged down with thinking about an architecture rewrite or with a huge backlog of nasty bug fixes.
The anxiety about getting your product to market will lead you to think that hacking together a system and refining it later is the way to go. Virtually always, this is a mistake. Speed is of the essence, but only the speed which you can deliver sustainable, quality product that continuously stays ahead of the competition. Look before you leap, it’ll make life so much easier.
