What is really DevOps?
There are many definitions for DevOps, the most simple one can be a unique team able to develop and to operate in a continuous way, supported by a tool chain enabling automatically code integration, test and deployment in a single pipeline, where the code, after several approval steps, is released into production.
In this post, I will try to share my definition and will share some personal considerations about the implications of decide for organize your team and development process in a DevOps way.
Other possible definition can be the continuous working cycle between tree main roles in a single team: Product definition, Product Development and Product Operations. The three areas collaborating and contributing for the product value in continuous interactions of feedback, inspection, correction and continuous product improvement.
In the development perspective this implies a continuous integration, a continuous testing and a continuous deployment assuring the ultimate efficient model of continuous development.
But also demands investment in a tool chain, discipline to don’t fragment it in thousands of applications (each team, each modus operandi can be chaotic 🙂 )…
DevOps is a mean to an end: drive Agile Transformation, collaboration, application modernization and the inevitable way to move to the Cloud. It is also the final technical goal for an Agile Transformation. The DevOps cycles and this continuous loop for sure will increase the delivered value to the customer, in better quality products, it will increase also team productivity and even can raise their motivation by the independent delivery capacity, in disciplined cycles.
Why the demand for a high skilled team?
When we organize a Development Team enabling them with self-sufficiency and independence, we need to make sure they have the skills to fulfill product definition and requirements, plan implementation considering requirements inter-dependencies in scenarios of incremental complexity, demanding for architecture flexibility, quality and security to keep data integrity, the best possible performance and user experience. It will be a challenge to group a team with those skills, able to reach your DevOps goals.
The proper DevOps implementation is very time-consuming, demands for change in different organization areas: processes, roles and fundamentally in quality levels to produce and deploy software.
Those reasons demand from managers and executives a regular update, reporting and prioritization of the DevOps strategy roadmap. Yes, you should define one DevOps Strategy road-map answering to:
- What am I targeting? More quality? Better time to answer for critical issues? Speed to deploy? Better build and release management? Better collaboration between the different application support layers? etc…
- In which applications can I really aim for DevOps?
When you put yourself those questions you should take in consideration:
- Application complexity: We are moving from architectures monolithic on premises application to cloud based applications based on micro-services.
- Legacy Integration Versus Digital Transformation: We should evaluate cost for benefit to bring heavy monolithic applications into a DevOps mode.
- Brownfield/ Greenfield – If we take the example of the financial industries, they have a lot of this monolithic, on-premises applications the switch to DevOps investment is big and painful.
There is no recipe for a DevOps transition plan
There is no recipe for a DevOps transition plan, it’s a serious decision. As I said before it implies deep changes and costs. My recommendation is:
- Analyse your business complexity and dependency in the apps where we are planning to start;
- Think about where you can slice and adapt to have more efficiency and reduce the risk to have a critical application completely blocked during one of the phases of your transition plan to DevOps.
- Evaluate if it‘s worthy to make big architecture changes in legacy platforms or just keep the system elegantly running.
- Make careful changes, learn change by change if it‘s worthy to continue.
- Maybe in your business for your customers it doesn’t make sense to have continuous deployment without communicate and train in advance your users for what is coming with the new release. Think about it!
Measuring the Impact
In some organizations the preparation of their applications architecture to give this step further is a very hard task, demanding heavy investment and know how, what often they don‘t have in place. If in one hand you should plan architecture ahead, you should develop a DevOps Roadmap targeting for short term goals, inspecting and reviewing the plan regularly.
Drive the DevOps plan in an holistic way, plan to short term, bring the planning practice into DevOps. The flexible architecture will allow you to adapt or correct quicker in your product.