 From around the globe, it's theCUBE with digital coverage of Enterprise Data Automation and event series brought to you by Io Tahoe. Hi, everybody, we're back. We're talking about Enterprise Data Automation. The hashtag is data automated and we're going to really dig into data migrations. Data migrations are risky, they're time consuming and they're expensive. Youssef Khan is here. He's the head of partnerships and alliances at Io Tahoe coming again from London. Hey, good to see you, Youssef. Thanks very much. Thank you, Dave. Great time. So your role is interesting. We're talking about data migrations. You're going to head of partnerships. What is your role specifically and how is it relevant to what we're going to talk about today? Well, I work with the various businesses such as cloud companies, systems integrators, companies that sell operating systems, middleware, all of whom are often quite well embedded within company IT infrastructures and have existing relationships. Because what we do fundamentally makes migrating to the cloud easier and data migration easier, there are lots of businesses that are interested in partnering with us and we're interested in partnering with. So let's set up the problem a little bit and then I want to get into some of the data. As I said, migrations are risky, time consuming, expensive, they're oftentimes a blocker for organizations to really get value out of data. Why is that? I think, I mean, all migrations have to start with knowing the facts about your data. And you can try and do this manually, but when you have an organization that may have been going for decades or longer, they will probably have a pretty large legacy data estate. So they'll have everything from on-premise mainframes, they may have stuff which is partly in the cloud, but they probably have hundreds, if not thousands of applications and potentially hundreds of different data stores. Now, their understanding of what they have is often quite limited because you can try and draw manual maps, but they're out of date very quickly every time the data changes, the manual map set of date and people obviously leave organizations over time. So the kind of tribal knowledge that gets built up is limited as well. So you can try and map all that manually. You might need a DBA, database analyst or a business analyst, and they might go in and explore the data for you, but doing that manually is very, very time consuming. This can take teams of people months and months, or you can use automation just like Webster Bank did with Iotaho and they managed to do this with a relatively small team in a timeframe of days. Yeah, we talked to Paula from Webster Bank, awesome discussion. So I wanna dig into this migration and let's pull up a graphic. It'll talk about, we'll talk about what a typical migration project looks like. So what you see here is, it's very detailed, I know, it's a bit of an eye test, but let me call your attention to some of the key aspects of this and then Yusef, I want you to chime in. So at the top here, you see that area graph, that's operational risk for a typical migration project and you can see the timeline and the milestones. That blue bar is the time to test, so you can see the second step data analysis. It's talking 24 weeks, so very time consuming and then let's not get, dig into the stuff in the middle, the fine print, but there's some real good detail there, but go down the bottom, that's labor intensity in the bottom and you can see high is that sort of brown and you can see a number of data analysis, data staging, data prep, the trial, the implementation, post-implementation fixtures the transition to BAU which I think is business as usual. Those are all very labor intensive. So what are your takeaways from this typical migration project? What do we need to know, Yusef? I mean, I think the key thing there is when you don't understand your data upfront, it's very difficult to scope and to set up a project because you go to business stakeholders and decision makers and you say, okay, we wanna migrate these data stores, we wanna put them in the cloud most often, but actually you probably don't know how much data is there. You don't necessarily know how many applications it relates to. You don't know the relationships between the data. You don't know the flow of the data, so the direction in which the data is going between different data stores and tables. So you start from a position where you have pretty high risk and to probably alleviate that risk, you probably stack your project team of lots and lots of people to do the next phase, which is analysis. And so you've set up a project which has got a pretty high cost. The bigger the project, the more people, the heavier the governance, obviously. And then they're then in the phase where they're trying to do lots and lots of manual analysis. Manual analysis, as we all know, and the idea of trying to relate data that's in different data stores relating individual tables and columns for a very time-consuming, expensive. If you're hiring in resource from consultants or systems integrators externally, you might need to buy or to use third-party tools. As I said earlier, the people who understand some of those systems may have left a while ago. So you're in a high-risk, high-cost situation from the off, and the same thing sort of develops through the project. What you find with IOTAHO is that we're able to automate a lot of this process from the very beginning because we can do the initial data discovery run, for example, automatically. So you very quickly have an automated view of the data, a data map, and the data flow that's been generated automatically. Much less time and effort and much less cost ultimately. Okay, so I want to bring back that first chart and I want to call your attention to, again, that area graph, the blue bars, and then down below that labor intensity. And now let's bring up the same chart but with a sort of an automation injection in here. And now, so you now see the sort of, it's called, so it's celebrated by IOTAHO. Okay, great, and we're going to talk about this, but look what happens to the operational risk, a dramatic reduction in that graph. And then look at the bars, the bars, those blue bars, data analysis went from 24 weeks down to four weeks. And then look at the labor intensity. It was all these were high, data analysis, data staging, data prep, trial, post-implementation fixtures and transition to BAU. All of those went from high labor intensity, so we've now attacked that and gone to low labor intensity. Explain how that magic happened. Let's take the example of a data catalog. So every large enterprise wants to have some kind of repository where they put all their understanding about their data, an enterprise data catalog, if you like. Imagine trying to do that manually. You need to go into every individual data store. You need a DBA and a business analyst for each data store. They'd need to do an extract of the data, they'd need to do the tables individually. They'd need to cross-reference that with other data stores and schemas and tables. You've probably done that with a mother of all Excel spreadsheets. And it would be a very, very difficult exercise to do. I mean, in fact, one of our reflections as we automate lots of these things is, it accelerates the ability to automate, but in some cases, it also makes it possible for enterprise customers with legacy systems, like tech banks, for example, they quite often end up staying on mainframe systems that they've had in place for decades and not migrating away from them because they're not able to actually do the work of understanding the data, de-duplicating the data, deleting data that isn't relevant, and then confidently going forward to migrate. So they stay where they are with all the attendant problems of systems that are out of birth support. Go back to the data catalog example. Whatever you discover in data discovery has to persist in a tool like a data catalog. And so we automate data catalogs, including our own. We can also feed others, but we have our own. The only alternative to this kind of automation is to build out this very large project team of business analysts, of DBAs, project managers, process analysts, to gather all the data, to understand that the process of gathering the data is correct, to put in the repository, to validate it, et cetera, et cetera. We've gone into organizations and we've seen them ramp up teams of 20, 30 people, costs of two, three, four million pounds a year and a timeframe of 15 to 20 years just to try and get a data catalog done. And that's something that we can typically do in a timeframe of months, if not weeks. And the difference is using automation. And if you do what I've just described in this manual situation, you make migrations to the cloud prohibitively expensive. Whatever saving you might make from shutting down your legacy data stores will get eaten up by the cost of doing it unless you go with a more automated approach. Okay, so the automated approach reduces risk because you're not going to stay on project plan, ideally. It's all these out of scope expectations that come up with the manual processes that kill you in the rework. And then that data catalog, people are afraid that their family jewels data is not going to make it through to the other side. So that's something that you're addressing. And then you're also not boiling the ocean. You're really taking the pieces that are critical and the stuff that you don't need, you don't have to pay for as part of this process. It's a very good point. I mean, one of the other things that we do and we have specific features to do is to automatically analyze data for duplication at a row level or a record level and redundancy at a column level. So as you say, before you go into a migration process, you can then understand actually, this stuff here is duplicative. We don't need it. Quite often, if you put data in the cloud, you're paying obviously for storage space or for compute time. The more data you have in there that's duplicated, that's pure cost you should take out before you migrate. Again, if you're trying to do that process of understanding what's duplicated manually off tens or hundreds of days of stores, it will take you months if not years. You use machine learning to do it in an automatic way and it's much, much quicker. I mean, there's nothing I'd say about the net cost and benefit of IOTAHO. Every organization we work with has a lot of money existing sunk costs in their IT. So they'll have ERP systems like Oracle or Data Lakes which they've spent good time and money investing in. But what we do by enabling them to transition everything to their strategic future repositories is accelerate the value of that investment and the time to value that investment. So we're trying to help people get a value out of their existing investments and data estate, close down the things that they don't need and enable them to go to a kind of brighter and more efficient future. Well, and I think as well, you know, once you're able to, and this is a journey, we know that, but once you're able to go live and you're infusing sort of a data mindset, a data-oriented culture, I know it's somewhat buzzwordy but when you see it in organizations, you know it's real and what happens is you've dramatically reduced that end cycle time of going from data to actually insights. Data is plentiful, but insights aren't and that is what's going to drive competitive advantage over the next decade and beyond. Yeah, definitely and you can only really do that if you get your data estate cleaned up in the first place. I've worked with and managed teams of data scientists, big data engineers, business analysts, people who are pushing out dashboards and are trying to build machine learning applications. You'll know, you know, the biggest frustration for lots of them and the thing that they spend far too much time doing is trying to work out what the right data is and cleaning data, which really you don't want a highly paid data scientist doing with their time. But if you sort out your data estate in the first place, get rid of deduplication, perhaps migrate to a cloud store where things are more readily accessible and it's easy to build connections and to use native machine learning tools, you're well on the way up the data maturity curve and you can start to use some of those more advanced applications. Youssef, what are some of the prerequisites, maybe the top few or two or three that I need to understand as a customer to really be successful here? I mean, is it skill sets? Is it mindset, leadership buy-in? What do I absolutely need to have to make this successful? Well, I think leadership is obviously key. Being able to sort of set the vision for people will always be key. One of the great things about IOTAHO though is you can use your existing staff to do this work if you use our automation platform. There's no need to hire expensive people. IOTAHO is a no-code solution. It works out of the box. You just connect to the source and then your existing staff can use it. It's very intuitive. It has easy to use user interface. There's no need to invest vast amounts with large consultancy if you may well charge in the earth. And you are actually at a bit of an advantage if you've got existing staff who are close to the data who are subject matter experts or can use it because they can very easily learn how to use the tool and then they can go in and they can write their own data quality rules and they can really make a contribution from day one. When we go into organizations and we connect one of the great things about the whole experience of IOTAHO is we can get tangible results back within the day. Usually within an hour or two we're able to say, okay, we've started to map the relationships here. Here's a data map of the data that we've analyzed. Here are some thoughts on what your sensitive data is because it's automated because it's running algorithms across data. And that's what people really should expect. And you know this because you're dealing with the ecosystem. We're entering a new era of data and many organizations to your point they just don't have the resources to do what Google and Amazon and Facebook and Microsoft did over the past decade to become data dominant, trillion dollar market cap companies. Incumbents need to rely on technology companies to bring that automation, that machine intelligence to them so they can apply it. They don't want to be AI inventors. They want to apply it to their businesses. So, and that's what really was so difficult in the early days of so-called big data. You had this too much complexity out there. And now companies like IOTAHO are bringing tooling and platforms that are allowing companies to really become data-driven. Your final thoughts, please, Yusef. That's a great point, David. And in a way, it brings us back to where we began in terms of partnerships and alliances that completely agree. We're at a really exciting point where we can take applications like IOTAHO we can go into enterprises and help them really leverage the value of these type of machine learning algorithms and AI. We work with all the major cloud providers, AWS, Microsoft Azure, Google Cloud Platform, IBM, Red Hat, and others. And we really, I think for us, the key thing is that we want to be the best in the world at enterprise data automation. We don't aspire to be a cloud provider or even a workflow provider. But what we want to do is really help customers with their data, without automated data functionality, in partnership with some of those other businesses so we can leverage the great work they've done in the cloud, the great work they've done on workflows, on virtual systems, and in other areas. And we help customers leverage those investments as well. But our heart, we've really targeted at just being the best enterprise data automation business in the world. Massive opportunities not only for technology companies, but for those organizations that can apply technology for business advantage. Yousef Khan, thanks so much for coming on theCUBE. Thank you very much, I appreciate it. All right, and thank you for watching everybody. We'll be right back right after this short break.