The Doppler Quarterly Winter 2018 | Page 43

DevOps is also about process changes , contemporary architecture and design patterns that you use to build software these days . It ’ s very much a culture change . It ’ s about trust , communications and better collaboration . It ’ s the empowerment of providing delivery teams with decision rights regarding everything they are doing in the build cycle . It ’ s a multidimensional perspective on DevOps .
We very much embrace the Gartner framework ( Figure 1 ) in this space , and I encourage others to do likewise . It ’ s a journey of multiple years . At Vanguard , we ’ ve produced what we call our DevOps decoder ring . Because even if you read all the books and all the articles and even find an industry framework you like and understand , [ that ] doesn ’ t mean the other 4,000 IT professionals at Vanguard , or the business people , will understand it . We took all that knowledge and put it into a DevOps decoder ring , which is no more than a simple Excel spreadsheet , and it looks a lot like a maturity model where all the different DevOps capabilities or characteristics are in the rows , and the different maturity levels are in the columns , so you can self-assess where you are in your journey . The idea is to have a long-term perspective where you can pursue embracing more DevOps concepts after you pass the foundational steps . DevOps is very much a significant IT change event occurring at Vanguard as we speak
CTP : We have something similar at CTP . The columns are people , processes and technology . Often we will come in and give a list of recommendations , and most of what gets worked on is the technology . The people and process stuff is hard and cross-siloed and only a small dent gets put into those . Agility can only go so far . We always say technology is easy , but people and processes are hard . How can we break down those barriers , silos , different mixes of incentives , to really get to the agility play ?
Dowds : I think you ’ re right . New architecture , in our case moving from a monolithic approach to building software , to microservices — it ’ s cloud computing moving toward a consumption model rather than a provision model . The CI / CD pipeline , putting those things in place to speed the build / package / deploy process of the software lifecycle . IT people can get their heads around technical changes and make progress on them and be successful , but full stack teams ( all the organizational entities and leaders ) have to let go of responsibility and allow it to shift to the delivery organizations . That ’ s difficult . All IT shops have senior IT people who own their areas of responsibility and are not always ready to let go . That kind of organizational change is not always easy .
The cultural changes . Even if you put a full stack team in place and give them the decision rights after you tell them what business outcomes you want , that ’ s another major cultural change . The developers themselves , rather than being experts in a few things , they obviously need to be full stack developers , which isn ' t easy — putting the collaborative pieces in place .
We ’ re collaborating on hangouts today , but we need collaboration platforms in place that allow the full stack team to communicate , not only amongst themselves , but with their business constituents , which is often challenging . The “ mushy stuff ,”— people , organizational and cultural change — is harder than the technical stuff . My only advice is to try to focus on a couple of top line metrics that tend to drive the behavioral change you ’ re looking for . Personally , I ’ ve focused on a single top line metric and its deployment frequency . If you ' re operating in a DevOps way , you should see your deployment frequency increase . There ’ s no way your deployment frequency will become greater than it used to be , unless you ’ re building in thin slices , embracing concepts like minimum viable product , [ and ] have self-provisioned infrastructure . Again , it ’ s about embracing microservices architecture , putting in place robust CI / CD pipelines , shifting your testing left , empowering your team to make decisions , shifting security functions left , co-locating teams that are collaborating and making business decisions that produce the business outcomes you ’ re looking for . I do believe that if the team is focused on their deployment frequency and embracing every DevOps concept you can think of that would have a positive impact on that frequency , you would eventually start behaving the way you need to behave from a culture perspective .
CTP : One of the things Vanguard did that we like to use as an example is that you talk about full stack team a lot . We like that because we think of a full stack engineer as a unicorn . There isn ’ t one person who knows everything about everything . But you ’ re able to bring people together from all different disciplines under
WINTER 2018 | THE DOPPLER | 41