Tell us about your work with O₂/Telefónica?

Plutora was brought in alongside NTT Data, which manages several test environments, alongside other hardware and consultancies managing independent systems and environments. NTT sought to manage all requests and environment usage and utilized Plutora in that effort to centralise all environments (those from NTT and those from others).

O₂ initially struggled to manage its test environments as any number of actions resulted in downtime for the environment. These are issues such as multiple teams deploying conflicting changes to the same environment, environment contention (not knowing someone else was using it), misconfigurations, and a lack of maintenance to the environments made them fragile. Test environment outages reduced the test team’s time and ability to verify features and ensure quality delivery. Meanwhile, much of the environment management team’s time was spent merely managing the schedules, environment requests, and configurations, rather than being able to focus on provisioning, automation, and maintenance.

How has Plutora brought a positive change?

Using a system to manage environments (rather than home-grown tools or spreadsheets) created a real-time connected view into what was actually going on. The benefits that O₂ has seen include:

1. Reduction in meetings and reliance on spreadsheets. No longer does the environment management team spend time managing spreadsheets, responding to phone calls and email requests (of which they had around 30,000 per year), and doing repetitive administrative tasks. The tooling enabling the team to focus on managing the workload, using data to focus improvement efforts, and improve quality service with the same staff.
2. Application delivery improved. Downtime for the environment has resulted in less time to test, rather than delayed schedules. Overall, bugs are found sooner and fixed more quickly.
3. The team is now able to consolidate usage of environments and focus on larger initiatives such as migration to cloud and improvements in development methodologies.
4. O₂ is moving towards a completely self-service model enabled by the environment management team, automation and tools. Provisioning and conflict resolution are being included in that effort.

 What other big things are happening in the world of telecommunications?

The world of IoT is exploding in every industry, including telecommunications. While testing internal software delivery against simulators is critical, it still doesn’t substitute for actual device compatibility and functionality testing on real devices. The environment labs are another type of test environment that now must also be managed. That represents a problem for most companies that don’t have centralised environment management, as similar problems arise in the form of scheduling conflicts, misconfigurations, and downtime causing overall project delays.

 What problems tend to arise in a telecommunications and testing environment and how do you overcome these?

Telecommunications companies have typically been around for a very long time. This means they have a long legacy of software and hardware products forming a fabric of solutions for their customers. Every application built must be compatible with the legacy systems (both hardware and software). In addition to that complexity, telecom is highly regulated meaning compliance adds time, process, and extra steps to each effort. As test environments look to mimic production, the complexity required for non-production is very high spanning architectures, methodologies, geographies, vendors and products. Each team must ensure alignment of their efforts to conform in an auditable way.

To overcome these problems, teams simply can’t deal with test environments in an ad-hoc way. Without automation, teams will never get on top of the requests for environments, let alone be able to improve the process of managing them.

You have written about release management; do you think this is something still relevant today? Why?

The job of release management focuses on managing the resources and risks of all application release trains. Release management also adds governance to ensure regulatory compliance of each pipeline regardless of the technology utilised. In product-oriented, DevOps style teams, there has been a push that release management is antiquated and can simply be automated.

As DevOps teams mature, they typically transform their relationship with release management from that of oversight and management to the release management coach. Release management teams are implementing more tooling to enable the increased velocity of each team and the explosion of smaller, autonomous teams. They use these tools to guide each effort for all teams regardless of their level of maturity. They commonly use the analogy of providing the “release highways” that include guardrails, down which each autonomous team can drive whatever car they’d like at whatever speed suits them.

Organisations that don’t resolve the new relationship of release management and DevOps stall in “wrestling matches” that are generally halted by the operations teams. As heard by one customer onboarding to Plutora, “We’ve been doing DevOps for 18 months – and have yet to ship anything.”

What big things do you predict for 2020?

• Now is the time of value stream management – using systems thinking to manage each application delivery pipeline independent of its tooling, architecture and mythology. Using metrics gathered as part of the process to drive further innovations to improve efficiency, quality, velocity and ultimately, value delivered to the customer.
• Autonomous teams will drive massive change in the way development is operated. Product managers will “own” not only each idea as it gets delivered into production, but also customer adoption and satisfaction. As an industry, we’ll see a continued push towards, “You built it, you run it” and no longer will teams have any walls to throw their applications over. These teams will be incredibly nimble and wrestle with how to provide governance and transparency to the business.

The post How this firm used DevOps to change the Telecoms industry appeared first on DevOps Online North America.

It can seem as though release management is unnecessary, with the operations team being responsible for production runs, and the development team in charge of building the applications. This is far from true, however, as continuous delivery cannot run smoothly without it, and businesses that don’t integrate this way of working will soon fall behind the industry leaders.

What does release management do, and who does it help?

Release management is designed to help focus attention on the bigger picture rather than getting lost in the minute details. It enables teams to see their software during the production and development process, as well as understand how it fits into the overall business goals. It’s more than just coordinating the manufacture of the latest software – it enables all of the resources, the features and the testing to be coordinated, and aids understanding of the lifecycle of the applications. Essentially, true release management is not just about risk, but also everything that is needed to coordinate both the software moving into production as well as all of the different teams to ensure that every release meets company standards. It also simplifies communication between stakeholders so that they understand how the products of each individual team work together in the production environment.

However, for release management to be adopted fully, the traditional structure of the business needs to be updated along with it. Product managers need to run the entire deployment process from start to finish with the end goal being to ship finished software. In doing so, they become the link between the business, the customer and the development team.

The challenge is that product managers are probably not already release management experts, so they can’t always fulfill this role alone. This is where the product-oriented team can bring the most value. Release management responsibilities are changing as DevOps adoption matures, so these are being transferred to the product-oriented team, although there will likely still be support from a release management group.

Is release management still relevant today?

It is not unusual for businesses to question the benefits of release management, but this lack of understanding often comes from those who don’t have release management in place yet, or that have been unable to make it work well for them. The answer is simple: release management helps teams to manage the consolidation of DevOps and distributed, microservice-based architectures – a difficult task for any team to handle unassisted.

Monolithic applications, independent from all other applications, are still very common in today’s digital world, and the trouble with them is that it means that there are dependencies. Dependencies will make life difficult for anyone trying to run autonomously, as these applications must be able to connect up with all of the others. Many teams will also still possess more stable systems of record, such as ERP (Enterprise Resource Planning) applications. Again, managing these presents more complications, especially when changes are being made, and if the cycle includes a hybrid environment. Failing to integrate an appropriate release management strategy to manage this complex landscape can lead to potentially severe disruptions to the everyday business processes.

How do autonomous teams benefit?

Automation is improving in leaps and bounds. While autonomous teams are as well, there are business areas such as security or accessibility that will never be completely autonomous, so the teams will still rely on additional support. This is where release managers can really make an impact. Since they have visibility of the whole process to see how every tool operates both as a stand-alone and in conjunction with others, they can easily identify where bottlenecks are cropping up so that they can be resolved.

Plus, release management accounts for every part that can’t be automated. For businesses to get the most out of this, they should either implement coaching for the product manager or introduce a part-time release manager to assist the product team.

However, there will be times when people are not available to help, and so there are also tools that can be adopted to make this process smoother, such as a “virtual release manager” tool. Something like this can cover all of the delivery teams – it’s a mix of release process orchestration and templatised and standardised releases that are fully approved by the release management team. The templates provide an example of how the release should look, just like a blueprint for each release – they create a foundation for developers to build on with the exact details of the required release.

Along with this, businesses should shift all requirements for governance, risk and compliance in the development and delivery to the left. They need to create non-functional requirements so that development performs all of the essential tasks during the development cycle, not after. Introducing accessibility reviews of the design, threat modelling, or architecture review, for example, early in the process can reduce risk later on, as any problems can be picked up and resolved.

Release management has not seen the end of its life – not even close. It might be tricky to implement effectively when the company culture is not used to this way of working, but the overall benefits of the visibility and support that are gained through the introduction of release management outweigh the challenges teams may experience in the early stages. By persisting with integrating this different way of working, DevOps teams will find themselves working more collaboratively with each other, and producing higher quality service to all customers in the long-term.

Written By Jeff Keyes, Director of Product Marketing at Plutora.

The post Has release management seen the end of its life? appeared first on DevOps Online North America.

It is something of an achievement to make the final list in a competitive and growing field and the number of big hitting companies listed is a strong testament to their fine work.

The list has leading financial service companies Barclays, Lloyds Banking Group, Allianz Insurance and Banco Santander all included.

The Leading Vendor category is packed full on major firms: Aqua Security, CA Technologies, OpsGenie, Plutora, Puppet and Redgate Software.

The Best Use of DevOps Technology, sponsored by Automic, has an impressive array of companies, with data software company Actifio, two banks in Barclays and Lloyds, energy company Centrica, digital and technological specialists Cognizant, investment bank Nomura, software outsourcing company Qarea, and software testing specialists Tricentis all in the category final list.

Devops Online is looking forward to an amazing awards evening on 18 October at Marriot Grosvenor Square, London, and hope to see you there.

Book your table here: http://www.devopsindustryawards.com/attend/book-your-table/

The post Exclusive: DevOps Industry Awards finalists announced appeared first on DevOps Online North America.