Share
These days, ec = ic, that is, every company is an IT company. DevOps provides a framework for examining and improving an organization’s individual software building blocks. Over the next couple of years, unanimous internal alignment will become the critical factor in successful DevOps. Early-adopters that have been doing DevOps for a while are now focusing on the best ways to organize their teams - from getting people with in-depth knowledge onboard to streamlining their (platform) teams.
Typically, early adoption started bottom-up, whereas now (and in the near future) higher management of a late majority organization will be adopting DevOps. Unfortunately, this top-down adoption causes people further down in the trenches to lose touch with the true meaning of DevOps. The challenge is to change your organizational structure and involve all people that play a role in the delivery pipeline. This is the only way to succeed with a fruitful and holistic adoption of DevOps.
Consolidating tools
If you aim for multiple daily releases rather than monthly or yearly ones, you need to be living and breathing DevOps, that is, focusing on people, process, technology, and information. Organizations that started a little earlier than others, already have multiple small DevOps teams. These circles are now starting to join and merge into high performing teams. Clearly, this is an internal transformation that includes learning from failures, experimenting (with the supporting tools and practices associated with DevOps in the context of continuous delivery), continuous improvement, infrastructure and configuration as code, and so on.
Organizations that are among the late majority of mainstream adopters, probably belong to a more conservative organization, regarding innovation. DevOps should be made more tangible to support the organization’s digitization, so that teams don’t lose faith when the going gets tough. Whether it's working on Docker, containers, or microservices, everything looks fine and rosy in the first period. But then things start to stagnate and the morale sinks. Accepting the learning curve and holding on through this “failure swamp” means trusting others’ success stories and creating an own DevOps mainframe.
There is no shortcut for experience
Working on DevOps principles forces a holistic approach that has a combined commercial, organizational, technological, as well as cultural impact. This implies significant change for the people in the organization. They have to work on modernizing their software architecture, adopting an agile and lean way of working, building intelligent infrastructure and adopting continuous delivery.
Talent management cannot be limited to training and individual development of employees. Experience is the result of a DevOps journey. Employees learn on the job doing their work the DevOps way. Ideally, they are guided intensively by agile and technical coaches which help them to understand and experience the DevOps implications, so they become real engineers. This process takes time. Experience is not something you can obtain overnight.
Apply a Ninja Approach for Software Selection
Avoid lengthy enterprise software tool selection based on general use cases, demonstrations and feature evaluations. Software tools only deliver value when they have been successfully adopted and integrated by teams in your organization. Rather apply a more unorthodox approach, where teams are empowered to introduce and experiment with software tools. They can uncover the real value and they must master (e.g. manage) the software.
Do not Pollute your DevOps Initiative
It is tempting to dump requirements from other running (project) initiatives or failed projects as requirements for your DevOps initiative. This pollutes your DevOps initiative with additional complexity, conflicting requirements and technical challenges. It will impact the autonomy of your HPTs, resulting in many impediments. Worse case, your HPTs are bound to existing ways of working and inherit existing technology and procedures.
Depth Over Breadth
Rather than an enterprise wide initiative with a shallow impact, start small within a single business product domain. Adopt DevOps end-to-end within this domain and include additional domains gradually. Build in-depth experience within your organization, before starting with a company-wide adoption.
Shifting Gears Successfully
DevOps is all about delivering continuous value to the business. This means that DevOps will be all about accelerating business (without compromising in quality or scope).
But how? The first step is to define the business capabilities you want to provide to your customers and to organize yourself accordingly, with minimal dependencies. This requires the assembly of high-performance teams (HPTs) around your business capabilities (also known as DevOps teams).
The next key to success is to start with one business capability. However, it is very important to apply all aspects of DevOps with this initiative. Culture, organization, process, automation, and measurement need to be considered from the get-go.
Benefits of the cloud
To ensure DevOps acceleration, consider the full benefits of the cloud. Bastiaan Bakker, an IT architect and DevOps coach, lists several instantaneous benefits of a full cloud experience:
- Automation: Exposing all infrastructure services via programming interfaces greatly facilitates rigorous automation, providing your organization with software-defined everything.
- Autonomy: The cloud’s multi-tenancy, resource isolation, and security enable teams to not only design their infrastructure but also to create and maintain it-- a holistic side effect of a cloud-native environment.
- Innovation: Cloud is a catalyst for both innovation and experimentation; there are no huge upfront costs for hardware, setup, and so on if you want to try out a new architecture or service.
- Feedback: Metering of used resources enables fast and detailed financial feedback.
- Knowledge sharing: Developers ultimately prefer sharing code versus writing and reading documentation.
- Responsibility: Bakker states, “Clear responsibility and boundaries between your cloud provider and your team facilitate a ‘you build it, you run it’ mentality. As a team, you can take responsibility for properly running the stuff you build”.
This article is part of the Urgent Future IT Forecast 2017.
