Description
Catch up on this webinar with Abhijeet Davi (SVP Enterprise Application Management at Natixis Investment Managers), as he discusses Natixis Investment Managers’ Salesforce DevOps journey in the financial services industry. From migrating to Salesforce in 2014 to taking their Salesforce platform beyond CRM Sales and Service Cloud, Abhijeet covers the challenges and opportunities of a digital transformation project in a global organization.
Learn more:
Transcript
Good morning. I'm Abhijit Dalvi with Net Ex Investment Managers. So I'm here today to share our Salesforce DevOps journey and kind of walk you through, like, where we started and where we are now today. So definitely, like, I do have a lot of slides because I think sometimes when you see something, you can relate and, like, try to see, like, where you are kind of things and but we can skim through those slides as fast as possible.
So a little bit about myself. I'm Abhij Dalvi. I head the enterprise, application technology at TenTexas Investment Managers. Amongst all the teams and systems, Salesforce is one of the biggest platform we have. It we use as our company's operating platform. So we are on this journey of digital journey for our company and, like, we are building more things and bringing more things on our Salesforce platform.
Little bit about NetX's investment managers, we are in financial services. So basically, NetX's investment manager is part of the asset and wealth management arm of BPC and NetAccess.
So the world headquarter is in Paris, and in US, we are based out of Boston for asset management. We have different entities as well as different affiliates that make up NetAccess.
So in France, it's one of the biggest bank made up of Banque Poplar and Casa de Pan. And then as part of the global financial services, we sit under the asset and wealth management.
That's where we are. Globally, for asset management, we are spread across the globe. I am based out of Boston, with my team, but, like, we work with various teams across the globe. Little bit about our setup and environment. So basically, we migrated to Salesforce in two thousand fourteen. Before that, we were Oracle Siebel shop like most of you maybe, and then we made a decision to move to Salesforce.
We have one instance for US distribution, which I manage and then different instances for each of the entities and affiliates. Me and my team are responsible for the US distribution, instance of Salesforce and over the years, we have built it more than a CRM system and built it as a operating platform.
So our journey continues with changing market conditions and automations that we, built on this platform.
As part of our digital strategy, we decided that we want to digitize both our internal systems, the departments, as well as the external, clients.
So with this, like, we started our journey on onboarding different departments. So we started our journey with just the CRM system for our sales organization.
Then we added the marketing automation to it. And slowly we started adding, like, we had the portal and kind of seismic, the RFP process and slowly started bringing our different departments on the system. So this whole thing, like, we started our journey and over the years, we have built a lot.
And also but what this enabled us to streamline the inter department processes and automation and, like, they will get rid of all the silos because the last thing you want a user to use a system for one thing and a different system to do something else. So the goal was, like, give a seamless user interface on this operating platform Salesforce and have all the departments work on that platform to streamline everything.
So definitely it was part of our digital strategy and with that, we wanted to take our Salesforce platform beyond just the CRM sales or service cloud. Like I mentioned, we wanted to have the internal and external digital presence, automate each departments, integrate data and system and not have any silos and start measuring results of what their results were. So as part of that, you'll see like today we have like all these different departments.
The one in blue are our internal departments and one in Korea are the external clients and advisors. So basically people and the departments we have on this platform. So as you see like we all started building more and more processes on this platform.
We integrated like different systems, both internal and external, as well as more data. So we wanted to provide a seamless view, our intuitive view for the users, so they can do everything they need on this particular platform.
And of course, when we started, like, there wasn't a financial service cloud with Salesforce and being in financial services, we have to customize our instance for any specific financial services customization.
For example, the three level hierarchy we need, the firm office and rep, or, like, extending the territory management to the contact level or, like, even customizing activities and other objects, building custom modules and apps within Salesforce to support financial financial instrument research notes, buying units, multi fee hierarchy, platform management, product hierarchy and the list goes on. So with this, like you've seen, like we are trying to have more departments, more processes, more data, more system integration and the financial services customization, so there were growing challenges. So basically, what worked before when we started just the CRM system had to be changed. There was more department requirements. There were like more code to manage and maintain.
Department requirements. There were, like, more code to manage and maintain. We had more data integration, more jobs and triggers, more code repository to manage, and definitely, there this caused, like, some unstability and error prone in the system.
What resulted in having is like there was more compliance oversight because we are highly regulated company in financial services.
Unhappy business because their needs were not getting delivered in time. The business priority was changing. The user adoption was going down and of course the development priority was also changing. So and so all this was a result of the growing pains.
So we decided like we'd need to get on the journey to make these changes to the next level.
So when we started, we were mostly using the production and a full sandbox instance of Salesforce. Dev sandbox was mostly used as POC and we were migrating from one instance to another, to deploy chainset into production.
We started with the tools that came out of box with Salesforce, the developer console, the data loader and we were processing some Agile using Jira, but this setup was okay for them, but like not with the growing needs and it lacked the code and repository history, the code review process. The migration between sandbox wasn't easy. Like if you had to back out, you had to create another chain set and push it through. So there was no back out. It lacked sandbox data seeding process and data backups and no advanced capabilities.
So we started looking at our process. So basically we decided like we need to have a redefined dev op process and then align the tools to those and kind of see how we can manage the whole process and have a governance layer on top of it.
So with that, like in the process side, we started looking at different modules. One was the code management piece, the code reviews, the seed data management, the the backups for repository and data, and frequency of deployments, the backups, the refresh and reviews as such.
So from the tools point of view, we started incorporating the Jira for stories, Visual Studio code for development, a code commit for git repository, and GearSet for continuous integration, monitoring, unit testing, code reviews, repository management and deployment, sandbox data management, backouts and SAST, and then we had data backups.
And on top of that, we started putting our governance on for, like, the user access, the policies, and processes.
So little bit about the DevOps process. Like, we decided, like, what's the best process for us, like, as an organization.
So we were looking at, like, okay. Having a sprint cycle, should it be one week or four weeks or, like, or in between? And we came, like, okay. After a few sprint cycles, we decided, like, oh, three sprint cycles works for us best from, you know, getting the business buy in, getting the development done, and testing and deployment.
The next challenge was, like, okay, like, we've been doing application development for a while and we've been using the code management, you know, the master branch, the hotfix branch, the develop branch and feature branch, but how do we align this to with Salesforce different sandboxes and instances and how do we integrate both? So that was one of the big challenge and trying to figure out, like, how do we do that? So then we started with this Git management, which we have on the right side as like, okay, every feature branch starts with the feature branch and then that's where the development team is working on.
And then once it's merged to dev branch, then we will roll this out into the partial sandbox. And once that's where the testing happens for the all developers' code is together. And then once that's tested, we move it into merge it to the master branch that is sent to the full sandbox, which we call it CRM stage and then it's deployed into production. So with this now we have kind of the same code base that is migrated into staging, the full sandbox and also in production.
The source of code is always Git and there is no more movement from one sandbox instance to another sandbox instance directly.
This was not like overnight. So it was like through multiple phases. So we went through iteration of phases as we went through this journey. So in the initial phase, like, we said, like, okay, we redefined the dev op process where you continue to use agile methodology using Jira and migrated to Visual Studio Code for our development needs.
We started taking daily repository backups using Giaset. So with Gear Set continuous integration, at least we started having a backup of our instances or productions, there's a full sandbox and development in Gear Set. So at least we had something to that is backed up and if we need to, we have something out there. We started using Gear Set for the change set deployment and so that we get used to Gear Set and then also we were doing data backups ups for the data.
In the interim phase, like we then implemented the Git repository management, which we saw on the previous slide and even though like we were using now Git management, but we were still using GSAT to migrate repository between sandboxes. We started using, GSAT's compare orgs, so that provided us ability to like do code reviews and compare what's different and such.
We started packaging and doing the deployments and validations using gearset and also the seed data management, the data management feature of the gearset to seed the data in different instances. So whenever the instance is refreshed or new development sandbox is created, we could use these data management packages to seed data.
And then we came to the current phase where we started using the sprint names for our Git management. So basically every feature branch is our sprint name. So those sprints are now deployed into are part of that sprint and get deployed into production.
Every instance gets the source repository from the git. There is no more from going from one sandbox to another.
And then we started using the advanced features like SaaS that comes with GearSet.
So definitely being a part of the regulated company, our security team was very happy because our compliance and security team were always trying to see, hey. This is a SaaS platform. It's not on our internal platform. How do we put controls and things? But now with the SaaS development, so incorporating the SecDevOps as part of our DevOps process, our security team is very happy and so is compliance.
And of course like using the GESID data management feature, now we have like more consistent way of seeding the data into different sandboxes, because before that, the developers would say, hey, my functionality works with John Doe record, but like it doesn't work with Sally. So, you know, we had all those kind of things. Now we're using the seed data management. We can have the data consistently in all instances so we can test every scenario and also churn out like a good code out and the functionality out in the production.
So just a few screenshots of what we're using for what. So like I mentioned, we are using Jira for stories and then we are using the, unit testing at the bottom. So basically, we set up what needs to be tested. It runs every night and every morning we see kind of what ran how many errors are there, and then we can, use that as part of our daily stand up to say, like, oh, we need to fix this or is it high priority or not? And then does it go in the current sprint or the next sprint?
Then there is the compare metadata where we can compare the code between the compare the code between the git and the instance, like between different git branches and that can be used for doing the code reviews. So it gives a nice user interface where you can see what's different, what was deleted, what was changed and kind of you can work with your peers and do some code reviews to make sure like everyone is building the code or writing the code in the standardized way and it's in par with our standards.
The next thing is the automation piece. Like, one of the thing was, like, the unit testing we saw on the previous slide. The other things that, you can do is, like, have continuous integration in place. Like, for example, backups of daily basis in our Git repository.
So anytime there are any issues, we know like, okay, we can look for any changes or like go back and, redeploy it. The third screenshot over here is basically the security features that GSAT provides. So it basically runs through all these things and kind of gives you like what are the different kinds of security errors that are there either in the code or in the repository and with that we need to fix it. So those also go into our sprint cycles as different stories and we deploy those.
Like we said, in the other development and tools and environments basically other than Salesforce, there are a lot of SaaS and DaaS tools and but not so many on the Salesforce development side. So this definitely helps us and, like, of course, like I mentioned, our security team is really happy with having this in place. This last thing over here is the notification.
So how cool it is, like, you don't have to go every morning, have someone monitor what's going wrong, what what didn't run or anything, but get the notifications to you saying, oh, this failed or this particular test result resulted in, like, two errors or the two tests failed or, like, something changed in your org in production. So then you can identify whether it was a planned change or a unplanned change and then you can look into it more. And or, like, some one of the continuous integration job failed and you get notified and you say, like, oh, let me see what happened. Maybe someone refreshed the sandbox and something needs to be configured right.
So, like, having this notification makes so much easier for us going into managing our environment today. So with all this in place, like what it resulted is like it brought some order in place, some stability and of course trust. So now we have a standardized and consistent dev op process, a better code management process. We do code reviews, testing and validations.
The same tested code is deployed in production. We have easy way to back out in case of any issues, managing history of changes and of course the stable and error free system.
So this resulted in having a great system in place. We have trusted partners because like now business is happy, the senior management is happy, the compliance and security team is happy, and we kind of move into this stage from where we were, like, few years back. In today's world, everyone's mantra is, like, do more with less, especially on development team, like, okay, like, they want us to roll out more projects, cover all business priorities, and also show results, but with less resources and less budget. So now how do we offset this given the today's conditions?
And I would say like to do that, the DevOp process and aligning the tool set really helps us. So now offsetting that by picking the right tool set that works for your organization is a key and that way you can manage and automate your DevOp processes as you go through. We use, like, number of different tools that in different areas and, of course, Gear Set plays a bigger role as part of that tool set. To conclude, like, this whole thing, it's it's a journey.
Like, we are progressing every year. We are redefining our process and continuously improving and making changes. So definitely, like Jed mentioned this morning, like, it's it's a maturity journey and you slowly start somewhere and do step by step and then you get to a place where you want to be and, of course, there are remote things, whether it's just the market conditions or the business or things and you have to change and adapt, but at least you have tools and things to help you grow. Thank you everyone.
