Subscribe

How DevOps can turbocharge your time-to-market


Johannesburg, 01 Sep 2016

Software updates. As consumers, they can seem like the bane of our lives sometimes. When we shut down our PC at work, when we boot up our laptop at home, when our phones get on WiFi and now even our TVs and thermostats - when we sleep, everything is getting updated.

Of course, annoying as it can be, we also have come to expect that most digital products are provided with updates and will improve over time. This fundamental shift in customer expectation has led to a constant two-way flow of data that rewards correctly structured companies that continuously analyse, refine and update their products responsively.

For those on the outside, it can seem almost impossibly fast and reactionary and may not feel like an appropriate fit. You may not consider your company to be in software development, but if you create and deliver any kind of digital product on or via the Internet, whether it be a Web site, widget, standalone program or even hardware, particularly with the rise of the Internet of things, then your business has a software component and could stand to benefit enormously from implementing DevOps, if it hasn't already.

A portmanteau of development and operations, DevOps is an organisational and technological framework inspired by software firms' pressure to deliver more often, at higher quality, more cost-effectively than ever before. The end result is a strategy geared towards continuous improvement and incremental updates, backed by a philosophy of improved time-to-market, followed by highly responsive, customer-focused development long-term.

As these models depend not only on increasing but also on maintaining customer engagement, the focus of getting software to production in a defect-free state is more critical than ever. This is put into practice by ensuring the software development life cycle (SDLC) is as streamlined as possible through organisational and structural change of software development practices, as well as the use of automated tools and tests to ensure high quality before deployment.

The DevOps approach is effectively applied across two main areas: organisational and technological.

Organisational changes

In a traditional business environment, departments are formed around skillsets and these departments work as independent units, dividing tasks for projects between them. In a DevOps environment, teams are formed around the skills needed to complete the project.

Skills are still grouped on paper; however, instead of operating as a single processing unit, it is treated as a pool, often referred to as a guild. When a project is put into action, project managers can then build their team based on the requirements of the project and staff availability. This group is known as a Delivery Pod, and ideally are located in the same space to enable better collaboration.

Internally, the Delivery Pod operates using what's known as the Kanban method. In essence, this approach is an evolution of Scrum, where team members "pull" work as they have capacity, rather than work being "pushed" into the process when requested. This structure allows for better workflow and resource management, identifying bottlenecks faster and for identifying and addressing bugs and defects more responsively.

Finally, keeping pods on track requires someone with a holistic understanding of both the business and DevOps, so a DevOps coach is assigned, with no affiliation to any Delivery Pod or guild to work with the PMs as an enabler, assisting with tooling and technology choices.

These changes can improve effectiveness by ensuring the right people, with the right skills, collaborate as and when needed to produce the best results.

Technological changes

When looking at new software releases, the typical way to look at developing and releasing them came down to two types of update:

1. Minor, Dev-driven changes that only affect a small and/or specific area of the product.
2. Major Ops-driven changes that have potential impacts product-wide.

The reason for this approach comes down to testing. The first can be applied more quickly by isolating the affected application or technology stack and simulating using virtualisation, test automation and applying Agile principles that may already be approaching the goal of continuous delivery.

This is much harder to achieve, however, when the project is large-scale. These often need end-to-end testing, have a large number of application changes and need to achieve operational acceptance. The point of disconnect between the two is known as the Complexity Wall.

The goal of DevOps is to tear down this wall through application-centric integration. What this means in practice is building goal-orientated, integrated teams across the entire organisation and its infrastructure to focus on fast, tight-knit development.

Much of the speed gains come from running virtualisation wherever possible, allowing for faster tweaking and testing, which in turn leads to faster turnaround. Enabling this requires restructuring software and data into separately deployable units.

Further gains are made through automating testing to as close to 100% as possible. This permanent monitoring system is combined with fall-back procedures to ensure continuous smooth running with minimal manual input.

Not every aspect of DevOps will suit every company and it is vital for Dev and Ops to collaborate to ensure any changes will have the appropriate QA and provide adequate benefits to justify the radical process change.

Getting started with DevOps

While technological change can be a challenge, ultimately it is a puzzle with a solution. Cultural change can, on the other hand, appear a daunting, seemingly impossible mountain to climb. Between managing change with existing projects of varying ages and end-dates, and dealing with political issues such as changing job roles, functions, responsibilities and of course reports, bringing an entire organisation into a totally new structure in one go is at best unlikely to succeed and at worst impossible to realistically implement.

Like most successful journeys, this one starts by creating a roadmap - a clear change programme that starts with a capability assessment, allowing a strategy to be defined for the transition, including a continuous improvement process that will eventually include as much automated monitoring and testing as possible to enable successful regression testing and creating a risk-based deployment pipeline.

Keeping quality high from as early as possible in the process will of course reduce the likelihood of defects and bugs reaching the public eye, potentially affecting customers as well as the company's reputation. This may hardly be a revolutionary concept, but the problem is often the increased time and cost of additional testing; however, by automating the tests from the outset, these constraints are massively reduced, making early-stage testing a far more viable option in the majority of cases. Automation can be implemented in various ways, such as automated regression testing, UI automation testing, shift-left performance testing and inbuilt static analysis for security and code quality.

Once successfully tested, any component needs to be integrated into the real-world environment to be of any value, so a continuous integration (CI) platform is used to oversee and govern any changes. A CI platform uses scheduled and check-in-based software builds to ensure no conflicts or overlaps across developers and teams. Essentially, it provides the holistic governance required to safely link development, testing, integration and deployment without manual input.

Embrace DevOps culture for an extra boost

Successful DevOps implementation is not just about the technology. To truly exploit this system, cultural change needs to work symbiotically with the software and hardware changes it brings.

As DevOps teams are based on project rather than function, individuals can (and need to) have a better understanding of the entire SDLC and their role within it. Working as a close team with a shared goal, issues stop being an individual blame-game, become a team challenge and can get resolved much more quickly than before.

This is not only true for developing the product itself. As DevOps team members have more holistic perspectives, they also become experts at adapting the DevOps process to suit their specific needs and goals, and can do so without having to make those changes across the whole department. That said, should these changes prove to be valid for other areas of the business, thanks to the managing, monitoring and coaching system in place, that training is built-in.

Conclusion and next steps

Having read thus far, it could appear possible to just get an off-the-shelf 'DevOps blueprint' and follow it, but this would defeat the object of the practice and in reality is unlikely to succeed. Although the process needs to be gradual and well-managed, ultimately, the culture has to transform hand-in-hand with organisational changes, which too have to work in harmony with process and technology changes.

It is a complex, often long process that can be daunting for even the most seasoned managers, so thankfully there are many resources out there to help at every stage of the DevOps process. A good starting point would be to read the whitepaper: "Transformations in Business and IT" from SQS, which provides further details on DevOps and other related areas, as well plenty of links and contacts to find further reading and assistance.

DevOps is no silver bullet and will not solve all your business problems overnight. However, if correctly implemented and maintained, it has the power to keep your business agile and responsive while simultaneously reducing overheads and developing and empowering staff. It may not fix everything, but it's a great place to start.

Share

SQS Software Quality Systems

SQS is the world's leading specialist in software quality. This position stems from over 30 years of successful consultancy operations. SQS consultants provide solutions for all aspects of quality throughout the whole software product life cycle, driven by a standardised methodology, offshore automation processes and deep domain knowledge in various industries. Headquartered in Cologne, Germany, the company now employs approximately 4 100 staff. SQS has offices in Germany, UK, US, Australia, Austria, Egypt, Finland, France, India, Ireland, Malaysia, the Netherlands, Norway, Singapore, South Africa, Sweden, Switzerland and the UAE. In addition, SQS maintains a minority stake in a company in Portugal. In 2014, SQS has generated revenues of EUR268.5million.

SQS is the first German company to have a primary listing on AIM, a market operated by the London Stock Exchange. In addition, SQS shares are also traded on the German Stock Exchange in Frankfurt am Main.

With over 8 000 completed projects under its belt, SQS has a strong client base, including half of the DAX 30, nearly a third of the STOXX 50 and 20% of the FTSE 100 companies. These include, among others, Allianz, Beazley, BP, Commerzbank, Daimler, Deutsche Post, Generali, JP Morgan, Meteor, Reuters, UBS and Volkswagen, as well as other companies from the six key industries on which SQS is focused.

Editorial contacts