Big picture decisions; small, iterative steps — an interview with DevOps Architects Amrut Patil and Sam Crossland

Nia sat down with two of Gearset’s DevOps Architects, Amrut Patil and Sam Crossland, to discuss their career journeys. They also share key insights for Salesforce Architects looking to get into DevOps, and the challenges they may face on the way.

Nia: Hey Amrut and Sam! Thanks for taking the time to talk with DevOps Launchpad today. What exactly does a DevOps Architect do?

Amrut: Hey Nia, thanks for this opportunity for us to share our thoughts, pleasure to be part of this interview. I have been asked this question many times by our colleagues and customers. Though I can’t think of a concrete definition of ‘DevOps Architect’, in simple words, a DevOps Architect (DA) helps development and operations teams by reviewing their automation needs, as well as designing and implementing the most suitable DevOps process for them. DAs also provide recommendations to customers on best DevOps practices and bring constant refinement to their release processes.

Sam: Hey Nia! Great to be here and thanks for having us. This role is quite a unique one where I get to work with a wide range of customers at different maturity levels in the DevOps space, and help them strategize/implement some improvements to their release processes, instead of the usual interpretation of this kind of role where a DA would be directing internal development and release pipelines. It gives the scope to work with customers of all different sizes and with unique workflows, which is great to continue learning.

Nia: That sounds fascinating! How did you both get started in the field? Was there a particular background that turned out to be helpful?

Amrut: I started my career as a Java developer and had worked as part of a build/deployment automation team, so naturally I had an inclination towards DevOps early on in my career. I’ve had several opportunities to work with large development teams over the last two decades, helping them to implement and automate their CI/CD processes. I would definitely say that working with big enterprise customers on large scale Salesforce projects as a DevOps Consultant has proved very helpful when taking up the DevOps Architect role with Gearset.

Sam: I fell out of university straight into a Software Engineer role in the Defence space actually, and throughout the years ended up moving more into a DevOps/Automation Engineer role, before eventually moving up to a Solution Engineer. This gave me a really good breadth of knowledge all the way from coding complex automation on the fly, to overseeing large development projects. Having knowledge in infrastructure and the way software development teams operate was certainly useful for me and a nice foundation to transfer into the world of Salesforce — along with seeing the actual ‘ops’ side of DevOps, when code can’t just be thrown over the fence and needs spinning up and maintained for end users!

Nia: It’s great to hear both your career stories and how you landed where you are now. Any standout highlights or challenges that you’ve faced in your roles?

Amrut: One of my highlights would be the scripting solution that I implemented on my very first Salesforce project. As a result, release time was reduced from an average of nine hours to about an hour, which was a game changer for the team and helped release changes to production much faster.

One of the challenges that I face in my role is adapting to different customer situations and needs, since every Salesforce team is unique and there is no one silver bullet solution that can fit all organisations. We come across different flavours of teams, ranging from novice to expert in their DevOps practices — as a result, I need to adapt quickly so that I can interact with them and plan out activities in the most suitable way possible. Another challenge is to keep my knowledge up to date with the ever changing technology landscape.

Sam: A big highlight for me was working on a very large automation based project and moving up through the ranks to the Solution Engineer level, eventually delivering a completely self-building system of applications from the ground up within 10-12 hours, instead of the usual several weeks plus it would take to manually spin up. It also allowed me to become an absolute advocate for PowerShell as a legitimate diverse scripting language rather than just a sysadmins’ ‘quick dirty script’ method.

A challenge for me was getting used to an entire new dictionary of Salesforce terminology and concepts, and marrying that up with prior experience in virtualisation and infrastructure deployments. There were tons of great parallels to draw between them and that really helped in spinning up in this ecosystem — but as we all know, Salesforce certainly has some pretty unique nuances as well!

Nia: It’s true, Salesforce can be a complex beast that is always changing — it sounds like being flexible and adaptable has proved really important in your careers!

Amrut, you mentioned how DevOps proved to be a gamechanger in your first Salesforce project. Although you’re both DevOps Architects, in what ways could adopting DevOps help Salesforce Architects, too?

Amrut: DevOps is a universal process that members of business and technology can benefit from. As Salesforce Architects help in architecting the solution, a good DevOps process can work as a catalyst to promote the solution across the Salesforce environments — all the way to production in a consistent, predictable, efficient, and safer way. For that reason, I certainly recommend that Salesforce Architects look at DevOps also as part of their solution proposal, and participate in the design and implementation of the process that suits their development and operations teams, allowing them to build and deploy solutions efficiently.

Sam: As something that’s been around for quite some time now in the wider engineering world, DevOps has been proven to aid in not only streamlining release processes, but also help change the mindset of development teams and senior leadership to adopt different ways of working and Continuously Improve. DevOps certainly isn’t ‘just doing standups’ or holding ceremonies just to say you did, so embracing the mindset as a whole can be really useful for Salesforce Architects as it keeps the potential implementation plans and working patterns they could leverage with their customers current and set the right foundation for greenfield engagements.

Nia: You certainly build a strong case!

Like you mentioned before Amrut, every Salesforce team is different and faces unique challenges, though — what obstacles might a Salesforce Architect face along this journey to Salesforce DevOps adoption, and any advice to help combat these?

Amrut: As with any role, we always have opportunities to bring changes for good in our own small way. Though there can be many organizational challenges and hurdles in order for any valuable changes to happen, it is essential and imperative for the team to follow one single standard process. Whether that process is the best or not is secondary in my opinion, but consistency is the key thing here. If all members in a team follow one single process, the issues and results that come out are more predictable and hence teams can be equipped to manage them swiftly. Shifting the team to follow a new/refined process in the future also becomes easier as a result. Therefore, I recommend Salesforce Architects provide both a short and long term vision to their business stakeholders, as well as the road map necessary to achieve it — which will likely involve constantly looking at ways to automate their tasks with the help of DevOps specialists.

Sam: I’m in complete agreement with Amrut’s point there; it’s usually the non-technical issues that prove most challenging, as it might be changing an entire team’s mindset of how to work, or convincing a set of senior managers that you actually need to slow development down for a short time in order to set some great foundations, before speeding it back up again. Being able to accurately outline how some short term pains and restructuring will really help gain velocity in the mid/long term can be really powerful, and help build up a portfolio of ‘success stories’ for future use also. Salesforce DevOps will encapsulate not only the release processes, but also the development and feature architecture also — so taking into account a customer’s specific issues around those key areas and then bringing together a scalable solution to help tackle most of them (we’d love it to be all, but know that’s not always possible!) will really help embed the value of adopting these new approaches.

Nia: That’s really sound advice. As DevOps Architects, your role often involves big picture decisions, but we know that adopting Salesforce DevOps works best by taking small, iterative steps. Where would you recommend Salesforce architects start?

Amrut: The ideal place to make decisions on any technology and process is if it’s a Greenfield initiative. However, very seldom do we get opportunities to work on Greenfield projects — this is particularly true for large enterprises who still need to work with legacy systems and processes. In these cases, it can prove challenging to bring the cultural changes necessary to adopt DevOps successfully. So as you rightly said, taking small and iterative steps can be a good start in most situations.

I would suggest Salesforce architects work with in-house DevOps teams or partners to define their DevOps roadmap as early as possible, looking at ways to improve on deployment times, quality gating, Role Based Access Control (RBAC), Governance model and reporting capabilities, along with (and more importantly!) helping businesses to choose the right DevOps tools for their needs. A great place for Salesforce architects to start would be DevOps Launchpad’s Salesforce DevOps Leadership Certificate, to help them kickstart their DevOps implementation journey.

Sam: Knowing the overall landscape and key points before engaging with a customer can be really powerful, so I’d suggest honing in on some key topics and concepts you want to discuss. These may include: what quality gates need to be implemented, separation of responsibilities, or deciding on key metrics to monitor at various stages during a DevOps transformation. As Amrut said above, having a wealth of different tools available (both open and closed source) to recommend to customers in various situations can be really helpful when evaluating the right structure to implement, too.

The courses on DevOps Launchpad are fantastic to gain an understanding of some of those key areas, with a favourite of mine being Git branching strategies as it’s so crucial when wanting to build out elements of automation and achieve CI/CD. There are also some great books available on Salesforce DevOps to help teams build a scalable process.

Nia: Thank you for sharing your invaluable insights with us today! One final question to finish off: which is your favorite Salesforce character?

Amrut: Although I like Astro Nomical — as they’ve been my friend throughout my Salesforce learning journey — my favourite is Ruth the elephant. She always reminds me of the mascot I loved during my childhood days, and of the Indian version of a nickname that my family calls me to this day!

Sam: It’s got to be Blaze the Wolf for me! She’s emanating ‘business transformation’ vibes and being there to help carve a path forward, and also reminds me of the emblem for the biggest project I’ve worked on in my career so far.

Level up with DevOps skills

Want to boost your résumé with free Salesforce DevOps certifications? Sign up to DevOps Launchpad today!