Okay, no, maybe it's the other one, should I try the other one? Okay, no, still not. Yeah, okay. Yeah. So when I have two, six, ten, it's clear. Okay, great. Thank you. Okay, good afternoon. Can you hear me okay? Yeah. Okay, so I promised you a Kubernetes tutorial. So first, I'm Mia Culver. I suggested I would give you hands-on access and so on. And I just realized when practicing with people in a two-hour situation that this wouldn't translate to a one-hour session. So I'll really do it in mode tutorial of doing things and showing you what I'm doing. But if you want to follow along yourself, either you've got your own Kubernetes cluster already or you do it after the event. Okay, I hope that's okay for everyone. Okay, so I'm Michael Bright. I'm a developer advocate at Containers. Containers are the creators of traffic. Some of you may know it. It's a reverse proxy load balancer and can be used as a Kubernetes ingress controller. So that's something I'll be showing as a demo. Just out of interest, what's people's experience here with Kubernetes? Are you all fairly new to Kubernetes or are some people... So who is totally new or pretty well to Kubernetes? Yeah, okay, good. You're the people I'm aiming at, that's fine. And just out of interest, is anyone here using traffic to use traffic already? No? Do people know about traffic? No. Okay, if you haven't. Good, thank you. I just say this tutorial is open source. The initial version, which was Swarm, Kubernetes, and MazeArts we've run about three, four times. And now this is the third or fourth time after I've run the purely Kubernetes version. And it's all on GitHub. And you're welcome to open any issues on it or just send me feedback directly. I'm keen to have this evolve. Okay, so this is what we will be covering. Basic concepts of Kubernetes. The basics, the command line client. Then we look at running pubs. So if you know about containers, then you know that you won't know. The basic unit of execution within Kubernetes is a pod, which is one or more containers. So look at that concept and running pods and what we call deployments. We'll look at how to perform a rolling upgrade across our cluster and then how to expose our applications as services. There are several ways of doing that and I will show just one way, which is ingress controller. And this time, which we'll very quickly just talk about Helm, which is quite an interesting tool for Kubernetes. If you want to do this afterwards, then there is a page that talks about setup options for just simply running your own cluster. The simplest way, of course, is to run Minicube. Minicube being... It used to be just a VM for running Kubernetes as a single node cluster within a VM. It's also a non-VM option as well, so you can just run it with the Docker to simulate a Kubernetes cluster. Just one thing, so you'll hear me talk about traffic and so on. I mentioned that I work for containers for the creators of traffic and we're hiring, by the way, for remote workers too. Okay, let's get started. Okay.  Mainly, I'll be doing it within the Jupyter environment. You don't have to worry about what that is. It's basically a notebook where you can mix markdown and executable code, so it's quite a nice way of documenting things as you go along. So I'll start with some slides and then go back into the notebook. So Kubernetes, first of all, what is it? I mean, it's basically a cluster manager managing a cluster of containers. It could be a whole data center that you're going to manage with it. The principle, of course, is that as we move towards microservices, we've got more and more containers running in our data center and it's becoming impossible for operators to take care of all the little details of deployment and you really need some sort of deployment platform which is going to allow you to say declaratively, okay, I want these services running. Kubernetes, go away and take care of where they actually run, okay. I do want that platform as well to tell you, okay, there's a, well, no, I don't even want it to tell you. When there is a problem, I imagine maybe a node of a cluster that goes down, that would be a physical node or a VM or a pod, a container, goes down. You don't even want to be informed. You just want Kubernetes to just relaunch neural resources in the place. So if you know about Cloud Native and the discussion about pets and cattle in the old world, all software and VMs tended to be pets. If there was a problem with the VM, then you would go in and try and fix it and do your best to care for it like you would for a pet, whereas here we're much more in a scenario of cattle where container dies, then you just launch another one in its place. Okay, very different philosophy where we tend to declare what we want to be running on our cluster. So historically, Kubernetes, it's an open source project that was created by Google. It was based on their experience with deploying containers within their infrastructure, so notably the internal projects of Borg and Omega. They really wanted to bring those same principles into an open source project. They donated this to the CNCF, Cloud Native Computing Foundation in 2015. And a lot of companies bought into that as a container orchestration platform. And it's currently at the 1.9 release, surely 1.10, obviously. Okay, this is just a Google Trends just showing the tendency of the different container orchestration engines. There are more, but I just compared Docker's form, Apache Mesos and Kubernetes. We can see quite easily that the blue line, which is Kubernetes, was just taken off completely. And in 2017, we've really seen the effect of that with some surprising or not announcements from Amazon. Everyone was expecting them to launch Kubernetes services, and they did that with their EPS and also Fargate services. To me, more of a surprise was Docker when they announced at DockerCon that they would support Kubernetes as an alternative container orchestration to Docker Swarm. We've seen new managed Kubernetes services. This is where you will pay to use basically a Kubernetes control planer dashboard to deploy a cluster in some other infrastructure. It could be out on Amazon EC2, for example. It could be on-premises, actual physical nodes on your site. So we saw new services launched from Microsoft and HPE, and no matter how many others, they managed Kubernetes space. There are many other distributions. One of the early adopters of Kubernetes was Red Hat. Their OpenShift pass is based implicitly on Kubernetes. Others have been, well, CoreOS with Tectonic, who have just been bought by Red Hat. Canonical also have their distribution. And we see new tools. There are many, many tools appearing around Kubernetes. There's one which is looking particularly interesting today, which is Hell. She essentially is a sort of allows you to create whole stacks of applications, a bit like a stack with Docker swarm today, but also with a catalog of applications that you can pull down, or full stacks that you can pull down. Okay, so if you look at the Kubernetes architecture, this is a bit small, this diagram, but it's really just to show three things. Basically, we have master and worker nodes, normally, in production at least, it's on the worker nodes that you actually run pods with containers in them. And the master node is the, or the master nodes are the control plane nodes that will monitor the workers and distribute tasks to the workers. There's also some sort of distributed key value store, so ETCD, which is used to manage the configure cluster, and in particular to say which of those masters, there's only one here in this diagram, which of them will be the leader. And so this is something that I don't know to what size Kubernetes clusters scale today, but essentially, as we're talking about, you might have a whole data center, or you might have several clusters in a data center. So if you look just a bit closer at the master nodes, there are three main components within a master node, apart from the ETCD itself. The API server, so most things you'll do with Kubernetes will be either using command line tool like QCTL, or the dashboard, or some other application built on the API. That is the way that an operator will interact with the cluster. There's a scheduler and a controller. So as I said, Kubernetes is very much based on the idea of declaring what you want to be running on your cluster. It's very much a declarative approach. And in the same way, the controller is actually, think about, 50 software control loops, each of which are checking some particular aspect. And they notice a discrepancy. Let's say you declare that you want 10 replicas of the Apache web service. For some reason, there are only nine. A part has died, or a node has gone down, and so on. The controller will detect that, and it will tell the scheduler, okay, we need one more Apache web service. The scheduler then, based on constraints, if there are any, will then decide where that new Apache web server should be deployed, on which worker node. Are there any questions about that? So if we look at the worker nodes, a few more elements in there. So the main contact point is the Kubelet. So this manages the API that the master node will use to talk to the worker nodes. Obviously, there's a container engine. So typically today, it's Docker, but Rocket is already supported, and we're seeing the creation of new container engines. So there is a specification, the CRI, Container Runtime Interface, which has also been used by Docker already. And Red Hat have created one constanciation of that CRIO, which then provides a new container and time. So who will see choice in that area? The Kube Proxy. So Interwack pods first. The pods, as they are one or more containers in each pod. They are on a separate network. So to get access to the actual application and running those pods, the Kube Proxy is the one that will provide the routing onto those internal networks. There are various add-ons like Kube DNS to allow service discovery and so on. And there's the dashboard, which itself is an add-on. And in fact, all of those elements themselves can run in containers on a Kube system, as we will see. So the pods, I said one or more containers. So the philosophy, just as like with containers, the philosophy is really to have one or more containers in a pod. In a pod, sorry, I meant one or more process in a container. In the same way, a pod will have one or more containers in it. But the idea is that you should have, you know, one principal functionality provided by this pod. And if there are other containers, they should be providing some supporting function to that main container. So for example, I don't know, could be Apache Web Server again. Maybe another container, which is maybe Fluent D, maybe doing some distributed logging to elsewhere. Or another good example for a web server, you might have a container which is doing a Git repo sync. So it will be pulling from a Git repo any updates, which are actually the static content of the website that you're serving up. So those are two quite distinct functionalities, but the Git repo is supporting the main web server functionality. And those containers, okay, share namespaces. So these will have different process IDs within them. They will have the same IP address. They're sharing the same IP address and they mustn't use the same ports and so on. So it's an abstraction which is a little bit like a machine, in fact, conceptually. Oh, and an important point is, as I say, a pod will be one main functionality and then some supporting functionality that really tightly linked. And the idea is that as you scale, this is the minimum functionality that you want to scale. I want to scale from 10 to 20 web servers. What I need, let's say the Git repo associated with each of those. So we'll see in a moment the command line client. I've heard about how they sort of are working from the command line all the time. But I should try and come back to the dashboard as much as possible because it's a pretty nice dashboard. So let me, rather than show you slides here, let me actually launch that dashboard. So, okay, Kubernetes dashboard. First thing to notice is within our cluster, we have three namespaces. When we run, we can create new namespaces, of course. When we run new pods by default, they will obviously go into the default namespace, so which is empty for the moment. I've not created anything. Other namespaces are kubepublic and kubesystem. But if we can change into kubesystem, and there we see already that there are some things deployed, kubed DNS, kubed dashboard, so the dashboard is showing itself in the system there. We can interrogate, obviously, the number of, well, replica sets, which haven't presented as a concept, and pods. So in fact, all that is a set of pods that represent our Kubernetes cluster itself. And in this example, I'm running a three-node system, one master, and two worker nodes default. If I go back there, it's like I didn't do cleanup. Okay, so as I mentioned, for this part of the lab, I'll be working with this three-node cluster. It's actually a complicated environment, so later, when doing ingress control, I will switch to another mini-cube-based environment. But I wanted to show it working in multi-node. Okay, so let me just do some cleanup. I see I did still have some things running. The advantage of the notebook is that it keeps it historic of everything I've done, so it allows me to archive with the whole tutorial. But to run it, it'd be better, I'd clear stuff. So I mentioned the command cube-ctl. Normally, I'd spend, or cube-cut all. Normally, I'd spend time just showing a bit of the option so that, but I really want to try and keep them to one hour. So I do a cube-ctl get all. So basically, with get, we can interrogate services, deployments, replica sets and so on, which we'll be seeing in a moment. If we do all, it will give us those types of resources from the start. So if we look at the most basic way of starting pods in the Kubernetes cluster, the quick and dirty is cube-ctl run. And what this does behind the scenes is it creates something called a deployment, which itself creates a replica set, and then will create pods that will actually implement our application. So what are these concepts? A deployment represents essentially a deployment, so a deployment of a particular version of an application. And we see that when we do a rolling upgrade, this is the resource that will take care of upgrading from one version of an application to another. It creates a replica set, which is responsible for obviously creating the number of replicas that we asked for. And in this case, I specified replicas equal to, so we have two pods. Of course, at a lower level, then each pod will have one or more containers. So I'm going to do a cube run of this image, of this image, K8S demo, Cologne 1. So Cologne 1 is standard Docker image notation saying it's version 1 of this image. This is basically an created deployment called the same thing, K8S demo. I'm going to apply a label. I haven't talked about the concept of labels. It's something that's very important in Kubernetes. Essentially, Kubernetes already applies labels to various resources, and you can explicitly apply labels. And it's a way of marking things. For example, if you're running on the same cluster, you're running development pods, test pods, staging pods, and production pods. I don't recommend it, but if that's what you're doing, then you could label, okay, I'm launching this just as a test, and I would say, you know, status equals test or something. And it would be a way of, later, if I just wanted to clean up, I could delete just the test pods, for example, not touching my production environment. Generally, labels are really useful. Another thing is imagine the nodes in your cluster. You might have nodes with particular physical properties. You might have nodes that have a GPU, a graphics card, particularly good for high-intensive compute operations. You might have nodes that have SSDs, others that have disk drives, and it would be useful for different types of applications. So you could use labeling to then select and say, when you run a pod, say, okay, I want to run this, only on nodes that have a GPU. Anyway, just to explain labels. As before, I will say we want two replicas, and I want the pod to expose port 8080. I'm going to do a kubectl get-all immediately behind that just to grab it in an intermediate state. Okay. So that first line deployment Ktest demo created, that's the output of the run command. And then the get-all curiously lists the deployment twice, and the replica sets twice, but I'll start looking from here. So it's launched a deployment. It says here, desired two. It's saying that basically we want, I think that's pods rather than containers at this level. We've declared that we want two replicas of this pod. There are currently two. It's already launched them. They're up to date, but zero are available. Similarly, the level of the replica set. There are two of them, desired and present, but zero are ready. If you look at the pod, we can see why. It's in the status container creating. Typically, it's actually pulling the Docker image off the Docker hub. Proving up the case in this example, so I'd already done that, but still there's a little time of container creation. And here, they're ready. We have zero of one. It's actually telling us that's zero containers out of one, desired. A particular pod specifies only one container. Okay. Oops. Okay. I'm going to run that command again. It will be basically the same, not the most prompt, except this. Now we see two available, two ready. And of course, both pods are running with one container out of one. Okay. Just to show an example of the sort of input we get with the QCTL. We can also explicitly interrogate the pods deployments and so on. And with get pods, taking the option wide, we get just a little more information we had to hear before. This is the IP address of the pod that's created. And this is obviously the node on which the pod was assigned. So normally you run pods only on the worker nodes. Though if this was a single node cluster, it would only have a master. So for development purposes, you can taint a node, allowing that to run pods as well. But if you were to scale to 10 pods here, we would see that they would all be distributed across the worker nodes, node one and node two. Interesting as well. Okay. I can see the nodes we have here. What I'm going to do, so there's a command called describe, which gives much more detailed information, a lot of information. If I look at those nodes, we can see the actual IP address of the nodes themselves. And we can see that, well, I know that these are slash 16 subnets. Knowing that, we can see that these are a different subnet than the pods. And in fact, I think that every deployment we create creates a new subnet specifically to those pods. Okay. So how can we access our applications? I'm going to use that information about the IP address of the pods. Again, this is not how you do it, but I'm working through to the different ways of accessing your application. Given that we have the IP address of the pods, with a bit of bash magic, we can pull out those IP addresses. Okay. And then we can do a curl on the port ATH that we were exposing. Okay. And the other one can't see both, but basically that's a different container name from the other one. Okay. What happens if a pod dies? So I say, well, you know, we will automatically not launch another one. So I just get to get the ID of the first one of those pods. And I'm going to delete that pod. I do quickly get pods behind it just to show, okay, we're in this intermediate state. So that first one, ending in S5, is already in the terminating state. It's not quite finished yet. And we can see that obviously the controller has detected that that pod is going down. Well, I actually would even know from the schedule. And it's creating another container in place.  And we'll see that with rolling upgrades. Here. Okay. So now we just have two nodes again. But one of them that you want has only been running for 49 seconds. Okay. So we've seen how to launch pods via a deployment and replica set. Actually, cutting down the tutorial to one hour, just one point that I didn't mention is, so I've been creating those from just a kubectl run command. That is the quick and dirty method. The way you would create resources, and we'll see it a bit later, because we tend to put those in a YAML file to actually, again, declare the overall set of resources that you want with your system. And we would actually do a kubectl create or apply of that YAML file. Which is quite nice because you can also, on the other hand, when you want to stop things, you can do a kubectl delete. Or if you want to modify parameters, you do a kubectl apply. Okay. So when we start doing stuff here, I'm going to use a different cluster. It's no longer this multi-node cluster. It's just a mini-cube, single-node mini-cube. And I'm going to show other ways of accessing our application. Obviously, what I just showed, I was accessing the pod directly. That's no good. I had to know the IP address of a particular pod to access it. And also, I was accessing directly an internal network. So that's a no-no. So let's look at how we can use services to expose those pods. So the basic principle is you will have a service which is going to expose one or more IP addresses, one or more pods so that some external user can get to those pods. And there are different ways of doing that. And it's important as well, not just because users shouldn't have access to a pod which is internal, but as well because of this whole nature of when we change things, pods will come and go. We can't keep track of those pod IP addresses. Okay. So there are many ways, actually. At least a couple I haven't listed here. These are maybe three most interesting ways of creating a service to access our application. The first one is NodePort. Wow, I'll skip to the following slide. So the idea of NodePort is that you will expose the IP address of each worker node and a particular port that will be used to access one application. Okay. So, well, yeah, but that means you don't have to know the addresses of the pods anymore. You don't have to access that internal network, but you still have to know the address of the worker node which might go away and be replaced by another one. And it's also no doubt an internal network as well. So that's really something that can be useful maybe for internal testing or something, but probably not something you'd want to use in production. As it says here, then, yeah, you'd also be using one port for each service to expose. It's also in this 30,000 upwards range. There are some disadvantages, but it can be useful for testing. Another way is load balancer. So typically, if you create a cluster on GKE, the Google Kubernetes engine, you could use this method and an external load balancer will be created for you automatically, and you can use that. That's sort of like the advantage or disadvantage of this. It's great when you're running in some cloud provider and they will provide the external load balancer for you. And this will provide you an IP address, a known IP address, and this will, no doubt, be on some safe subnet that you do accept to expose. And then it will load balance between the worker node or between the pods, I should say. So this is good for deployment. But there's a third way. That's the one I want to present to you, which is to have a Kubernetes ingress controller. And this one provides more functionalities. So it will provide public addresses you can use to get in to the services running in the pods. The thing is that you will no doubt be having a large number of services in your cluster, and it becomes complicated to route between them. The concept of ingress controller allows to do different types of routing to get to those services, like path-based recruiting. So it's an example where, based on the host name that we attack will be directed to a different service, and it's the ingress controller that will provide us that functionality. Okay, so traffic is an example of a reverse proxy load balancer that can be used as an ingress controller. That's how I'll use that in a demo. Traffic allows quite extensive combinations of host name, path prefix, or sort of URL path, and port-based routing to be able to direct to different services within your cluster. It also allows to do hot reloads of the configuration. You don't have to restart traffic if you reconfigure it to add another service or to change an existing service. And it also has less encrypted support so it can actually do automated encryption. Okay, so I'm going to go away from this previous dashboard. I'm going to close that. Okay, so this is Kubernetes dashboard of another Kubernetes cluster. So I said this one is based on Minikube. So we should see here it has just a single node. I think I have nothing running. Let me check that. Okay, so I'm going to show how to deploy traffic itself as an ingress controller. For the moment, I didn't show you explicitly. Again, if I cleaned up properly here. No, I didn't clean up properly, apparently. Okay, let me... Okay, so I just got a scripted demo. I taught you through the different steps. So I'm going to install traffic itself. We see that's quite simple to do with the appropriate YAML file. I'm going to deploy some pods of an application that shows cheeses, as you have seen. Traffic is really into cheeses. And I will deploy a service of those different applications. And then I will set up different paths to those services. Okay, so the first step, I won't show the actual YAML files there. I've actually applied the configuration to install traffic. And now I'm going to create my applications, my services. Okay, so we have... I'm looking for the image. We have an application called cheese. I'm going to deploy that. So I've deployed three services, actually all based on the same image, called Stilton, Cheddar and Wensleydale. We can see that those three services are running now. Okay, actually still have... Okay, something wasn't cleaned up properly. So I have an Ingress running, but that's not going to create this problem. So I'll get an error here, I think, because the Ingress is already created. So it actually might work better than before. So let me come clean. I have a working version of this demo, and it was the first time I installed it myself. So this may or may not work. If it doesn't work, I'll switch to the working version that I already had. But it would be really cool if this works. Well, now let me change, because that's not... That's the working version, and this is the maybe working version. Okay, so just to say, the address up there, which is totally unreadable, is traffic ui.minicube3. And I have an ETC host's entry with the IP address of that particular node. Okay, so this is the traffic dashboard. I didn't mention that traffic actually can work with many different backends, so obviously Kubernetes, Docker Swarm, Apache Mesos, Nomad Rancher, and also some other back-end services like Consul, ZooKeeper, Eureka. There are a lot of back-end services. What we're seeing here is, okay, in terms of providers, we have one configured, which is Kubernetes. So when we configured it as an ingress controller, basically enabled this tab. What we're seeing is a number of front-ends. So these are actually the ingresses for the services I created. Now, this first one actually is an error. This was me trying to set up the system earlier. And then these following ones should be good. Okay, actually I'm a bit surprised by the address, but okay. And these front-ends are going to basically root through to the back-end services. Okay, yeah, HTTP, it always helps. That's fine. I don't normally use that address. Service and available. Okay, never mind. So I'll go to my working version then. So I'm cheating. So I'll start with the dashboard of the other system that I have. Okay. This is more to be honest. This is more than I was expecting. Of cheddar.miniCube, Stilton.miniCube, and the last one, wensleydale.miniCube. So these are the host names. Again, it's the same IP address. I have entries for these in my, et cetera, hosts. So now, if I try to access cheddar.miniCube, I will be directed to the cheddar service. Wensleydale. Okay, and I think you get the idea. But I fancy that it was Stilton anyway. Okay. So that's, I just wanted to show you the idea behind an ingress controller, where basically you can configure different routes. In this case, basically if the host is cheddar.miniCube, then we're going to route through to the back end, cheddar.miniCube, and this is going to direct through to the pots. What traffic is doing here is there are different ways it can be configured. It's actually interrogating the Kubernetes API. So we don't have to configure traffic to say, okay, these are the services. No, it's traffic which has detected that those services are running. If I normally, if I delete stuff, delete the pods, then those back ends will, will disappear. That's one of the advantages, at least a traffic that has this dynamic configuration reloading. Okay. And generally, this is the sort of functionality that reverse proxies ingress controllers will provide, but maybe not with such dynamic reloading. So in this case, it's very simple filtering. We're basically saying it comes in on cheddar.miniCube hostname with path slash, then go to this service. We could do things more extravagant. We could have regex in there and this sort of thing. So there's a lot of possibility for quite flexible routing of different services. Are there any questions on that before I go on? Yeah. I guess you could, not sure to understand the use case, but yes, I mean, a lot of the use cases we have are treating where head is already been modified because they passed through different systems. I guess you could have chaining over this proxies. Does that answer your question? Yeah. The use case was more if it was a multi-tenant, a nice cluster. So each user controls the routing steps. Okay. But then let's do that global. So, yeah, I think that would be the fifth possible. I tried to remember it as an idea for a demo. It would be pretty cool. Okay. Finally, go back. Let's say this is really the shortened version. This is the cheap one-hour version. Speaking of which, I mean, this is the first time I present traffic. The second time would be this evening. And maybe think earlier of, say it never happened to you. I got in a plane once. The pilot proudly announces, you know, I'm trying to put people at ease. Don't worry. This is the plane's first flight. So everyone's happy except the engineers. I think, what? Engineering, reliability curves and stuff. It's the same. My first time presenting traffic. So a few hicks. Hope you'll go a bit better for the second time. See if I can debug in the MRT later. Okay. So I mentioned, I mean, there are tons and tons of tools coming out of Kubernetes. I even bumped into a guy this morning, the speaker who presented three new tools. Something that he's working on. Pretty cool. But there's one in particular, Helm, which is particularly interesting. So it was a company called DICE who started working on this and some of the tools. And DICE got bought by Microsoft last year. And that continues to operate as an open source project. But there's real momentum.  And already in January, I think, there was a Helm summit. Wow. Okay, so what is Helm? It basically allows you to specify in a YAML file a whole application stack. And then those YAML files themselves are available on the hub. So that's pretty nice. That means you can actually browse. Do I have it over now? Okay, we go there. This is the Helm website. Down here is the option to get charts. They go over there. Cube apps. And explore apps. So if I want, I don't have bought you with this, but I could even install traffic using Helm. But you can see a whole load of application stacks. There's a command line tool as well. It allows you to do quite simply Helm search, I think it is, then Helm install. Maybe that's not quite the plan, but it's a really nice way of being able to install complete applications across your Kubernetes cluster. Okay, so I'm going to stop there. So in the end, that was a 55-minute version, not the hour version. So any questions from people? Yeah. So let me see. So jitub.com, container orchestration labs, actually, then it's an orchestration Kubernetes, and it's actually on a branch, FOSS Asia. And yeah, I'm interested in any feedback, any issues, if you want to open against the tutorial. This is a one-hour version. I mean, could actually run for anywhere between one and three before hours next time. Okay, thank you for your time.


Hello, my name is Bob Boyce and I'm a product manager for ARM specifically for the Kyle tools group and here we have a Running on a STM32 G4 processor board a new Kyle U-Link plus Debug adapter which collects power information and displays it in the Kyle micro vision GUI up here. You can see where the current and the voltage are collected from From the U-Link plus down here interrupts are all displayed in a graphical format and down here I've put in some tags in the source code so we can relate between your source code and these waveforms This information is all collected and I've also what I've also done is I put a start and stop in the code So from here to here it collects a certain amount of power Information and you can have many of those and that's all shows up in here I also have a printf working down here that does not use a UART and The information that's collected from all this power is displayed in this window here And it shows you from where it start to the stop it consume this much power with this much voltage Took this long and this is how many times this occurred in where you set these codes And if you need more information about this go to kyle.com and everything is there. Thank you


And here we go. Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager of DataVercity. We'd like to thank you for joining the latest installment of the Monthly DataVercity Webinar Series, Advanced Analytics with William McKnight, sponsored today by Matillion. Today, William will be discussing organizational change management and becoming an analytic organization. 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. For questions, we will be collecting them by the Q&A in the bottom right hand corner of your screen. Or if you want to share highlights or questions by Twitter, you can also do that using hashtag ADV Analytics. And 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 middle of your screen for that feature. And if you'd like to continue the conversation after the webinar, you can follow William and each other at community.dativersity.net. As always, we will send 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 turn it over to Sean for a brief word from our sponsor, Matillion. Sean, hello and welcome. Hey, thanks so much for having me. I appreciate everybody taking their time today. I'm getting my screen all shared up. Hopefully everybody can see that. Again, my name is Sean Johnson. I'm with the company called Matillion. I've been in data warehousing for about 20 years now, last two years or so in the cloud data warehousing space. Today, as we talk about the complex concept or topic of organizational change management, one of the things that we really kind of want to focus on is creating a technology stack that reduces some of that complexity. And this is where Matillion provides a nice solution. We are simple. We have a really easy to use, no code, low code UI. We scale based on the cloud. We offer paid as you go pricing models. And then we provide you guys really fast time to market with your products. As we look at this, in our modern data analytics ecosystem, not much has really changed. We still see a lot of various sources over here. These are going to be very complex. But we see on our right side that things are getting a little bit more consolidated. And where a tool like Matillion fits into this modern architecture is through what I call automation, of source control management. And so we'll look at source control management a little bit and how Matillion can support you through that process. Built into our tools, you're going to find tools like the Git integration, a Matillion API. What these allow you to do is create data lineage and documentation so that you can understand your analytics ecosystem and then apply appropriate change models and methods that you'd want to utilize. Oftentimes within organizations, we don't necessarily always understand the process that we follow, but using a product like Matillion and ETL development, give us insight into how that data moves within our ecosystem and the different ways that we need to manage that from a change perspective. It also allows us to kind of monetize the various changes that we're going to go through. And then what we can do is we can apply automations to those processes so that we really generate solid documentation, which creates lineages within our environment so that we fully understand our data analytics environment.   And then we can apply change models to that so that ultimately at the end of the day, we end up with really high quality change practice through our data warehouse development environment. And the final thing that I would kind of say about best practices inside of Matillion is we're changing every day. Change doesn't stop. And so really what we like to do at Matillion is we like to build change into our process. We release about every 12 weeks and that gets us into this kind of cyclical continuous change process so that we're always manning change within our environment. And we find that this enables our organization to stay ahead of the learning curve in a lot of cases with the various vendors that we work for. So as William kind of dives into organizational best practices for change today, I want you guys to kind of think about automation tools that you can use that underlie these practices that William's gonna discuss to really enhance what you guys are doing as a business and generate much better outcomes for you. I wanna thank you guys for your time. And with that, I'll turn it back over to Sharon. Sean, thank you so much for kicking us off. And thanks to Matillion for sponsoring. If you have questions for Sean, feel free to submit them in the Q&A section in the bottom right-hand corner of your screen as he will be joining us in the Q&A at the end of the webinar. Now let me introduce to you our speaker for the series, William McKnight. William is the president of McKnight Consulting Group. McKnight Consulting Group focuses on delivering business value and solving business problems until problems utilizing proven streamline approaches and information management. His teams have won several best practice competitions for their implementations and he has been helping companies adopt big data solutions. And with that, I will give the floor to William to get his presentation started. Hello and welcome. Thank you, Shannon. Thank you, Sean, as well. Change is a key word today. Word of the day, you might say. Sean talked a little bit about how important it is that your technical solution embrace the change that's going to happen within the technical architecture, specifically for a company like a Matillion. Changes in the source that are required to get pushed through to the various targets that that data goes through. We all know data goes through many permutations throughout the organization. And I'm gonna talk a little bit about a different kind of change, organizational change, people issues, people change. Now, this is going to be the least technical of all of the talks in this series. And this is the, I believe this is the 18th talk in the series, Advanced Analytics. By the way, you can see some of the prior sessions out on YouTube, as well as here at the university. So feel free to browse them. And I also looked out on the roadmap of what's coming up. And yes, this is going to be the least technical one. But if I were to assign importance to the topic for your success out there, I would say this is possibly the most important one. It's not as sexy as some of the others and myself. And I'm sure a lot of you enjoy the technical aspects of our projects much more than this stuff. But it is absolutely required for success. So let's get into the topic a little bit. What we want to avoid is this. What we want to avoid is attention organization, enterprise, we are now in production. So start to change, start to use what we've built here. No, and let that be a surprise, right? And they expect that that's going to cut it and get people to use this, whatever it is. No, it should not be a thud out of the tree like this. It should be something much, much more gradual. And we have to account for these issues all along the way throughout our project. This is something I've learned in my practice leading consulting groups for 20 years. And we've incorporated it into our practice with a high degree of success. I'm going to share that with you here today. And I hope that it helps you become more successful. I'm sure you're building some great technical foundations out there. I'm sure you're building some great data. But let's get those users to actually use it. Let's get those application developers to actually incorporate our data into their projects.  Now specifically, we're talking about trying to lead an organization into the world of analytics, the modern world of analytics, that is. Because I don't find too many people say, oh, we're not doing analytics here. But if you dig, if you dig as I do, you find that, well, it may be some fairly shallow use of analytics. So let's know that we're talking about some mature, modern uses of analytics, which probably includes artificial intelligence and machine learning, probably includes big data as well. And these types of analytics are absolutely critical to business success today. Now, this isn't the data maturity talk, but I make that point loud and clear in that talk. I believe that was last month's talk. Predict what is going to happen without intervention and actually intervene. I actually had to talk about predictive versus prescriptive analytics, and that's what I'm talking about here. Prescriptive analytics, doing something about what you're learning about. It's great to learn about what's going to happen, but you have to know what you're going to do with that information. Don't just report on what did happen and then let that be it. That's great to see the sales figures from last month, but how does that impact what we're going to do on a go-forward basis? Get business representation in determining the analytic calculations and predictive models. Again, you find this as a recurring theme in all that we do in information management and analytics. It's integrating with the business and being sure that we have that business representation in everything that we do. We're not coming up with the analytic calculations or predictive models, but the business side is. And some of us sit real close in that, but I find that most people are either implementing the technical side or the business side of it. They may sit right next to each other and be on the same team, and that's great. And we're going to get into some of the business models, how we can form to make analytics most effective within the organization. But still, we want to see that integration. Determine the analytic data that will be useful to business strategy. And I might kind of, with a wave of the hand, say, well, that's all your data. And then some, your third party data as well. And at some level, maturity probably is. But maybe the key here is determining a priority of data that you can bring under management and get in the enterprise architecture, not sitting out in silos, not sitting out in someone decided one day that it's going to be this way and nobody understands it or believes it, et cetera. Not that, but inside your leverageable data warehouse, inside your leverageable data lake, inside your leverageable operational data stores. And yeah, of course, you're going to have some data marks for good reasons outside of that. But have a true architecture might be another way of putting that bullet. Involving analytics in every initiative and business decision. That's right. Every initiative and business decision. If there's an initiative going on that does not have analytics consideration, as part of it, that is something to be improved upon. And hopefully one of the models that we talk about right here is going to help with that. Because analytics, again, needs to be part of all projects. So we have to know what those projects are. We have to have the analytic resources eventually at some point, knowing what those projects are and involving themselves and the analytics appropriately. So we have different models here. Center of excellence. Now, the difference between the center of excellence and central lies has to do with the influence of that organization. So with a center of excellence, you get more localized influence from that center into the various use cases, projects, et cetera, that's going on throughout the organization. So in a COE model, analysts are actually allocated to the units to the projects. Activities are still somewhat coordinated centrally. But the analysts are residing out there, at least for a temporary basis out there actually in the projects. And this, by the way, is the model that I like the best, especially for an organization that is of low maturity or getting started with their analytics program, getting started with their rollout. So start here and keep some elements of this, I would say, throughout your analytics journey. Now, another one is decentralized. And this is kind of problematic in my view if you go full decentralized, because sometimes I find that that's like saying, we're not really doing anything about it. We're just maybe nominally thinking about it within our project teams. But there's no central coordination or central functions in that. Then there's centralized, which I talked a little bit about, centralized though, you're not going to allocate resources. Resources are not actually reporting up through the project teams. They're centralized. And the project teams have to dip out into that centralized group to get what they need. This is effective as well. And of course, every organization is different. And you should think about your organization and what works there as you go through that. But I think that you're going to get more powerful center of excellence, more power from a center of excellence approach. And finally, you have a functional approach where you may have to do this, where you have all the analytics are driven by a functional agenda, but there's no vision of getting this to go broader within the organization. And finally, some overlay on top of all this is you might use consultants to actually do one of the above functions, which can take on quite a different persona than what it ultimately will inside of your enterprise, once you incorporate. OK, successful analytic organization transformation efforts require much more than the right analytics and good planning. And it requires a lot. It definitely requires more than good technology.   We just buy predictive maintenance. We can buy supply chain management. No, it's not a buy. It's a build, but you buy things to support the actual build of the various projects that you want to have within the enterprise. Good technology. Just buying it will not solve it. And I've been doing a lot of these budgets. I'm actually writing what I think will be a very good, very big paper for our industry on the true cost of modern projects with machine learning and artificial intelligence. And as we know, some of us, the professional services, the FT costs, and so on, are definitely going to be more than the technology for the most part. And that's still true today. So keep all that in mind. And I'm actually going to suggest in this presentation that we allocate a certain percentage of our budget towards these organizational change activities. So we will encounter many risks that are people related. Yeah, many risks that are people related. I can't tell you how many times I've come in to analyze a data organization, a data infrastructure, and I've found that I really like it. I think they've done a great job here. But the business side does not seem to agree, or at least they're not showing any of that. And sometimes it's the actual reverse. So either way, we've got to bring up the people side of this. Now this is a slide that I think belongs on, if not your walls, in your project artifacts and something to pull out when there seems to be an issue. Because the issues usually come back to something in regards to this, at least at some level. At some level, if leaders are not aligned with the transformation case or change, if they don't get that, you know, the projects that we work on, we data analytic professionals, the projects we work on are highly transformative to the company. I'm not talking about building a report. If we're working kind of break six stuff or working off a queue, I'm talking about the projects. Talking about leveling up our supply chain management, doing that predictive maintenance, doing that fraud detection and so on. Modern projects, leveling them up. We're all doing that stuff, but are we doing them to modern standards? And a lot of companies out there today, even with the pandemic and the shutdown, are doing those kinds of projects. They're leveling up in terms of the basic functions or taking them into artificial intelligence and so on. But the leaders are not aligned with that. There's going to be issues down the road. If departments fill they have little or no input in the process, clearly that's going to be a problem. Employees are concerned about how new processes will impact their current jobs. And this has to be handled delicately. What can I say? I do find that most people will come along eventually with the new way. As a matter of fact, you know, it really is our job to level up our organizations all the time. And that's essentially what we're doing with our jobs. We're not, you know, quote unquote, I won't say we're working ourselves out of a job, but we're leveling up the organization. We're hopefully growing into the jobs that our organizations are going to need in the future. So corporate change might be resistant. Corporate culture might be resistant to change. And that's a big problem. And that's something that, you know, we're definitely going to need to work from the top on. But good news is in the plan I'm going to give you, there is some working from the top that we do. Interruptions and day-to-day operations. Yeah, it's okay if you build that data lake out there. It's okay, just don't bother me. And oh, you don't really expect me to actually use it once you build it. That is a formula for failure right there. We are going to have to appropriately interrupt business and interrupt day-to-day operations and get some time from the stakeholders. You got other things going on. Of course, the staff itself is not adequately prepared to execute new processes and technology. You know, one thing that you'll find in my speaking, I'm motivating a lot. I'm trying to motivate us in data and technology because I really believe that we're sitting on the gold of the organization to pull a sentence from last month's talk. We are sitting on that gold and we have to be bold. We have to be assertive about that in order to get the company to understand and offer their own good, our own good, all good. Change readiness in organization impact assessments can provide OCM leaders. OCM for organizational change management, by the way. You'll hear me saying that. With additional insight into the people risk. So let's look at some of the things that we do out there. We build data warehouses. We build data lakes. We build business intelligence. We build analytics, et cetera, et cetera. At the top level, what do we want when we build this thing? We want use. We have to have use. We cannot spend millions and let it sit there. We want people to use the warehouse, not the old ways to get the data. We want people to accept that the data in the data warehouse is great. It's what they need. Not question is quality or it's completeness or any of a number of other things. Think of other uses for the data in the data warehouse. Not the first use. First use is the only use. That's not a data warehouse to come to think of it. That's not a leverageable artifact that you've built there if you think of it that way. We want the users and the business to contribute derivations, calculations, summarizations for the data warehouse, not just, oh, it's okay that you built that, that data lake, whatever. I will come and get the data off of there as quick as possible and get it out here to where I'm comfortable in my warm pond of Excel. No, that's not what we want. We have to work that side of the equation as we build our data infrastructure. Master data management, I'll be quick about this. Not everybody's doing it, but you should probably, but anyway, you'll often hear me say this as I come into a company to talk about master data management, to build a project, to do an assessment, et cetera.  I want to be the single point of this. That makes it leverageable. But if they're still gonna get data there, they're old ways, then I have failed. I want people to contribute their master data to MDM. That's the converse, right? So get and contribute their data to master data management, not the old ways. We're creating a very efficient structure here. We're creating something that we're gonna build once, use many times. Now moving on to big data. All right, now, I don't know if it's okay that I say big data anymore. I get chastised for saying big data, like I said, that's an old term, but still a lot of organizations are breaking out of their normal, if you will, alphanumeric data that fits nicely into, or could fit nicely into Excel. Breaking into big data, sensor data, clickstream data, a full log, full call detail records, et cetera, everything. So we need to extend our business analysis to include big data, it's not okay. It's not okay to sit back and say, well, nobody's asking for it. So I guess I don't need to do it. I don't need to think about it. I don't need to motivate that. No, I say you have to motivate that. You have to motivate it all. If you know it's good for the company, you have to motivate it. Even if you're busy and it's not something you can handle today, it's something you can negotiate into your plate, somebody's plate, but the business absolutely needs big data, whatever that means to you and your industry. Every industry is a little bit different. We have to get them to trust the big data collection process. It's as good as it, that it is as good as it gets. It's not something that we just threw together and we're losing pieces here and there, and it's just bad. We got to get the business to also think big and think beyond what they're doing today. Really, the death knell for a company is everybody's still doing the same thing year over year and expecting that that's gonna be competitive. That is not competitive, absolutely. Okay, response to change. Now, I'm not taking us back to, I don't know, Psychology 101 here or anything like that, I hope, but this is true. These steps are true, not just in our personal lives. They are true in our corporate lives as well. I have seen this happen. I can almost read out where people are on this now, on my projects and on your projects. Starting with denial. A lot of people, everybody goes through this for everything. Some of us go through it a lot faster than others, so. So, when you know that the end of the road is down there at the end, maybe I'm spreading the word or this isn't bad, wherever your good end of the road is, knowing that you're going to get there should help you get there. I hope that made sense while I just said, but it helps me know that when I face resistance that there's hope. There's hope to get through this because it's normal, that's people for you. We will deal with people, right? So, let's go through this. The change won't happen. Yeah, you can, I'll pick on a data lake. You can build that data lake, but I just don't think it'll be, I don't think it'll be good. I think you'll probably fail just like the last one or two and it's another fad and blah, blah, blah. That's denial. It won't affect me.  I'm not going to have to spend time right now thinking about this data, I think you called it a lake, okay, that you're building over there. So, because I don't think it's going to affect me. And okay, well, it looks like you're going to production with something here, but yeah, it won't last. It'll be short lived. Oh, now I'm angry because it's kind of creeping over into my territory. It's got data that somebody expects me to use, but I've got this clunky old way of doing it and I spend three days a month doing it, but I like it and I'm comfortable with it. And I never bothered to learn, you know, what they're doing to build what they're doing. Okay, I'm going to kind of try to stop with the role-player, I can't help it.  And then how can I stop it? Then you start bargaining, okay. You know, maybe I'll use it a little bit. You know, I'll try.  I'm going to give it a try and use some of that data lake. And hey, hopefully you get to, this isn't bad and I'm spreading the word. But no one individual, if everybody is stuck at denial, if you allow everybody to get stuck at denial, and that's a really rare situation by the way, but people will look around, they will look around and see where everybody else is on this journey. And they will act accordingly. So if everybody's in denial, you got a real problem. If everybody's in, it won't affect me. You got a real problem there. So from the start, there are some hills worth dying on, on these projects. And one of those hills is you have to get the users involved. We cannot do this without, without their input. And yeah, because a lot of them are going to be, unfortunately on the right side of this cat, this bell curve, where they are skeptical. They will come in, but they'll come in late. We love the ones on the left. They're going to come in and adopt early. And yeah, we can take a few innovators on. Now the good news about all this is, this bell curve as you see here, that's about how people do shape out in an organization. So you're probably not going to have all deniers, okay? But it's your job to identify who your important stakeholders are and where they are on this curve and act accordingly.  You have to maybe overweight in terms of how you are treating them, but not to the complete detriment of taking care of your early adopters, okay? It's a balancing act. And I'm going to leave a ton of judgment in there as I give you all these tasks to do here on your projects. I'm going to leave a lot of judgment out there for you as well. I can't take that away.  Okay, let's get to it. The analytic organizational OCM strategy. OCM will focus on mitigating the people risk and enabling the realization of business benefits across these five areas, five areas for you here. Training the workforce. So they're not behind when it comes to what they need to be doing to be utilizing whatever it is that we're building here in analytics, addressing the organizational implications. Yeah, there may be some job role titles or descriptions that need to change. There may be some reporting changes that have to happen. I like to, just to make a point sometimes, I shouldn't say this because it's a strategy, a consulting strategy, but I like to make a big play about how the job roles are going to change as a result of this, just to get people to realize, oh, you mean they're not over there just writing some reports? Oh, no, they're actually doing predictive maintenance. We're not going to do maintenance the old way. We're going to do it a new way. It's a wake up call. So you need those wake up calls early and often throughout the process. Engage and communicate, lots of communication. No such thing as over communication. We have to have that as part of our plan and communication from your scrum masters and so on doesn't just go down to the team. All right, it goes across the organization. I want regular touch points with key stakeholders on this at multiple levels of the organization. Speaking of that, we have stakeholder management in the upper right, which is probably the most important one on here. And I'm going to give you specific tasks in each of these five areas. Again, to put on your backlog and to put in your project plans, change readiness means that the organization is ready for change. People have exhibited the behavior that shows that they're ready. We have the artifacts in place. We have the support team lined up, et cetera. Change readiness is important to OCM. Now, OCM can be embedded or it can be standalone. So we can put some of it into projects to support that project or it can be standalone sitting aside, kind of like the center of excellence model in support of multiple projects that might be in development or might be in production, but not fully in production. You know what I mean, it's in production but it's not getting used the way that it needs to be used. Data governance often has some Venn diagram overlap with OCM, that's okay. We can have a whole talk on data governance if that's not your vote in your organization. Okay, well, let's do some things with OCM and we won't worry about that except that we need it. So let's build our data governance separately. But anyway, recommended to orient it to projects and have short-term wins. OCM is not like the data governance programs of the 90s that sat on the sideline and did their thing and expected major business results as a result of what they're doing when they're not integrated. OCM needs to be integrated. Let's just do that from the start and let's get these tasks and specific things that we need to do in the projects. All right, how much OCM to do? Well, I suggest you do an assessment and these are your metrics at a high level. Are you making process changes as a result of this project? One to five. Do you have numerous stakeholders and do you have high potential for unsupported stakeholders apparently? In this example, we do. We got that out there at a five. Is there widespread organizational implications or is it departmental rate that? Are jobs changing? Or is the organization used to change? This is really important. Is the organization used to change? Have they successfully dealt with change before? Or have you wasted millions on projects that seemingly look good but didn't get anywhere? Now these five things obviously map to the five things on the left, all right? So as we go into it, that's your mapping. Let's go into the work products. Now this is a macro look at the work products.  Again, a slide you can take off and refer to as part of your project team. And I know that I have designed, build pre-production and deployment across the top. Like as if I'm doing some kind of waterfall and not agile. When I know that most of you are doing agile, I'm doing all agile. Okay, I get all that. I get all that. But just because you're doing agile doesn't mean you're not designing, you're not building. You might be doing it in smaller increments but you're still doing all this stuff. And so whenever you're doing this stuff for your project, you just kind of read down that column and you see some of the things that you might want to do. Again, the more, back on this graph, the more out, I guess, closer to five that you have rated the respective function, the more of the things you're gonna want to do. So stakeholder management, we thought that was a problem for this project or a potential problem, right? Not a problem if we deal with it. Let's read across stakeholder analysis, do a stakeholder management plan. We evaluate and update the stakeholder management plan at pre-production. We evaluate and update the stakeholder management plan at deployment. So you're doing a lot with this stakeholder management plan. It's coming up early and often when that is the case, okay? So we need to bake all of that into projects that have a problem with stakeholders and many do. Same thing applies to all of the other rows that you see here change readiness, engage in communication, addressing organizational implications, training the workforce. So as an example, we might decide based upon our spider grasp to do this. We're gonna do stakeholder analysis. We're gonna do a stakeholder management plan. We're going to do a deployment readiness assessment, except for what you see here. And I think that what you see here is actually bare minimum, for any project of any kind of scope whatsoever. You need to be doing this. Now you might say, okay, teachers say job roles definition, not much to do there, but you should address it. You should at least acknowledge that that's a possibility. That's a tool in your toolbox. And if you don't pull it out, then you are definitely hampered in your ability to take this where it needs to be because your success as a leader doesn't end when you put it in production and declare victory then. It's later. It's after you incorporate change. It's after you actually get a ton of usage and bottom line business value from that thing. It's a tough job. Okay, stakeholder management. Let me drill in, double click on a few of the stakeholder management. I've raised that that's a pretty important one, right? Okay, identifying your stakeholders, assessing your stakeholders and influencing the stakeholders. And many times here we're talking about stakeholders that are VP level or above. And when that's the case, you influence them on an individual basis. You are not creating a one-size-fits-all plan for the CEO and the COO and et cetera, right? Okay, you have to take into account their personality and their understanding and just what it is that they're gonna be able to handle. Again, it's not a one-time event. It must be reassessed. So stakeholder dimensions. Identify your key stakeholders.  I got hundreds of users for this, okay? Well, identify 25, okay? Identify up to 25. And let's do an exercise within the team. We don't have to tell them. We don't have to tell them we're doing this exercise on them. But let's write them according to all of this. How are they? Red, yellow, green, ROIG, red, yellow, green. How are they to the project? And maybe you don't know, figure it out. But how are they to the project? And where do we desire them to be? No, but we don't desire anybody to be red, okay? That means they're completely opposed to the project. And that can't be if they're a key stakeholder. If they're in my 25, they can't be red. We gotta give them to at least yellow, okay? I say red's the yellow, yellow's the green. What is our project role? What role do we want them to have on the project? What actions do, can they do that manifest that they have moved forward or moved to where they need to be to be a successful stakeholder? So this is an example, a little plan here. I won't read it all, but we have a description.  We're gonna have a meeting, a one-on-one with that person at the beginning of each release. It's gonna be one to two hours. The objective, and this is for department as apparently, is to prepare them for their role. And here we have a sample agenda that we're gonna take through with them. Yes, we're going to do this, we're going to reach out. I have done some pretty weird and wild things to make sure that my stakeholders understand their level of involvement in the project. When they are elusive, I have looked at their calendar, their schedule to see when they're bumping from meeting to meeting. And oh, I just happen to be standing in the hallway when they're going from meeting A to meeting B and with a concise message for them. Of course, that's hard to do today when we're working from home, but you'll have to get creative about it in your own way. Okay, so let's move on to something else, the communication plan. I recommend a communication plan. So you're going to have scheduled meetings, face-to-face demonstrations, presentations, all hands meeting, yes, these are all at your disposal. And you can just take this slide and do it, right? Because this is kind of all filled out as an example. And I think it's pretty good. It's targeting all the people that you need to target, the project team, the business advisors, committees, project staff, et cetera. We're trying to slide everybody into kind of those little roles there. And you can see the frequency, face-to-face meetings and events and so on. Pull this off, put it on your backlog. So who's going to do all this work? Where's it coming from? Well, okay, I said earlier that I'm going to recommend a number. Here comes a number. I'm going to recommend a number of, it's a percentage of your budget that needs to be allocated to these types of activities. Again, for any media project, unless a 10%, 10% of the budget should go towards these activities. Now, there's different ways you can get that 10%, right? You can say, when you go to the budget committee, you can say, I need 10% for OCM. Okay, that's the good way to do it. That's the upfront way to do it. And that means that you're being very assertive and moving things forward and you're getting them involved immediately. Another way to do it is to bake it in to the project. These are just project tasks that need to be done. Need to be done. And I don't find that they get questioned too much. As a matter of fact, I find my clients are much appreciative of the fact that I'm acknowledging this stuff because it's very easy to see that these things go straight to the bottom line, go straight to acceptance. And if I had to say, what are my sponsors for my projects over the years? What are they most concerned about? They're most concerned about acceptance, acceptance of the project by the powers that be within the organization. Yes, of course they're concerned that we build it, right? But they're concerned about acceptance. Now, the bigger your project, the more you're gonna need these boxes in terms of being actual people. You may need a different change management sponsor than the project sponsor. Hopefully you don't, but not all project sponsors are right to actually lead change within the organization. We might wanna think about having a different sponsor just for change management. I've done that to success. I think that's a good idea sometimes. Change management lead. I'd say project manager. Now, I would love for a project manager to be so skilled and have such an abundance of talent and time that they can do all of this stuff and that the project is small enough to where they can do that. But that's not often the case. And so oftentimes I will have a different change management lead. Yeah, maybe they do some other functions for the project too. Maybe not for huge projects. When I'm doing multi-million dollar a year projects like 10 million dollar a year projects, you better believe I'm gonna have a dedicated change management lead on that project. And he or she is gonna be responsible for a lot of this. And I might even even have more. Look at the green boxes. Communication, somebody to do that. Training, somebody to do that. Organizational alignment. Someone to do that. Mayor may not need people specifically dedicated to those roles, but the bigger the project, the more likely that I do. But the main thing is that these things get taken care of. That we do a communications plan. That we do a training plan and we execute it. And we do look at job roles and we do change them accordingly. Okay, so when I'm sharing the task, you're wondering maybe, well, where's it all gonna come from? Well, it's gonna come from these roles right here. And let's take a quick gander at the change management lead. They're doing OCM strategy. They're doing the OCM plan. They're doing OCM leadership interviews, OCM leadership strategy and operational vision. They're mobilizing, supporting and coaching the change champion network, which is basically the network of people in the company that support the project. Coordinating the overall execution of the OCM program and all the development of the architects. So in conclusion to my part, and I do welcome your questions. You got a few minutes. You wanna throw some more questions into the Q and A panel for us. OCM is essential to organizational analytics transformation. So no matter what other niche crook or cranny that you are involved in in analytics, make sure someone maybe you is involved in OCM and making sure that what you're doing actually gets accepted by the organization. Choose the applicable work products. I give you the macro set. Maybe there's more. Maybe there's more that you can think about that will help you in your goals of OCM. Certainly I'm open to that. Certainly your project should be open to whatever it takes. Don't push OCM off until the very end. That's when you get the thought out of the tree. Don't push it off till the very end. Make it a part of the journey. Start people towards their change on their change plan from the very beginning. Insert work products into plans, be that an agile backlog, be that the project plan, whatever it is you're doing. I hope you're doing agile, but insert the work products into your plans. Focus on, these are the key ones. If you forget everything else, do these things. Stakeholder analysis, job roles, training, deployment preparation and communications planning. Again, back to my bare minimum slide, okay? They're on there. Make sure that you do all that for these projects because when it comes to analytics projects, when it comes to data lake project, data science projects, all the ones that I'm involved in that you're probably involved in, from a project perspective, these are going to be highly impactful to the organization. You might as well deal with that head on now as opposed to later. You might as well start getting the organization prepared for the success of your project long term, which is the only success. Make the soft, this idea that people need to change, people need to come along with the program. Make that real and tangible. And let's not blame them for being human, right? They're going to go through the steps that I showed you. They are, some slower than others. There is a point, I suppose, at which people are not coming along and that's going to be too bad on them, but I find that most people will, if given the chance, you have the opportunity, the great opportunity to give them that chance by creating this program. To bring them in, it's a win-win. Make it a real tangible part of an action-oriented framework. All right. Shannon, that brings me to the end of the formal part of the presentation. I turn it back to you for the Q&A. William, thank you so much for another fantastic presentation. Just to answer the most commonly asked questions, just a reminder, I will send a follow-up email by end of day Monday for this webinar with links to the slides and the recording of the session. And we invite Sean to join us back in with the Q&A here. So let me just dive right in here. What will the new roles be for organizations becoming analytics-led? Well, data scientists, for example, what skills will they have? Yeah, I'll start. And I know Sean works with a lot of data scientists and new roles as well. But yes, you hit on a key one, right, data scientists. We want to see more of that. That's a maturity factor for organizations in terms of analytic maturity to have that role. That role is hopefully going to be curating upon, not curating the data, but curating the science out of the data and gleaning insights out of that data and having a bit of a free hand to go where he or she needs to go but understanding kind of the bigger goals of the organization at the same time. So data scientists is big. But when I talk about role changes, I talk about, yeah, of course, there's the big ones like we're adding data science and so on, but there's also analysts that used to go to the file cabinet and used to go to the FAP machine and used to lob telephone calls to check on payments and so on. Well, there's a new way. We're done with what we're doing, right? And so we want them to go about their job in this new way and not resist and see the benefits of doing that. So job role changes are all across the board. Certainly analytics projects are bringing in the data scientists and so on, but they're bringing in so much more. We are all needing to change as a result of the changes that are happening around us with artificial intelligence, machine learning and advanced analytics. All jobs are changing and they're changing as rapidly as ever. And they're changing to new ways of doing things. And so it might not be a title change. They were talking about here, it might just be that the roles are changing and how they do their job is changing and they need to be more informed by data. So these are things I want to capture in terms of new roles. I heard a lot of that, William. You know, as a developer, I think I was probably in an active coding role for probably close to 15 years. And a lot of times change management is an impediment to a developer's job because you have all of this processing and you have all of these hoops that you have to jump through, you know, justify why you're creating code and all of these things. And as I've progressed in my career, I've really kind of opened it up to where, you know, I try to take all of the roles within an IT organization now and make them a part of effective change management. So in other words, you're not buying into a process, you are the process. And I think as companies move towards the web and cloud data warehousing and processing faster, people are gonna realize, oh, the best way to be a part of change is to be the change itself and not really worry about what process I have to follow to get my change to the end environment. Hopefully that makes some sense. Indeed. So I've had luck using these tactics in the past that my current role, my employer has approximately zero interest in spending any money on the additional cost, strictly seen as a speed bump suggestions on how to overcome that attitude. Sorry for the chuckle there. It's not funny. But yeah, there's a lot of that as well. And I get that. And I find that, you know, the first place that, you know, somebody wants to cut on a project budget is, what's this you got here? Organizational change management? What's this thought stuff? You know, and that just gets back to what I said earlier. It has to happen. You have to bake it in. And you're trying to get success. And you can get it in one of two ways. You can either bake it in and knowing that you'll be allowed to do it, or you have to, you know, kind of beat that tree with the club a little bit to get the top down support for what it is that you're doing. And frankly, you probably gotta do a little bit of both at least to make this happen. So, you know, there's, I also use the phrase in the presentation, he'll worth dying on. And only you can decide, only you can decide if this is gonna be that he'll worth dying on for you, if you're gonna stand up for organizational change management or not. But I think you can probably see based on your question that it's a good thing for the project, possibly a very necessary thing for the project. And so I think you've got some things to do in terms of, you know, working on that person. But also I wouldn't hesitate to put, just put it or put these tasks right in there. And that's why I give you the task to make it real. And you probably won't get pushback when the tasks are encountered in the project because they're just so obviously necessary. But good luck with all that. Yeah. So I would piggyback on that. I think William's absolutely right. And I'm gonna give you an example that's not IT related, but you know, change management is about managing risk. So one industry that we have in this country that manages a ton of risks is credit card companies, right? If credit card companies didn't manage their risk in their agreement with you, they would go out of business quite quickly. So when you sign up for a credit card company, they've already kind of prepared all of those costs associated to the account that you've signed up for. I like to think of change management the same way. And I'd go back to that supervisor kind of with that and look at the way that credit card organizations manage their risk. It's the same thing that we're doing with our software. We want our software to live beyond the average self-life. To do that, we have to invest in this daily activity called change management. And if we do that, we will be successful because we budget it for it. Perfect. What is the best way to figure out who the stakeholders are in these projects? Yeah, yeah, good one, good one, very good one. Okay, so I think the first five are gonna be obvious, right? They're the people that are going to be actually using this the most. And that might be actually your first 25. But I would start by looking at the users and I would go up the chain from there, meaning their bosses and directors, VPs, and kind of use your judgment and kind of find your way by starting with the users of this. Now, don't just stop with the users, right? Look at the user organization in the org chart or the informal org chart, as the case may be. Look around that box and see, okay, who does that box interface with? Like supply chain, if I'm doing a supply chain project, okay, they're gonna interface a lot with the product management team. Okay, they're gonna interface a lot with the transportation team, et cetera, whatever it is for you. So it's quite possible that I need stakeholders in my 25. I need some from those organizations as well. I almost always need one from finance no matter what I'm doing, okay? So yeah, so start with the users, branch out, branch out, branch down from there. And it won't take long until you're at your limit in terms of how many you can actually deal with in this process, but it should be meaty. And I kind of use the 25 as a rule of thumb, but it can be whatever it needs to be for you, whatever you feel like you have the bandwidth to manage in this process and you want them to also represent.  And you hope that the green ones are gonna spread the good word out to everybody else who is maybe a more minor stakeholder. Yeah, I don't have your prowess and I don't work necessarily at your level, William, but at my level, when I'm working with different solution architects across different organizations and different teams, the people that I'm really looking for, the people that are out there really kind of cheerleading all the time. Those are the people that I lean into, that I tend to push more into kind of a stakeholder role. Now, I don't have this big organizational wide kind of responsibility that you do. My projects are short, but generally I will try to find the person that speaks the most and the happiest about that work and put them at the top and use those individuals as my kind of evangelist of the project and what we're trying to accomplish. I love it. And so what if you implemented the change before proactive planning? So what if you implemented the change before proactive planning? Is that the question? That is. Okay, okay, okay, I get it. So you've already done your project, you've gone on to production and you were not proactive about this stuff. Yeah, that happens a lot.  And realize that you now have another project on your hands, it's just the organizational change management, part of the project that you neglected the first time through. And hopefully you have a good asset on your hands that you want people to use. Sometimes it's easier to show than tell, right? When you have something you can show people, hey, here's what it is that you want to do. We want you to do. So just take advantage of that situation and show, don't tell and try to get people involved as users at that point, as stakeholders at that point, as people that are getting great business value out whatever it is that you built, unfortunately at that point, you did it backwards, but it may or may not be salvageable. It probably is if the horse isn't too far out of the barn here. And so I would just get about doing those tasks and I know your budget's all spent now, right? So that's gonna be another part of the problem. If it's truly a bad situation, a red situation, then you might have to seek budget for some of these OCN tasks that you neglected in the first place. Would you kind of into almost a continuous improvement cycle? And if you think about it, you've got great lesson learned from a project and now you've got some backup material and you can use that information from what you've already done to apply a lot of these lessons and then generate a different outcome going forward. At least you got something out there. Indeed. So I think we have time to slip in one more question. Uh-oh, broken up. Shen, you got a little choppy there. Hopefully I'll hold up here. I think we've got a few minutes for one more question. What are some of the most difficult? Shen and I heard you through difficult. I think I just need one more word. Well, maybe I can poke around in the queue and I can find this. I think it's, what were some of the most difficult OCN problems William encountered? Okay. Well, one time, I built a, it was a supply chain management project with analytics. It wasn't too long ago. And this company was unfortunately in the dark ages prior to this project and we made a tremendous step forward for them. But we were talking about droves of people at this organization that were doing things in a manner in which they were used to, which is Excel spreadsheets, literally phone calls and faxes and everything. Can you hear me? Hello? Hello. Hello, Shen and I, I'm just answering the question. Okay. Sean founded on the Q&A for us. So these people were doing things with file cabinets and all these really old style ways. And I found that by trying to bring them forward so far that there was, almost I would say the word is mutiny. But the good news is, you know, from the organization standpoint, they, you know, they were all going to stay in their jobs. They were just going to do it better and level up. And so we had to spend a lot of time, maybe the word is hand-holding, training, desk side sitting and so on with every level of that organization to make sure that they came along with the project and would use it and would make the whole thing successful. And so we did and everybody did come along, but it did look bleak at first because there was a lot of people in the red, a lot of people in the denial, but by following this program and frankly that project helped to hone a lot of the things that I talk about now in organizational change, and all of the things that we do. So good thing that project came before this presentation and made it a lot better. So there's help out there, even when people are in a bad way to begin with. So my worst situation I'll say is that with a lot of people that were rebelling against the project. Sabulous. Well guys, can you hear me now? I'm so sorry about that. I don't know what happened. Yep. Okay. So that does bring us to the top of the hour and just want to say thank you to Matillion for sponsoring and thanks to all our attendees for being so engaged in everything we do. Another great presentation and just a reminder, I will send a follow-up email by end of day Monday with links to the slides and the recording. Thanks everybody and hope you all have a great day and stay safe out there. Thanks all.