 Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager at DataVersity. I'd like to thank you for joining the first latest installment of the Monthly DataVersity Webinar Series, Advanced Analytics with William McKnight. Today William will be discussing strategies for transitioning to a cloud first enterprise. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. If you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the bottom of your screen for that feature. For questions, we will be collecting them via the Q&A in the bottom right hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag ADV Analytics. And as always, we will be sending a follow-up email within two business days containing links to the slides, the recording of the session, and additional information requested throughout the webinar. Now let me introduce to you our speaker for this series, William McKnight. William is the President of McKnight Consulting Group. He takes corporate information and turns it into a bottom line producing asset. He's worked with major companies worldwide, 15 of the global 2000, and many others. McKnight Consulting Group focuses on delivering business value and solving business problems, utilizing improvements, streamline approaches, and information management. His teams have won several best practice competitions for their implementations. He has been helping companies adopt big data solutions. And with that, I will give the Florida William to get today's webinar started. Hello and welcome. Hello, Shannon. And welcome, everyone. And welcome back. I see a lot of familiar names out there and people coming in from all over the world. It's really great to see. Again, this is held monthly at this time. So do come on back and stay with us here. It's basically my random musings about the things I'm seeing in my practice, things I want to share with you, things that in my educational background, really, I'm really compelled to share. And today is one of the most important ones, I think, it's strategies for transitioning to a cloud-first enterprise. And this is something that a lot of my clients are going through. Obviously, there's a lot of talk about the cloud. There's actually a lot of action about the cloud. A lot of companies moving there. They're there to some degree, right? However, there are an increasing number of cloud, so-called cloud mandates. Of course, there's a lot of wiggle room inside of those mandates down at the practical level. But the idea being that many enterprises are trying to get more and more to the cloud. For all the good reasons that there are. And today I'm not going to belabor those reasons. I'm going to talk about how to help you once you've made those kinds of decisions in your enterprise. Now cloud-first doesn't mean cloud everything. As a matter of fact, it's hard to find a company that is cloud everything out there. But cloud-first means, to me, it means that when you are provisioning new resources for new applications, new services that you want to develop internally, the cloud comes first. You are highly, highly considering, maybe not selecting it every time, but you are highly considering cloud solutions. It's not, well, now it's time to talk about whether we want to do anything at all in the cloud or not. That ship has sailed in these organizations. And I think that's a good thing. As a matter of fact, I think that cloud is here to stay. I don't think that organizations of the future will be provisioning their own data centers pretty much at all in about 5 to 10 years. So you have to make decisions as an enterprise. The way you make those, the way the manifestation of those decisions is in where the money goes and where you are spending for your resources. Is that in the cloud or is that in your on-premises solutions? I think it's going to skew more towards the cloud. I think leading organizations are already there and many more are going to be coming on. Again, I think this is a good thing. This is one of those things, one of the few things that really is required, I think, to be a leading enterprise of the future. Really, leading might even be a strong word. Just sustaining as an organization of the future, basically given the basic competitive pressures that will occur to those who remain on-premises. Okay, so with all that being said, companies are shifting their focus to or entertaining a notion for a first time use of the cloud. I'm not going to read everything but I want to point out a few things on all my slides. I find that the time that a lot of companies make the big transition is when the hard on-premises assets are coming to, not end of life cycle necessarily, but at least to time for renewal. So a few months before renewal, I start getting calls from organizations saying that we really want to look at this. We want to look at is it time to move this or that to the cloud? So that may be happening in your organization. And if so, please be aware, be ready for that. A few months is seldom enough to move anything of significance to the cloud. Keep that in mind. So start making your plans early and often. And in terms of the planning, I want to give you a framework for that plan here today. That's my goal of the next half hour or so is to give you that framework of how to plan. Mostly from a, not from a detailed technical level, mostly from a managerial level. And so a lot of managers, maybe they're not technicians, but they'll come to me and ask me about how they can steer the organization successfully towards the cloud. And this is the premise of that discussion that we have. And really it's a more or less elongated engagement, because any one of these things, I'm going to give you a few here, could be enormous in your organization. And as a matter of fact, while I'm thinking about it, I think it actually takes a little bit more maturity as an organization to go to the cloud then to continue to do things on premises, which may be surprising, a surprising statement to say you're here. But this just means that some of those maturity factors are some of the early stage activities that must occur in that path to cloud. It doesn't mean, oops, we're not mature, we're not going to move to the cloud. I wouldn't encounter any organization that I think I would say, no, you can't go to the cloud, you're not ready. And forget about it, unless you're just kind of writing it out. I'm speaking to organizations here today that are not just writing out the next few years, but really intend to be around in 5 to 10, 15, 20 years doing more of the same and more new and great things that they do. So some of the decision points around the cloud are here. The software model, you have to understand it. It's different. The pricing is different. The access to resources is different. The provisioning is different. The elasticity and all that. I'll go through this. But it's different. Development and quality assurance, what about that? Let's not leave that behind. That's pretty important. And as a matter of fact, those may be gateways to full on being in the cloud is to do some of that kind of activity in the cloud. We'll discuss. Recovery from outage and credit for downtime. Yeah, that's different. You can't just have internal challenges, performance reviews, etc. Whatever you have today for your on-prem, oops, that shouldn't have bounced. Whatever you do for your on-prem outages when you move to the cloud, it's different. Your recourse is through the cloud provider themselves. And so we'll talk about that. So you need to know some things about that. Capacity planning and growth, that's different. Now, when you move from on-prem to the cloud, your need for capacity planning and growth diminishes in a lot of ways, but doesn't go away. Because you're still picking your resource levels from many of these services that you're going to be picking. So it doesn't completely go away. As a matter of fact, just knowing the size of the bread box going into a new application is actually pretty important in making sure that you develop it correctly. So anyway, security and privacy. This is probably number one in terms of the conversations, in terms of the hold back if you will, from moving to the cloud. So we'll talk a little bit about that. Disaster recovery is another of the gateway drugs to full-on being in the cloud. It's a good way to start. For some people, they do it the exact reverse. As a matter of fact, if you think of a scenario out there of hybrid cloud, okay, hybrid cloud, some things on cloud, some things on-prem, if you think of a scenario, it's actually happening out there for sure. For sure another organization is doing it that way. And it's all going to be in the execution from that point forward into whatever plan that you make. So there's not a right and wrong here, but there are some things that will get you there faster. We'll go through all that. Disaster recovery might be one of them. Query performance and service levels. People worry about the performance of queries, the service levels of the databases with the data in, how's that going to respond to my users. That's a big deal. And I'll give you some hints when we get there. Data interchange in the cloud similarly. If you're going to be moving data down, moving data up on a frequent basis for various things, there may be some costs to pay for that. So you have to take that into consideration. A lot of people get into the cloud because they don't have to pay for resources that they're not using. And that sounds good on the surface, doesn't it? And I think it is good. Don't get me wrong. But if you're just overpaying or paying a very high price for it when you are using it, and it all kind of nets out to be more, then you haven't gained anything. Now I'm not saying that's the case with most cloud implementations, but I can say definitively that if you don't architect well for the cloud you will not gain the advantages, and you actually possibly will be paying more for it. For example, compressing backups is a way to save oh, 20-25% of the cost of doing the backup. And that's just one thing. There are many tips that you're going to need to know to fully realize the benefits. And I also find that organizations that are not doing one of the ten things, you know, the compressing the backups, let's say, are not doing one of those things. They're probably not doing the others as well. They haven't stepped up. They've locked and loaded. They're on-prem to cloud, and that may or may not have been appropriate. And they're not getting the benefits of the cloud. So you don't want to go into it without that kind of knowledge. Staffing levels are not zero. What does my staff still do? Yeah, that's a big question. They do a lot is the answer, and there's a lot more for them to do and for a great IP professional to do. So this is another big deal in my work moving organizations to the cloud. And I do find that in many organizations dealing with the people issues is as important as dealing with the technical issues. So I'll give you some tips there, and they fall under the program of organizational change management to bring people along with the move. And let's pick some first targets for the journey, or I should say some next targets, because we're all there to some degree in the cloud for what's next. So I'll help you with that. The software model. Now just about any software, including databases, and if you've been exposed to me, you know that's my background, that's my passion is enterprise data. Obviously a lot of that's going to be stored in databases. So there may be some antidotes here from that world. And I would say while I'm thinking about it, moving to the cloud as I said before I think it's one of the key things that's going to define an organization in the future. One of the key things that's going to make an organization viable. I think there's some other key things, treating data as a key asset and security. And they all work together, don't they? They all work together. There has to be some great vision over the top of all of this to make sure it is a successful, I'll say journey to the future. Today several platforms were born in the cloud. A lot of the software we use, Salesforce.com is a great example, right? There's no on-prem aspect to it at all, at least that I'm aware of. But others have done a major engineering effort to their on-prem solutions and they work very well in the cloud. They do get a lot of the benefits of the cloud. The rapid provisioning, the charge back, the access to a wide variety of resources, the rapid elasticity of course, and the pay-as-you-go kind of an approach. So let's not say that a piece of software that was born, let's say a decade or more ago, previous to the cloud era is not great in the cloud. It certainly can be. You have to look at the cloud. You have to look at the factors of the implementation. So what I'm trying to say is that many software, much of the software that has been put into cloud does give you the rapid provisioning, does give you the rapid elasticity, does give you access to a wide variety of resources, the charge back, the service levels, etc. that you would expect. And by the way, those things that I'm mentioning, and you figure out what it is for you, but those things are absolutely imperative today for any enterprise level application. Whoops, any enterprise level application. So it's not like they are optional. There are a few other things that are optional as well. You can have security breaches. These are things that whether you say it or not has to be baked into any implementation of today. There's a lot of wiggle room there. You might have some wiggle room around performance. Maybe you don't need top tier millisecond performance out of every query. Okay, I'll grant you that. We'll figure that out. Performance is usually pretty important, but okay, on balance it may not be worth going and spending the 99th percentile for. But some things are and you want to make sure your platforms have those things embedded. Software comes with a wide array of integration with cloud from a licensing perspective. And of course you've all heard of infrastructure as a service, P-A-A-S and F-A-A-S. And usually by now, in the evolution of a term like these, I would cease to use it because it's become meaningless, but these still stick. And you can still classify the software out there, or the platforms or the infrastructure into their right categories. And these are them. And I think by now we know a lot of what that means. I do a lot of work not so much in the software as a service area, but more in the platform as a service or infrastructure as a service area. Okay, let's talk about development and quality assurance. So we're all excited about production and what we're going to do with our production. It's going to go into the cloud, but oh, yeah, there's development quality assurance environments. And some of you have more environments than that that you have to deal with in the development cycle in your SDLC, if you will. So what about them? For some of you, you're going to move them first to the cloud because it's less critical and keep your production on-premises. I can definitely see that as being a great stepping stone to that future of everything in the cloud. For others of you, you're going to say, well, I want to keep my development quality assurance as it is. And it's really production that we want in the cloud. That's what's really important here. That's probably 90% of the importance in moving to the cloud. So let's move it. And there's definitely a scenario there for that. If you learn one thing today, it's that there's no one size fits all. You have to think about a lot of things to make the best plan for you. And I want to plan, whoops, there we go again. I don't know why it's doing that. I want to plan this actually going to work in an organization because I really believe in a movement to the cloud for you. And I know some of that means that I as a consultant for this stuff have to impose my will on the situation. But also on the flip side of that, sometimes I have to go with the flow of what's going to work in the environment. Pick your battles and so forth. You've got to have the same mentality as you try to level up your organization into the cloud. Development quality assurance is an area to think about for that. Now let's understand the pricing a little bit. And I'm going to bring in some specific examples from my practice into this part of the equation. And in some trial runs these were the most important sides for a lot of people because it's kind of eye-opening. The first thing I want to press upon you is the first bullet there. The price performance metric is dollars per query hour. That's right. It's not dollars per node. It's not dollars per uptime. What is that database in this case? But what is that database doing during that time? And how is it? And I think you can get kind of sideways comparing prices when you're not comparing price performance. And so price performance really important. It's a normalized cost of running a workload. It is calculated by multiplying the rate offered by the cloud platform vendor times the number of computation nodes used in the cluster. And by dividing this amount by the aggregate total of the execution time. Sounds like a mouthful. Not a huge deal. I think you get the idea, right? It's how long does it take to run and what is my bill? What is my bill for running this workload? And so I encourage everybody to start to move into these cloud databases and other forms of the cloud. Try it out. Try it out. It's not like before where it was a huge deal to try things out. Now we're looking at business users that are looking at an IT situation where to provision a new server on-premises is going to take months and heartache and a lot of work. Versus, you know, 50 cents an hour to spin up something on the cloud. So you better be a great IT shop if you want to hold on to that kind of fork. That kind of on-premises fork. Otherwise you need to be flexible and go with the cloud options and help them into that and show that you're an asset in that environment. That is the environment that we're going to be working in. So to determine pricing, getting back to the slide, each platform has different options. And I'm speaking here of database platforms as an example. By the way, maybe it's because of what I specialize in, but this is a lot of what people want to move to the cloud. First, second, and third, it's the data. And once the data gets there, other things can drag along, but let's get that data there. And so we are thinking a lot about cloud databases like the ones I'm going to be talking about here. As a matter of fact, if you want you can go watch a rerun of last month's Advanced Analytics webinar in which I talked about this subject in more depth. Databases versus cloud storage versus Hadoop. And I'll leave it there. For Azure SQL Data Warehouse, obviously from Microsoft, you pay for compute resources as a function of time. Obviously this is on Azure only, right? The hourly rate for SQL Data Warehouse varies slightly by region. I'm most inclined to go with the closest region. However, based on my experience, I will change that time to time. But generally speaking, that's what we do. Also add the separate storage charge to store the data. It's compressed, but you're still storing it at a rate of some number of dollars per terabyte per hour. I will give you on the next slide I will give you the links to the various pricing pages where this information is. And you can see that there are some differences across these leading cloud databases that you want to be aware of. By the way, that storage charge is usually quite low in the grand scheme of things. But that's Azure. What about Redshift? You also pay for compute resources, nodes in this case as a function of time. Redshift also has reserved instance pricing, which can be substantially cheaper than on-demand pricing. It's available with a one or three-year commitment and is cheapest when paid in full up front. This sounds like buying many other things that we do that we buy personally. You have to make those kinds of decisions as well. Whereas before, it was a huge decision that you would make and then live with for quite a while. This is a little bit different but there are elements of that as well. The Amazons, the SQL servers, SQL data warehouses of the world and so forth they do want to know, are you in? Can you commit? If so, you can get some discounts. Snowflake, you pay for compute resources as a function of time just like the other two. There is one difference which is that they have some different flavors of Snowflake that you can choose from. Standard Premiere Enterprise or Enterprise for Sensitive Data and Virtual Private Snowflake. The costs for all of them except for Virtual Private Snowflake is posted at the pricing page which is found at the lower part of the slide here. You can check that out. I think it's the same code base. It's just some features are going to be turned off if you haven't selected one of the more advanced flavors or options. For example, Enterprise, I call that multi-cluster because that's the big feature there and that really helps out concurrency. Maybe that's why it's called Enterprise. That's what an Enterprise would go for. By the way when you're checking it out though, if you want to just check it out, you can get standard and save a few bucks and check it out. With Google BigQuery it's a little different. One option is to pay for bytes processed at a certain number of dollars per terabyte. That's a published number. There's also a BigQuery flat rate which is published. That's an all you can eat option and I understand that many of their customers do avail themselves of that flat rate. You can save, if you're actually really using it, you can save quite a bit by going with that but there's a bigger commitment level there again. There you go. Without using numbers here because that would have taken us down a path that I didn't want to go to today. Without using numbers those are the examples but nuanced ways that for example the cloud database market price is there where. You do have to understand pricing in your move to the cloud. Recovery from outage and credit for downtime. Now if this happens you can't go scream at the system administrators because they are not responsible. It's more the Amazon or Microsoft or Oracle or IBM or wherever you have your data that is responsible. However they give you a service level agreement. This is the famous on this billboard here is the famous Amazon one and I believe it's pretty recent and I was probably the one that's up there right now but if the annual uptime percentage for customer drops below 99.95% for the service year that customer is eligible to receive a service credit equal to 10% blah blah blah you can get something back. I have not in my walk come across an organization that has availed themselves of this. Of course we all seem to know about it when AWS goes down and I guess I've been lucky none of my clients have been in that boat. I've heard stories so I do know what happens but this is your recourse. Is it a better recourse than what might could happen internally holding people accountable? That's hard to say but this is the recourse. I tend to think it is it's more quantitative. You can factor it into your plans and so on if you want to. You can also look at their uptime and you can see that they well exceed this most of the time. Of course you may be doing that internally. I don't know in my experience though this is going to be better than most internal operations. Going back across my years of experience I can remember many times and I'm sure we all can. I've been around a little bit many times when there was outages and downtime in our on-premise situation. I used to run the data teams at enterprises and I ran production support. Back in the days of the beeper we would transition the beeper once a week and you would be if you held that hot potato beeper you would be on call. That's how it worked. Moving along from that nostalgia, safe harbor and cross border restrictions. You're going to want to know where your data is today and for multinational companies the concern about safe harbor and country border restrictions for data keeps many from going to the cloud and that's why we see quote-unquote clouds popping up in various countries around the world. We see GDPR and I don't need to belabor that here today. We could spend a whole section or a whole session on GDPR, global data privacy and this is in the European Union, real quick here for those who aren't aware, European Union and it features the ability of a citizen of the European Union to have their data removed from a company should they wish to do that. Without peril to the company by the way GDPR has been out for a few months now there have been fines. That's what it was all about. If you violate the restrictions you will have fines. There's been over 5 million dollars of fines something like 5.6 million but over 5 million of it went to one company. That's right one company Google. So I would say you can look at that as half full or half empty meaning it's a healthy number of dollars but mostly it's been small. However it's there for a reason we're going to see more of this. We see California now for example coming out with something similar to GDPR and we'll see how that plays out in other countries. Here in the USA especially for domestic based companies this may not be as big a worry for those of you in smaller European countries with obviously customers across borders easily so this comes into play there but everybody needs to know where their data is. Okay capacity planning and growth the platform should be able to grow or shrink. The platform should provision only what is needed. Yes especially if you're paying by the uptime as you saw before you will do that. Now for an enterprise data warehouse that's really important it's 24 by 7 for any European system that's 24 by 7 for the myriad of systems in our organization that are 24 by 7 that's not going to factor in that uptime down time charge for example. The platform should provision only what is needed and by the way this provisioning if you really want the benefits of the cloud and I said it before rapid elasticity is one of the important benefits of the cloud and it actually is a must-have today as you go forward into the cloud you are going to need it if you're in an enterprise. That is just the dynamic of the organization today so if it takes it should take minutes to scale up or down and create little disruption for migrating or repartitioning otherwise one of the key benefits of the cloud is lost it should not take hours it should not be a big stepping stone it should not be like a oh I don't know what's the analogy I should not have to walk up stairs and every time that I want to make a change it should be a very tiny step or something that is maybe a moving walk way where you're just continually moving forward and you don't even know the more proactive and involved the customer has to be in the process of resource determination the less elastic the solution is. I would prefer not to have to talk to Amazon when it when I get a when the cluster gets bigger or smaller. I prefer not to get on the phone I prefer not for it to be a war room for it to be a big meeting or a big deal and truly it's usually not and it doesn't have to be and so that is your goal going in so set yourself up for that Now what about security and privacy? This is very related to what I said a couple of slides ago about the safe harbor and cross border restrictions but these are the largest areas of concern today with the cloud you need to do your homework with your security policy and this can be quite a bit involved but one of the things that we start with is what kind of certificates does the provider have and what kind of certificates are important for you in your industry there are those in healthcare, government, obviously financial etc so that takes you a certain way down the path of comfort with the vendor but there is obviously more to it than that and just as a breach can occur in your data center it can also occur at cloud hosting data centers. Yeah it can occur obviously breaches can and do occur at AWS, Azure, etc etc so you have to be prepared to deal with it and your customers largely will be uncaring that it's their fault versus your fault so you have to be prepared to deal with it as if it were on premises and once again we're bouncing slides. Okay disaster recovery. I alluded to this before so let me go into it a little bit more here. It's something that is of digestible cost usually it's just going to sit there and going to receive data on a regular basis and sit there. There is room to scale and it's a good fit for dual purpose and it's practically maintenance free so when I have an organization it's really struggling to move anything of significance to the cloud and I'm not getting anywhere. This is one place that I'll go to help start that transition and I believe that the first step is the hardest and you will see this throughout my consulting work and so on where I'll encourage somebody to well you know what would be the first thing that you would do if you wanted to get this report done would you start a word file and maybe put a heading on it. Okay let's do that and things start to naturally flow from that and this is disaster recovery for you. Not that disaster recovery on the face of it isn't important it certainly is but it's a great place for your data and maybe you want to put your data in for example external tables like S3. Keep in mind that those databases that I just talked to you about they can use S3 as external storage and not that this would be relevant for disaster recovery necessarily but that those tables can be in Parquet, in Ork, in CSV, in Avro in all kinds of formats and so one way to save money getting back to that in the cloud is to put the colder data out there on S3 and to just attach to that as external tables. You can be doing other things with that data on S3 if you want. I keep using S3 as an example but maybe it's a bad example but there are other cloud storage options out there for you. Clearly Azure has a different one, clearly Google has a different one but my point is cloud storage. Now query performance and service levels. Cloud query performance will depend upon the same factors as on-premise query performance. You can't just, I mean you don't, how do I say this? I really want to impress upon you that and I said this a little bit earlier you can't just drop anything in the cloud and expect it to perform. You have to not only tune it for the cloud but it has to be well tuned on the face of it to begin with. Some people asked me the question I think was last week does our data have to be in a dimensional model? Well let's talk about what you mean by have to be in a dimensional model. No, it will function. If you put it there for ad hoc analysis in a normalized, excuse me model it will function. Will it perform to the best? That will depend upon many things, some things that have to do with the cloud but other things have to do with the design of the data model and dimensional in my view is the best for interactive access. So you probably will want to. Do you have to? Do you have to go through the, oh I don't know, few hundred hours of person time to redo the model? Well there's a cost associated with that and so forth. Generally speaking though you probably want to keep to all those great design standards that you have for your analytic and your operational environments when you move to the cloud to get the best query performance and service levels. And we're coming upon data interchange in the cloud. And this is probably the thing I want to impress upon you about this which is something to do with the best laid plans. I think a lot of times we design our applications such that we think they're going to be all in, all encompassing and self-contained. Self-contained. And then we get to points in the application development process where we look around and we see John over there seems to have developed something that we could use and either I could rebuild that or I could use that. Maybe I need an SLA to what he's doing. And that's where leadership can really step in and help out. Ensure that this happens. Ensure that they're sharing. Ensure that you're building for sharing in the first place. You want to build your applications for the cloud for sharing in the first place. Meaning that knowing that you may not foresee the details but knowing that there will be interchange back to on-premises for certain things. And there will be non-standard meaning not just the nightly batch update, not the trickle feed, but there will be other things that you'll want to push up there. And you want to be aware of the cost of that and the cost of loading the data. And some of the databases I talked about like Google Cloud there's no charge for loading the data. They get it all on the query side of things. So that's okay. But there's still time involved in work involved in doing that. So you want to be prepared for that. I definitely wanted to spend some time or leave some time and leave some impressions upon you about staff. Because these are still sort of relevant things. What is the escalation for production failures in the middle of the night? Now the hardware going down probably that's not going to happen or be in your control or in your purview. But the application's surely it can go down. Google didn't write your application. Amazon didn't write your application. You wrote it. So that's coming back to you. So what about that? Is that still a thing? And does everybody have access to do what they might need to do? And middle of the night is sort of proverbial these days when a lot of things are 24 by 7. So I really mean any time. Who will manage hardware and software patching? Just make sure the vendor should be doing this. The cloud vendor should be doing this. Just make sure it's going to be done. Understand the philosophy that they are undertaking to do it. Is it as soon as it drops? Or is it after they've tested it? Or is it after it's been out a while? Okay. A lot of times you can't affect, you can't change that. But knowing that will come in handy when you're talking to your vendor and they said oh well we just put that bug fix out there last week. Or that feature is dropping next week. You'll know you won't be getting it for three weeks or you're going to get it as soon as the album drops. It's going to come into your iTunes. You're going to figure that out. Figure that out. How will we make the call? Or spend the budget for additional whatever as the implementation grows. You're going to get a monthly bill from these guys. But you can watch it daily if you want. You can report on it internally daily if you want. I have clients that do this that keep a close eye on it. By the way, this brings up a point that I want to share back which is you can't be looking for ROI in every little thing. You have to have made the big hairy statement about moving to the cloud and then the things will fill in. And on a day-by-day basis there can't be ROI expected on the day-by-day decisions if they are progressive towards meeting the bigger challenge which is moving to the cloud. Now the roles for the staff depends upon the piece of code. Software as a service. The user company owns who keeps bouncing on me. Who can have access to the software? For platform as a service, since the vendor is responsible for the infrastructure you need to design with those parameters in mind. For infrastructure as a service there is much more responsibility back on you including managing the network, the service, the disk, the patching, encryptions, backup, logging, building redundancy, etc. What have you. So no free lunch here but there are some better lunches than others in terms of the workloads. So it's all about a big balancing act as I like to say a big leadership act. Organizational change management. This is very important. I only have one slide on it but this is the program to bring the staff along with this move to the cloud. I get pushback a lot on the progress that I want enterprises to make. The time frames the urgency factor of what I feel is important to a client. You may too. You may too but you need to bring other people along to some degree. I believe that given the chance most people will come along with the move despite sticking their stick in the ground and dragging things out and just being the proverbial stick in the mud in terms of this move to the cloud. It happens. They're great people. I feel like they'll mostly come along. If this is going to happen, if the move to the cloud is going to happen, if that person is not going to stop it, then it's in their best interest to get on board and it's in everybody's best interest I think to help them get on board. So I really am passionate about this, helping people come along with these big moves. They may hate me at first. They may hate you at first, but it's about the move. It's about really a career enhancing move. It's about the future. It's about being part of that future. That inevitable future. Do you believe that if you're moving to the cloud, you must believe that it's inevitable? I certainly do. And so I think it's in everybody's best interest to get on board. So it's a big change for people. It's the biggest change in our career as technology professionals of a certain age. It's the biggest change in our career of this on-prem, everything on-prem to eventually everything in the cloud. Stakeholders of the cloud move come from various parts of the organization and beyond. Job roles will change. Stakeholders must be trained to behave differently. Communications around status and dates are essential as well. Your cloud moves must have a focus beyond technology and address these people related risks. Now a program of organizational change management includes things like stakeholder analysis, includes things like changing job roles, includes things like organizational readiness, okay, training, desk side training potentially. But there has to be some teeth behind the move, but it has to be done in the right way. And this is where leadership comes into play. Anybody can come here and give you the ABCs of this stuff. But implementation is longer than it takes me to read a slide. Implementation of this is multi-month potentially when you're talking about organizational change management, it could take potentially quarters to get the organization on board with such a move. And in my experience a lot of times it's people in IT roles that are the ones that are the hold backs on moving to the cloud as well as agile as well as other things, big data, et cetera. And that's okay, it has to come from somewhere. We just have to be ready to deal with that and enhance these people's careers, help them be successful in this new world and help them become assets to this program. Okay, I said bandwidth finally. You know, this is something that doesn't have anything, well, doesn't have a lot to do with the cloud provider. We can talk all we want about the benefits of the cloud. We can talk all we want about performance of queries and performance of moving data up and down. But one critical factor resides squarely on our organizational shoulders and that's bandwidth. And I'm not the one to, I'm not a network administrator consultant, alright, but they are important in this process. The cloud can get a good or bad reputation based on this factor. And with cloud acceptance you naturally stop drinking your data out of a tiny straw. If that's what you have, you're going to have to work on that and fix that first. It's well worth it. It's not a knockout factor. A lot of people come across factors like this oh, we're not ready. Oh, so and so says the cloud is not secure. Our bandwidth is not good. Okay, those are things to be fixed. That's your phase zero of your program. Just build it right in. A lot of people think, well, you know, I'm tasked with moving to the cloud. So, you know, set the table for me. Make sure everything is ready and then I'm able to step in and do my job. Well, your job is to pick up the ball wherever it is, however the organization looks today and make it happen moving that forward. And this is where I keep coming back to that word leadership. You might have to get involved in things that you're not really, you're not trained in. I'm not trained in network administration. I've learned enough to be dangerous and to I guess steer that ship a little bit to make sure that the rest of this program is going to work. And that's what you may need to become as well. So, don't shy away from that. Keep the end goal in mind. That's your goal. So, let's pick some next targets for the journey. The right amount of criticality. It can't be something with that's a nothing burger that's not really going to do anything. Pick a manageable problem that you can solve. Consider technical integration points of the application with the legacy environment. So, if there's a lot of interchange points, those can take up the complexity in the time and the cost exponentially. So, you want to find things that are somewhat isolated. Have a strong executive sponsor. One who puts clout behind the project. Yet understand perfection is not possible. Not someone that's going to chop your head off at the first sign of something going wrong. Something will go wrong. Hopefully it's nothing big. But that's all part of the journey. If you're not making small mistakes, you're not moving fast enough. Get help. Get experience. Get some people in that have done this before. That have had similar journeys. And don't necessarily make sure that it's all been 100% successful journey. It's great for them to have gone through some trials and tribulations already. And remember, we're all kind of new to this. So, take that for what it's worth. Now, there's more maturity in moving to the cloud imperfectly than in merely perfectly defining the shortcomings of the cloud. So, let's not stay on the outside of this issue. Let's get on the inside of it. Especially for those companies out there that had that cloud mandate. Let's put some teeth behind it. Let's put some definition behind it. Build internal credibility in the team. This is going to give you the ability as the leader of the cloud movement, whatever it is. Maybe you're leading the organization. Maybe you're leading a department. Maybe you're leading an application. Maybe you're leading data or a piece of data. Or a piece of software. Okay, whatever it is. That leadership. You build credibility so that the organization will defer to you and you do have the enterprise needs in good hands, right? That's you. You do have the enterprise needs in mind, right? The organization must know it's well taken care of. And this is the team that will do that. Your team. Don't talk yourself out of starting. I belabor this a little bit. Remember the term phase zero? When you're encountering things out there that would hold you back because you didn't think about them or they're not in your purview. Just remember William said phase zero. That is part of my purview because I have this goal in mind. Success is not perfection. You cannot accurately predict activities for two to three months out like in detail, okay? Let alone six to nine months. However long it takes. Get started. That resistance to the cloud is not about being there. You've already decided you want to be there, okay? Let's get there. But it's not about being there. It's the path. It's the right team in place. It's their ample communication. And of course all of the 10 factors or however many factors I went over today are all of those taken care of. That will smooth your transition to the cloud. And with that I'm going to turn it back to Shannon for any questions that we may have while you look at this slide and see that we're going to be back here the second Thursday of next month and every month thereafter. William, thank you so much for this great presentation. As always just love it and to answer the most commonly asked questions I will be sending a follow-up email for this webinar by end of day Monday with links to the slides and links to the recording of this session. So diving, if you have questions feel free to submit them in the bottom right hand corner in the Q&A section. I'll see some questions have come in. So you talked about this a little bit. What would be the basis for choosing a multi-cloud strategy? Well the basis that I hear the most about this is to hedge your bets. So you're not completely captive to one of the cloud providers. What I haven't heard a lot of is that I want to go here to Azure because they have things that aren't over here in AWS. Although that is somewhat true I think it should be more true. In other words like I'm in the database space as most people are aware. So if I'm looking at databases if I want Azure SQL data warehouse in the shop I want Azure SQL data warehouse in the shop because it's going to be the best. Well it's only available on Azure and we're in AWS shop. I think there is a conversation there to open that door to having multi-cloud just right there. If that is the best and I'm not saying it's the best every time but if that is the best for that given situation. Are you able to speak on FedRAMP compliance? I am not. It's very pretty specific but I'm not sure we can find some stuff on that. As we're diving in here currently a little bit further do you have a strategy a surgery excuse me. I have had surgeries. Yes I have. Well that's actually what it says. Do you have a strategy or give tablet first and keep monitoring when it comes to resource allocation in the cloud including bandwidth. Can you come again with that I'm sorry. I'm trying to I think so do you come straight way for one actually let me just ask the question or if you can re-type that comment and question see if we can get that in there. So let me jump to the next question here. So will the underlining security framework of cloud impact the query performance as well? That's a good question. I've done a lot of performance field testing on these databases. I have not considered that that would impact performance. What I've done is thrown workloads at databases at streaming solutions at APIs at embedded databases at data integration tools etc. and seen how they performed and each one of them obviously comes with a different set of security approaches but I can't say that I want all the security I can get. And that is a factor that could override performance obviously and then make performance a secondary consideration. I think the vendors all want to get as many security compliances as possible on that basis. Even if it were to slow down query I cannot see them being connected. I've been a database engineer in the past. I can't see that as being a major factor in that. Sorry for missing something on that. Sure. And do you consider alternatives to the current software? For example Data Lakes and NoSQL on a common basis to the current on-premise data warehouse solution? Well I see as an alternative to the current on-premises data warehouse solution to be a cloud-based data warehouse solution that's also in a traditional database like some of the ones that I mentioned in the presentation. So that is the transition that we're helping organizations to make but well beyond the data warehouse there are many other platforms that make a ton of sense inside organizations. Many other analytical, many other operational systems that make sense. The whole is NoSQL still relevant you know that's a whole mouthful there conversation. So I'm not sure that we want to get into that but a lot of the databases I will say have absorbed a lot of the functionality that NoSQL databases had especially early on in terms of being able to deal with JSON data for example XML data some of the other data types. So there are definite alternatives in making that decision. So I would ask probably you know my top 20 questions and then we'd get somewhere on that. Sure. Okay so it really is. So do you go for surgery straight away on the day zero or give tablet first and keep monitoring when it comes to resource allocation in the cloud including bandwidth? Ah I get the question now. Okay. The part of it. I don't like surgery for myself or for my clients so I prefer a more measured approach but you know some organizations frankly they're so far behind that they need to jump some cycles and they need to take some big leaps or they're just not going to be around. They can make the decision to kind of not do anything and write it out and I think people start to become aware that that's what you're doing and that's not so fun. Or they can be doing things and sometimes that means swinging for defenses and a lot of times that means you don't have the right people in place or enough people in place or the right skills in place to make that happen. So I'm not opposed to it in certain cases. I will say that the way it's come down in many organizations is a little bit more of a measured approach but you know there's a spectrum there. There's a spectrum. There's no one there. It depends upon your circumstance, what your goals are, what your industry is doing and how far ahead or behind you are of that curve and what needs to happen. So I use a maturity model and I think this may be a future presentation but there's five levels and I'm telling everybody that they need to be at level three if they want to be a sustainable organization and that the levels keep changing. If you've heard me talk in the past year, you've already heard me say stuff like this but you know the levels keep changing. You've got to level up and you've got to be sprinting to that level three just for sustenance. Level up for market leadership. That's a four or five. So let's talk about what your goals are, where you are and that'll dictate how fast we want to move. I love it. Such a good question. It's all in the reading. Well, William, thank you so much for this great presentation and thanks to all of our attendees for being so engaged in everything we do. We just love it. Again, just a reminder, I will be sending a follow-up email by end of day Monday for this presentation with links to the slides and links to the recording. That's about it. William, again, thank you so much. Thanks everybody. Have a great day. Thanks, William. Thanks, Shannon.