In the North’s biggest digital transformation event DTX Manchester the focus is on how to thrive in the age of continuous disruption and amidst chaos. We have asked Slalom because not only it is a purpose-led, global business and technology consulting company, but it also claims to have a ‘fiercely human’ approach.
Since they started their consulting business in 2001, Slalom has grown rapidly in seven countries, 44 markets and has over 13,000 team members in seven countries and 44 markets. They have close partnerships with over 400 leading technology providers, including AWS, Google, Microsoft, Salesforce, Snowflake, and Tableau and claim to deeply understand their customers.
To see how their approach works in practice, we asked Slalom's leading cloud architect Michael Morse about the hot topics shaping the IT enterprise industry, the boundaries of using ChatGPT in DevOps, and how to win the battle for increased security.
Alica: According to Forbes, Slalom was awarded the World's Best Management Consulting Firm title in 2022. What were key milestones in technological insights that helped to achieve this title throughout the years?
Michael: “Here at Slalom we are constantly striving to create real impact for people, customers and communities while having fun along the way. Being able to create the custom-built software and data products of tomorrow through two distinct technology offerings makes us stand out from the crowd. We have Slalom, which focuses on the Technology Consulting of helping companies determine which tech opportunities can achieve key strategic business requirements and Slalom Build which then takes the baton and works with the companies to design, develop, test, release and scale the modern digital products.
“I believe that building up partnerships with world-leading solution providers (including AWS, Microsoft, Google, and Salesforce) over the years has helped get us to where we are today. They enable us to deliver and build the highest quality digital products and experiences as well as innovate, grow, and improve customer reach. We have a great alliance team internally that continuously promotes and is the glue between the company and the different partnerships we have.
“Having a Swiss-army knife approach to consulting proves useful when engaging with different companies. Within Slalom and Slalom Build, we have many capabilities that aid in building out the product of tomorrow, from Tech Enablement and Business Services to Platform Engineering, Software Engineering, and Solution Ownership.
“Finally, (and I'll use a recent engagement as an example here). I believe what makes us stand out is that we want to help companies on their journey by giving them the building blocks to succeed (whether that's a backlog of work to be completed or demoing a Proof of Concept).”
Alica: DevOps and ChatGPT are incredibly hot topics. It seems that everyone and their dog is using ChatGPT. Is there a clear understanding of the limitations of ChatGPT in DevOps? Can you give us an example of the best, or worst use of ChatGPT in DevOps Engineering?
Michael: “It's such a buzzword right now and I get a 50/50 reaction from my colleagues when discussing it. I see it as a tool to absolutely boost the productivity of any engineer. As a Platform Engineer, I have a mantra to "write myself out the role" by building toolchains, workflows, and platforms for engineering teams so that I can focus on innovation, optimisation and cost-cutting exercises. ChatGPT helps me write myself out of that role even further.
“Use it for day-to-day operations as a DevOps Engineer, ask it to generate small scripts and configurations (for e.g. a bash script to list files or terraform to deploy resources). Additionally, ask it to troubleshoot code (particularly and anecdotally, an AWS IAM policy statement that's malformed). Finally, on the subject of increasing productivity, ask it to automate tasks and develop CI/CD pipeline code, discover new tools and improve skills, and ask it for a tool recommendation or how to reduce the AWS bill.
“In my opinion, ChatGPT is not a threat to engineering. We uncover new tools every day in the DevOps world, ChatGPT is just another tool on that list.”
Alica: What is your experience regarding faulty patterns in the application of ChatGPT in engineering?
Michael: “As with all Generative AI tools, ChatGPT has to be taken seriously and human vetting is absolutely necessary here. Whatever is typed in it, it owns. Think of ChatGPT as a person who does not work for a company when engaging with a client and reacts accordingly. Don't tell it or ask it anything that you wouldn't ask a stranger on the street.
Also, it's worth recognising that it doesn't understand figurative language, responses often do appear relevant and coherent but can also lack accuracy and depth so again human intervention is always needed. Finally, it's worth noting that it's not always right, it's still learning.
I asked it the other week to build out some terraform to deploy an Application Load Balancer (or ALB) in AWS, the code didn’t work because, by default, it needs a "default action' code block as part of the ALB terraform resource. However, I informed ChatGPT of this, and it apologised and added the default action block.”
Alica: There is no one in the current market who would not face the incredible requirement for increased security. There seems to be intense competition with time in terms of ensuring the system functionalities perform better while decreasing vulnerabilities. The more devices we have and the more applications, and functionalities that need to be linked the more risk there could be for compromising data security. Is there a process checklist one could follow to avoid major throwbacks?
Michael: “It's never been so important to shift security left as early in the development process as possible. To the point where we should even have a prevention rather than cure attitude and test locally before pushing remotely. There are plenty of tools available now that run "anywhere" whether it's a developer's build laptop or a local build agent/runner running in the cloud.
“In situations like this, I've always referred to the OWASP ASVS (Application Security Verification Standard) publicly available on OWASP's Github. The guide has verifications suited for all audiences; ops, engineers, and architects each with a control objective that summarises the assessment. The guide also has verifications suited for specific components of a system such as Session Management, API and Web Services, again each with its own control objective and sub-verifications.
“I've seen in recent engagements and companies I've worked for implement a Security Champion for the above where that person has taken the OWASP ASVS certification and has become a crucial security asset in project work.
“Another good resource is the Security Pillar in the AWS Well-Architected Framework, a framework published by AWS to help understand the pros and cons of decisions that are being made while building systems on AWS. The Security Pillar of the Well-Architected Framework describes how to take advantage of cloud technologies to protect data, systems, and assets in a way that can improve security posture. The Security Pillar focuses on several areas including Application Security, advising best practices such as Testing, Code Reviews and security training.
"Again, it might be worth upskilling a collection of people to take the AWS Certified Security - Specialty exam so that there are several champions within the company to evangelise the importance of security.”
Alica: I think what is truly shocking is how much background technical knowledge is enough to be able to guarantee the security of a system. What are the key indicators of actual security, is there any general consensus on what counts as a secure system or does it depend on individual discernment? If a system is secure - how long can it be secure? What is the temporal feature of security? The more complex the system is, the more precise maintenance must be. Is there any time when we can state that a complex system is secure and if we can, can we say that to what degree?
Michael: “That's a loaded question, so let's break that down a little. Generally speaking, examples of key indicators of actual security in any company in my opinion are time to detection and time to resolution. Ask how long is it taking the organisation to detect a threat. And how long to resolve? A further key indicator is the number of false positive alerts, as that can judge how well the implementation of a security system (if any) is coping.
“In terms of what counts as a secure system, I don't believe there can be a general consensus as a system could have many components depending on the product. Take the OWASP ASVS for example, there are over 10 different component verifications each with a handful of subcomponent verifications. My advice there would be to look at the overall system from a birds-eye view, identify the components, and then map them to a checklist such as the OWASP ASVS. For example, does the system handle session management? Check out V3 of the ASVS, review the control objective, drill down into the sub-component verifications such as session binding and termination, and view the best practices.
“In terms of duration of system security, I think a system can be secure as long as the agreed KPI measurements are not exceeding agreed metrics. Putting on my SRE hat, there is an agreement with the business: SLAs, SLIs and SLOs to set expectations about how a service will perform.
I don't see an issue practising this methodology in the security world to set expectations about how secure a system is. So when identifying components we were talking about earlier and mapping them to the checklist, think (carefully) about what KPIs are to be included. For example, if it's a public-facing website, a possible KPI measurement could be a number of critical vulnerabilities. Every system is different.
“There are many key elements of the temporal feature of security but I believe it all comes down to awareness. Once awareness and training are in place the rest of the key elements will follow as individuals will remain vigilant and be knowledgeable about emerging risks and best practices.”
Alica: What is something in your work you are passionate about and what is your hobby horse concept in that area? According to you, what makes a good DevOps engineer? If there was one insight, talent, or skill what is it in you that ensures that you design systems with maximum efficiency?
Michael: “I think I'll go back to my mantra of "write yourself out the role". As a platform engineer or DevOps engineer, we build toolchains and workflows that empower engineers to iterate effectively and provide a platform. We enable self-service capabilities to improve developer velocity and therefore speed up product to market which is the end goal.
"By providing a platform and platform as a service you are enabling yourself to focus on other interesting areas such as innovation, and personal growth, as well as on the specifics: optimisation/features/enhancements. A final word would be to treat the platform as a product and don't build that product hoping for the best, it's important to seek developer input and understand how developers work.”
