Home United States USA — software Cloud Migrations, Highly Regulated Environments, and Making Work Visible

Cloud Migrations, Highly Regulated Environments, and Making Work Visible

324
0
SHARE

At the London DevOps Enterprise Summit 2017 (DOES17) conference, the second morning of keynotes discussed the role DevOps plays when migrating to cloud platforms; the creation and cultivation of effective teams that must work within high-regulatory environments; and how to improve the flow of…
At the London DevOps Enterprise Summit 2017 (DOES17) conference, the second morning of keynotes discussed the role DevOps plays when migrating to cloud platforms; the creation and cultivation of effective teams that must work within high-regulatory environments; and how to improve the flow of business value by making work visible.
Day Two of the London DOES17 conference began with three keynotes, this first of which “Sorry Mr (s) Ops, We Hadn’t Forgotten You: Part Two of the Hiscox DevOps Journey”, was presented by Jonathan Fletcher, Chief Technology Officer at Hiscox. Fletcher began the talk by describing how Hiscox began their journey in 2015 from a centralised IT function to a federated one, and that efficiency gains were achieved through the implementation of continuous delivery. This journey was described at DOES 16, and although Hiscox were clearly making strides in becoming more flexible (moving from ~2 deploys a week to ~50 deploys a day) , the team realised that they weren’t really doing “DevOps” – they continually asked themselves “where was the ‘Ops'”? Over the last year Hiscox have started a migration towards using cloud platforms, which was driven by an examination at the past and future trends on how IT is deployed within high performing organisation, and they are using this as a catalyst to fully implement a DevOps approach to delivery of business value.
After experimenting and creating proof-of-concepts with Microsoft Azure and Amazon Web Services (AWS) , Hiscox selected Azure as their cloud platform of choice – a key factor for this was that Hiscox have traditionally developed software using Microsoft technologies. Discussing the transition to becoming “cloud first”, Fletcher stated that until their current in-house infrastructure is fully decommissioned, they are likely to see an increase of total IT running costs. Accordingly, the migration must happen as fast as possible, and where an application has a return on investment for being re-architected (or re-built using cloud-native technologies) then this will be commissioned, otherwise it is “lift and shift ASAP and turn off our data centres – move then fix.” Moving to the cloud will not be the answer to all of the challenges faced by Hiscox, and significant investment must also be made in people, process and technology.
Discussing the future of IT at Hiscox, Fletcher stated the focus will be on high-value tasks that bring competitive advantage, and IT will be seen as a broker and integrator of technology capabilities, rather than the creators of them. All sides of the IT organisation should be using the same processes, toolsets and cultural ideologies.
There should be no ‘IT and the business’, instead we see BizDevOps as the ways forward.
The usage of cloud and Infrastructure as Code (IaC) changes the core skills needed within the IT department, but attitude to learning is more important that current technology skills. Hiscox are developing ” T-shaped ” people, with broad general IT knowledge and one or more deep specialities, and this is being achieved through a change in recruiting strategy and internal training.
The second keynote was presented by Suzette Johnson, Northrop Grumman Fellow, and Robin Yeman, Lockheed Martin Fellow, and explored “Cultivating High Performance Teams in High Regulatory Environments”. Johnson and Yemen both talked about their first and latest adventures with Agile and DevOps, which included developing large scale systems for data collection to support the US military “warfighter” project, and a classified asset management system for a US governmental department. Four key lessons learned were presented: work across the organisation; cultivate Agile teams and culture; build the infrastructure; and measure progress and success.
A core tenet of working across the organisation includes communicating the project vision, and ensuring buy-in from key executives. Customers must be engaged early in the project lifecycle in order to seek continual feedback and help build the business case. Internal team coaches need to be identified, and associated skills developed – Agile teams and culture are built upon trust and collaboration, and continual education and associated incentives must be properly aligned in order to support this. Agility and DevOps maturity assessments can also be useful to help gain an understanding of where an organisation/department currently stand.
Automation and integrated tool sets are vital for scalable implementation, and everything must be codified and placed within version controlled configuration management.
Both Johnson and Yemen stated that supporting infrastructure must be built and maintained by teams working within high regulatory environments, and this includes common frameworks, patterns and templates. Automation and integrated tool sets are vital for scalable implementation, and everything must be configuration managed. The final call to action included the importance of measuring progress and success. The team must understand what problems are being solved and the associated story being told (i.e. how the team communicates in regard to responsiveness, schedule and transparency) . It is essential to define what success looks like, and metrics to validate success must be specified up-front. Results must also be reviewed from multiple perspectives in order to ensure the required business value was delivered effectively.
The final keynote of day two, ” Making Work Visible – How to Unmask Capacity-Killing WIP ” was presented by Dominca DeGrandis, Director of Learning & Development at Leankit. DeGrandis opened the keynote by asking “why are we really so overloaded with work?”, and suggested that this overload can be unmasked by using Kanban designs that can bring visibility to things that stifle workflow capacity. Many people believe they can finish work tasks faster than they actually can, and accordingly take on too much. Sometimes burnout cultures play a role, but it is often due to the facts that people don’t want to let the team down, they are keen to start something new rather than toil in something unglamorous, they didn’t realise how big the request was, or their boss asked them to do this. This individual overload often negatively contributes to the delivery of business value by the associated organisation.
If the delivery of business value becomes stuck, then start by identifying the associated constraints: unplanned work, conflicting priorities, and dependencies
A “DevOps culture” combined with lean principles can help mitigate against overwork by focusing on identifying the information and value flows throughout the organisation, promoting the value of learning and continuous improvement, and encouraging high cooperation and trust i.

Continue reading...