Cloud Crunch
Cloud Crunch

Episode · 1 month ago

S3E1: Don’t Leave Out Your Data & Analytics Element when Migrating to the Cloud

ABOUT THIS EPISODE

Welcome back to a new season of Cloud Crunch. In todays episode, we intend to address many of the difficulties, and opportunities, of your evolution in the cloud. We are joined with our new co-host Fred Bliss, CTO of all things data at 2nd Watch and our guest Evi Hatzopoulos as we explore the topic "Dont Leave Out Your Data & Analytics Element when Migrating to the Cloud"

Involve, solve, evolve. Welcome to cloud crunch, the podcast for any large enterprise planning on moving to or is in the midst of moving to, the cloud, hosted by the cloud computing experts from Second Watch, Ian Willoughby, chief architect cloud solutions, and Skip Berry, executive director of cloud enablement and now here are your hosts of cloud crunch. So welcome back to a new season of cloud crunch. In this season we're tending to address many of the difficulties and opportunities of yours. Is such a year evolution in the cloud. We're going to hit upon some topics covering from application modernization enabling cloud native development, data insight, as well as cloud economics. Now, normally I'd be joined this season with the ever president, ever learning skip Berry. However, he decided to go on holidays. So sitting in the Co host seat today is Fred Bliss, CTO of all things data at Second Watch. Greatly appreciate you sitting in here, Fred, as a co driver of this season. So welcome Fred. Great to see Michael joining us today. Is Someone I've had the pleasure of working with for at least the last five years, evy hotspholis. She spent the last five years delivering data centric projects and a wide variety of projects at different clients and she's now leveraging that experience to find a really high value work for our clients that are structured with delivery teams in mind. So thank you for joining us, heavy. Yeah, glad to be here. Welcome heavy. So I'm going to start off with kind of the title of this podcast, which is don't leave out your data and analytics elements with migrating to the cloud. So you know, starting with that. Let's let's start with you, Fred. Do you see many organizations that are really just going to the cloud, just kind of lift and shift mentality forgetting everything else, or what are you starting to see? And then we kind of dive into what are they missing by doing that? Yeah, that's a great question and I think it differs depending on your audience, right. You know, when you are working with I think, well, maybe in the early days of cloud, we saw a lot of focus on e S, right, so folks taking applications, databases, even full data warehouses and just migrating and lifting and shifting them right over to the cloud, and the benefits you get from that aren't really great. Right, maybe you need to get out of a data center and that's about it. But yeah, what we've seen in the last couple of years is, you know, especially when we're talking to some of these mid sized enterprise organizations, is that sometimes when they start with the data project, this is their real first venture in the cloud. They might have had a couple applications, maybe they acquired a company that had a little bit of a cloud presence, but when we're building these data...

...applications, a lot of the time it's a fifty of the time, when we're working with business users, this is their first venture into the cloud and from a data and analytics standpoint, we're pretty much now at a place where it just doesn't make sense to host anything on Prem what you can do in the cloud. It's not so much from a performance or even a cost saving standpoint, but it's the flexibility and the tooling that you get with that. A lot of the platforms that we work with tend to be their software as a service or platform as a service, and that abstracts away so much of the heavy lift and the infrastructure knowledge Um to make it easy for the technology teams that we build these solutions to eventually adopt and start to use. So, you know, as we're getting them into the cloud. Um, you know, they might typically have one or two people on the I t team and that may include the same people that are doing the data work. So we bring these analytics workloads in from database sources or systems that they might, you have on prem and use this as kind of they're jumping off point for bringing it into the cloud. And that's interesting for it because, you know, what we see from very large enterprises is they've gone to the cloud from an application perspective and the data has followed. And what I'm hearing you say is from from the midside or organization, actually, data has led their their venture into the cloud. So, evy, I mean what you've been your experience? You've worked directly with a lot of these companies. What's been your experience as far as data first to the cloud versus applications to the cloud? Yeah, that's what I've seen as well. I mean granted, aptative kind of focused on all things data. So a lot of the projects that we did and we're very data having data focus in mind. Um. But the thing with data too is once you get that in the cloud, the visibility of exposing those insights. The organization is kind of hot right now. That's a lot of what the executives want, so it's sometimes easier to lead with that and that makes the cloud a little bit less like obscure. It's kind of like Kay, like, if we're going to move this stuff to the cloud and it's going to have a direct response that people can see and touch, you know you're gonna get this report out of it, you're gonna get your insights out of it. Um. So yeah, so usually we we'd see something similar to what fread mentioned. You start with your data, you get that moved over and then once you kind of see how quick it is to modernize once you're in the cloud and kind of there's not really a heavy lift that you would see a lot with on prem applications or on prem databases. So once you kind of see the ease of moving to the cloud, that's when we would start to see kind of everything else in the organization follow suit. And a great example of this is Um evy and I worked on a project where, you know, it's a large organization and they had everything on Prem and the data project that we're working up with them on was kind of a side project. It was something that they just wanted to bring some data in, do a little bit of discovery on it and, you know, didn't really even have a business use case for what they were going to use it for. But that became kind of the central point of of what we were building when it came to application development. So they had a lot...

...of legacy systems on Prem Um, some that were old, as as old as twenty years old, some running on, you know, extremely old versions of Java, and rather than try to just even lift and shift those or even refactor those applications, they wanted to completely rethink the way that these applications worked within their business. And so by taking this centralized data platform that we built for them, they essentially went from Um having all these legacy applications and all these old web services to, over the course of a year or two, essentially building a Greenfield new application that was cloud first, that was intended to replace a lot of these legacy applications and that also had this insights hub kind of right in the middle of it. So the application itself was not just a siloed application from the data warehouse, but they were embedded together. So by using embedded analytics and having textually aware of reporting within the application that you're using and by enabling a P I s for other applications and other end users to consume that data, you essentially had this nice holistic approach to everything and a path where they can start to sunset some of these older applications. So then what I'm hearing you say is there are organizations that are more focused, more data driven, as they're on path to the cloud and what solving business problems with, you know, looking at the data side versus a modernization effort. Yeah, and I I mean you do see the opposite as well, right, like a very large and large organization that I worked at. They they were essentially on the cloud. They did exactly what you talked about, Michael Or. They did a lift and shift of almost everything just to get out of their data centers and it was a huge footprint. And so they looked more towards a modern data solution and they had an old, legacy data warehouse that was still sitting in there, had a lot of code behind it and because it was very, I t driven, without really a lot of, I guess, business goals behind it. They are. What they essentially created in this process was an old cloud data warehouse that was bringing data over to the new data warehouse, and you had reports feeding that. So the goal was to get rid of kind of some of this older stuff. But with that lift and shift approach and not really having a good use case for what they're going to use this new cloud data warehouse for Um it, it kind of fizzled out right and what they were left with was uh, double the double the maintenance effort versus what they had before. So evy, from your perspective, mean, is that one of the big risks you've seen as far as wanting to just essentially move without thinking strategically about how best to look at what you're trying to achieve and move towards that goal, versus just a lifted shift mentality? Yeah, absolutely. I mean I think a lot...

...of times organizations are eager to kind of keep up with the competition and move to the cloud and modernize. But you know, it is a big undertaking and I think it's important to understand for the entire organization to kind of be marching towards the same goal. Right. So you need to know what are your reasons for moving to the cloud. Um, what are the pain points that you're facing now? What are you hoping that you know, moving to the cloud? How would that ease those pain points are or enable you to be even more competitive going forward? I think if you just quickly try like the lift and shift mentality without putting, Um, additional like thought into what are some things that we can do better once we are in the cloud? Um, you right into into some risks there. Not to say that it's all bad. It just, you know, might take you a little longer and might be a little bit more expensive for you to end up where you ultimately need to end up without putting that you know and from you know, that forethought into it. And that's a good point of because, Um, you know, a lot of the lift and shift data warehouses are, you know, full data platforms that we've seen. They're taking the old enterprise data warehouses that were built in the nineties and early two thousand's, and these things kind of became the everything data warehouse, and this was the era of self service reporting, where you had this gigantic data warehouse that served up everything you could possibly want about an enterprise defined by I t right. And so marketing, the way marketing looks at data, the way finance looks at data, the way the sales or looks at data. Um, they could all be very different, right. And so these things quickly became very overwhelming, to the point where I started taking on the task of creating reports and delivering reports as opposed to putting it in the hands of business users and analysts that are working for those teams. And so the most successful projects that we've done, in the most successful, I guess, cloud deployments we've done when it comes to data platforms has always been business driven, in that you know, you think about something like the data model, and this is something that has to be gotten right because you only get a chance to do it every time you're building a new one Um, and that pretty much only comes when there's a big technology change. But the way you model your data needs to look like the way the business looks at data, the way marketing looks at it, the way sales looks at it, not the way that you know your e Rp might look at it. And so I think that's kind of been a fundamental shift that we've seen over the last ten years. As folks are moving to the cloud and getting these modern data platforms. Um, it's a chance to rethink how this all works. And you know, every and I both worked on a project together where we were taking the same source data for a logistics company, but essentially because they had two different businesses, entirely different businesses, one being a services piece and one being a brokerage, piace Um, we could take same data but create different views of it for these two very different businesses without reinventing the wheel from the beginning. So let me ask you this. I mean you talked about being business driven. Give us a just...

...an example of what it is in business driven and what some of the probably the bad outcome has been because of that. I think that the worst outcome that you can have from an analytics project or any kind of data project is the lack of adoption. Right, you spend all this money to do something and business users don't use it. Um. You know, we've seen examples of that before where we've built something in Um. You know, maybe it was driven by cost reduction, right, like we want to move to the cloud, to a cloud data platform, to reduce the costs of our footprint with Oracle licenses. That sometimes makes sense, right, and if you've got the right business backing behind it, sure, but in this case there was no top down initiative to start using these things. There was no real, I guess, time spent by the business to start getting used to this data, into this new world. And so without kind of that executive support, which you can get all the way at the beginning of like doing a strategy project, but without that you've you're going to let the businesses just fall back into the way they've always been doing things. So I mean, you know, what are you know we think about this? What are some of the simple changes that organizations and executives can do to really increase the adoption of data and analytics? I think they need to just they need to be talking about it all the time, at the beginning of the project, as the project's going, you know, as we're developing to get them to where they ultimately want to be, and especially afterwards, they need to be actively using what is being built, whether it be reporting or, you know, a separate application, whatever the outcome is. Um they need to kind of lead by example, I would say, and show that, hey, I'm looking at this data on this report to determine these things about our organization. So if you're kind of not on the same page as that and you're not looking at the same things I'm looking at, you know, your performance may we may, we may be comparing apple storenges here. Right. So I think from our experience, as as long as top down, they're completely bought into what we're doing and they and they kind of want the organization to view the outcome the way they do. Essentially, Um. So we're just kind of making what frauds said there. Yeah, and all it takes is one person right, one champion within the business to kind of steer that effort Um. Some of our most successful projects start with a data strategy to get folks talking to each other and US talking to each other and everyone kind of aligning around the same business goals and vision. Um. But you start small, like start with maybe a single use case and maybe it's uh, you know, maybe it's sales data across your product and you know your customer right, something really simple that you can get a team behind. In some cases that might be the account the accounting or finance team, and you've now suddenly created this brand new use case that may have been extremely difficult to spent, you know, hours and hours in excel every week trying to p it together, and you've...

...just made someone's life easier. Now you get that person working with other folks within the business and kind of evangelizing it a bit, that becomes really powerful. So a little bit of curveball. As you've worked with clients from a departmental perspective, who are you seeing driving this modernization of their data platform? I think it's it's kind of across a lot of different places. I would say, UM, some of the most successful ones are CFO driven. A lot of our customers end up starting with uh, with sales data, which quickly pivots into General Ledger accounting data, and that because you're bringing in you know it' say revenue, cost of gets sold, those kind of things. You can now quickly bring the sales team into that and now you start to add some more attributes, maybe from salesforce or from your marketing automation platform, and you start to enrich that and now marketing has a use case for using this data, even to the point where they're not using it for reporting but they're also using it to send to their marketing automation platform to have this full end end platform where you can go from entering an a lead into salesforce, having it run through the process and having your market marketing automation platform start to send out very targeted emails to your customers or potential customers. Yeah, and I would agree. I think the two biggest, most successful projects I've been on we're both being lied by the CFO. He was kind of the main, the main driver in both those organizations. Yeah, and sometimes you do see it from a data standpoint. Some of the more mature organizations, Um, where the way they're organizationally structured is they've got some kind of director of, you know, data and analytics or chief data officer. When those are lad and that person has kind of the right backing from those business leaders in that C suite, that can be really powerful as well and that can uh, you know, sometimes lead to, you know, starting with something really big and really ambitious where you're bringing in a whole lot of data sources. We've got one project right now where we've got over twenty five different data sources including, uh, you know, audio data from call centers. And when you're doing something like that, you've now just opened up, you know, a huge potential for not just analytics but for machine learning as well. All right, let's jump to kind of the last question I had it, which is around data quality or data governance. And you know, how does good or bad data quality affect the effort or pace of change or final outcomes or overall project risk? When? When? When you think about that in those broad terms, I think that bad data is exists everywhere, right, like there's no organization that doesn't have bad data. It's just kind of inevitable, and that's completely fine. I think the biggest piece there is you just need to be aware, right, you need to not kind of be blind that maybe your data has gaps or, you know, as not as robust is maybe it needs to be Um and if we do kind of the due diligence...

...upfront and we kind of talk through, all right, we're running it, we're gonna run into some data quality issues. This is why it looks the way it is, this is how we can fix it and in the meantime, this is kind of how we have to work around it. That's completely fine, like I don't see that derailing of project at all. I mean you know, depending on how much work is needed to make up for the bad data, the timeline might be extended, but it's not some unforeseen catastrophe. I think Um the biggest problem there are the biggest note there will just be upfront to to be very clear about what our data sources are and kind of the data they contain and have a plan um to get that data one way another to end state that that makes the most sense for the business. And if you're if you're a person coming into a new organization, you know, as you know a new employeer or a consultant, one of the best indicators to figure out how good their governance is as a as a company is to see how much time or how many folks are spending, you know, a chunk of their day either writing code or fixing bad data somewhere in the middle. And you know, we saw, you know, a lot of M D M projects come out in the early two thousand's because there was no governance at the beginning and it's a lot easier to throw a technology piece of software that's that problem than it is to fix the people process problem. So what we can say doesn't work is you will spend a never ending amount of time fixing bad quality or bad data quality. But, like every said, if it's upfront and you've got everyone on board and you're letting that data flow through, what that let's business users then do is start to build governance boards and assigned ownership to these source applications. So if you've got a hundred different duplicate customers in salesforce and none of them are organized, there's no hierarchy and anything like that, it's going to flow over to the reporting looking exactly like that. And sometimes bad data could be valuable. I'm, you know, working with a client right now and they are aware that there's a portion of their business where it's the data is barely available in the data that is available is pretty bad, and they're using that as kind of leverage to expose that and say, Hey, guys, we need to be a lot better here, like this is an area of the business that we want to focus on and could help us be more competitive, but because no one is kind of filling it out as appropriately, we can't leverage that data and do anything with it. Um. So just kind of, you know, a testament to all the data is good data right, having data is what's important here and then, like Fridsaid, just building processes around what's bad or lacking or poor quality to make sure that it's as useful as it can be long term. And as as we're, you know, thinking about like as more organizations are starting to productionalize machine learning models. Um, this bad data, it's even more it's way more important than ever now because it's not just something that's going to show up on the dashboard. But if there's trust in this machine learning model and there's good explainability behind it and everyone in the business is completely out...

...into it, it may be the perfect model, but if you've got bad data training it and feeding it and reinforcing it, there's gonna be bad business decisions coming out of that. Well, I know that our salesforce, incidence, is perfect with so yeah, I think it's everybody's struggles with that. Alright, any final words that you want to leave the audience with? I think in general I just say, you know again, the best way I've seemed to start with something, whether you've got, you know, no data warehouse or you know, basic reporting or a legacy data warehouse or maybe five of them. Um, the best way to start with something new is to start really small and really targeted. So, you know, start with a very small use case, align your entire executive team, uh, in your champions, around a common vision in roadmap so that when you do start building, you know exactly where you're going in this roadmap. It might be on year, it might be two years, it might be five years, but at least you've got a map for where you want ahead. And traditionally, how long does that roadmap take to kind of build out? You know, and I guess it's that strategy. How I mean? Is that a is that a month long engagement or what does that look like? Yeah, traditional data strategy for us is, you know, about four weeks, up to eight weeks, depending on how deep you want to go with some and how many interviews you're doing. But really, uh, what that sets you up for is typically a roadmap of around, you know, maybe a couple of phases, and you know we like to chunk phases into you know, about three months of work small teams and you know, we will typically roadmap that out to I don't know, maybe three phases and after that it's kind of just a collection of these are all the different various business capabilities that you can unlock along the way. Um, a lot harder to budget things when you're talking over a year out, but it still gives you a way to start executing on something small and building a foundation to start expanding upon. Overtime. As in saying, the roadmap kind of allows them to do things in parallel. Right. So as you're focusing on what that first initiative might be, if, throughout the process of discovery and roadmapping they know that where they want to be long term they need to put some processes in place or by additional tooling or whatever the case may be, that gives them the opportunity to work on that internally to kind of keep things moving according to plan and then also kind of getting buy in from whoever they need internally as well. Um, so that first discovery slash roadmap phase is really crucial and really, really helpful when you're working on these types of projects. So I just want to kind of conclude. Thank you very much, edvy. Thank you very much, Fred for joining us on cloud crunch. Very informative. Always appreciate when we have guests on. I do know we're gonna have an episode two where you're both going to be on talking about how to create business intelligence before cloud migration, but for this episode, really appreciated and thanks for joining. Thank you,...

Michael. Thanks so much. You've been listening to cloud crunch with Ian Willoughby and skip Berry. For more information, check out the blog second watch DOT COM, slash company, slash blog, or reach out to Second Watch on twitter.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (33)