What is Transformation
The way to look at digital transformation is to look at organizations from a holistic point of view. There are 5 elements (or groups) that are key to transformation. Although these groups have different challenges and objectives, these organizational groups need to work together to successfully achieve transformation.
Leadership
This is the management layer; the executives, the directors and middle management. Their role is to enable the right behaviour and create a shared purpose and vision, by breaking down barriers between departments, decentralizing decision making and measuring the system as a whole. This is the group that will provide the approval and sponsorship, and enable experimentation. They make the rules of the game everyone else will play.
Product team
This is the team that is connected to the market, led by the hottest role of 2020 i.e. the Product Manager. Their role is to connect tactics to the strategic vision, take model driven decisions, communicate the Whys and not only the Whats, and get feedback from failures. Team members include business analysts, people with visibility into the market and people with client interactions. They look after the strategic requirements and are aligned with the client, figuring out what the client wants, and building the right thing.
Development
This is the engineering team. They deliver the features, translating the product requirements into actual features. They are responsible for building the solution in the right manner, making sure everything is built correctly. Team members ideally should be high on technical excellence, follows the best practices in terms of security and tools and understands the Whys. This team works on communication and collaboration and there should not be any silos between the production and operations teams.
Architecture
Their role is to keep promises and minimize surprises. They define the guidelines on how the platform is used, how the different solutions will be used by the different groups. They are the guiding coalition to establishing the way the development group will be run. They will choose the solution and tools that devs will consume. Or new solutions that will be rolled out. They make sure that all processes contribute to the faster and safer movement of the build process. To do this, the team should try to standardize as much as possible so that they spend less time exploring solutions. If the development was responsible for build the right thing, this team’s job is to make building the right thing easier for the other teams.
Operations
This is the secret sauce of cloud computing. Going by their name, they are responsible to keep systems running. The mantra here is communications and collaboration, embracing risks, eliminating manual labour and of course, metrics. To do this, they standardize the environments as much as possible, aim for lower variations, and optimize the easy stuff for easier rollout to the end customers.
Evolution of methodologies
Waterfall
Software development has traditionally followed a waterfall approach or a linear approach in which requirements are documented and signed off by both parties and then work starts. Teams are silo’d, architecture is well-documented but there is a scope lock-in.
Delivery Time: Weeks to Months
Agile
Over the last 10 to 15 years, teams have started moving towards more of an agile way of working. Instead of being linear, the approach is iterative meaning architecture or requirements are incremental. Teams are cross-functional and they prioritise user stories and backlogs over documentation.
Delivery Time: Days to Weeks
DevOps
A more advanced approach called DevOps has risen to popularity which takes agile to the next level. Here the main focus is on people, processes and technology. It focuses on strong collaboration between different business units like architecture, development and operation. The key strategies include automated processes using pipelines, software-defined architecture which allows for scalability, and faster and safer delivery using feature toggles and blue-green deployments.
Delivery Time: Hours to Days
New ways of working, the digital way
Co-creation
The first step to achieving true transformation is to transform the existing culture to that of strong communication and collaboration. Teams need to break down silos and partner with each other to achieve a common goal.
Real business needs
Instead of sitting through trainings, teams should start with Proofs-of-Concept and fit small business case modules into the DevOps pipeline. This builds the team’s skills faster and increases their trust in the new system.
Open-source
Recently there has been an upsurge of open source solutions courtesy of CNCF. Although they do have a robust support network, blindly following this trend is not suitable for most organizations. A tailored solution that combines the best practices from these projects into a custom solution is usually the best fit for most organizations. Also, open-source the assets and packages inside your organizations so that other teams can contribute and benefit from each other.
Short MVP
Aim to deliver smaller chunks of the solution to clients faster, for faster feedback and higher quality and improved product-market fit.
Automate infrastructure
Data centres should be software-defined as much as possible. In a cloud-native world, this is all the more important. With proper SRE teams in place, organizations can set up enterprise-scale infrastructure with the push of a button. This cuts down weeks of provisioning time that was seen earlier and gets teams working from Day 1.
Anywhere, Anytime
Cloud-native doesn't have to end with development and operations teams. Product teams and business teams should also migrate towards tools that can scale effectively horizontally and vertically. PM tools like Jira and Confluence and analytics products like Tableau are all on the cloud now. Teams can collaborate effectively anywhere anytime. Microsoft has even launched a “cloud” version of Windows.
How I help do DevOps
What is DevOps?
To answer that, we have to first put out a disclaimer on what DevOps is NOT. DevOps is not a single product or tool. It's also not a job role.
DevOps is a set of principles for software delivery. It is more of a cultural change and a mind shift of teams (not just dev and ops but business, test and product also). It highlights the 3 elements of people, process and technology. It is the cultural aspect of things, automating the process as much as possible and approaching technology as a cloud-first approach to achieve better agility and deliver software faster and safer.
Challenges to implementing DevOps
It returns back to the same 3 things.
People are afraid of change. Teams are silo’d and have different goals and challenges. They do not want to divert from their established way of delivery. Like they say “if it ain’t broke, don't fix it”. Organizations need to change this mentality via training and workshops.
Teams have either a waterfall approach or more of something we call “scrumfall” instead of agile. It is seen that projects have some of the aspects of agile like daily standups, but their method of delivery is still waterfall, where requirements are fixed and averse to changes. Although most tasks are automated, there is no CI/CD (continuous delivery) pipeline in place.
It also doesn’t help if the technology stack is legacy. Very often it is seen that organisations start migrating to the cloud without a proper cloud strategy in place and end up with even more complex hybrid systems. For instance, infrastructure should be software-defined instead of manually implemented. Another critical aspect of this is the security implementation. Teams should strive to bring security to the picture as early on as possible so that it doesn't become a bottleneck. The same goes for quality assurance (QA). These should be baked in and automated as much as possible. Security should start right from the development stage, from code quality checks up to integration testing and further out to penetration testing. One strategy would be to follow zero-trust security, where we start with zero access and then allow iteratively as it is required. I could go on another 400-word rant just on Security (or DevSecOps) but that's another article for another day. In a nutshell, DevSecOps views security as pivotal to the entire development life cycle — not just reserved for a specific team in the final stage of development.
Measuring the business impact via KPIs
DevOps like talking metrics! And business leaders love this diagram.
Lead time for changes
This is essentially the time taken to get a feature or fix out of the door. Projects which follows DevOps have reported a 106 times reduction in the time taken to deploy changes; from a developer committing his changes to getting that code out onto production. This translates into market agility.
Change failure rate
Businesses also love high SLAs. When you are working with software, things will break. How DevOps can help is to reduce the number of times it happens, like, reduce it by as much as 7 times. This results in higher SLAs and eventually higher confidence in your products and services.
Deploy frequency
Another KPI for market agility is the deployment frequency or the number of changes your team has deployed over a particular sprint. More deployment means faster innovation and more bug fixes. With CI/CD and cloud-native architectures, teams can deploy features and patches a lot more and a lot easier than before.
Mean time to recovery (MTTR)
This simply means the time to restore a service after it has gone down. With proper CICD in place, you can roll back those breaking changes much safer and faster. This reduces your MTTR drastically and you can achieve six-sigma levels of SLAs if properly implemented.
So, which one is more important? The answer is that it is not a compromise. With DevOps in place, organizations can target all of them. There is also no tradeoff anymore between throughput and security
Below is a very simplistic diagram of what is known as the modern software factory. Any DevOps implementation will be a custom version on top of this architecture.
Next Steps
When I go in to consult with clients, I assess the technology landscape and fit the existing model into something I call the DevOps readiness framework. With proper inputs in place, it tells me the timeline and budgets required to implement DevOps. Post that, it boils down to these steps:
- Setting up the vision and objective, assessing the capabilities and baselining current ability to run DevOps today.
- Conduct deep-dive interviews with engineering teams and development teams about the SDLC and agile practices
- Meetings with the operations team about networking and access management.
- Interviewing with the product team; how they view the product and how they get feedback from the client and the market.
- This is followed by a workshop with all teams present to brief them about the way forward.
- Setting up a set of goals and roadmap for everyone to move forward on this new digital transformation journey.
With benchmarks from the market, the general timeline turns out to be something similar:
Conclusion
Some companies think that DevOps is a magic wand that will transform them into super-productive software factories, but there is a lot more to DevOps than cutting-edge technology. To achieve apparent benefits like faster delivery and lower costs, there has to be a culture shift at the organization level. Leadership should be able to look at the big picture and be willing to fail fast. Implementing DevOps also comes with high upfront costs and is time-consuming.
Although it seems like an uphill task (which it is), the transition will pay for itself in the short run and long. Accepting these caveats and following best practices to create a continuous delivery pipeline with CI/CD and proper security in place will unleash the true potential of what DevOps can do for you.
