If you've been around mobile development circles for more than a few years, then you probably remember the days when the technology stack was, in many ways, fossilized. We had client side code, infrastructure, a database, and a Web server. And the design and development phases for applications and new initiatives went on for months, years even, and the integration work pertaining to large applications and systems was never truly complete.
In large organizations, CIO tenure rarely outlived such initiatives, where developers came and went and by the time the application was near completed it was outdated. Throw in consumer app scale, and the ability to have a static IT stack caused many a sleepless night.
These are also among the reasons why such a large percentage of big application deployments and IT projects ended up as failures. A lot of these organizations had agile development teams, but the agility existed only within the development teams themselves and did not extend to operations or to the larger business.
To improve enterprise development efficiency and effectiveness, more organizations have embraced both processes and technologies that foster continuous change. We see this notion of continuous everything and constant change with technologies like development pipelines, devops, cloud platforms, virtualization, and microservices.
Consider the continuous nature of devops, where development and operational teams work in steady collaboration, as well as the emergence of the microservice. Both devops and microservices can be argued to be working breaking down monolithic processes and applications into more manageable chunks. This is especially important in mobile app dev.
If the new IT model is continuous everything, you need to be constantly looking at how you can improve and change apps and processes. I'll admit that I am a big sci-fi fan, with Isaac Asimov being one of my favorite authors. In the novel "I, Robot," Asimov famously defined the three laws of robotics as a way of providing guidance on how robots would behave and function. It got me thinking: what laws would we apply to a world of continuous everything? And could these laws have deep influences to modern app development -- throughout the entire stack -- in a way that encapsulation and polymorphism did to object-oriented programing. After much internal debate and analysis of successful customer implementations, the following laws of continuous everything emerged:
The Four Laws of Continuous Everything
- No appdev process shall be implemented that can't be fully automated.
- If an app, or process, can be rewritten to take advantage of new technology and improve its operation or maintenance, it should.
- When an app, or process, can be replaced with a third-party service, it should.
- When the Second or Third Law are limited by the First Law, look to the Second and Third Law to automate more.
With the laws defined, what types of technologies will be essential to succeed in the continuous stack where change is constant and embraced? I think there are many: devops, identity management, microservices context, training, metadata (streams of intelligence), and more. Each of these disciplines will be important to master in the year ahead as the pace of the continuous stack only continues to accelerate.
And, finally, with all of those processes in place, it won't matter if projects or initiatives live longer than any IT leader or developer in the organization, because the processes and the tools will be place for the organization to successfully master the new connected everything continuous IT stack.
This article is published as part of the IDG Contributor Network. Want to Join?