Engineering DevOPs
DevOps is all about mindset change, truly.
Its as much and more a transformation to the engineers as it is for the business, especially when the application landscape is complex and is a combination of legacy and greenfield, involving a multitude of businesses. When DevOps is truly practiced, and when the benefits become visible, Business buy-in comes in naturally. There is a good amount of work that we as engineers have to do, and it is not a mandatory initial step to have business buy-in, however if it is there, the journey becomes more easier.
'If the build is broken, nobody goes home until the build is fixed', 'Run what you build' are widely used, so is microservices design, containerisation, immutability, idempotence, E2E Automation and other CI/CD/CT principles that are very popular. However, the key is that these principles are followed through progressively and with rigour, especially given that unlearning to re-learn and these Changes are incredibly difficult in the beginning.
Through perseverance and progressively improving results, the confidence of the team increases and the adoption improves and at steady state this becomes the new norm of working. The new norm of working is easier for the life of the engineer as well. Accountabilities are clear, quality is assured through the stage gates of CI/CD pipeline, impact analysis is easier, and making changes to the code and ensuring clean, peer reviewed code is a part of normal process.When this state is reached, you will see that the team is collaborating and working in a happy state of equilibrium - no silos, no blaming and taking mutual accountability for their actions. Monitoring and telemetry becomes a key part of their lifecycle; evidence gathered in production, and real time results provides a fail-fast-recover-learn attitude to the team. People are multi-skilled and full-stacked, and running operations become a critical part of a developer's life.
Business ofcourse see the results - the product features are delivered incredibly faster than ever before, UAT cycles are tremendously reduced, defects are near zero, and any change is delivered quickly. Behavior and user role driven functional automation allows them to test and think scenarios broader than before. Thanks to microservices design and the use of containers, there are no more single points of failure and any impact is limited to a feature alone. No more delays due to infrastructure readiness, and computing resources are autoscaled seamlessly. Just to jot down a few of the benefits.
'DevOps is not an IT hype, its real', I heard a business user say the other day. And he is right. This is no hype.
Can't agree more that embracing DevOps is a massive mindset change, not just for engineering but for leadership as well. DevOps teams are multidisciplinary by definition; are autonomous and requires high-trust, psychological safety and ability to take decisions independently.Supervisory tasks often become removing their obstacles or sometimes even getting out of their way. If I oversimplify, DevOps way of software engineering and delivery is more in favour of Theory Y style of leadership. The volume of mindset/culture change varies depending on where a team/organization finds itself on the Westrum model. Whatever the volume is, determined leaders can change the culture, as affirmed by the 2016 State of DevOps Report. The report had a section labelled "Changing organizational culture and identity ". As someone with a keen interest in the effect of 'Human Factors' in software engineering, I find it the most intriguing yet often overlooked parts in DevOps transformation journeys.
Good Article Shivagami.
Nice one!!! But, the first line itself is the toughest one to achieve. To make #tags a real success you need 'self organized’ teams with ‘equally contributing’ members and its a rare thing to happen in organizations where they carry ‘legacy’ and don’t embrace change.
Well said Shivagami. The first sentence says it all.