Industrializing IT with the Help of DevOps
The digital transformation of their IT organization is a major topic for many banks and insurance companies. DevOps (Development and Operations) can be a decisive door opener, transforming IT from a simple service center into an integrated part of the value chain. What needs to be considered and how best to implement it?
What is DevOps?
Faster, better and less costly are the most common goals when planning to implement DevOps. In the era of digitalization, especially the capability to deliver fast-to-market is becoming an important competitive advantage. The term DevOps, first emerging in 2009, is used to describe a cultural and professional movement that stresses communication, collaboration and integration between software developers and IT operations professionals while automating the process of software delivery and infrastructure changes. The aim is to establish a culture and an environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably. Approaches like continuous integration and continuous delivery help to improve the flow and the quality. Automation is seen as an enabler within this. Most things are not really new within DevOps. The major difference is the goal to consequently measure the output of an IT organization and sensibly combine different well-known methods. The key idea behind DevOps is to break down the silos between development, operations, and other groups, such as business, architecture and testing by encouraging the engineers within these departments to collaborate more effectively. With the progressing evolution from agile to DevOps (via continuous integration and continuous delivery), the increasing collaboration delivers more and more value to the organization ( fig. 1).
We understand DevOps as a kind of target operating model for the IT aspects of an organization. Below, we elaborate on the underlying collection of ideas and principles that can be used to transform IT from a service center into an integrated part of the company’s value chain. While every organization is unique and needs a tailored road map to introduce DevOps, we outline an approach that has proved to be successful for Synpulse clients.
Adapting IT to changing markets
Software development as such is very well understood in almost all organizations. Most banks and insurance companies have already introduced «agile software development frameworks», e.g. Scrum or the Scaled Agile Framework (SAFe), to better meet their customers’ needs by increasing the flexibility of their development organization. Although this has proved to be very beneficial, these frameworks only focus on what needs to be developed and when and how this can be done in the most efficient way. They neglect important tasks further downstream in the software value chain, such as testing, packaging, deployment, and maintenance. Furthermore, the development teams and the operations team, responsible for looking after the systems that run the code, exist in two relatively separate worlds.
Here is where the DevOps movement fills the gap by considering to look at the whole IT value chain. The two communities (Dev & Ops) need to learn to cooperate and work together for the good of the organization. Organizations who have successfully introduced DevOps have shorter development cycles, an increased deployment frequency, and a faster time-to- market. A typical deployment cycle in the financial industry is semi-annual. In contrast, Amazon for instance is deploying on average every 11.7 seconds to their productive IT systems. The benefits of these frequent deployments are obvious! Shorter time-to-market is much easier achievable – a key asset in the time of changing markets. In addition, collaborating or interfacing with a FinTech/InsurTech company or product is simpler on both ends if they share a similar agility – and the FinTech/ InsurTech startups are agile!
The three ways
There are three basic principles – usually referred to as the «three ways» in the DevOps community – which form the foundation of all DevOps patterns. They describe the values and philosophies that frame the processes and practices of DevOps.
- The first way emphasizes the importance of understanding the flow of work through the organization, from development to the IT operations team. The aim is to increase the flow by achieving a profound understanding of the entire system and removing constraints.
- The second way is about creating feedback loops to upstream process steps (e.g. automated testing, event management data, shared on-call rotation, etc.). The goal of almost any process improvement initiative within DevOps is to shorten feedback cycles and amplify feedback loops to make the need for change more transparent and also to support the continuous drive for improvement.
- The third way puts a spotlight on continuous experimentation and learning. On the one hand, organizations should explicitly allocate time to allow their teams to innovate the daily work and to reward them for taking risks. On the other hand, rituals to reflect on one’s own performance need to be constantly practiced to gain mastery in a certain field. This helps to critically assess the added value of a recent change and to retreat quickly if something goes wrong.
The journey to organizational agility
When planning to introduce DevOps, most companies first think about tools to automate their IT processes. In fact, a plethora of tools is available in the market to support the underlying practices and principles. However, DevOps is not only about replacing the tools used in the IT organization. While tools can facilitate certain aspects of the transformation, the more significant change must take place in the minds of the employees in all departments and on all seniority levels.
As every organization is unique, there is no universal way of introducing DevOps. Yet, Synpulse was able to observe a bottom-up approach in four steps that has proved to be successful at various clients (fig. 2).
- Generally, it is advisable to lay the foundation for DevOps by introducing some kind of agile method within the development team, such as Scrum or SAFe. This fundamentally new way of working usually finds a lot of support, not only from young, but also from more senior software engineers as it empowers the development team to organize itself rather than following an externally driven plan. The teams will go on a journey and experiment what is the most effective way of working to deliver value to their end- users, and performance will improve.
- Once the teams have established an agile way of working, the exchange among these teams and other departments needs to be enhanced and the organizational silos need to be broken up. This is usually the most challenging part of the journey, as it involves a painful break with beloved habits and requires a lot of active coaching. To change technology and tools is easy, but to change the mindset of people is tricky. All employees need to look left and right to understand the issues and obstacles of co-workers in preceding and downstream process steps. To foster a positive attitude rather than a destructive atmosphere, mutual trust needs to be built among the teams and an open communication needs to be established. This second step («communicate») will most probably already improve your organization’s performance and reveal bottlenecks in the processes, but it is not the end of the journey.
- While specific steps can be optimized in an isolated manner, it is essential that the organization is clear about all the departments involved. The sequence and the interface of all departments must be known (and documented), from the business department submitting a new request to the IT support organization supporting the new feature in production. Only a bird’s-eye view enables the standardization of the internal procedures and the handovers in the IT value chain. There are other advantages of a global business process map shared across business and IT functions. Coupled with strong process governance, such a map can be leveraged during the assessment of the change impact of a new feature and facilitates test automation.
- Only when end-to-end processes are fully understood, bottlenecks are removed, and standards are established, the automation should be started. Automating process steps too early in the transformation can result in paving the cow path.
You have completed the transformation into DevOps? Your company is working in a fully agile manner, and your IT team has achieved an impressive time-to-market? Now the time has come to leverage the investments in your organization. Reacting quickly to new market demands is only the first step. It might be interesting to expand the tool set of your organization with innovative methods, such as Design Thinking to create and deploy revolutionary products, distribution channels, or revenue models. Your organization will be ready to launch and evaluate pilot projects in a short time («fail fast» principle). Given a positive outcome, the pilot can be scaled to the whole company within no time.
The transformation towards DevOps is not a walk in the park. The underlying change in the mindset of IT, business, and management is significant and requires a clear vision, strong leadership, and a stringent change management. There is also a plethora of tools on the market to automate all aspects of the IT value chain. To avoid distraction from the social aspects of the transformation, changes in the tooling should be considered late in the process.
DevOps changes a lot in an IT organization. We have mentioned a few key benefits: Faster time-to-market, short pilot project cycles and better compatibility with FinTech/InsurTech. In addition, the 2016 state of DevOps report also emphasizes three times fewer deployment failures and 24 times faster time to recovery.