You may be aware that DevOps is mainstream now. However, as per latest state of the DevOps report 2022, not all IT organizations are able to see expected level of agility, reliability in their software delivery yet. Basically, they don’t have capability to deliver new feature when it is required.
In this post, I will be providing little background on DevOps and one of the challenge I saw while implementing DevOps practices and solutions to address it.
That challenge is “resistance to change”. Before talking about exact “Change” and why there is resistance, I would like to share some basics.
How business are tied to IT
So, what is the business objective in general? Businesses would want to validate new business ideas with their end customer as early as possible. In today’s world, almost every business is software business or have large dependency on their IT system. Hence, any new business idea can be validated only if supporting IT system is ready.
Now, let’s understand traditional way of developing and delivering new features in IT system. We used to prioritize multiple relevant features, develop, package and release them in predefined windows usually on weekend and with predefined cadence like monthly, quarterly or half yearly.
Impact of traditional delivery methodology
You can see that this way of developing and delivering software was time consuming. Even for small feature which can be developed in a weeks’ time, it used to take months to test and deliver that feature. We used to see defects, firefighting after releasing so many features in Production for varied reasons. On top of that, rollback was complex, not easy as it involves many features and changes.
why releases ware less reliable and time consuming
Now, let’s understand why releases ware less reliable and time consuming. One reason is, QA was manual or semi-automated. For most of the software deliveries, QA cycle was in multiple weeks to months. Another reason was, governance requirements. Considering security policies and impacts on upstream, downstream system, organizing production release was humongous task.
outcome of thE way of developing and delivering
These reasons, forced organizations to prioritize and club multiple features together and push them in production in one go and in a specific, agreed window and in predefined cadence mentioned earlier.
Obviously, the option for optimization was to build teams specialized in their specific phase of delivery like Development, QA, Operations, Security, Infrastructure. The outcome of this way of developing and delivering software was dedicated departments with distinguished purpose and objectives.
These departments were having different objectives and most of the time they were contradicting each other. For example, the Development team would want to develop and deliver change as quickly as possible, whereas the Operations team would aim for stability and hence would avoid changes which were less reliable as mentioned earlier.
On top of this, for cost reasons, business used to outsource their development and delivery phases to different IT vendors.
All these reasons increased delay in delivery and friction amongst different teams, which resulted in lowering productivity.
Why traditional delivery methodology is not sustainable now
This way of working and delays were acceptable till last decade. In last few years, we saw advancement in internet technologies and also we saw availability of reliable, cost optimized infrastructure on cloud. This gave birth to new business and increased competition in existing business tremendously. So, the ability to push new features in production, quickly became a matter of survival for some of the business sectors like telecommunication and online retail. For example, British Telecom, Vodafone and Amazon.
Delivery methods to address challenges
To improve Development pace, IT thought leaders introduced a new way of developing software. Small teams are organized and empowered to decide and work on meaningful, useful deliverables, over a short period of time like 2-3 weeks. This helped in drastically reducing development time. We know this way of developing software as Agile methodology
However, the other phases of software delivery like packaging, testing, deploying software were still following the old way of working and was time consuming.
The obvious question for IT thought leadership was, how can we shorten test cycle time without compromising quality? How can we reduce release time without compromising security and reliability? How can we reduce hand-off time involved in different departments?
Changes with new way of delivering software
To address these questions, IT thought leaders came up with a new approach of delivering software.
To optimize and reduce testing time, a test automation approach was explored. And to reduce time required to develop test automation, the test automation team should start developing test automation as soon as code development starts. This essentially means the Development and Testing team need to work closely to understand a new feature and how to automate its testing. To find defects early in the development phase, the approach was to perform tests as early and as many times as possible.
Similar approach was explored to find and address operational challenges early in the Development phase. Operations team and Development team should work closely to understand, detect and mitigate impact on environment, upstream and downstream systems. Also, to reduce deployment time and ensure repeatability, automation was explored in Build, deployment phases.
Same approach was explored with the security, Infrastructure team.
Another recommendation was to relook the processes involved in software delivery, some of the legacy processes may not be relevant and should be eliminated altogether, some processes may be automated completely. Some of the processes like compliance requirements may remain manual which is OK.
Now, you may somewhat visualize changes impacting people, process and technology involved in the development and delivery phase.
All these recommendations enforce having a one team with single objective. This team includes Developers, Testers, Security and operations team members. Basically, all those who are close stakeholders in developing and operating that application should be part of one team and ideally co-located.
Developing and operating application should be that team’s responsibility.
The Development, QA, Operations, Infrastructure team needs to learn new tools and automation.
QA, Operations, security management roles need to be reorganized.
How resistance is obvious
With this level of changes, most of the time, we see resistance from the teams while learning and following new ways of developing and delivering software.
These challenges are still somewhat relevant for the IT organizations.
Now, let’s talk about how we can smoothly introduce these changes.
How should we approach this situation
Instead of planning for the big bang, identify one independent and less complex application or application component and experiment with it.
While building a team which will be responsible for end-to-end application development, delivery and operations, try including team members who are willing to learn and change for good.
In the initial stage, it would be advantageous to organize DevOps conceptual trainings for management and leadership roles. For the teams on the ground, Technical, interpersonal skills training is more useful.
In initial stages, introducing automation involves procuring new tools, setting up automation and optimizing existing processes. For example, Code versioning tool, CICD tool, Infrastructure automation tools would need to be procured, configured. Relevant automation needs to be developed. This requires a good amount of time and effort. Management needs to support these efforts by providing adequate funding.
Also, management need to work on realigning roles, reporting structures for some of the team members.
As we see small successes in this endeavor, these team members will become evangelists automatically. This will also encourage other application teams to adopt this new way of working.
That is all for now. Welcome to DevOps journey. In the next blog, I would be covering other challenges and possible solutions to address them.
Techsphere 
Leave a comment