 My name is Shannon Kemp and I am the Executive Editor for Data Diversity. We'd like to thank you for joining today's Data Diversity Webinar, Data Systems Integration and Business Value Part 2, the cloud. And here's August edition in a monthly series called Data Ed Online with Dr. Peter Akin brought to you in partnership with Data Blueprint. Now let me give the floor very quickly here to Megan Jacobs, the Webinar organizer from Data Blueprint, to introduce our speaker and today's webinar, Megan. Thanks, Shannon. Hello, everyone, and welcome. My name is Megan Jacobs and I'm the Webinar Coordinator here at Data Blueprint. We are pleased that you found the time to join us for today's Webinar on Data Systems Integration and Business Value Part 2 at the cloud. As always, a big thank you goes out to Shannon and Data Diversity for hosting us. And we'll get started in just a few moments after I let you know about some housekeeping items and introduce your presenter. We have one more for the presentation followed by 30 minutes of Q&A. We'll try to answer as many questions as time allows, but feel free to submit questions as they come up throughout the session. The top two most commonly asked questions is you will receive an email with links to download today's materials and any other information you request during the session within the next two business days. You can find us on Twitter, Facebook, and LinkedIn. We've set a hashtag Data Ed on Twitter, so if you're logged on, feel free to use it in your tweets and submit questions and comments that way. We'll keep an eye on the Twitter feed and we'll include answers to those questions in our post-session email. Now introduced due to our presenter, Peter Aiken is an internationally recognized data management thought leader. Many of you already know him or have seen him at conferences worldwide. He has more than 30 years of experience and has received many awards for his outstanding contributions to the profession. Peter is also the founding director of Data Blueprint. He has dozens of articles and eight books. What's recent is the case for the Chief Data Officer. The best hobbyist is through Data Diversity's bookstore. I'll receive information on how to do this in the follow-up of emails. His experience is more than 500 data management practices in 20 countries and consistent as a top data management expert. Some of the most important and largest organizations in the world hot out his and Data Blueprint expertise. Peter spent his entire year in merchants with groups as diverse as the U.S. Department of Defense, Deutsche Bank, the 12th Fargo, the Commonwealth of Virginia, and Walmart. He appears at conferences and is constantly traveling. Peter, where are you headed to this week? So as we finish this today, Megan, I'm headed for the airport to go visit the DEMA chapter in Columbus, Ohio. We've rescheduled an event that got canceled by the weather a couple of weeks ago where we spent about 11 hours on the airport runway at John F. Kennedy International Airport, and I'm sure some of you guys have those stories as well. The joys of traveling, but at least we don't have to worry about that today, although we are going to talk about the cloud. So again, this is a part two of a three-part piece that we've been working on that we're hoping to, you know, that you guys are taking this into context and getting a broad approach to integration type of things here. And from a business perspective, cloud-based integration allows some very significant capabilities. I'll go through them in a lot more detail, but just at the top here, it's increased automation and storage capacity. It gives you some very different ways of putting together your cost equations. It gives you some flexibility components in that, and it frees up a lot of your IT staff who may or may not be the best at doing this. And finally, it's easy to use in many ways. Now, from a data management perspective, we're going to talk about some very fundamental pieces, though, that are just not appearing anywhere in this. And that is that even if you do gain these advantages that we've talked about here, investment in the cloud will be useless from a data management perspective unless you look at it specifically a governance architecture quality and development practices perspective in here. You've really got to understand your data architecture and the strategy that surrounds that, or you won't be able to evaluate the various cloud options. And the key is that data in the cloud must be re-engineered, and they'll have a very specific definition for re-engineering. But the data that you put in the cloud must be re-engineered to be less in volume, better in quality, and more shareable for the cloud, or you will not be able to achieve the business value that you're attempting to get to this. And if you do that, the only people who win are the cloud vendors. And there's nothing wrong with the cloud vendors, but we'd really like to make this a win-win situation. And quite frankly, they would too. Before we look at here, I will start out with my usual data management contextual overview and just review very briefly for you where we came from from the last webinar, bringing up to date here on this. And then we'll talk again very, very quickly about some prerequisites in here, just some highlights from these other topics, governance, architecture, development, and quality. This will then lead us into a discussion of understanding cloud-based technologies. And then we can talk about the benefits that accrue from those technologies, which gets us to our goal again of smaller, cleaner, and more shareable data. We'll look at some of these references and QA at the top of the hour and dive in right at this point in time. Again, our focus here is on data management. Most people get scared off when you show them a chart like this because it shows that data management is a discipline that is five integrated practice areas. They are in the management version of this. The ability to manage our data coherently, the ability to share data across individual boundaries, the ability to assign responsibilities for the data, the ability to engineer data-specific delivery systems, and the ability to maintain data availability. If you don't have those, you do not have a good data management practice. Now, I mean a lot to Maslow's hierarchy of needs, and many of you remember from high school, you've gone through this. If your food clothing and shelter needs are unmet, it is unlikely that you're going to do self-actualization. And yet so much of what we do in technology, it falls into that same self-actualization category. That is to say that our data management practices are necessary but insufficient prerequisites to doing the self-actualization activities of master data management, big data analytics, and of course, cloud in all of these areas. We want you of course to pay attention to these areas, and the best source for this is the data management bloody of knowledge, and the certification comes out of it being the certified data management professional designation. And a shout out to some of my Dama colleagues who were last week down in Sao Paulo, Brazil. We now have the first two CDMP holders in South America who have now passed their exams in that area. Great job, Sue, and everybody who was down there working on that. So again, our series here is that most people, when they're looking at integration problems, are looking at it from technology pillars. They're looking at it from a silver bullet perspective. Our three-part series that we put together for you this year started off last month with metadata practices. We're now going to talk about cloud today. Next month we'll move on to what I call warehousing at all. Part one, we're pretty straightforward. Data management and data management in particular is important to people. You need to pay attention to it, and Gartner has come up with a terrific definition. Metadata unlocks the value of data, and the second half of the sentence is very important. Therefore, it requires management attention. The metadata practices that we look at specifically mean that we need specialized team skills in the area of metadata engineering, metadata storage, metadata delivery, and metadata governance, so that we can match sources and uses of data so people know things like the provenance of the data, its origin, its lineage, if you will. Metadata becomes the language of data governance, and metadata describes the essence of the integration challenges. If you have an integration challenge, and it is not specified in metadata terms, you do not understand that challenge fully. Now, we've looked at this data management body and knowledge from a couple different perspectives. Again, just to warm up for this session today, data governance, again, and those two areas, data architecture and metadata management, all work as a related period to help you with those efforts. So we'll now extend this into the next area, and again, the idea here is data governance is one of four pieces that you really need to do, how to do well in order to achieve cloud-based success. Again, the first one is governance. I'm not going to go through this with you. We will all have gone through the governance tutorials where you have the real purpose of data governance is understanding what does governance mean to my organization, which means it's getting some individuals whose opinions matter. You need to have some people whose thought leaders are less. They need to form a body, some authority of purpose who will advocate, evangelize for, again, not dictate and enforce a rule because it doesn't work that way. What we are evangelizing for is increasing the scope and rigor of what we call data-centric development practices. Now, the greatest example of this is that most organizations have a lot of good people at their top jobs, your top IT job, your top operations job, your top finance job, and your top marketing job. Most organizations have not, however, implemented a chief data officer job. In fact, our survey show that 70% of the CDOs have been hired in just the last year alone. The reason this is important is because the chief data officer has to create a governance organization and takes these data assets that such as these are foundational building blocks for IT projects. The CDO then coordinates these IT investments with the top IT job, and the CDO determines when IT projects are ready to go. The more you separate these functions, the faster your IT projects will go. One of the other questions we get a lot is how does this work with agile? The answer is it precedes agile and if you are prepared, doing data governance will make your agile organization even more agile, your projects faster. One of these is architecture management. Again, we have our slide here describing this. I'm not going to go through it with you. The idea is, of course, architecture talks about arrangement of large components and the interaction of those components. When you do that, the best place to start is John Zakman's version 3 of the Zakman framework or what he's calling it now, the ontology. This is the idea that an information architecture is a database structure of information assets supporting the implementation strategy. All organizations have data assets, but most of them are not supportive of strategies. That is, their information architectures are not helpful. So the real question is how can organizations more effectively use their information architectures to support their strategy? Yes, of course, is that the organizational needs have been instantiated into information architecture and this articulates specific information systems requirements. We have a feedback loop and everybody's happy, but most people think this occurs once, actually, it's a continual process. So our better definition of architecture is that all organizations have them. The question is, is yours understood and documented and useful? If it's not, it's going to be difficult, and if people try to figure out what it is you're doing, you're saying you're trying to come up with a common vocabulary for everybody in the organization to speak. The development activities, again, these are the pillars that we're doing. The idea is that most organizations have no clue when they build a database whether that same data goes into the next project or not. Should the brown database be used to support the things that the database is doing? If we don't have somebody officially looking at it, the answer is no, and it's easier to build a green one and then a orange one over here in order to come up with it. Again, our data development focus is broader than software architecture or database architecture. The analysis on the system-wide use of the data and on the problems talked about specifically by data exchange interface integration type problems. The architecture goals are strategic rather than operational. And just so that you know, all data development activities can be represented in this particular framework that we're going to come back to at some point in the summer. In that every change can be mapped to some transformation in this framework. It's a very formal process. It's very easy to do once you understand it, but it's not taught, so it's not really well understood. The last one is data quality engineering. Again, it's fit for use. The idea that we're going to look specifically at this, and we did a whole seminar on this a while back, but again, just to remind you of the key points, quality management is the idea that we're going to put something in place that allows people to do this as a formal way of doing this and that it's a continuous process and that data quality engineering is something that is known well within the business but not well known outside of it. I told a little story about PAPA. I see if anybody remembers that particular story later on. Again, the idea is that we have quality dimensions that are not generally addressed beyond the value and representation of the quality. It's the quality of the models and the quality of the architecture that supports them, which gives us a very different data quality lifecycle than most organizations have. Again, the questions that don't go into this, and you'll see where it all ties together in just a minute, is that if I'm putting data in the cloud or the lake, do I want to clean this stuff up before or afterwards? Does the data have to be perfect? Can I find out what a Pareto analysis looks like of my data because not all of the data is of equal importance? There are specific engineering disciplines that we can bring to bear in order to do this. So our prerequisites that we have here, let's now dive into what cloud-based technologies do. I found a terrific infographic on the web. These things are fun to put up on your wall and look at it. And the idea here is, of course, from this side, this perspective here, what we're looking at is a data management technology component. And again, you can see the telegraph in 1861, the telephone fax machine. By the way, the fax machine was actually invented in the 1870s as well, but it became useful and widespread use in the 70s. Email, the World Wide Web, Wikipedia, et cetera, et cetera. If we look at the other side of that little pyramid, there we have the other side of it here, the mechanical computer in 1821, magnetic tape, the desktop PC, data warehousing in 1990, and we get the cloud version, put them together. And we now see that there's a very nice marriage of data communication and data management together with a home in the cloud at last. Now, terrific infographics. They're a very useful way of representing these things. Let's look at another really useful infographic, which is something called the Gartner hype cycle. Many of you are familiar with it. It starts out where you have a technology trigger and you rise to the peak of inflated expectations. When you get to the top of the peak of inflated expectations, hang on to your stomachs because you're getting ready to dive into the trough of disillusionment. That trough produces large, very discomfort as people find that the syllables don't solve all the problems that they supposed to. We then get to the slope of enlightenment and eventually level out on the plateau of productivity. Now, let me show you the Gartner cloud hype cycle. This was dated 2011 and, nevertheless, while clearly maturing, cloud computing continues to be the most hyped cycle in IT today. So just a word of warning, it is a lot of talk and a lot less in terms of people actually being able to do things with it. So what do we mean by cloud computing? Well, the location independent computing, this is the idea that pieces are available on demand that we can plug into the cloud and the cloud will give access to things in the same manner that people understand the electricity grid. Now, that's a nice idea and it's being implemented very, very well in many organizations and in many contexts. Those of you that are familiar with music streaming services know that your music exists somewhere up in the cloud and when you play it in with your device, you get the music that comes to you and you don't actually have to carry it around with you. It gives you the opportunity to access any of your music, not just the stuff that happens to be on whatever device it is you're using. The natural evolution of virtual is service-oriented architectures and utility computing as in on-demand type things. Members do not have to know these details. They have no expertise, no control over and the cloud infrastructure supports them. Now, this is important because we're also talking about where our various IT organizations have gotten to in their relative maturity. Some of them are very good at this, many are not. So let's let somebody else manage this. But again, let's look at what this means. Again, cloud computing is a set of disciplines, technologies and business models that allow us to work through these things. And again, they talk about five particular characteristics, shared infrastructure, on-demand self-service, elastic and scalability, processed by consumption, only use it when you need it and dynamic and virtualized. So what does this mean from an actual usage perspective? This is where management starts to pay lots of attention to this. If you're looking here, and this is a graph from Amazon advertising their ability to deliver this, I'll uncover the first part of this. You can see that the actual cloud infrastructure is the green versus the conventional infrastructure, which is that blue line that runs across it. So the cloud infrastructure has broken through the conventional infrastructure, whereas we had an unexpected surge in demand, and our servers might not have been able to handle it at a point, whereas with the cloud they certainly were. When the demand lulls towards the end of that particular curve, we then can drop back down and use less than we had. So before we had only the blue line and more to our capacity, as I'll do at this point, we had the same type of thing that could go into place. So hopefully everybody can see the cloud gives you a much better way of matching your supply and demand than it does, in fact, and looking at it from a fixed perspective if I have to go out and buy disks, for example, in order to do this. This now gives organizations a very attractive value proposition. I don't anymore have to manage the size of my disk form, but instead I can put this in place so that it will now give me the ability to scale as I need to, and as I don't need to, I can also shrink. Again, just think of it as needing to peak load. In the past, your IT infrastructure had to be built so it would handle that largest time that you were going to need it. Well, okay, that means you're going to have more most of the time, particularly if your peak time only occurs while you're out of 24 during the day. Again, some business models that's going to make perfectly good sense for, other business models it's definitely not. So this scalability, this ability to grow and shrink as is needed, as long as you're making money with the growth, it turns out to be a very nice proposition on this. So again, if there's questions, we can certainly get to them, but I think this is a very, very good rendering of it. What you end up with, of course, is that the sale you're trying to do nowadays will just connect everything to everything else. And that will make everything wonderful and everybody will be happy. And it never, of course, works out quite as easily as that, but it does give us the opportunity to increase our capabilities in some very significant ways. That's a nice way of describing this, and I may sort of look at it as a ladder to the cloud, which is a nice way to describe it again. Consolidated data sharing is their first idea on the bottom floor. They have a couple of organizations, instead of everybody having their own data centers, they may in fact move them off to other places. I'm aware of many, many organizations, particularly hospitals, that have moved their data centers to somewhere else and let somebody else manage the data centers. Take a vendor like Cerner, for example. Cerner will manage the data center for you, so you no longer have to, so you can get on with your key business, or key business, which is the idea that you're saving lives, doing research, whatever it is, the sharing of the organization. Well, once that has happened at that consolidated data center level, you can move to something called a virtual data center level, which allows us now to get to a, wow, I don't even need a data center at all. I can have as much or as little data center, nests as much as little data capacity as I need to have, which allows me now to go in and do the kinds of things that I need to with a very dynamic environment. If I need that much capacity once a week, I can buy it and pay for it only one day a week instead of having to buy it and keep it forever on the off chance that I might need it once a week. The next ladder is the private cloud, which allows organizations to be set up for automatic provisioning. We're doing this in the middle areas. We send off different aspects of lighting forces. We are now setting up their own areas so that they have automatic provisioning so that everybody starts out with a, essentially just like a provision in your NAPSAC, the cloud that gives you certain data that allows you to get these things as well. This operator on a chargeback model, again, they'll take the military model as the one that you should follow, but it's a very well implemented model within there. Finally, our last idea on this is a public cloud, which means you're using somebody else's. You're using Googles. You're using Apples. You're using whatever. And this gives you, again, this idea of extreme scalability with no major capital expense to go into this. But of course, as you're doing all of these things, you're making trade-offs. And the question is, what are the various trade-offs that you're having to make and how do they work from the organizational perspective? Excuse me. So here's a way of looking at this as well. And I don't know where I get this particular trick from, so I apologize for whoever we ended up grabbing that from. It came, I think, into the deck. Very nice set of things, software as a service. It's in the left-hand corner, specialized. Maybe they only service very narrow section of the market and focus specifically on the applications in the middle where the database is and things that they're doing. They move over into the next green one, the engineered stack, which is the idea that we're going to put together a specific stack that's going to be well-suited for, oh, just say, a transportation or a logistics component of it. Again, here's a private cloud idea. So we can encompass many of those things, but we're going to make sure we keep ours away from everybody else's. So there's just no chance of mixing anything up. Then, of course, we have the public clouds. The functionality goes down. It's no longer supporting the applications in the middle where it's more operating system or even server or storage level. And there's a colo, again, that's the same thing we saw before about the services located before. In fact, we have the network providers, the telecom providers that are simply providing network components. And people have a pretty good idea of these, but then, of course, we have our really fine pieces that we need to get into, which is how does Big Data fit into all of this? And Big Data, of course, is a challenge. Again, those of you that have heard me before, I don't like the term Big Data because Big Data doesn't unfortunately mean anything. If we talk about Big Data techniques and Big Data technologies, now we can have a good discussion. The Big Data techniques do not mean anything. It's a vague, ill-defined term, and it's going to be difficult. Nevertheless, we do have to address it, which is to say that we have some Big Data techniques and technologies that we may want to bring into our cloud environment or may want to take advantage of our cloud environment. Now, there's two pieces of this that are important at this point to point out. One is that from a Big Data technologies perspective, this means I can now incorporate flash memory and faster access than disk-based access to things so that my memory for my servers, instead of being measured in megabytes or gigabytes, as it is on our PCs now, can be measured in much larger quantities. Again, Facebook and others have developed their own specialized servers with enormous amounts of capacity in the brainware part. That is leading us to some very, very interesting opportunities. What can we do in memory computing as the general term that you'll hear for it? The second one, then, is the idea that we have also a terrifically large amount of storage that is high speed instead of low speed. In the old von Neumann architecture, we used to take data, grab it and bring it to the processor, and then put it back out on disk. Now, that process can be entirely inverted, and we can take the processing and bring it to the data. Very, very exciting possibilities in terms of what can go into this. And when you add the cloud environment to it, it adds another layer of both complexity but advantages, benefits that we can see this. Let's get some of those benefits as we go around here and see what happens. First here, why should you use cloud computing? When we've discussed this a couple of times, you pay for only what to use, assuming you set your contracting upright. By the way, don't let people who don't understand what they're doing be the ones who want us to comment on your various service contracts because these can lead to a lower total cost of ownership. Again, the graph that I showed you from Amazon earlier, instead of having to make a step function and always engineer your infrastructure so that it is able to meet your peak demand, if you have the right service levels, the right partnership with the cloud vendors, your service level can expand dynamically as it is needed. You can also improve your reliability and scalability, and I don't want to leave you with the impression that this is fallible, excuse me, infallible. In fact, Amazon has had some well-publicized outages, not to pick on them in particular, they just happen to be in the news, and people have lost some very significant amounts of data and processing when portions of Amazon's cloud have failed on them. And it's not a usual occurrence, it runs very, very high reliability, but it's not infinite and it's not perfect, so to make sure that you have built things in structure that will make manage those the things that are good and at the same time hedge against the things that don't work. The cloud can be more secure. Again, this thing is more secure than locking a disk in a drawer somewhere and putting it behind locked doors and sticking that inside a vault and putting that behind armed guards, but that secure storage environment can get picked to that as well. In addition to lower total cost of ownership, we also have a lower capital expenditure in these areas, which means that your internal resources no longer need to be focused on those aspects of things. We can free our brilliant people up to go off and do other things that are better for them. And look into the specific technologies. You'll see they're highly automated, which means as things fail, things automatically take over. There is automatic fail-safe. Again, one of my favorite stories is the Netflix Chaos Monkey that runs around on their intersystems just causing problems to keep the people on their toes. It provides an environment where they don't know that things will necessarily go wrong, but when they do go wrong, they are well-equipped to adapt and put them up. But I'm not aware that Netflix has any cloud storage offerings, although clearly it's delivering all of that wonderful streaming video from cloud-based servers. In other words, you can look at the utility of your organization, things that are useful for your group, and particularly, you might not have to get everything else out there. And these things become better and more automated and more mature practices. They become easier and more able to develop and deploy them. And they now can be device-located and independent and offer large, good support that's in there. Again, a little more benefit. It's easier to administer the software. These are what people are looking for. This is a TechSoup survey on this, but it's easier to access the software. It's easier to recover from a disaster. You have reduced requirements for system administration and much more rapid development in there. Again, cost, lower capital, fewer IT staff needs, and you're transforming these capital expenses into operating expenses, which means it's a cheaper form of money. You have a different form of partnership here where you're working with the vendors, and it's easy to partner with other organizations. And from an integration perspective, too, if you put your stuff in the cloud, then they only have to gain access to your cloud in order to gain access to your stuff. So if you have a collaborative venture doing, and I'll talk about one here this week that I heard that was far fetched, but it's kind of interesting. Some of you may remember that Jeff Bezos bought the Washington Post this week. And I heard one pundit saying that one of the reasons he bought the Washington Post was not so much for the newspaper, although it's a wonderful newspaper, but actually he wanted his delivery staff. So you can imagine now the Washington Post showing up in your mailbox every morning along with your Amazon orders from the day before. Interesting. From a delivery model perspective, a very easy way to do that. Now, again, the better both the same there. In other words, if one person can gain access just by gaining access to a cloud, another one organization can gain access to a cloud, and you have poor security in place, well, that's not going to help as well. So you just have one single point of failure there and people can gain access to it. So data security is an important component. Data, if you follow my guidance here, again, of less data, more wearable and higher quality then it should be better data organization under your control that you're able to put in place. Another one, again, improved data quality is something that people anticipate getting out of this. Although in practice we have not seen this. What we have seen is that most people fork-lister data into the cloud. I'll show you an example of that a little bit later on and it ends up being a disaster for them. Again, reduction in installation and maintenance efforts, implementation efforts, manual processes, again, the amount of automation that we can apply in this is large. Reduce time to collect and prepare the data, and it's easier in general to apply the data governance practices that you need to in these areas. Let me get an opportunity here that the federal government is now going through. This is two years, excuse me, three years old at this point. Vettkundra, who is the federal's chief information officer a couple of years ago, said, look, we've got two data centers and we have been going from 400 to 1,000 and we've got to do something to do this. This is purely a cost perspective and he says we're going to move to something called a cloud-first policy. With the idea that we're going to think that the cloud has our place of delivering these things first rather than going the other direction because if we go to the cloud first we have the people seeking in those directions. People will understand what it is they're trying to do as a cloud-first piece. And interestingly enough we have some precedence for the way this works. Again, some of you know my background. I started out in the U.S. Department of Defense in the early 1990s and I was part of the group to put together a law called the Klinger Cohen Law. At the time it mandated, made it illegal for anybody in the federal government to buy IT resources unless they could be shown to be supportive of the existing IT infrastructure that the organization had. So again, I'll make it very specific if I was purchasing something for the group that I worked for, the Defense Information Systems Agency. And I could prove that that IT resource that I purchased complemented the existing IT architecture that we had in the U.S. Department of Defense. It was a violation of U.S. federal law. Now, frankly, I don't know anybody that was ever arrested and charged with violating the law. But it did bring the force of law to what we were doing when we were meeting with people and people say, why are you doing that? And we say, because it's the law. It's not just the right thing to do, it is the law. Well, this cloud-first policy here is the same thing. And we're going to have a federal government that is, in fact, more advanced in many ways than many of the people out there working in the private sector. So while I have data that shows that the federal government's data management practices are better as a result of the Klinger-Cohen law on this, we may see five years from now that that country's initiative here of going to the cloud-first helped us to train and sort of encourage with a bit of a carrot-and-stick approach some of these things in terms of moving to the cloud. So again, great ideas. Sometimes we get mad at the federal government for doing some things, but this is an area in which case the federal government has done some very, very good things. Let's take a look at the meat of the presentation here, which is data in the cloud should have three consistent attributes that data outside the cloud should not have. It should be Klinger. This is a pretty easy argument to make. If we're going to put data in the cloud, we want it to be of lower quality. Now, I know that sounds like it's a bit of a no-brainer, but by God, if we put data in the cloud and it gets messed up in the process of going to it or it's not clean in the first place, you'll have a lot more accessible access and data of a lot lower quality. So take this opportunity of data outside the cloud or data inside the cloud. It's very easy to determine where the data is. It's either in or it's out. Let's make sure that as we're putting it in the cloud that we in fact run it through the various data quality engineering activities that we talked about a couple of webinars back as we were doing this. Data in the cloud should be of cleaner quality than data that is outside the cloud. Data in the cloud should also be smaller in volume. Now, this immediately sounds like it's contradictory to the big data push, but hear me out on this. Have data that is properly engineered that our data should be also more shareable and that more shareable should be smaller. Now, that means that our numbers are very clear on this. When we look, data in the cloud is about one-fifth of the volume of data outside the cloud in a properly data re-engineered scenario. This means that you should be paying one-fifth of the cost, et cetera, et cetera. But the only way it will work is if it is also more shareable or shareable or, I know that's a terrible issue on that, but these are the points. If it's not cleaner inside the cloud than outside the cloud, then people will continue to use the data that is outside the cloud. If it's smaller, it will be easier for people to get their hands around to understand what is there and to create the third attribute, which is more shareability. Again, we want our data to be cleaner, smaller, and more shareable inside the cloud. Now, what we always see when you see these pictures is this wonderful aspirational picture of data in the cloud. Oh, fabulous stuff. It's going to be so easy. We'll just stick everything in there and it will be fine and dandy. Well, we cannot just take the data that is outside the cloud and put it into the cloud. Other than through a process called architecting or re-engineering. There are two specific goals of re-architecting. Again, maximizing effective organization-wide data sharing. Those of you that are seeing my triangles pictures know that I'm pushing for data-centric methods where data centrism is the part that we start to do before we think of applications and networking. Only with an organization-wide perspective can we understand how data is used. Very interesting. I was talking to an executive from a very large financial firm just the hour before this. And one of the things that he indicated to me was that the past three months had all been focused on their concept of sharing information internally about the customer. She said, and I kept reminding him one of the things that you tell me all the time, Peter, which is that customer is too simplistic a concept. For everybody to use. We need to classify the customer. I'll give you two examples. Are they current customers or are they not customers? And knowing these two differences makes a huge amount of difference in terms of the way we're going to architect the data around this concept of customer. The second component here about re-architecting is that we have to eliminate or at least minimize the amount of rot that we have in the data. Those of you that are encountering rot for the first time, I wish I could tell you that I'd invented the concept. I did not. It's out there on the Internet and there's no attribution to it whatsoever. So somebody's going to take credit sooner or later for coming up with the idea that data in organizations is 80% redundant, obsolete, or trivial. In which case you should ask the organization why maintaining data that's money that is redundant, obsolete, or trivial. Again, our volume inside the cloud should be one-fifth the volume outside the cloud. That's a significant economic motivator. This means when we look at this, in our various collections that we have outside of the cloud, each of those collections of data, our data stores, if you will, have individual strengths and weaknesses. You need to understand what the strengths are and leverage them. You need to address the weaknesses. If simply forklift the data into the cloud, neither of these can be accomplished. And what this means is that the data will not possess the same attributes inside the cloud that it does outside the cloud. And there's no real reason for doing it. Most organizations do it this way. When this happens, we get very discouraged and we hope in most cases that we can help intervene in organizations do this. Again, very, very few who work in the area who understand how to do this. My team has done some remarkable things in those areas. Let's look specifically at what we're talking about here. Getting data into the cloud. In most cases, they say how much data do you have? We handle it. And they move the data into the cloud. The reason we're forklifting the data is that there is absolutely no basis for any decision-making. In fact, one of the reasons forklifting is so popular is because it takes the decision-making process out of this. They have no thing to think about. We just simply say, let's put it all in the cloud. By the way, that can be a very easy decision for people to make because at least the data is in one place, the cloud, and we know where it is. It's not on somebody's spreadsheet or there's no more hidden show IT services and things like this. But it's not good because when we do this, we don't have any inclusion of architecture or engineering concepts that are in there. The data that's in the cloud is the same as the data outside the cloud with the one difference being that it is in one place, and it will probably cost your organization a bit less. However, there's no ability to go in and say that there are some concepts moving from the processes. And the first concept that's missing, the idea that the cloud itself is a nation, a change. It represents the transformation of the place where the data used to be in your legacy systems and now it's in the cloud. Well, it's an opportunity for everybody to pay attention to it, to learn more about it, to do some education, and finally to add in these three fundamental engineering concepts that I talk about. So again, the idea is let's look at a formal transformation process of getting it into the cloud. It represents a barrier, which means we can have a governance process around it, and we can say to organizations and everybody else that's involved, nothing is going into that cloud unless it has been through a formal transformation process. We're going to screen it drop, we'll make it smaller, and we're going to clean it up. So again, the data of the cloud is less, it is cleaner, and it is more shareable. Even if we're not doing these things, we lose a phenomenal opportunity here. So as you see your organization headed down this pathway, oh, don't worry, we can clean it up later on. I've got a funny graphic that shows you a little bit about that. Before we get there though, let's talk specifically about what data is. Data is your organization's sole, non-deplatable, and rating double strategic asset. Talk about data. We take awful times about data management, and that's really a very bad set of terms that we use. We have to take a blame for some of that, we weren't imaginative enough. If we really wanted to get where we would be in terms of our thinking, we should be talking about leveraging data, because that is of course what you do with an asset. Right now, data as our sole non-deplatable, non-degrading, durable strategic asset. This means within the organization, as well as with our data exchange partners, we need to deal with lots of it. We're getting barraged with all kinds of things that are coming at us from all kinds of different ways, and this is a very big challenge. So anything we can do to make this more useful is going to be helpful to the organization. Now, the leveraging concept here is the implementation of these data-centric processes, technologies, and human skill sets, all of which are lacking, although technologies are at the top of the pyramid that I showed you about 42 minutes ago when we started out this. Again, because one of the integration technologies next week will come back and look specifically, excuse me, next month will come back specifically and look at warehousing at all technologies in these areas and how they fit into integration. But if you think about it, when you look around the organization, your organization is spending 40% of its IT budget doing integration-type work. It's sad. It means your knowledge workers are less productive than they should be, which means they're frustrated, and they're generally not indicated around these areas as well. It's not to say that they're not smart people, but if they have a case of you don't know what you don't know, now you have a big set of challenges because people don't know that there is a better way of doing this. So if we look at our little processes here, this is the idea of people trying to work with a lever. Our people know how to use the lever, so they pull down on it, and they can pull on that lever until they're blue in the face unless they had one other piece of technology, which is that fulcrum that we have for the lever. So the two technologies working together, the combination of the lever and the fulcrum, allow the people to use leverage to move the heavy object, and that becomes our organizational process. Again, the bigger the situation, the bigger the potential leverage that exists there. And if we remove rot, the leverage similarly increases dramatically. This means that we need to treat the data more simultaneously. Excuse us, I like simultaneously. So we can lower IT costs and increase the knowledge worker productivity. And then if you're thinking about analytics, as we see this wonderful new term come up, and everybody is having a great time saying, wow, learn about the customers and do some analytics on things like this. That's a fine thing to do, but when you go out and hire those data scientists, they go around and spend a lot of time being idle because they are simply doing things that this process will take care of. I tell organizations that are trying to do this, hold on to hiring your analytical people or you'll bring a bunch of people that are really highly paid, and the first thing they'll do is they'll spend 80% of their time doing stuff that somebody a lower paid petitioner can do. The story around that, perhaps, when we get to the question and answer session, we can talk about them in a little bit more detail. Let's go back to why it is that we need to have the cloud really, really well understood as a destination. Yeah, it simultaneously becomes a place where you can go in order to do this, but you should put data out there in the way, and I had a friend of mine call this data branding. I think it's an excellent term. Data cloud can become known for being higher quality, less in volume, and more shareable data in other organizations. The executive that I was talking to just before we started the webinar here was explaining to me one of the things that they, for their customer data warehouse that they're looking at, is that you go in and you can actually get in this one place a record that represents the customer. If you want to find out what the customer has been up to, you have to go to a number in the dozens of other sources to find where that is, because all that gives you is a bunch of pointers. You have to develop your own access methods in order to come in and use these points to grab things and bring them to different other places. So if you look at data with the integration tool, we should also look to it and say that this data that is in the cloud is of known as opposed to unknown qualities. This is because we can apply things like continuous improvement, statistical control, quality cost models, and most importantly, empowerment of things that go out there. If we can reduce the data, we can start to get better and more broader pattern analysis. We can now start to understand different components of mathematical and schema evaluations that go in there. We can now start to impose standards on these processes. But technology allows us to implement reusability and implement better types of technologies that we have and look at more specific language opportunities that we have in there. Now let me give you a quick little story of one organization that I worked with. This organization had a very courageous data manager and what she did is that when people were using the data, she made them sign a little thing that popped up like a Microsoft product license. And it said, I know I'm using bad data and therefore I'm wasting company money. Well, that kind of sucks. Word got back to her CEO pretty quickly and her CEO said, you shouldn't do that. And she said, well, no, it's true. Data is not of good quality, right? It represents a waste of customer resources, excuse me, a waste of organizational resources as we use this. So they allowed her to start putting data in the cloud but only data that was of good quality. So people recognized when they used data outside the cloud they got this little disclaimer that said, I'm using wasting company resources but data inside the cloud acquired a brand. It was good quality data. It was useful data. It was data that was easy to use. It was easy to access all of those benefits that I talked about before on this program. This allows you that opportunity. We only pay for it as you use it. So rather than forklifting the data into it and starting to pay for lots and lots of this data storage, you can now implement these techniques in a way that allows you to do this. And by the way, if you have to go in and fix data that's been forklifted into the cloud, keep these pictures in mind because these pictures are what it does represent to have to use. This is a device called a glove box. And usually the things on the other side are unpleasant. Many organizations are having to do this. A couple more points here. We come back to the top of the hour. Again, I told you we'd come back to this diagram in particular, let's talk specifically about the re-engineering of data. Now again, we have what I call the Data Development Evolution Framework that allows us now to understand specifically here what it is that we're trying to do when we re-engineer data. We have our as-is models, our 2B models, our conceptual, our logical, our physical models. And I add another dimension to this as well. The models are validated or, ooh, I have a mistake there. It should say unvalidated on that slide. So either validated or unvalidated models. This gives us the opportunity within this framework to understand and more importantly represent every transformation that needs to occur. Let me show you this. I'm going to pick up with this and hopefully it'll be helpful for everybody at least explaining to how this works. So this is where we typically show this. We have our as-is and our 2B. We kind of gloss through it. And data people really get this, but let's make sure that our business partners understand this as well. Below the horizontal line there are things that are technologically dependent. This means we have a data-specific version of it or a cloud-specific version if our as-is is outside of the cloud and our 2B is in the cloud. We, in order to re-engineer this, need to abstract our data up to a level that is independent of technology. We have a logical representation on this. We then move it to our 2B. So the idea is we start off with our technology-dependent physical as-is model and we move it up to a logical representation by taking out everything that says, oh, just for example, Oracle or DB2 or Informix or Teradata or whatever the platform is that you're using on it. Then and only then can we move to our 2B or our more shareable state and finally move it into the cloud. That is a bit of architecture work that doesn't actually move any data. But what results from that is a plan to take our physical as-is data to move it into a common format. Again, our more shareable format and put it out there. And the problem is when we explain it that way, everybody goes, wow, I don't see the value in that. So let me do the whole over again, which is to say we start off with our technology-dependent piece that starts to occur here. And then we abstract it up to that level, which we did before by removing all the technologies. But now we have a time dimension that needs to occur in here. And what happens is during this time, other logical as-is data architecture components are added, are supplementing to our existing model. And I'm going to transform the existing model to a blend of these technology pieces in here. So you can see it's a combination of the orange and the green. And then and only then when we have transferred all these things in here and decide how the span of it is, how large the span of our architectural engineering needs to be, what types of things we need to pull into play, et cetera, et cetera, do we then move that piece over into our 2B and finally put it back into our model. So hopefully that's a way of describing that a little bit more conveniently than we've been able to in the past. If we don't, we will have people who just want to forklift the data. So we're almost at the top of the hour. Let me give you a couple of quick takeaways on this for part two on the aggregation. And this is the idea that first of all, if you're going into the cloud, you cannot do it correctly unless you incorporate aspects of data governance, data architecture, data quality, and data development. And that these practices in your organization need to be of sufficient maturity in order to take advantage of the self-actualizing cloud-based practices. If you do not, you will enrich only the cloud that matters. There are a variety of cloud options and these architectures will give you opportunities to do different forms of implementation. The joke is, if you don't know where you're going, any road will take you there. And if you don't know which architecture you need, any architecture in the cloud will serve your needs. However, your organization has a strategy. If you understand that strategy and how data is a part of that strategy, and again, our surveys show that only 110 organizations have formal, board-approved data strategy. Then and only then will you be able to understand the options that are available to you in the cloud and implement in a way that complements your existing IT and business architectures. Data must be re-engineered in order to take advantage of the cloud because if you do not have data in the cloud that is of less volume outside the cloud, that is of greater quality than data that is outside the cloud and that is more shareable than data that's outside the cloud, the only thing you're doing is putting money into the service vendors product and less in your organization. However, if you take your data, understand the governance, architecture quality, and development which would be an absufficient business value to it, understand which cloud architecture best complements your existing IT and data strategies, and understand the practices associated with re-engineering your data to be less more shareable and of better quality, then you will be able to take advantage of this exciting new cloud technology that we have. We're back at the top of the hour. It's time for questions and answers. I'll turn it back over to you and we'll see what questions we have. All right. Thanks, Peter. That was a great presentation. Now it's time for Q&A. It's time for all to ask your questions. So just click on the Q&A feature at the top of your screen. You should be able to submit your questions through that Q&A window. So let's just give it one minute here and see what we get in. You should have come up with some fake questions to get people started, shouldn't you? You know, one of the questions that comes up most often on this is that people don't really see how they can get their organization involved into discussion of cloud because clouds are always off on the infrastructure group, particularly in large IT organizations. I get this question a lot, and maybe this will help spark some of the other questions. But when you look at the infrastructure side of things, they just look at cloud as a place to stick things. And that is, in fact, one of the things that it does bring. And it's a good advantage to it. But if you look back at where you're seeing organizations that are really achieving success in these areas, they're actually incorporating the things that Reagan is very specialized at doing, which is a marketing-type function. And I say to people, oh, all our data is of terrible quality, which often does happen in organizations. I can't tell you how many organizations I walk into and say, you know, Peter, our data just sucks. Well, it actually doesn't. You have some good data. You have some bad data that's in there. But if you start to use this as beyond a technology play, it's actually something of business value to the organization, which is to say that we're going to have some only good quality data out there. So then people start to get excited about it. And even in your infrastructure group, we'll say, wow, it's actually good because I only have to buy such infrastructure in order to actually support that particular aspect of it. Anyway, that's the question, but did you get any more on there? I didn't see here. The first question is, do you recommend production data to be in cloud? Well, that's a good question. It's actually too vague to answer in the sense that if production data has the dependency that somebody will get literally killed, so for example, the Army uses clouds to support some of our military operations, I want to think twice about whether you really want production data in the cloud. So again, it's going to go back to your strategy. What is your organizational strategy? How are you going to implement your organizational strategy in IT, and how of that IT strategy is data a component of that strategy? So there are some very good reasons for putting data, production data in the cloud. Again, the example I gave earlier about streaming songs out of the cloud, right? What service that you use if it's coming down from the cloud. That is an example of production data being used in the cloud. And there's nothing wrong with this. People have very satisfactory representations. I also mentioned Netflix, which is an example of production data that's in the cloud. On the other hand, I spent some time with an organization, a big retail organization that was working at one point, and their data center went down for a number of days. You can imagine such a thing, which meant the cash registers weren't ringing at a portion of their retail outlets. You know, is that particular, and I'm not saying it was, is that particular how did it have been due to data in the cloud? Somebody would be seriously reconsidering it because you can measure the amount of sales that were lost in the terms of if the cash registers don't have any power to the computers that are there, they can't ring out that particular set of services. So it's not a simple answer to say, should production data be in the cloud? I think the question is more, you are probably the expert in that organizational practice, and what would be the strengths and weaknesses of cloud-based production data? If so, then you're the person who hopefully can take advantage of the information we presented here, and also the other things that you have, your business acumen, et cetera, et cetera, and answer that question specifically for your organization. I hate to dodge it, but I think that's probably the safest answer under the circumstances. All right. The next question is, what has happened in government cloud adoption since the Vivek Kandera Membo? So, as a odd first mandate, one of the best things that's happened is that most of the federal government IT shops have started to experiment with clouds, and we now have a wealth of experience three years on where people have learned some lessons, learned what works, learned what doesn't work. Remember, none of this is perfect in any way, shape, or form, but there's been a whole lot of really good education. And frankly, some of the people that are inside the federal government are now getting picked away by private industry who want to learn from what the federal government has learned on the various cloud initiatives that they've had. Second, have had some areas where the federal government has achieved some very significant cost savings by moving into the cloud, which is really the major incentive behind Kandera's initiative there. So there have been some very, very good things that have happened out of it. On the other hand, a lot of the data was fork-lifted into the cloud, and so a lot of the cloud vendors have pocketed more federal funds perhaps than necessarily ought to have them do. But we've also seen a lot more integration opportunities around those areas. So again, really, we have to sort of come back and say it's really much more of a lessons learned type in area. And out of these lessons learned, we're now getting better educated folks who have more experience around their cloud-based alternatives. Okay, and the next question is, how do you encrypt the data in the cloud? What encryption methods are available? Well, the encryption method that is available to you outside the cloud. These are, again, the cloud is an infrastructure that will inhibit you from implementing any one or any more encryption methods. It's a different form of disk storage. And so when you move data into the cloud, you can encrypt everything on the way in, and if it's all encrypted with the same encryption level, then you end up with one type of encryption that only has to be broken once in order for people to gain access to your data. So if you're thinking that the clouds are going to dictate that, that's really not what we want to think about. When you look at encryption, what you're really trying to do is to say, how can we keep this data from being read by unauthorized sources? And that encryption method is absolutely independent of the type of technology that the clouds are implemented with. So those two things are separate, although it does bring up a good point, and I have to say this was kind of interesting. The team and I were visiting a company, I think it was, no, just last week. I have to think where we were. And this was the first time in 15 years of this team being together where we had seen this organization put security architecture out there. They said, we know our data architecture is relatively unhelpful to our organization, and we want to come in and address both the data architecture and the security architecture at the same time. And as many of you know, I've done hundreds of organizations we've worked with over the years. This is the time in 15 years we have seen an organization say they want to do them both together. We absolutely were floored. We told them this. We said, this is the first time we've seen you guys do this as a single integrated step up front. And it does make sense. I'm betting that the caller here is part of a similarly mature group and saying, look, as I'm going to do this, I should consider these security issues as I'm considering the infrastructure issues that I'm putting in place. So again, very astute question that the actual form of the encryption is. It's just a hard disk, just like any other hard disk. Next question is, is the cloud a good place to put data when you are retiring an application? Well... Okay. When we say retiring an application, my understanding of the question and correct me if I'm incorrect here is that you're looking for a place to permanently archive this. Cloud can be a place to permanently archive this, but if you're really looking at a situation of saying, I'm closing down on the application, and let me give you a very specific example here that this one at least calls to mind. Many organizations go through these activities where they are looking to get rid of their existing applications and move them to the cloud so that they can do the expenses. Right? We talked about that back during the session. And this group looked over and said, hey, here's a server, and it hasn't been accessed in 11 months. Nobody must be using this at all. So we're just going to take and turn this server off. We're not even going to migrate the data to the cloud. Well, it turned out that that server was the one server that the CFO, who very technologically literate, used to do the year-end books on. By throwing that server away literally in 30 days later, the individual is going, where's my server that I used to do my year-end stuff on? That's why they kept that one server there because they knew the environment, they knew exactly what was going on. I'm not going to say it was a best practice. It certainly was not best practice to throw away the data without any backup. In that instance, it would have clearly been better to keep a backup of that. As you know, some media deteriorates, whereas digital media has the ability not to deteriorate. So cloud as an archival storage mechanism makes sense under certain circumstances. If you do have a question about specific archiving, though I would not approach it from a technology issue first, I would approach it from a process issue first. Because a process issue is the one that you are more likely to get in trouble with. Because if these things ever go to court and somebody says, what's your data retention policy? The first thing everybody's going to try to do is to say if you follow your data retention policy. So I'll recommend the question or two a book by my colleague and friend Jack Olson. And Jack Olson at Amazon, you will see he has a terrific book on archiving data. Start off with those processes first and then approach the technology. Because your processes in an archival situation are going to be important. That said though, let me take the question here from another perspective, which is I've got to leg it the application. I want to turn it off. It's got expensive hard drives. So I don't want to use them. I'm going to put the stuff in the cloud and then I'll integrate that back into the cloud as you said later on. That's a perfectly acceptable way to do it where it's holding something temporarily and moving it and waiting for subsequent integration. So again, I hope the differences between those two questions, the way I could approach those two questions are clear. And then certainly a good question. Again, please feel free to ask a follow-up if my answer is not good. The question is, do most cloud solutions reduce technology complexity? Yes. And that's one of the things they offer. It's one of the things that people want to do. Instead of your organization having to be good with things that they may be kind of good at, but you'd really rather than have the good at this value, for example, that absolutely represents a very, very significant simplification of the technology. Which is why it's so tempting for everybody to take and literally forklift their day into the cloud because they're just dumping it all out there. We'll figure it out later on. And again, this example is not a trivial prospect. So don't let people do that if you could help. Let's see here. What about the idea that data should be kept in its original raw form to preserve the possibility of alternate analysts later cleaning up a destructive process that can't be reversed? Absolutely. Again, this is going to go to your data strategy. If you're an organization particularly dealing with the aspects of data, how it looks in its original form, its provenance, where did it come from? Did it make a difference where it came from this or is it a copy of the original data? These are huge, huge important questions that you simply cannot leave and assume that putting it in the cloud is going to take care of them. In fact, sometimes the worst. They can read the question again because it's a very, very directly worded question. Okay. What about the idea that data should be kept in its original raw form to preserve the possibility of alternate analysis later? And that data isn't a destructive process that can't be reversed? Absolutely. Again, the questioner said it perfectly. Doing data quality on something often causes irreversible damage to the original component of the data if it's not necessarily a good or bad thing, but it's a risk that the organization faces. So your strategy will dictate your risk mitigation approach. I'll give you one example that I've used in several other contexts here, which is that the Lehman Brothers Barclays Bank when the brothers crashed and burned and went out of business, Barclays bought a bunch of the assets from Lehman Brothers. And the way they determined which assets Barclays would take and which assets they would not take was that they put them in a spreadsheet and they took the spreadsheet and hid the columns of the things they didn't want to take. So some of the cells were hidden. And then when they printed that data out, they said, these are the ones we want and anything that's not on this list we're not taking. Well, it turns out that they handed that list to a junior associate who went back and accidentally unhid 179 columns representing 179 contracts that Barclays Bank had no interest in accumulating. Again, this was almost a disaster for most of the organizations that were here. So as the caller said, the quality improving the data quality is often a destructive process that irreversibly harms the data. So the only way that you can say that putting that in the cloud would be a place where it would not be destructive is to make sure that you have a 100% bit-for-bit copy of both the data and the metadata going into the cloud or use the cloud as the source, excuse me, as the destination for where you were originally capturing it. Otherwise, you run the risk that the questioner said in there. A very, very, very good question on all of that. I hope, again, I've answered it for you satisfactorily. All right. The next question is, what factors should IT consider when choosing an approach? I'm sorry, Megan, what factors? What factors should IT consider when choosing an approach? Thank you. Okay, so I realize that while I'm clearly a data big idiot in this environment and I'm saying that the data assets are clearly important and that people need to do this, it may be a valid concern to your organization to simply reduce your cost of disk storage and do it very quickly. While I'm telling you the proper way to do this and saying, don't move the data into the cloud, use the branding opportunity I've described here and everything else, if your organization says, tough, I got to get these disks off the floor quickly and we need to put it in the cloud by tomorrow, look at it. All right. So, again, I'm giving you a data-centric perspective on this because we are actually doing this through dataversity and that's our lens through which we're viewing this, but there are other things that are important. So there may be things that are completely outside of our control for which we are simply not aware. Again, one of them I can think of here happened actually in Richmond, Virginia when we had a tropical storm named Gaston that came over top of the city and dumped 14 inches of rain on us in a matter of about four hours. Now, what happened there, interestingly enough, a data center group that we were working with, the storm floods. So the data center was in the basement and the storm just backed up and the water came up through the vents in the floor. They'd never plund on this. And if they said, ah, we're going to get flooded out in a couple of hours, you know, you take the data and you put it in the cloud as quickly as you can. That would have saved them a lot of time and energy because it took them literally months to rebuild that data center after that happened. Like the business was able to survive and, again, partly through good data management practices there. So there are lots of other factors that you need to consider. We've talked about some of them here as well. And again, I'll just go back and view, again, the various architectures for the cloud, again, the strategy, the organization. All of these things are going to be important. You know, is it more important that we support specific applications or is it important that cloud just simply function as the telecommunication system does a transfer layer that moves data bits from back and forth and back and forth. So lots of things to consider. Your strategy is going to drive this, which is why it's so important to do that first. Great. The question is, how is cloud integration different from traditional middleware there? Excellent question. So middleware tends to try to connect things either in a series of analysis. For example, I'm going to dive into a presentation that I'm going to do on Friday where we talk about different types of things here. So hang on. Where is it? There we go. I'm just going to put up some different middleware architectural integration options. They are listed. This is from a terrific book from an IBM or a person who put it together. It's data integration and blueprint and modeling. And the first one is enterprise application integration. The second one is service oriented architecture. The third one is federation. The last one is an ETL strategy. These are not the only ones, but these are four different types of patterns. So the question here is, could cloud be one of them? And the answer is yes. Cloud could play a role in any of these or all of these. Clouds can be used as enterprise service buses in some applications today. So the idea is when you're looking at integration, what are the strategic goals of your integration? What are you attempting to do? You're attempting to go for a standard merger and acquisition integration where both companies have a million customers and both companies have systems. And if we can put them together, we'll have 2 million customers in one set of systems and that's got to be better. It'll be better and cheaper. Or are there other activities that we're trying to do? What is the strategy that we're doing in order to do that? That would be our goal here. So that's definitely the place to start. Cloud is going to be simply a component that we can use or might not want to use depending on what we're attempting to do. So it always goes back to strategy. Great. And it looks like that is all the questions we have for today. Thank you, everyone, for participating in today's event. We hope you have enjoyed it. Thanks again to Dataversity and Shannon for hosting us. Once again, you will receive today's materials within the next two business days. Our weather next month will be data systems integration and business value parts for the warehouse thing. Hopefully, you'll be able to join us for that as well. As always, feel free to contact us if you have any questions. Thanks, everyone. Have a great day. Thank you. Thanks, Megan, for another great presentation and thanks, everyone, for attending. I echo Megan's sentiments and hope everyone has a fantastic day.