Transcript
Welcome, everyone, and thank you for joining our webinar today. I appreciate there may be some questions along the way. So if you'd like to pop them in the q and a section of, of the call, the team can either answer them in place or they can highlight them in our questions section at the end.
And with that said, let's get going with today's session.
So our special guest this this session is Marco Pinder from ninety one. He's led their digital transformation for Salesforce as they demerge from Investec, the Anglo South African International Banking and Wealth Management Group. He's gonna be talking about how Salesforce and DevOps accelerated that digital transformation.
And I'm Rob Cowell. As a former Salesforce consultant, I've got twelve years of developer and architect experience across a range of clients, including the financial sector.
I joined 海角天涯社区 as a DevOps advocate to to continue guiding and advising teams on how to get the best from their Salesforce investment through the use of DevOps best practice.
So 海角天涯社区's the only complete solution for Salesforce DevOps, and we have extensive experience working with large teams and enterprises to achieve their business goals.
So this is a very quick rundown of what I want to cover today. First, I'll set the scene on where DevOps fits into a digital transformation in financial services, and then we'll hear how Marko was able to put this into practice at ninety one as we hear his story.
So the financial services industry is somewhat unique. There's numerous large, well established companies trying to keep pace with the recent influx of agile and nimble fintech.
Additionally, with it being such a regulated industry, the ability to deliver at the pace of change expected by modern consumers can often be hampered by legacy culture and process.
DevOps brings the promise of responsive, and dare I say it, agile delivery of value driven change, while still meeting the need for accountability, visibility, diligence that's required in this sector.
So let's dig into some of the core areas to focus on ahead of seeing how DevOps contributes to those needs.
So companies have to keep up and adapt with the changing needs of customers according to Gartner. So they must have a fast and robust accurate deployment mechanism.
From talking to some of our largest customers in this industry, enterprise agility is more com critical than ever. In a competitive space, the ability to adapt and embrace change responsibly is what's going to set you apart.
The transformation into a streamlined DevOps organization begins with the culture, not the tooling.
A wider team encompassing all aspects of end to end delivery is the key to removing some of those blockers, and teams need to work together to achieve project goals. But the way many financial services firms are structured tends to block this. Silos don't allow them for working across teams and units, and DevOps encourages better collaboration.
Now with the pandemic, it widened the digital gap in financial services. Some companies have their digital transformation well underway and have the agility to respond to opportunities or crises, while others are lagging even further behind than ever.
To beat your competitors, your organization needs to be able to match or improve on that pace, which is much more realistic when you have a DevOps process in place.
Financial services companies are generally more risk averse, and so it's surprising twelve percent of financial services companies don't have a robust backup and restore strategy or a platform.
Regulation and legislation such as Dodd Frank, Sarbanes Oxley, GDPR, COPPA, and more mean that the scrutiny is higher than ever.
So it comes as no shock that the highest priority initiative for financial services is increasing the security and privacy capabilities.
The current trend in financial services also is to not let the fintechs overtake them in this space, and this has brought about the need for digital transformation like no other industry.
We're now firmly in the digital age. Financial services needs to deliver that optimum experience for the customers and the internal teams to differentiate and win in the marketplace.
So a lot of organizations have brought in Salesforce to deliver that transformation, and DevOps has a strong return on investment for financial services.
Eighty four percent of financial services companies that have adopted DevOps practices have seen an increase in their Salesforce return on investment.
So next, we're gonna have a look at how DevOps itself is a significant contributor to that digital transformation success.
Companies often create a digital transformation roadmap in which Salesforce becomes a critical platform for that modernization, acting as the central hub and source of truth. So how successfully you manage to integrate Salesforce can play a significant part in the success of your digital transformation.
However, according to a Boston Consulting Group report, seventy percent of digital transformations fail, and research has found that banking is not immune to that failure.
Despite years of plugging away at change, only sixteen percent say their digital transformations have improved performance.
Less than fifty percent say they're prepared for new competitors and rising customer expectations.
So an organization's success is now determined by the digital platform it decides to use to support its business and the business model that that platform enables according to Accenture.
You can use tools like our maturity matrix to map out the maturity of your cuss your company's approach and decide on an actionable path forward.
Digital transformation is moving to the next stage with ever greater business demand on Salesforce teams to deliver. Faster releases, higher quality features, tighter feedback loops, these are all key to unlocking future success and maximizing your Salesforce ROI.
It's critical to make sure that Salesforce is effective as possible and a worthwhile investment. And for this, it helps to have DevOps.
First and foremost, the overarching benefit of DevOps is that it helps you get maximum value from that investment by getting the beneficial changes that you make into the hands of your customers faster.
After all, a transformation that delivers impactful change is the goal here. But DevOps isn't all about speed here. In the financial services world, accuracy, precision, and robustness are of equal importance. So a well planned and well executed DevOps strategy will deliver these points as well, for example, by leveraging the testing capabilities of the Salesforce platform and extending it with techniques such as static code analysis to identify those issues early and help reduce the risk.
I would contend that getting the culture attuned to a delivery model reaps considerable rewards too. Legacy processes and operating models for delivery can be significant blockers to transformational change.
It's possible to eliminate the delays presented by, for example, awaiting approvals from external groups or streamlining your review process in order to accelerate getting meaningful improvements into the hands of your teams.
DevOps doesn't eliminate these safeguards and stage gates that are a big part of financial services, however. On the contrary, it brings greater visibility, increased review through collaboration, and it means that all the checks and balances are intrinsic to that entire process.
It allows for a get it right first time approach to delivery, and that can only serve to accelerate that pace of change while remaining visible and accountable.
An organization's ability to integrate Salesforce in an agile and responsive way has a direct impact on its ability to drive the entire digital transformation in an agile and responsive way too. So integrating and optimizing Salesforce to up operate at maximum efficiency in your organization is so important for that digital transformation.
You can integrate Salesforce quicker with a DevOps platform and not suffer with change sets. Gear set is, on average, twelve times faster than delivery with change sets.
And it's this promise of in an improved time to market that's gonna set you apart from your peers in the sector, but it also allows you to keep the same pace in financial services as in the fintech market and allows you to continue to compete with them.
The overwhelming majority of today's business and technology team leaders understand that a digital transformation is necessary to maintain that leverage amid a constantly changing set of customer preferences.
They also have a clear picture of the desired end state exemplified by companies like the tech sector, for example, Amazon.
However, only a small minority have a clear understanding of the path that they need in order to lead that market.
Accenture found that those that are nailing that digital transformation in the sector are actually leapfrogging ahead to become the leaders in this space. So it's not a gradual shift. They and they end up lead leaving others lagging behind.
So while Salesforce is likely playing a critical role in your digital transformation, it's important that the wider business and the senior stakeholders in your organizations are aware of the benefits that DevOps can have on Salesforce and, thus, the overall digital transformation goals. So let's have a look at what typically we would recommend that you include in your business case.
Now there's a lot to unpack here, and we sadly don't have time for a deep dive. Of course, if you want a one to one help with with crafting a business case, the team here at 海角天涯社区, can certainly help, to to to help you elaborate on the the value of DevOps for Salesforce. But I like to call out some key items that will support your case and help answer some of the questions illustrated on the slide there.
So typical results that a business is looking for are higher growth, reduction in cost, reduction in risk, or maybe you're undertaking the purchase of a business or you're partitioning an existing existing business. So the objective will impact to your business case and how you frame it. Most senior stakeholders will have projects, scorecards, objectives, and key results, and some of those metrics will be an estimate and some of them will be backed by numbers.
So it's key that you find out what's most important to those stakeholders and make sure you look at the impacts that DevOps will have on those elements.
The financial impact is perhaps the most easily calculated for growth or risk metrics, so the dollar value of growth or the dollar value of loss if risk is realized. So every business case will be unique, and we're always happy to sort of partner with you to help pin those down.
So at this point, I'd like to try and bring all of that to life with a customer story of a digital transformation with DevOps at its heart. So at this point, I'd like to introduce Marco from ninety nine.
So Marco, as I said earlier, led the the digital transformation on Salesforce for ninety one, and we'd love to hear the story of that, Marco. Welcome.
Hi, Rob. Thanks.
So I guess kind of looking back at what we were talking about sort of around sort of clear business cases and clear objectives, what were the objectives? What was it that ninety one was was kind of out to set to achieve with with that digital transformation?
Yeah. So I think, at ninety one, you know, we we understand that Salesforce is a a key strategic platform for us.
And we were we were, I think, suffering from some of the challenges that that perhaps some of the listeners on on the call today have experienced is, you know, you have multiple work people working on the platform, and you can you can experience issues with with deployment, you know, people overwriting each other's changes and, you know, not not having a an ideal process in place. So I think when we first began sort of looking at achieving some sort of DevOps process from from a Salesforce perspective, it was to try to iron out some of those issues and to just streamline this and and get a a much faster, sort of release process going so that we can actually get our changes into the hands of the users, and and sort of really benefit our business. So that that was what we set out to achieve.
And we were fortunate as well. It just coincided with the fact that we had a new CTO join the organization, and she was really sort of pushing agility and understood the merits of working in an agile manner and and the benefits of DevOps. So that sort of really helped drive us forward as well.
Okay. And at what stage in in that did did it become apparent, you know, potentially to yourself or or to your CTO that, you know, getting Salesforce delivery right was kind of that fundamental element to your overall transformation at the organization?
Yeah. I mean, you know, we've got we've got a couple of product teams working on our Salesforce platform. And just the the volume of change that is being required upon us is pretty high, and I think everybody experiences the need to sort of get more from the tools and and the the platform that you've got.
So, you know, part of this transformation was to to ensure that, you know, we we could get through our backlog, you know, much faster.
And as I said earlier, we could we could just deliver to our customers, our end users, a lot a lot faster.
Excellent. I mean, that sounds like, you know, that enabled you to be sort of more responsive and agile, which is, you know, precisely what, you know, we we we aim for in this.
Yes. Absolutely.
So going into that then, I mean, did did you have any sort of concerns about how you would be able to achieve that that level of agility?
Yeah. I I think that some some of our concerns were sort of around the the the varying skill sets within the team. I I think that was one of the key things. And, you know, with people working on the Salesforce platform, there is a sort of a wide variety of skills, of of people. You know, you've got developers, you've got architects, got administrators, each with their own skill sets. And I think being able to implement such a transformation, along with a a tool to help such as 海角天涯社区, which is obviously what what we what we chose in the end.
You know, those those were some of the concerns. Is is there a tool out there that will fit and be able to satisfy the needs of of all of these varied users?
And we found that 海角天涯社区 was was an absolutely great fit for that. It it sort of it had the advanced functionality for those that that want it and then can leverage it. But it also is extremely accessible to administrators and and those that perhaps are familiar with Change Sets previously and and just sort of, get some of the traditional standard configuration.
That's great. And, you know, one of the things we do aim for is is making sure that, you know, the tools can fit your process and not that you have to change your process to fit our tooling. Yeah. So it it's good to hear that it it was a good fit. But in terms of those processes and, you know, the the culture, you know, we we talk about, you know, making sure that, you know, culture is valued as much as as tooling and that, you know, we foster greater collaboration and and break down some of the silos.
How much of of the, you know, the DevOps mindset, I would say, impacted on the sort of the culture and and the the the mechanisms of delivery, in your organization? How did how did the culture change as as well as the technology?
Yeah. So that's an interesting question. I mean, one one of, sort of one of our internal slogans, I guess, at ninety one is that that we actually have the freedom to create. And we believe that we have a, you know, a very strong culture at ninety one. And the again, going back to the fact that we were fortunate to have a a CTO come in that actually sort of really drove this forward and then sort of made it accessible to us. I think that was one of the things is that that she was able from the top down able to drive that sort of cultural shift and get into more of that DevOps and and sort of agile mindset.
Some teams, you know, embrace it just because either they've experienced it at previous organizations or they're just, you know really keen to see some change because they're the ones that are actually feeling the pain day to day for some of these challenges that I that I mentioned earlier.
Whereas you know some some people are resistant to that change but I think being able to explain and and sort of bring them along with the journey and and tell them sort of where how they will benefit from these changes. I think that that really helps. And and, you know, I I must say that over the last couple of years, I've I've certainly seen a massive shift across the sort of the entire IT organization at ninety one in this space.
No. And that's a very good point, you know, because, you know, in in some organizations, you know, resistance is encountered in terms of of change and, you know, a little bit of that that's the way we've always done it mindset.
You know, certainly from my own experience in in in the sector, I, you know, had to overcome quite a few of those challenges, I I I will admit.
But I think you're absolutely right in the, you know, the key to kind of unlocking that and and getting the the cultural transformation is to continue to highlight and and stress the benefits, that those types of changes will deliver.
You know, we've we've enumerated, and I feel like the the responsiveness not just for, for example, you know, support issues, but also, you know, to be able to drive initiatives and project work forward, you know, and get them into the hands of of people a lot quicker.
Yeah. Absolutely. I I would say that, you know, when when we first began the the journey, you know, we we identified a particular project that would that would really benefit from from implementing sort of more of this agile sort of DevOps process. And, you know, we we were given the the space and allowed to try it.
And I think that that will that is actually what really helped. We were able to succeed. We were able to prove, you know, how how much it helped, where the value add was. And then from there, it just grew.
You know, once you actually can prove and and and demonstrate the the the success, you know, it it just the trajectory went up from there.
Fantastic. And taking another another kind of lens at at the the aspects of transformation, you know, obviously, the the financial services sector is heavily regulated. There are a lot of compliance and and audit and accountability type of needs with folks like the FCA here in the UK or or perhaps the the SEC in in the US.
How has how has DevOps kind of lent itself to having that greater level of accountability so that you can kind of see, you know, the change and you you have that kind of traceability. Yeah.
I mean, that that's hugely important. I I I think that, you know, as part of our transformation, we we went all in with, you know, ensuring that we were using source control so that, all edits to any of our metadata, all of our Salesforce configuration was auditable. We can see who's been making what changes, how changes have evolved over time.
But I think the other peripheral elements of DevOps such as, I mean, you mentioned earlier about automatic unit testing, you know, static code analysis, all of these other elements are almost like safety nets and and mechanisms to help you to help give you confidence that the change that you're delivering across your environment is of a high quality and is less likely to break and less likely to introduce that risk that you're so keen to avoid.
So it's it seems like a no brainer to to, you know, really look at all of these different elements and and try to implement as much of them as you can.
Absolutely. And, you know, why why we wouldn't want to necessarily cast dispersions on the on the quality of deliverables, sort of pre DevOps, You know? Are you noticing a a a marked improvement in the, you know, successful deployment, getting it right first time thing, or is it about the same?
Or Yeah.
Absolutely. No. No.
I experiences.
Yeah. So I I I I often look. So within gear set, I you know, there is some reporting capabilities where you can actually see how successful your deployments are into various environments and so on. And it's something that I look at frequently and report back to the wider platform team.
And, you know, when when we consider how many challenges and how many issues we would have prior to, you know, our our DevOps implementation and transformation, compared to now, you know, it's it's night and day to be quite honest. And I'm still enjoying seeing the improvements even now. You know, when even when we first adopted DevOps, as you can imagine, it's still gonna be a bit of a bumpy road. It's it's a new process. You're learning new ways of doing things.
So there would still be odd occasions when you'd get failures or issues. But, you know, as you learn and, you know, learn about the nuances and the the small things that, you know, might catch you out if you don't know what you're doing, as you start to learn those and get better, it's again, it's just, you know, greater greater success as time goes on.
Absolutely. Yeah. You know, we always like to sort of emphasize that, you know, it's not a a big bang implementation for DevOps. It's a a gradual incremental step by step process as you kind of increase in in that level of maturity.
Absolutely. I mean, when we first did sorry to to to cut you through that. But no. I mean, as soon as we when when we first, adopted GearSet as our sort of choice of of, you know, tooling to help us with this, we were we really implemented it as a replacement for changes. We were just doing deployments from one Salesforce environment straight to another.
That was a huge eye opener just to begin with. I mean, the ability to be able to compare metadata across two environments and almost peep into your target environment.
It felt like you had a superpower and you could really see what you're about to affect in the next environment and whether you're going to overwrite something that you didn't intend to do. And you just don't get that visibility with with Salesforce's standard tooling. So that that was what we initially did. And then as you've said, you know, it's it's not a big bang. We've just then added on to that, and we've we've gone down the road of adopting source control. We've we've introduced, you know, automated unit testing.
We've defined our own static code analysis rules. And now in in more recent functionality that CareSet has actually rolled out around pipelines, we've also adopted that and we've just, you know, slowly added on these these areas of functionality and just seen more and more benefit as time has gone gone on.
Fantastic. Is it sounds like so overall, your then your your digital transformation has has been, certainly, from the the technical standpoint, and the cultural standpoint, a success. So is there anything that you you feel is is yet to be achieved in that process? You know, I I it always feels like a transformation is never done. So what what's next in your in your sights?
Yeah. No. That's true. I think I mean, first of all, it's a hundred percent been a success.
I think, you know, if if you were to ask anybody sort of in my team about would they go back to the old way? I think it'd be a resounding no. You know? Nobody wants to go back to the dark ages, it seems.
But, yeah, in in terms of what's still to be achieved, you know, in in recent months, I've I've sort of heard and and read a bit more about something called DoraMetrics.
And I've and I've also understood that that 海角天涯社区 has, introduced some some APIs and particularly a reporting API that provides some information and some insights around that. And that's more to do with sort of the time to delivery and how quickly you're actually releasing the changes that that, you know, you're you're pushing through your pipeline.
So that's something that I would like to focus on next. That's where I feel that we haven't quite got to where we want to be, and I'm keen to take a look at some of that information, sort of start measuring where we are now so that we we know what our baseline is, and then start to work on that and improve. And, you know, part of the mantra of DevOps is continuous improvement.
And so, you know, just just, you know, little by little, we'll we'll try and improve that as time goes on.
Awesome. And one final question before we we, kind of open up to, everyone else's questions.
What, what advice would you give to any other financial services company that's looking to embark on a similar transformation within their organization?
Yeah. I I think that, absolutely, it doesn't have to be a big bang. You know, that was you know, we we we took that sort of slow approach, and just found that we were getting more and more momentum, getting, you know, better and better results to to to continue pushing those boundaries and adopt more and more. So my advice would be to to absolutely give it a go.
I mean, you've really got nothing to lose. And if anything, it's, you know, it it's a risk to not be adopting a a DevOps process when it comes to your Salesforce implementation. You know, not not only from a, as I said earlier about sort of mitigating risk and and sort of making sure that the quality of what you're releasing is better, but even from a talent attraction perspective and, you know you know, employees and and future colleagues that you want to have, I think, you know, if you if you don't have that good foundation and that those good, sort of processes and and tooling in place, it's not particularly attractive to to to other people to to want to join you as an organization and to work on your platform.
So I think it's yeah. There's there's more of a risk of not doing it. And, yeah, just don't be fearful. And and as you mentioned earlier, GearSet are are there to help with business building a business case. And I've also had fantastic experience of support even sort of using the tooling and and any issues that have arisen. They've always been super helpful.
That's great to hear. Thanks, Marco.
So at this point, we are into the q and a section.
So, folks, if you want to, drop any questions you might have for either myself or Marco in the, the q and a panel in the chat, and, we'd we'd be happy to pick those up for you.
So I have the, the team on standby keeping an eye out for questions for us.
Let's see what we can come up with.
Okay. I've got a couple of questions coming in now. So, I I I guess these ones are are very much for you rather than general questions. So what was the deployment process like for Salesforce changes before you've adopted DevOps?
Yeah. I mean, that's that's a great question. And I think that, we're probably all guilty of not having a a very sort of clearly defined process on occasion. And I think when I think about the sort of the journey that we've been on and then the the fact that our team has got more mature and more experienced in the way that we deliver.
But prior to DevOps, you know, predominantly the the way that we released was using change sets. But Mhmm. It really is a bit of a a black box. You know, you don't really know what's going on some of the time when you, you know, you you build your change set, you push it to the next environment, and you just hope that somebody didn't beat you to it, you know, half an hour earlier, and they haven't affected the same piece of code or piece of metadata.
And, you know, you're you're going to end up destroying theirs. It's the last one in wins, basically. So there was always that element of risk. So that was there.
And I, you know, I shouldn't probably admit this, but I think on on the odd occasion, somebody probably affected something directly in production.
You know, if somebody calls up and, you know, logs a ticket and needs new value in a pick list and all of a sudden it it's urgent. Now, obviously, you shouldn't bypass process. But I think, again, not having good process in place, and sort of good, discipline, you know, can end up with some of those results. And that those were all the risks that we wanted to avoid and and unwind and and make sure that having a DevOps process in place totally eliminated those. And, you know, I'm happy to say that it it really has.
So in terms of sort of the the rest of the question I can see here in terms of average time to to deliver the change post transformation, I mean, the the fact that we have really adopted all the functionality that GearSat provides with regards to pipelines, you know, the speed with which we can deliver something can be hours rather than days now. You know, the depending on the, requirement, depending on the urgency of it, Even if it's, for example and and this very, very rarely happens if there is a bug in production. You know, we have a straight we have a straight route into production from a hotfix environment, our hotfix branch, the way that our pipeline is configured. We can get that that fix in very quickly into production and then back propagate those changes across all of the other environments very, very easily to ensure that all of our environments are in sync, and we're not going to lose that fix anytime soon.
Okay.
So, yeah, I would I would say that, you know, that was how the deployment process was previously, and it was very ugly and very time consuming. And now, you know, if we really want to, we can get it down to hours.
You know, we could release multiple times a day if we really want to.
Fantastic.
One last question I wanna quickly sort of inject. It's one of mine, actually, but, just before we kind of wrap up here. So in terms of your kind of due diligence process for for things like, for example, your change advisory board or change management board where you, you know, you have to, kind of have a little more sort of regulatory oversight to change, How how has the relationship with with, those groups changed since you've adopted this ideally faster process? Sure.
Are you finding that that the business is catching up, at the same kind of pace?
They are. Yeah. We're we're having again, it's sort of it's been an opportunity and, an experience for sure to to sort of bring that sort of that risk and compliance side along with us. So, you know, we have a weekly change advisory board that meet, you know, anybody across the whole entire IT organization at ninety one that has, you know, a significant change goes to the board. You know, they they they talk about their change, see if there's any any conflict, any sort of anybody that wants to question anything.
But we have we have found a way to actually introduce our own to the standard change process whereby we have educated, you know, the the people that are involved in the the change advisory boards to let them understand what the capabilities of the Salesforce platform are. You know, you again, you you almost well, we are lucky in in the sense that, you know, we have unit tests that run, you know, you can't affect code in production really, at least Apex classes, you know, without running all of the tests, things like that.
So being able to educate our internal teams on that has given them the confidence to let us sort of release a lot more frequently and to have a much more streamlined change process where we don't necessarily have to announce and talk about every single change at CAB, which has been another sort of great time saver for us.
Fantastic. That's that's really great to hear. Unfortunately, we are slightly over time now.
So In no. No. Absolutely fine. It's fascinating to to find out some more details on on your journey there.
With that, I'd like to offer our thanks, Marco, for for sharing that journey with us.
Thank you.
Hopefully, it's given a lot of insight to folks on the call, that are at at various stages of their digital transformation.
And as we indicated earlier, you know, if there's any point at which, you know, you need guidance and help on how DevOps can help deliver that, feel free to reach us at dearset dot com. We'll do our best to to help you deliver that change.
And with that, thank you, everybody, and have a good day.
