S02 E07 Revolutionizing the Data Landscape: Inside Salesforce's modernization journey with Murali Kallem, Head of Office of Data at Salesforce

Hello everyone and welcome to the Modern Data Show. Today we welcome Murali Kallem, the head of Data data platform at Salesforce. With over 24 years of industry experience in web and app development, business intelligence, and data management, Murali has an impressive track record of building and managing high-performance teams onshore and offshore. He's a firm believer and practitioner of coaching and mentoring individuals to become mindful and empathetic leaders. Murali's expertise in traditional and modern data management, complex cloud migrations and project management skills became a valuable asset to any organization. With this extensive experience in various industries, including finance, automobile, transportation, utilities, and so on. Murali has an excellent understanding of solution architecture, product requirements, and development. Stay tuned as we explore Murali's insights and best practices for data platform management on this episode of the Modern Data Stack podcast. Welcome to the show, Murali.

Thank you, Aayush Thank you for all the kind words. Looking forward to this podcast show.

Amazing. So, Murali, let's start with the first question. I just happened to check your LinkedIn and you have got a very unusual title. So you have the title of head of Data platforms, but you also have this title in your LinkedIn, Head of Office of Data. That's a new term. That's the term that you are reading for the first time. Explain us that term.

First of all, let me do a quick intro about my background and then we'll talk about your specific question. But I was born in India and then I came to the US for my master's and did my computer science in Masters. I went to Clemson University and then I joined the workforce as an engineer, rolled up my sleeves, and started doing coding and things like that. And then got into leadership roles. And then, went from company to company performing various roles as well as tackling different data domain problems. So I built a master data management solution, a homegrown solution that is. And then I led a marketing data team. I've led IT teams from a data warehouse implementation perspective, migration of data warehouses, and then also data science use cases and so on and so forth. And as I navigated that space, I realized I do not have a whole lot of experience from a governance point of view. So that's how I got into the Salesforce role as a, office of data. And then my role pivoted as well. And now I'm heading a data platform. For all of Salesforce, we provide a comprehensive and robust data platform for our internal company usage. And so that's essentially what my role is here.

Amazing and just to go a little deep into that, how does your data platform looks like, what are we talking about? What are the components that you're talking about?

We are currently going through a modernization effort. We were largely having a presence on premises and so we are going through that effort to modernize our complete portfolio of products that we offer from a data perspective. So we are currently migrating to Snowflake as a data warehouse platform. We are also leveraging a cloud-friendly ETL tool. We're also adopting a cloud-friendly orchestration tool. Tableau is a visualization tool we used to use a different competing product, but we migrated to Tableau and it makes it easy because Tableau is now owned by Salesforce. So that's that. And we are also providing a data science platform as a capability for the users as well. A lot to be done there. A lot to get into a lot to stabilize and make this platform a more user-friendly platform modernized platform, so to speak.

And Murali, what was the key driver behind this modernization project? Was its scalability?

Very good question! I think. So the driver here is agility and our previous platform was not agile enough and scalable enough and so on and so forth. So we wanted to build a platform that allows us to migrate faster and Operate faster and enable people to use it in a way that they were not able to use before. Mainly centred around the business value in terms of agility and so on and so forth

and really often, when we speak with our guests, there is often a question of build versus buy. And you obviously went with probably, which wouldn't be a very blanket true statement, but you went from building and now to buying, right? You mentioned you're adopting a cloud, ETL tool, you are having cloud data warehouse. Does it also have an impact on the engineering resources or the in general resources that you have within the cloud data platform? So has it shrunk your data organization? That's my basic question.

Good question. But I don't know if it really shrunk it. But we have a very resource-sensitive focus on how we want to approach this. Yes, we had an on-premise presence. We still have a little bit of it but that is mainly centred around using appliances. So we were not maintaining a whole lot of infrastructure, so to speak but those appliances were also not scalable to a certain extent because as our data needs were growing the appliance were, can only be scaled by adding more appliances to it. So there's no separation of compute and, storage philosophy, through that mechanism. And so I think going to a cloud data platform definitely is enabling us. Now I think a lot of the onset of appliances, there used to be this term that you do not need a DBA. I'm sure Snowflake and the likes of it, also would save to a large extent, they are right. And I think we optimize our resources wisely to manage the platform efficiently. We might not need a dba, but we might need somebody to tailor the platform and make sure that there's proper spend of credits and that the systems are behaving the way they should be, and things like that. So those are all some key focus areas for my organization.

Right, and walk us through the structure of your data team. How is your data team structured? What are the core functions that you have within your data team, and how do these functions work with the end consumer? How does that whole orchestration happen?

So within Salesforce, we do have data teams outside of the IT organization. I'm part of an IT organization. We have data teams that build data insights and so on and so forth. And they are our partners and we provide a data warehouse to those users. And then they come and consume those data sets and then they go build on top of it. So it's a partnership between IT and the business teams to come together and produce accelerated analytics, so to speak

And the reason I asked that question is in one of our previous episodes we spoke with one of the guests where we dive deeper into the whole, the topic of data mesh and accountability within the data environment, right? Walk it from your experience, how do you guys set accountability with respect to your data from both, the business-facing teams versus, you as an IT owner of the whole, the data platform, who sets accountability, who sets the responsibility, and how do you govern that?

No, I think that's a very burning question. I would say you quite often. Industry experts throw really, cool buzzwords and jargon out there, the data fabric, data mesh and all that. But I think fundamentally they're trying to talk about the same things that we all have been dealing with for the past several decades. Number one is trust in data. Do you know what data you're bringing? Number two is how do you make it consumable in an easy format? And then along with that who is gonna maintain that data and so on and so forth. And now you see the evolution of data as a product, which basically means you are selling that as your iPhone, which should mean that it has proper documentation, it has the proper quality and that people can trust it and so on and so forth. Then you set out a good roadmap of what all features you want to bring in for that data set, which might mean not only it's an internal data set, you might have to go bring in some augmented with some additional industry data sets and so forth, and make it a more comprehensive data sets and so forth. So, if you look at this end goal, then there, I think from the perspective of the role, there are several roles that several people have to play here. And it all depends on the company's org structures, dynamics, and the R and Rs and so on and so forth. First and foremost, I think it starts with the data owners and the data product managers. They play a key role in my view, in defining. What consists of their data product and, whether they augment the data? How do we make sure that the documentation, the KPIs, the metadata, all that stuff is captured and is made available for people to consume and so on and so forth? And then there is the platform aspect of it that comes into the picture because if every product manager is trying to publish their data sets as an example, where do they publish it? How do they publish it? And how do they make it easy for people to consume it and things like that? So yeah we can talk for hours and hours on this. But yeah I guess you know where I'm going with that.

Yeah, absolutely. And since you are, through this modernization process and there would be a lot of tools you would be considering for various aspects of this whole modernization project, tell us from a data leader perspective, you're a data buyer, you are the guy who is, not specifically you, but you and your team are responsible for procuring this new software, new capabilities to be able to do all of these kinds of things. And we have a lot of, members in our community, our data vendors, who are looking to provide software to enterprises like that of yours, tell me your top three key buying criteria. If you want to take a specific example, we're happy to go through that. But when you are looking to procure and buy a particular software, what goes through your mind?

I think first and foremost, what's the need? What is the problem that I'm trying to solve, right? And what's the business value? Is there a value the business value that I'm providing by doing this? The majority of the time I don't approach it as a technical upskilling or upgrade project mindset. I look at it from a what's the value perspective. Why do we need to upgrade this? Why do we need to spend this money? And why do we need to spend so much time and effort to do this? Not only from my organization's point of view, but also from the end users who might be using it, because they might have to be brought in to do some testing and things like that. So ultimately it goes back to the purpose. The business case, the value that you're providing, and if it is solving any business problem quicker, and, things like that. So I always approach it from that perspective and I try to anchor it to their business objectives for that particular year and anchor it around that. Secondly, the question then is, is this something that I can build or buy? And If something exists, 60%, 70%, or 80% of the time, then, you'll have to make a decision. How much customization do you have to go through, or, do you have to have your team do versus do you just go and buy the product and rather than reinvent the wheel, you reuse some of the existing functionalities that the vendors provide? I don't want my team to go build solutions that already exist out there, or, even if it's loosely there, then you know, I would still want to explore that because I think the focus should be on providing business value than building the next best ETL tool out there, just as an example because that's not what my team needs to be doing to provide business value. So then the third item is what are the requirements? What do I need from that tool? What am I looking from it? What do I expect from it? And so on and so forth. Now, there are certain things that we try to capture, but there are cases where I go to the industry experts like Gartners of the world and so forth, and they provide a good comprehensive requirements that you can make use of. And we tailor it to our needs and add in our specific requirements and so forth. And then we involve our procurement folks to call for RFPs and RFIs and, go through that whole process to bring in the experts in that space. And some of them our procurement team might know and some of them, we might have to roll up our sleeves doing our research and doing our exposure in the industry and use things like Forester Port or Gartner's Magic Quadrant to determine what vendors should we explore and so that's how we start and we have that dialogue. And then the one other thing that we always like to do is we like to score the vendors based on, what needs we are expecting. And that way it's always quantitative, not emotional or, anything like that.

And where does this consideration between an open source versus a commercial offering come in?

So, very good question. And it's a tricky one. It's a tricky one because first of all, do I have that skillset in my team? It's somewhat easy in the Java side of the world, but on the data side, it gets a little bit tricky. What is it that I'm trying to bring in as an open source? Take some examples. Airflow is an open-source solution. Now, do you leverage, Airflow and set it up yourself and then start maintaining and managing it? How many people do you have? How many people are you willing to put on it to build the ecosystem and know Airflow infrastructure and build the capabilities to make sure that Airflow scales to the needs of the organization and things like that? Because It has so many other complex architectures baked into it Kubernetes and so on and so forth, and does my team have that background and bandwidth and so on and so forth? And so similar to like buy versus bill. Should I go and buy and manage service on this than, do it myself? Do I have the budget for this? What's the timing? I think there are quite, quite a few things that factor in. If time-pressed, I would not want to go, take an open source and then go do this. I would rather go have that conversation with my leaders that I need this much money than suck it up and then implement it by myself because then it's gonna hit me one way or the other later. And largely it's because of the team's skillset or time it takes for them to come up to speed and all that. Now, if I have a fully baked team that has done this in their previous jobs, sure, I would probably take a chance there. So it all depends on these other factors that I mentioned about.

And one other thing which is pretty much related to this is you see a lot of companies that is they're in this modern data stack ecosystem. They're all young companies. Most of these companies have been around for more than two years, maybe two and a half years. And my question to you is, there is a well-conceived notion that, it's hard for these, young companies to get into, companies like that of Salesforce. First of all, do you have any kind of experience in terms of working with these early-stage companies while at Salesforce? And if so what's your experience has been?

I would speak general, not just at Salesforce. I worked at small companies, I worked at large companies like Salesforce and even bigger ones and so forth. I think you have to have a lens of what does it take for you to bring in a vendor to support the enterprise's needs? Enterprise needs are very different from the needs of a small company or a startup, because, most likely your team is probably able to get into it, and so on and so forth. But enterprise large companies, fortune 50 companies have different kinds of needs. So I always wear that hat whenever I'm exploring vendors. Because I want the vendors to have a mature process of how they manage their own releases. How do they push the product upgrades and so on and so forth and they force me to go do the upgrades because doing these upgrades in a large company is fairly complex because you have to follow some release cycles. You have to follow some change management practices.And then so that's one thing I would like to look at those aspects. And then secondly, what's their support organization looking like? I try to get into those details because to me it's very important if my team runs into an issue we don't mind paying money to get that support. And we typically try to enter into that kind of conversation when we're buying licenses, but we need somebody to answer the call. And in the middle of the night on or on a Saturday evening if we run into an issue we want somebody to get on the call and solve it. And you get that with established companies, they have a pretty robust support structure and that kind of suits my personality if I'm working in a bigger company because then I know I have some account managers on my hot-speed dial, and then I can call them if something if we're not getting looked into right away. So I think those relationships also matter, the bandwidth and the support structure that the companies, these, budding companies have also matters, in these deal negotiations.

Wow, that's very insightful. And on a different note, on a different topic you mentioned, you guys are migrating to Snowflake as a data warehouse and you guys have a tremendous partnership with Snowflake, not just for usage for your internal own purpose, but from a public partnership where probably, very soon every Salesforce customer would be able to in a very native way be able to export all of the Salesforce data into, Snowflake. And, that's where people can build their own data applications on top of Snowflake itself. Two questions here. One is, as a data practitioner, where do you see this strength emerging to be? You know what, modern data stack as an ecosystem has been professing this fact that the data warehouse is the heart of the data ecosystem, and that's where you start to build on top of that. And that's a big validation from Salesforce. To that ecosystem where the data warehouse is actually the heart of this modern data ecosystem. So one first question is how do you see it as from a practitioner's perspective? Is that a big validation to the whole data community? And the second thing is as a data practitioner, would you see other software companies adopting such kind of data warehouse native approach to be able to sync their system of record, source of truth data directly from those applications to a data warehouse without requiring a need of ETL tool like Fivetran and so on, so forth.

So I'll answer this question more as Murali Kallem with 24-25 years of experience and not as a Salesforce employee. Yeah. But I'll also say that I'm very excited about Salesforce's product the Genie Data Cloud. I think it has a lot of promise, but let's take a step back and understand what's the most expensive part of a data warehouse. It's the ETL activity. You build, you spend so much time and effort to build up these data pipelines that have to be tested for quality and things like that. And if your ETLs are somewhat rigid then you add a new column to a database then which has to be a database table. And then that has to be reflected in the ETL jobs and then on this target side and so on and so forth. So these have a never-ending loop of changes that you have to deal with. And not to mention the testing and things like that, and if the data signature changes, all these stuff probably have a profound impact on your ETL activity. And I think, the onset of zero-copy architectures that snowflake and these architectures bring, that is definitely one of the compelling factors within my organization right now that we are migrating to snowflake. But we are excited about this opportunity that Data Cloud brings to the table where we can minimize those ETL jobs and leverage, I think the concept is the Federation, data Federation and largely it's benefited through the Apache Iceberg and the onset of those open source standards and so on and so forth. So I think the future is very compelling. It's high time Data Federation comes to Limelight and provides a lot of solutions that will reduce the pain points of data customers across the world. So, yeah. Federation, Virtualization, I think are very promising technologies for a lot of data practitioners.

Amazing and, just as we inch closer towards the end of this episode, I'll have a couple of, closing questions here for you, Murali. The first question is whether there has been a Cambrian explosion of tools that has happened in the modern data stack and the modern data ecosystem in the past couple of years. There are a lot of tools that kind of came and went, and we are seeing a lot of consolidation these days, even if you go and look at the ModernDataStack.xyz Website, you know there are around 28 or 30 different categories of tools that are out there. And as a practitioner, as someone who is actually working with Data day in and day out, do you find that unsettling in a sense where you have a huge spectrum of tools each doing, some piece of very specialized functions and you as a data consumer has to kind of buy these set of tools to be able to do the job? Or would you see a future where you would have certain vertically integrated tools that are capturing the entire value chain?

As a practitioner? I think it helps me if I have very few moving parts, right? I would say that helps me and very few contracts that I have to negotiate, very few salespeople that I have to deal with and all that. But I think the breakthroughs in the data industry have been phenomenal since 2000, I would say and new technologies come up every few years early on and now. Probably every few months there's something coming up. And just as a tidbit, whenever I go to conferences, I don't go to the big booths. I go to the small booths because that's where the disruption is happening. And you try to understand what they're trying to do and what they're trying to solve. And sometimes it takes for you to understand what they're trying to do because you are not completely thinking through the actual need and so a lot of great promise there. And, as a practitioner, do I want some of this consolidation to happen? Yeah. Mainly because it's a convenient thing for me. But I'm sure if we focus on specific aspects of data I don't mind looking at it that way. As an example, I don't necessarily want to go with just one vendor for all data, different data topics like data quality, data governance, and master data management and, things like that. I don't mind going with different tools best in class tools if they're interoperable. And I just need to figure out how much customization that I have to do from my team's perspective to stitch these things together. So it's about the pain that I have to go through versus the integrated things that these vendors offer.

That's a brilliant perspective. The last question before we let you go today, Any specific tool or technology within the whole data ecosystem that you are personally very excited about? That's something that you say, wow, that was smart!

I will say the whole Genie Data cloud offering is a very compelling one. I am not saying this because I'm a Salesforce employee, but I'm saying this as a general data practitioner. If I'm on the other side where the majority of my data resides in a Salesforce ecosystem and I have few other data sources here and there that I want to bring in, I think that's a very compelling product that minimizes a lot of build that you have to do and so on and so forth. There are a lot of things that are also happening outside of that. Like, we hear about chat GPT, the open AI initiative. That's very pathbreaking. Curious to see how we can leverage chat GPT type of solutions to solve, to revolutionize the visualization or the analytics aspects of how people consume the metrics and reports and so on and so forth.

Yeah, and hopefully very soon we should be able to see some kind of Tableau integration with chat GPT.

Yeah, I'm looking forward to it.

Hopefully that comes out soon. So thank you again. Thank you so much, Murali, for your time today. It was such an amazing episode for us. I hope I and all of our audience had good key takeaways from this whole episode. So thank you so much for giving us your time.

Thank you very much. Thanks for the opportunity. Salesforce is moving towards a more user-friendly and modernized data platform that allows for faster migration and operation, while also enabling users to take advantage of new functionalities that were previously unavailable. In the latest episode of the Modern Data Show, Murali Kallen, Head of Office of Data at Salesforce discussesthe Snowflake modernization efforts, including migrating to Snowflake and adopting cloud-friendly tools. Murali also covers the importance of vendor support structures for established companies and he consideration of open-source versus commercial offerings. "Revolutionizing the Data Landscape: Inside Salesforce's modernization journey and the secret to unlocking your data's full potential!"