Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
By Yousef Awad, Chief Executive Officer, Integrant
Remember huge monolith apps deployed on premises with client-owned servers? Remember when speed and quality were oxymorons? Thanks to the cloud and its role as a catalyst for accelerated innovation cycles, speed and quality can work together instead of against each other. Today, we all think about ways to accelerate our deliverables without compromising on quality, performance, or security.
The next generation of agile or rapid development has arrived in many forms, including DevOps, continuous delivery and microservices, to name a few. All of this is born from a need for speed and an understanding that continuous experimentation is what enables us to build better solutions. It’s the accelerated speed at which businesses operate and which today’s consumers expect that drives technical innovation.
Where are you on the adoption curve? What makes sense for your business? Consider today’s methods, trends, tools, and processes, which will surely continue to mature in the next five years. With the right teaching, training, and planning, your software development team will drive business through continuous experimentation and shift from functioning as a mere internal service to becoming creators of innovative solutions.
Continuous Experimentation
So, what will IT as a driver look like? Start with the decision-making process for launching a new product, funding a new app, or targeting a new demographic. Speed enables continuous experimentation and testing. IT can test new features without distracting from current operations. Look to Facebook for a successful example of this approach in action. Facebook selected users to beta test its chat feature and had it running in the background for eight months before successfully releasing it to the public.
With concepts like continuous delivery and integration, continuous experimentation does not and will not drain time or resources. As a result, failure becomes nothing more than a low-cost experiment.
This strategy will be increasingly important in five years because more CIOs, working jointly with sales, marketing, and operations, will transition to chief innovation officers driving business growth. Here’s an example: The CMO says, “I suspect there’s a market for a higher-end brand. Can you help me test it?” The CIO takes it from there with a team running concurrent experiments with different designs, functionality, and offerings at little cost, risk, or impact on the mother site. So, the dynamic will move IT/engineering from executors/order takers to collaborators. This type of innovation will yield more speed, energy, insight, inspiration, and ownership with fewer mistakes.
The Rapidly Growing Need for Microservices
The need for scalable infrastructure and technical autonomy is the driving force behind microservices. To meet market demands for speed and responsiveness, we must change only what needs to be changed. At the same time, technical independence allows teams to experiment, leverage polyglot concepts (the right tool for the job), and inject more creativity. For example, an e-commerce business may need to change its content management and shopping-cart functionality during its busy season without altering its order processing. However, with an increase in volume and load, order processing must expand and perform. By using microservices, we can pinpoint precisely what needs to change or scale and for how long without impacting the entire application. By designing software applications as suites of independently deployable services, we allow decentralized control of languages and data. This approach results in “chunking responsibilities into manageable, ownable parts—slices instead of layers.” (http://martinfowler.com/articles/microservices.html)
Microservices is an example of speed and quality working in tandem. It brings life to operational excellence and innovation. We see controlled independence balanced with accountability. It is here to stay and that will not change in five years.
Microservices is a direct response to market demand for speed, scalability, disaster recovery, and cost. The question is where and how to leverage microservices within the application environment. Where and when does it make sense?
The Shifting Roles of Engineers
In this new world of continuous experimentation, rapid development, and higher expectations of quality and performance, the role of the engineer is shifting. There will be a continuing modification of roles to allow more ownership, autonomy, and creativity. Engineers will become more specialized and take on more responsibility.
For example, this shift will enable roles such as security specialist or performance specialist, where responsibility and accountability span development, operations, and the entire lifecycle of the app. So, security will be a specialty as will performance. In the future, companies will not have performance test engineers, performance IT administrators, and developers who fix the performance issue. Instead, there will be a performance engineer accountable for the entire function. The performance engineer will serve dual roles of specialist and generalist.
The next generation of tools will transition processes to a model where almost everything is automated. Today, developers are able to deploy instead of just passing code to IT, and robust tools automate most of the deployment process. To keep up with accelerated dev cycles, more tests will be automated as test engineers learn to script or code.
Developers will continue to take on more responsibility in meaningful, analytical ways. Because of the fast movement from IaaS to PaaS to CaaS and now to APIaaS, in five years expect the continued emergence of multi-platform programmers. It’s not just about C# and JavaScript. Developers will have to understand different data stores. They will have to be able to analyze and work within a multi-platform, multi-paradigm environment.
Similarly, the role of the technical architect is also expanding. Containerization will make it easier and more functional-to-use multiple platforms. So, the architect of tomorrow must be able to analyze performance, purpose, consistency, orchestration, and permissions among clouds. Many are adopting a multi-cloud approach where curated libraries are assessed for strengths/weaknesses and matched to the application. Issues such as the cost of outbound traffic and the comparison of a myriad of options must be analyzed and addressed. With so many rapid changes, a good engineer will be the one who can assess what to ignore.
Creating the Right Teams
It is all about leadership and good people. Innovation bubbles up from your teams. With teams being more distributed and global, face-to-face meetings and strong technical leadership will remain imperative for optimal team functioning.
If you are outsourcing to extend your team, it’s critical to partner with a vendor that can integrate seamlessly with your tools, processes, and protocols. The vendor should make it easier to pivot, progress, and innovate.
Finally, the future will demand far more qualified, well-trained, and educated coders, but where will we find them? The answer comes from a transformation in elementary education. School systems need to educate children to learn coding in the lower grade levels. It’s already working for project-based learning and the same should be true for coding. Like every goal of education, we have to train our young with the right skills.
About the Author
 |
Yousef Awad is the Chief Executive Officer of Integrant and an advocate for providing access to coding classes to all children at the elementary school level. |
This article was written by Yousef Awad exclusively for Developer.com.
