Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Information technology has been an integral piece of the modern enterprise for multiple decades and that dependency is only growing. With digital transformation, there’s the inevitable increase in demand for new applications. As such, software development services will continue to be a vital component of the business amidst the mounting pressure to innovate and deliver. This has resulted in many organizations moving from traditional development practices to more flexible and agile methodologies. Conventional software delivery methods are also being replaced in favor of enterprise DevOps practices such as continuous integration (CI) and continuous delivery (CD).
While DevOps stimulates innovation and speeds up software delivery, adopting DevOps practices does not guarantee success as there are times when companies have been underwhelmed after implementing DevOps practices across their development teams. Knowing this, it is important to state that most DevOps failures come down to flaws in the execution of the methodology. A best-practice DevOps implementation should increase the value and impact of IT infrastructure by bridging new and old technologies. This allows for companies to better navigate change with clear time-to-value merits and lower risk. In short, it’s about scaling DevOps practices with security and quality embedded every step of the way.
Look for Small Wins and Build on What Works
Implementing DevOps best practices can mean a radical shift from the way an organization currently works. It is important that the entire team buys into this new approach. However, different dynamics within different organizations can lead to different results.
Ideally, you should never have large complex projects. The best approach would be to work in small batches where you and your team can quickly learn from your decisions. By identifying the bottlenecks causing the largest constraints in your delivery process and incrementally changing, transforming and optimizing, your team could demonstrate the advantages of the new DevOps practices and build confidence in the team’s ability to implement the new methodology. Wins like these give a great start to the project before you’ve even introduced the entire IT organization to the changes needed to implement DevOps best practices.
Break Down Organizational Silos
Known as well-intentioned areas of specialization, organizational silos are defined within the business to sharpen expertise and assign roles. Silos may have unintended consequences over time though, as each department potentially starts paying less and less attention to the other departments as they become consumed by their own assignments. As a result, silos inadvertently limit collaboration and have the potential to contribute to delays, bugs and conflicts. This is why C-level executives must initiate the process of removing the barriers to these silos and integrating the different disciplines within the IT department.
For DevOps to work across the enterprise, executives must reorganize the configuration of software development projects by bringing in representatives from all important IT disciplines.
Everyone Needs to Be on the Same Page
Sometimes silos can be deeply rooted in an organization, and even if you do succeed in removing the barriers, there’s always the risk that they could re-emerge. Due to this, it’s important to create motivation for a silo-less enterprise.
Anyone wanting to change a culture needs to define the actions and behaviors they desire, and design the work processes that are required to reinforce those behaviors. If your ops team is measured only by mitigating risk and your dev team is measured by delivering change, it goes without saying that you have a conflict.
Through the incorporation of intra- and inter-team collaboration metrics into individual and team performance reviews, you can base a considerable amount of the review on lead times and quality metrics for software delivery. This is important not just for the dev and ops teams, but also QA and security. It’s easier to act your way to a new way of thinking rather than think your way to a new way of acting.
Real-Time Visibility Across the Toolchain and Environments
When a team has poor visibility of their system, it can result in bad decisions and missed opportunities. Teams must replace manual project and release tracking methods that use spreadsheets and emails with an open, web-based solution that your team can leverage to plan, track and govern the entire application release management process.
As teams and their stakeholders need real-time visibility across the entire DevOps toolchain and production environments, it is important that the chosen solution enables product team members to focus on their critical tasks while providing pertinent real-time information to their managers and stakeholders.
Don’t Lose Sight of the End User
Once deployed, the application or service will interact with existing, and quite often, new systems. As it is developed for use by humans, don’t lose sight of the end user. Their satisfaction determines the success of your application or service.
Actively involve users every step of the way, not just at the ideation and product requirements level. Teams should take the appropriate time to properly assess and fully understand the issues, challenges, priorities and constraints of their users. This knowledge can be utilized to define key performance indicators (KPIs) and continuous feedback throughout the DevOps toolchain.
Move Forward on Orchestrating Continuous Delivery
There’s no question that a lot of work goes into preparing and deploying a release. With the goal of delivering releases that have a high impact, it seems that companies sometimes choose to hold and then bundle together multiple application improvements into a single release. Such a strategy can lead to poor quality and failure—a result of deploying large infrequent releases. As another key driver toward an increased need for orchestration and automation, a lack of skilled employees means that many organizations have trouble releasing software in a reliable manner.
The orchestration of continuous delivery is a fairly new way of planning and delivering business applications across the enterprise. With a focus on continuous improvement, continuous integration and ensuring you are always ready to deliver what the business needs, release control and deployment automation are vital to ensuring smooth delivery and a basis for governance.
Conclusion
The implementation of DevOps is a long term commitment. More a philosophy directing how you work, DevOps is not a rigid set of practices like ITIL, lean or Agile development.
No organization will reach a state where it can comfortably say it has perfected its DevOps best practices model. Instead, it must continuously experiment with new processes, capabilities and tools identifying those that can yield the highest possible integration across the entire DevOps toolchain to deliver the best value for the business.
