Preventing your next application from becoming obsolete (in a hurry)…
The development landscape has changed rapidly in the past decade. NoSQL databases, Javascript libraries, Mobile Computing and other technologies have changed the traditional development lifecycle including, changing the end-game. The end game used to be about building sophisticated web applications – using loose coupling (web services etc.) to integrate disparate systems.
Today, the end game is about building an application that, first and foremost, will NOT become obsolete in two years. Not only is this happening to most of the apps out there, it is happening at an alarming rate. So, how do you keep up? How do you safeguard your next app (or the next release of your app) from becoming obsolete before it is even out the door?
Here are some things that a modern day application needs to be mindful of:
- Multi-channel (Multi Platform) Design: Multi-channel applications are written to be delivered to multiple platforms. Web and mobile are the two big ones – but IoT (Apple Watch for example) is also an emerging target platform (and Desktop apps are still around, at least for now). The app should be designed in a way that the code (including the presentation layer code) can be reused to target multiple platforms. Bootstrap is a good example of designing a UI once and having it work across devices seamlessly. For middle tier code, the challenge is a little more daunting. How do you write common code to target say – both mobile and desktop devices – both SQL Server and NoSQL databases. A design pattern that I worked on (source code included) accomplishes just this.
- Distributed Microservices, Cloud Aware Apps: A microservice is a simple SaaS or PaaS offering that essentially saves you the trouble of building your own component. E.g. – if your app needs a GeoCoding service, in the past, your options were limited to homegrown vs. SOA based integration. With microservices, you have a similar ‘GeoCoding’ SaaS available – though in a far more lightweight manner. In fact, if done right, you get to use all their (the vendor offering the microservice) plumbing without any of the maintenance nightmares. A distributed or microservices architecture is key to flexibility and agility in the application. The app should be able to incorporate new elements (e.g. new Geocoding service) without any substantial rewrites. Apart from code agility, this also provides additional scalability avenues for an app (each microservice can be scaled independently).
- API-First – The distributed design mentioned above also implies that the app must design an API alongside the main codebase (this is sometimes called API-first approach). API first development allows an app to expose functionality in a modern context – allowing additional revenue sources (e.g. consumers of the API). You may think that you don’t really need an API. Turns out, that you just might – and building one AFTER the fact, is a lot harder.
If you are not following these design paradigms in your next application, chances are your application will not be flexible or scalable in the way that most modern apps are. Gartner even goes as far as to say that if your application ISN’T leveraging microservices and the javascript stack, it will suffer the same fate as mainframe apps in the very short, near future.
References
Pattern for targeting multiple platforms with the same common OO code
Side-Note: If you are hosting your application in the cloud (say AWS), you can utilize AWS’s API Gateway. It lets developers create and operate APIs for their backend services without developing and maintaining infrastructure to handle authorization and access control, traffic management, monitoring and analytics, version management and software development kit (SDK) generation.
Leave a Reply