DevOps in the context of enterprise agility

    6877
    SHARE
    DevOps

    DevOps Lead at Barclays, Barry Chandler, exclusively explains to Software Testing News Journalist, Leah Alger, the importance of focusing on enterprise agility and entrepreneurial thinking rather than DevOps in isolation

    Chandler has been at Barclays for more almost 17 years’, beginning his time as a developer in post-trade services (settlement) and progressing to managing development teams across multiple locations. He has also led teams responsible for improving application performance, increasing capacity on mission-critical applications by multiple factors.

    When Chandler’s teams became more agile, approximately 5 years ago he took on a wider remit and turned his attention to DevOps.




    One of Chandler’s core beliefs is that you can be brilliant at agile delivery, live and breathe DevOps, but lack of focus and understanding of your value streams is the biggest cause of waste, resulting in these capabilities being ineffective.

    ‘Sometimes DevOps isn’t going to help’

    “I realised pretty quickly that optimising your DevOps capability in isolation is no guarantee that an organisation will add business value. I believe it’s extremely important to focus on the combined effects of a collection of capabilities like transformational leadership, entrepreneurial thinking, diversity, as well as technical aspects such as agile, security, cloud and DevOps. I refer to this as enterprise agility,” said Chandler.

    Chandler is familiar with a variety of DevOps tools such as Git, Jenkins, Nexus, TeamCity and Sonarqube and encourages others to use them. Within his remit as co-chair of the DevOps community of practice, Barry helps Barclay’s carry out tooling related proof of concepts and seeks out continuous improvement opportunities across the board.

    He continued: “Many DevOps related tools work pretty well together, although they often require some degree of orchestration. A lot of engineers prefer to handcraft this toolchain although I much prefer a low code approach to orchestration as it means the DevOps pipeline can be owned by a wider group of people and reduces key man dependency. There are low-code solutions out there that manage the orchestration of your CI/CD process for you, like Xebialabs XL Release, which has a large collection of plugins which help to bring a DevOps pipeline to life with little or no development effort. You don’t need to be a developer to be involved in the process of using tools anymore – anyone can be involved in the process because of the low-code approach facilities this.

    “Another dynamic to be considered is how these tools are managed within the organisation. Typically there are 2 approaches, managed service or federated. Managed service is when you have a central team look after the toolsets for multiple teams or the whole organisation whereas a federated approach is where each team looks after their own instance of the tools. There are pro’s and con’s to both approaches but I prefer Managed Service for long-lived tools such as source control and artefact management and federating everything else, ideally maintaining control over how the tools are used consistently by pushing out consistent images via chef cookbooks or Ansible playbooks etc.”

    A DevOps marketplace

    Chandler is now exploring an idea to create an internal DevOps marketplace whereby DevOps related services are made available to other teams at a cost which is then used to fund more continuous improvement initiatives.

    Examples of this are:

    • Putting in place a service to shut down a given teams cloud infrastructure when not in use (e.g overnight and at the weekend) so cloud costs are minimised
    • Automating the right sizing of teams compute requirements

    Automation, in general, underpins a lot of DevOps activities and has changed the scope of software testing. Whilst many organisation still rely upon manual tests, a move towards fully automated tests is key to supporting a culture or innovation and the ability to adapt rapidly. Manual testing simply doesn’t scale.

    Chandler also organises conferences including SEACON and DevOpsDays (2016), as well as a monthly, meet up a group called SEAM. He believes it’s important to network, share experiences and to do case studies, which is another way to finding out how other software testers add value to their customers.

    Written by Leah Alger