 Okay, we're right at the top of the hour. Hello, everybody. My name is Tony Shaw. I'm the CEO of Thetaversity. Pleased to be filling in today for my colleague, Shannon Kemp, who's taking a well-earned summer break. Today's webinar is the monthly webinar series on data insights and analytics brought to you in partnership with First San Francisco partners, and today the session is sponsored by Lookup. The theme is analytics, business intelligence, and data science. What's the progression? As you join the webinar, you'll notice that your audio is muted. We'll be collecting questions throughout the presentation, however, in the Q&A section of your screen. Or if you prefer to tweet, then you can submit questions using the hashtag of DI analytics. So as we get going, there's a few other points to get us started. You're also welcome to use the chat screen on the right-hand side, but we'd prefer if you could submit specific questions in the Q&A section, please. And to anticipate the most common question we always receive, we will be sending a follow-up email within two business days, which will contain links to the slides, the recording of this session, and any additional information requested through the webinar or unanswered questions that we didn't have time to get to today. So Kelly, it's my pleasure to introduce you now. Kelly O'Neill is the founder and CEO of First San Francisco partners. Having worked with software and systems providers who've been key to the formulation of enterprise information management over recent years, Kelly has played an important role in many of the groundbreaking initiatives that confirm the value of EIM to the enterprise. She's recognized an unmet need for clear guidance and advice on the intricacies of implementing EIM solutions. And to that end, she founded First San Francisco partners in early 2007. Kelly, it's a pleasure to be with you today. I'm very happy to turn over the controls to you to get us started today. Hello and welcome. Thank you so much. And good morning, good afternoon, and good evening. Nice to be with everyone again. So analytics, business intelligence, and data science, what is the progression? So this webinar that we're going to go through today is going to define each of these capabilities and then also talk about how they relate to each other, what the overlap is, and that sort of thing. Because truly it's not, these aren't three completely separate disciplines, which I'm sure that you guys are all well aware of, but there are things that are unique about each of them and can serve different purposes. So what we're going to talk about is we'll go through the definition. So that's where we're going to start. We will talk a little bit about the differences in architectures that are driven by the reasons that you would focus on a concept like business intelligence versus analytics. We will talk a little bit about when you would use a concept like business intelligence versus the other, and we'll close with the evolution and what's coming next. And then finally we will talk about some key takeaways. So I know that we allocate 10 minutes at the end for questions, but Tony, I'm always happy to take questions in the middle if there is something that is very pertinent to a specific topic that might be good to capture the idea at that time. So please don't hesitate. Okay. I will keep an eye on that. Yeah, absolutely. Also it might be more interesting for people to hear someone else's voice other than mine just every once in a while. All right. So why is today's topic important? Well, I do think that there is still a lot of struggle around, you know, how do all of these different new terms fit together? And if, you know, my boss told me that I need to go look into an analytic solution, what does that mean to my business intelligence solution? Does it mean that I need to replace it? Does it mean that what we used to do is no longer valid? So none of that is really true. So what we're trying to do is help to define when to use which of these core capabilities and how to put them together in a toolkit, if you will, to be able to provide to your organization different capabilities that are useful depending upon the different business purpose, different use case, and of course the different type of data. There are lots of different ways of going about doing this. The ideas and the examples that we're going to be going through today are based on our experience, our perspective. And I'm sure there are many of you in the audience that have other reference architectures that you might use or other viewpoints and perspectives. And so, again, these are ideas around how to help categorize, understand the capabilities and determine when, what is most appropriate based on a requirement within your organization. Okay. So there is no solid demarcation between these different styles of using data. And I want to just lay that out there and I might say it a few more times to make sure that you all leave today remembering that. But as we go through the definitions you will see how gray the area is. And I took the liberty to leverage definitions from the Gartner group because they do tend to be a well read, well distributed resource. And I thought that their definitions actually supported this statement that there's no solid demarcation between these styles of using data. So I'm going to start with business intelligence. Business intelligence has been around the longest. So that's why I wanted to start with this. And Gartner defines it as an umbrella term that includes the applications infrastructure's tools and best practices that enable access to and analysis of information to improve and optimize decisions and performance. So pretty general statement around what business intelligence is. It's not just technology. It's not just applications. It's not just your infrastructure stack. It's the processes, the consumptions and the best practices. How does this differ from analytics? Again, analytics is viewed as a catch-all term for a variety of different business intelligence and application-related initiatives. So I think what's kind of happening here is what we used to define as business intelligence has kind of morphed into a broader umbrella term that is now being called analytics. Analytics could include business intelligence. It could also include other sorts of more contemporary or modern ways of analyzing data based on new data types that are more accessible, the ability to leverage new data volumes that are becoming more and more accessible also. So what is data science? Well, Gartner actually groups data science underneath advanced analytics. So they define data science as the autonomous or semi-autonomous examination of data. So that's one thing that is different is it talks really about focusing on the examination of the data as opposed to the process of analyzing the information. And that is a difference is that it is really focused on the data itself. And to a certain extent, trying to have the data present the correlations versus analytics trying to use the data to mine the data to come up with some sort of answer to a business question. But advanced analytic techniques also include things like data and text mining, machine learning, pattern matching, forecasting, visualization, semantic analysis, sentiment analysis, et cetera, et cetera. So I don't need to read this to you because of course you can read that yourself. But I do think that data science has become also a catch-all phrase that is leveraging new tools, new capabilities, and advanced concepts like machine learning and as we move into more artificial intelligence and ultimately leveraging neural networks for deep learning. So if we think about these definitions, one key differentiator is that business intelligence and analytics were focused on the business questions. And then they started to hire statisticians. As they started to hire more and more statisticians, that cadre of statisticians, excuse me, my goodness, statisticians became known as the data scientists. And those data scientists applied additional rigor, mathematical analysis, and more complicated quantitative analysis to become more scientific. In this way data science focuses on the data and business intelligence and analytics tends to focus on the business requirement. But they do work together and complement each other to provide a complete picture of a, to resolve a business question or to promote business decisions. Data science can be viewed as a foundation for business intelligence or analytics. And business intelligence and analytics really is across the spectrum and data science is that capability of identifying anomalies in the data, developing the algorithms that are essentially used by business intelligence and analytics. One thing that is unique and as you can see by the definition here is that data science provides insights that are not possible with traditional descriptive business intelligence tools. So again, this is as the title of this webinar indicates what's the progression. This is a progression that leverages new capabilities, new technology, and new learnings that we've had in the market. So then the question becomes, well, which one do I use? Really the answer to this question is driven by what you are trying to achieve. Are you looking to do more operational reporting? Are you trying to communicate out to your line managers information about the efficiency of a supply chain? Are you communicating to an external regulatory body? So those sorts of use cases where you're looking at repeatable requirements or information that is based on historical trends that are presented so that that manager can make some very tactical operational decisions, those are instances where you want to leverage business intelligence. So more operational reporting, analytics and data science is leveraging more complex models ultimately to predict engagement with customers versus business intelligence can talk about how say a line manager or retail manager who's interfacing with the customer can understand their hourly, daily or weekly sales. So again, it's really driven by what you're trying to accomplish. Other considerations that you want to take into or other considerations that you want to have in mind are what are the capabilities within your organization already? So do you have business intelligence already? Have they started to do more advanced analytics? Has anyone been hired as a data scientist? How can you best leverage who you have and what you have already to progress the business requirements that you have? Now, if you don't have it within your organization already, what are you willing to invest in? Because that is another big decision. If you are transitioning from a more traditional business intelligence environment through analytics to advanced analytics and data science, those are investments in technology, in people, and the way that the organization needs to respond to the output of those exercises as well. So for example, if you brought in a predictive model that said that we recommend that an action, for example, would your management team be able to consume the output of some of those predictive recommendations? That answer of whether a management team could consume the output of a data science exercise or an advanced analytics exercise could be based on their ability to trust data as a key input into decisions or whether they are more comfortable making decisions based on their own personal experience or gut feel. Maybe those sorts of decisions that are based on an advanced analytics exercise would need to be, again, validated against other more trusted processes, for example. So you also want to make sure that if you invest in the more advanced capabilities around analytics and data science, that your organization is primed to consume the output and be able to action the recommendation that may come out of one of those more advanced exercises or be able to validate it to a certain extent and ensure that that validation process enables them to trust the recommendation in order to action it. So those are just some ideas around how to decide whether to use business intelligence analytics or data science. Now some of this has to do, of course, with the data volumes because you wouldn't necessarily want to do data science on small volumes of data because you may not have the ability to or you may not have enough of a representation to do that statistical analysis, but you can do analytics on small data. Business intelligence has traditionally been done on more small data. So there is also the size and the volume of data that comes up around your decision of which one to use or which one is going to be best tuned for your decision at hand. All right, let's look at what happens as we get into the implications of those questions in the business decisions, which means it starts to drive our infrastructure and our architecture. So we started talking about the difference between sort of business intelligence and advanced analytics back earlier in this year when we put together kind of a reference architecture. And we started using the terms vintage for traditional sort of business intelligence enterprise data warehouse categories and contemporary for more advanced analytics. So we're starting to change that nomenclature. And you can see here that on the left-hand side of this slide, we're calling this traditional. And on the right-hand side, we're calling it contemporary. So the way that we put together this example or this graphic is that you start in the middle. And depending upon your business goals and your information requirements, you either turn left to look at a more traditional approach via business intelligence, or you turn right and you look at a more contemporary approach via analytics and data science. So traditionally, business intelligence has been driven by historical or backward-looking requirements. Analytics and data science is looking forward. So whether that is just through new capabilities, whether it is through predictive analysis, prescriptive analysis, trying to determine what will happen in the future and what is the recommended action that we should take in the future. If your audience, if their goals are to make better decisions and they're looking for some operational accuracy, they're going to look more towards a business intelligence sort of infrastructure and architecture. If your audience wants to identify new insights, maybe it's to support the development of a future strategy in the organization. And maybe the audience is asking explicitly for data science. And of course you need to turn right and go towards an advanced analytics or a more contemporary sort of architecture. If you are looking at steady states of data sources, so the difference between a business intelligence architectural infrastructure tends to have known consistent sources of data, versus on the more contemporary side, the sources are extraordinarily dynamic. They might include those same sources that are used in a business intelligence approach, but they also would include other sources like unstructured data, much more purchased data, acquired data, crowd-sourced data, what have you. And those sources will be changing very dynamically. So those are other decision points. And then of course, what are your requirements from a management and a governance perspective? And if you've got very stringent requirements from a governance perspective, where you need to be able to have specific quality standards, those quality standards need to be reliable and repeatable and extraordinarily precise, that leads you more towards a traditional or business intelligence sort of architecture. So if you are looking for governance to provide enablement, meaning governance is providing data understanding through data cataloging, available consistent data definitions and business glossaries, and that sort of thing where you're not looking to control necessarily the data in the same way that you are in a traditional environment, but you want to be enabled to do your investigative analysis and that sort of thing, that would be more along the side of analytics and of course data science, where they are looking to do the experimentation and not be bound by some of the rigor that is necessary from a business intelligence perspective. So if we think about these as being the different drivers of why you would leverage business intelligence versus analytics, then how does that show up in the actual architecture? So how it shows up in the infrastructure is that essentially it's a traditional, you know, extract, transform and load, so ETL, EAI, leveraging data quality, so that the data quality can demonstrate the repeatability of the data, the thresholds are being met in areas like completeness and consistency and accuracy, etc. From an infrastructure perspective, it tends to be anything that works, and so that anything that works is a recognition that many times the infrastructure for analytics and data science is purchased by the user for the user and sometimes sits under that user's desk, quite frankly. So it is leveraging more cloud. It is leveraging the ability to buy something quickly and install it quickly and get it up and running quickly so that they can start to run more sophisticated analytics and data science and not be bound by maybe some processes or some constraints that are necessary to go through a more traditional IT-driven purchasing process. Other architectural differences, for example, data volumes. This is where a lot of people think about the main difference between, say, data science and business intelligence is all about the volume. Well, yes, of course it is. Business intelligence is much more used to leveraging the controlled volume, smaller volumes of data, etc., that enable you to have that trust from a quality perspective as opposed to the streaming data, high volume data, constantly changing data that is needed on the analytics and data science side. And then, of course, there's the usage of the information. So from a business intelligence perspective, traditional queries tend to have limitations. So they're tuned specifically to a report that you're running because you want to maximize that speed of response. So it's very fixed, it's less changeable, but it's very trusted. So that is what is in a more traditional business intelligence side versus on the contemporary side, the access process is actually tuned to consume high volumes or rather huge volumes of data. So it's tuned to run the massively parallelism that enables you to get that statistical base to come up with your predictive recommendations and that sort of thing. So again, these are differences and tradeoffs essentially that are all part of the decision making process around when to leverage business intelligence and when to look more at analytics and data science. And as you could imagine, this really is a continuum. And so the way that we've looked at, excuse me, the way that we've looked at this is kind of, you know, on the left-hand side, this is to a certain extent time-based. I don't want to say that this arrow is 100% time-based because there's a little bit of overlapping that happens. And there's, of course, the fact that people are still using enterprise data warehouses and data marks and that sort of thing. So it's not 100% time-based. But there is somewhat of a continuum where reports were really looking at what happened. Dimensional queries of your ability to more real-time slice and dice data to get a more flexible outcome to an ad hoc business question. Then we looked to find predictors and leverage predictive modeling that are identifying relationships and trends. And then that moved into the ability to understand not just what is, but if this will happen, then what decisions should we make? So thinking about forecasting based on scenarios. And then we're moving or have moved into goal-seeking models. And what I mean by this is that we're looking for the data to do some of the correlation for us and to recommend ideas that we may not have thought of, and therefore we may not have asked of a predictive model or a scenario-based forecast. So that top line is really looking at kind of what are we asking of the data and how are we analyzing it. And the bottom part of the arrow is looking at the traditional sort of data sources and data types that we were leveraging over periods of time. So going from normalized data structures and application-based analysis to combining the data from multiple applications into an enterprise data warehouse, leveraging those via more solution-specific data marks. And then, of course, as we go into the data lake world where we're able to leverage Hadoop and other technologies, the reason that I said load Hadoop here is that, you know, when we think about kind of the processing, where the processing happens, you know, you don't actually do a lot of processing as you load the data into Hadoop. And in fact, what you're doing is looking to do the processing as you read the data out of Hadoop or other sorts of data like technologies. So there is kind of a time-based analysis or a time-based component of this. There's other things that start to drive the structure and flexibility in what you're asking for. For example, as our world has become more real-time, there's also a currency aspect. So where we used to report monthly or quarterly that enabled that we could pull from normalized data structures and ultimately from enterprise data warehouses and data marks, we have gone to a much more current demand so that we want now to understand not just monthly, but we want to understand weekly, daily, or even real-time. And that sort of processing capability is much more difficult for using some of the more traditional data sources and traditional analysis capabilities, where it's easier to do based on some of the more contemporary and data-like capabilities. Kelly, before you move on, the question submitted earlier, and this might be the right context in which to bring it up. The question reads, should I normalize my data and define my questions before I select and configure a tool? Or should I throw all my data into a data lake and let the data science lose on it? It depends question I assume, but perhaps in the context of this particular diagram, it might be a good time to address it. Yeah, and I do truly think that it is and it depends because there is the appropriate nature of understanding your query first and implementing an architecture or leveraging an architecture that already exists in your organization to answer that question, right? Now, part of the reason that the data science came up anyway is what if we don't know what questions we should be asking? And so it gives you a more flexible ability to investigate based on the data and enables you to do more real-time modeling around what could happen versus what we have seen happen in the past. Now, realistically, that sort of more predictive prescriptive analytics needs to leverage some of the information that we have gathered over the years based in the past. So for example, if what you're doing is that you're trying to do fast identifications of data patterns to come up with some sort of answer to your question, somewhere you need to start to ensure that those patterns are appropriate and understood to begin with. So it's, you know, understanding your core operational and managerial reporting still has a place and it actually can help you to develop your more sophisticated analysis and can ensure that that more sophisticated analysis is based on that true understanding of your business process or your customer base in the first place. We have another question about governing unstructured data, but I think we'll come back to that at the end. Okay, yeah, not a problem. Okay. All right. Okay, good. Not a problem, not a problem. Sometimes it takes me, anyways, I moved my cursor off and finding it back, so anyway, that's my problem, not yours. So you all have seen this slide to a certain extent before. So this is our iBeam in which there's a architectural structural capability in which you need to support an infrastructure that enables data insights. And we call it an iBeam because of the thought around how an iBeam provides architectural support in a building. And the idea is that you've got kind of on the left hand side of the iBeam, the more traditional area, and on the right hand side, you have the contemporary area. And we changed this from vintage to contemporary based on some feedback that I received that vintage felt a little judgmental, which it was not intended to be judgmental to anything. So we think about it as kind of a traditional area versus the contemporary area, which is where we think about more of the big data world. Data scientists live in the contemporary area versus when we think about traditional stakeholders like managerial reporting, operational reporting, or what have you. So essentially, you cannot do traditional business intelligence without a certain infrastructure, just like you can't do data science without a certain infrastructure. So it's virtually impossible to try and accomplish what you want to do from a data science perspective in a traditional infrastructure. You have more data, more information, shorter windows in which to do the analysis, more complex querying, more sophisticated algorithms. And so the idea is that ultimately this iBeam concept enables you to marry your traditional environment, which still has very much value to your contemporary environment that's more experimental and investigative and what have you. Now, analytics, because it is such an umbrella term, spans both in the traditional and the contemporary area. Analytics in the more traditional area feels more like business intelligence. Analytics in the contemporary area feels more like data science and advanced analytics. So as you go, you can see that as you go through the left side and the right side, on the right hand side, you have the large volume ingestion. You have data being produced by edge processing or smart machine, social, etc. You have bots. So for example, as we talked about in the last webinar, bots both use or consume data and they produce data. And the data scientists want to be able to leverage all of the data that is shared from traditional sources into the contemporary area as well as all of that data that is being purchased, acquired, and pulled from other sorts of technologies. So you can move back and forth between the traditional and the contemporary depending upon your requirement and your business issue. And then the data itself leverages this iBeam or this data movement infrastructure to provide the data via a data access layer. On the traditional side, we think about data access as reports and visualization tools. In the more contemporary, it's also visualization, but it's also the ability to consume that data via more edge analytics type of use cases. Even analytics that could be potentially embedded into operational systems and applications. So again, going back to some of the decisions around your business and information requirements and whether you turn left or right, you will turn left for certain areas that are more traditional from a data source perspective. The data sources are more steady state and you will turn right when your data sources and your demand on the data is more variable and changing. So how do we decide so we came up with a few principles in terms of, you know, determining which part of the data use spectrum, it really is a series of principles. So it's not just as simple as we need a lot of data therefore it has to be a data lake. It is really thinking about what are the architectures that we need in order to deliver business intelligence and analytics to reflect the business needs. So this is what we've called in the past the, you know, where we want to recommend the best fit architecture so that you are actually creating an architecture that is truly designed to meet your business needs, understanding that those business needs do change. But creating an architecture to support the business needs not just creating an architecture that happens to be really trendy and gets a lot of recognition. So another principle supporting organizations around business intelligence and analytics that reflect true self service. This has an architectural implication to make the data available from a self service perspective, but in order to make the data available from a self service perspective there has to be some level of people in process to ensure that the data is appropriate for a self service that it is understood by the self service. And that when there are multiple people looking at the data that there's the ability to know that this data represents the same thing that that data represents so that you don't end up with conflicts. And then finally, an architectural solution must be based on the ability to support both modes so whether it's vintage and contemporary traditional and contemporary etc. So the demands of the business are to be able to do both business intelligence, as well as analytics. So just a couple of other decision factors as you're going through this so if you are answering yes to the first series of questions, that is a traditional business intelligence environment, in the sense that it the results need to be repeatable. It's meant to be operationalized and by operationalizing those repeatable results, then you're driving specific business decisions, and you can monitor progress within those business decisions, almost to the opposite of that of those questions. And then analytics and data or advanced analytics and data science group would almost answer no, in the sense that no we don't want it to be repeatable in fact we want it to be experimental. We want to be able to leverage new capabilities like artificial intelligence and machine learning algorithmic models are much more sophisticated. We want to use advanced analytics and data science versus yes of course we use somewhat of analytic models and algorithm algorithmic models and business intelligence but nowhere near to the same sophistication in advanced analytics. So would that data leave the organization either in the form of a report, or in the form of a data monetization exercise meaning that you are selling the data or you are sharing the data with a business partner for a trade for something else. So, when you do that, there's a certain amount of control that is inherent into a business intelligence environment that is absent for the most part from an advanced analytics and data science and if the data is leaving the organization, then there needs to be a bit more rigor applied that is more similar to a business intelligence environment to ensure that there is compliance around that data. Many times this is bound by regular regulatory constraints as indicated here. So other decision factors when you're trying to determine whether to use business intelligence or advanced analytics. And then this is just a process to consider that you go through and this might answer or be another way to answer the question that was posed earlier Tony where you're thinking first about business strategy and goals and so what are we really trying to accomplish. And do we have a need for operations managerial reporting, etc. Identifying those business requirements data and information needs for the planning and analysis and then of course you want to assess the organizational capabilities and the ability to support it and then develop your best fit architecture. As opposed to creating an architecture and then going back and determining whether it will actually support your business strategy or your goals. Again combinations are what's happening now not business intelligence versus analytics and data science and so it's really just what is the combination that is going to best support the business needs based on the requirements that have been articulated and sometimes the answer is both. So that may be the answer to this next question Kelly which references slides 13 but we may not need to go back there. Can we do a predictive analytics and data science under an enterprise data warehouse or is it better to do that under Hadoop and that question is based on the graphic on slide 13 which is the long arrow. The arrow, exactly the arrow slide. Well, so. Data science almost inherently means that you are looking at more of a big data infrastructure versus an enterprise data warehouse but again remember this is a continuum because enterprise data warehouses became bigger and bigger and bigger and because of the constraints associated with the requirement to have data structure around your data in the enterprise data warehouses the limitations that that requirement of structure had led to the creation of technology to support the data lake and so yes you can do predictive analysis. You can probably do a certain amount of prescriptive analysis from an enterprise data warehouse a data scientist will probably not want to use an enterprise data warehouse because they don't want to be bound by the structural constraints that are inherent by the term data warehouse and the structured schemas that are necessary within a data warehouse in order to get to the ability to predict predict you will also need to have a high volume of data so it would not be a small data warehouse might not give you the volume that you would need in order to do enough statistical analysis to be able to predict or prescribe anything so that would be another consideration of why you would want to go more towards a data lake Hadoop oriented environment versus enterprise data warehouse environment. Yeah. And it's and it is. It is again it's a continuum so it's not it's not black and white. So let's talk a little bit about organizational considerations I know that we brought them up a little bit earlier when we talked about things like the audience and the governance and that sort of thing but I did want to just explicitly call out some of the organizational changes that we have seen over time and as I was thinking about this I realized that you know what it really has kind of bounced back and forth and what this graphic is meant to represent. Hopefully you guys all can relate to this toy that or this I guess it's a toy that I'm talking about otherwise you're just going to think I'm crazy but they usually sell all these toys at the gift shops of science centers museums and that sort of thing and they tend to be like four or five hanging silver balls and when you lift up on one end and it swings back to the other three or four remaining balls the energy goes through those metal balls and the last ball on the other end swings out like a pendulum and then it swings back in hits the other balls and it swings out like a pendulum on the other side. You guys know what I'm talking about and I go tick tock tick tock anyway. Hopefully you do. But that's what I was thinking about when I was thinking about this concept of you know centralization decentralization what do organizational what do organizational units look like in that sort of thing. So business intelligence came up you know we started to to understand the value of business intelligence in order to maximize that value at the top left of this graphic in order to maximize the value of business intelligence. Many organizations created a business intelligence competency center. There are still organizations creating a new business intelligence competency center and this is kind of a centralized capability to enable efficiencies around business intelligence to enable data accuracy data reliability and best practices around business intelligence. As the users of the business intelligence tools became more and more sophisticated and independent that it shifted to a decentralized model which was more along the lines of self service business intelligence where the user wanted to have greater flexibility around the questions that they are asking. And therefore they don't want to be bound by specific queries you know more structured queries and that sort of thing. As we talked about earlier analytics is really just a progression from business intelligence. So that concept of self service business intelligence became as the tools became more sophisticated it became self service analytics or business driven analytics. So the ability to buy a cloud based analytics solution or a very lightweight based analytics solution, a simple server, load your data into it and do ad hoc personalized analysis was kind of the the grail around business driven analytics or self service analytics. Well, as that proliferation of analytics purchases around an organization became to lead to inefficiencies, then it swung back to a more centralized approach where the analytics organization provided an known reusable analytics workbench that the self service analytics group could actually leverage as a centralized toolset. So again it's swinging back to the other side. As data science came up data science, the group of data scientists tend to be a centralized group of advanced data processing and they were centralized, because they had a very specific skill set. And it was a very unique type of skill set, but now as the access to large volumes of data is easier as the ability to understand that data becomes easier based on automation and visual data processing. Now we're going back to this decentralized concept of a citizen data scientist. So, organizationally it's not either centralized or decentralized it's the understanding that there's efficiencies to be had and innovation to be had, depending upon where you are on the spectrum and what your goals are around the inquiry that you're making around analytics or business intelligence. So, I think somebody said it's called a Newton's cradle is that right. Well, thank you. I should have looked that up, right. So then if we think about kind of how do we want to consider this from an organizational perspective. So, if the two extremes are centralized and decentralized, of course we know that our world ends up being somewhere in between. We want to think about what are some of those drivers, and therefore how do we react. So, from a strategy perspective, business intelligence, and in general, the centralized sort of approach tends to be more it driven where the organization occurs based on the tools based on the tools that's available to them. And in this instance is it driven business used. Well, over time, the business has become much more technical, just like it has become much more business driven, and a decentralized capability is supported by a business driven and IT can support that business driven approach. We touched on this a bit earlier, but another consideration around centralization versus decentralization is the risk tolerance and the risk associated with the data. So, if there is risk associated with the data or if your usage of that data is for a very low risk purpose, there is value around something that is centralized where it needs to be zero risk, zero chaos. Business intelligence kind of fulfills that category there. So, this might be for regulatory purposes or when that data is published externally, and that can lead to reputational risk if the data is inaccurate and consistent, what have you. If the risk tolerance is extraordinarily low and in fact what you're looking for is to leverage chaos in order to drive innovation, then decentralized is kind of the way that you want to go so that you are enabling experimentation and you are enabling people to play around with the data if you will, but it is for internal experimentation as opposed to externally delivered information. Centralization is also something that can help when there are very specialized skills that are hard to find, hard to train, hard to maintain, and this happened with the business intelligence competency center and of course it happened with data science where the data science groups started very centralized. As the skills are more general, more cross functional or better enabled by technology, it can be decentralized more. So, again, I think I've probably positioned about three different continuums throughout this presentation, but truly that's what's happening is trying to land somewhere in between. So if we talked about the architectural principles, well what are some of the organizational principles? Well, one thing is how frequently is your business changing and therefore how frequently are the demands on the analytics capability going to change. If you are in a low volatile business, anyway, I'm running out of words, if your business doesn't change very much, then that would be a place where you could leverage centralization for efficiencies and optimum organizational coherence and that sort of thing versus the variability where you need to be able to respond quickly. As well, how adaptable are your people? So if your business is changing frequently and your organization has not developed an adaptability from a skills perspective, you might want to consider organizationally how centralization may be able to leverage folks and their traditional skill sets while at the same time being able to outsource them if you will as the business requirements change. Another decision factor is collaboration. So the more decentralized an organization is, the better they will have to collaborate in order to maintain optimizations and efficiencies. And then of course we mentioned regulatory requirements. So regulatory requirements tends to drive a level of centralization, whether it is limitations or controls around tools, processes, what have you, it tends to drive towards a level of centralization versus the decentralized organizational model. Well, with just a few slides left, I'm going to go through a couple more evolutionary slides. And this one might be something that you guys have seen in other formats before. So the evolution from descriptive or historical hindsight-based analysis, again traditionally business intelligence-based through diagnostic, which is what if analysis into predictive, prescriptive and ultimately the ability to leverage the data to provide foresight. And the idea here is that there are different requirements from an analytics perspective that drive the data solutions and the use of data solutions. And I don't know if hierarchy was necessarily the right word because it may imply to people that the top of the pyramid is more important than the bottom of the pyramid, but that wasn't what was intended. It was the ability to say that there is a build process that happens where what you have established from a descriptive analytics perspective around really monitoring your business and ensuring that your data is available to help you make decisions to operate your business creates a very solid foundation upon which you can do the more sophisticated types of analysis. So whether you're doing the what if analysis, et cetera, et cetera, as you go up to artificial intelligence, each of these layers, if you will, builds upon the previous one. And so jumping to a machine learning sort of artificial intelligence, if you don't really know how to monitor and operate your business in the first place, may not give you the results that you're looking for because it's not based on strong foundations in your business. So another way to think about the solution. So here's a summary slide in terms of when to use one versus the other. So the as you've seen in the previous slide. So what happened so this is the historical sort of descriptive analysis as we go into what will happen the predictive. And again, I probably should have shaded this to make this look like a flow but reporting in business intelligence tended to be more historical what did happen and as we move into initial analytics and advanced analytics and data science. Again, that's how we think about the more future looking foresight driven forecasting driven. And what should we do next. And these categories are supported by the ability of or the capability of the organization and depending upon the application of the organization or the requirements of that organization for whether they're just managing to survive and operational efficiency or whether they have the the opportunity to automate, invest and anticipate. So I know we're coming up on the end it just, you know, inevitably I always end up going down to the wire here so you'll hopefully we've got some repeat viewers or listeners, and you'll recognize that this slide that came from a previous webinar and which we did an overview with the data scientist. And I think the message across all of this is that data science enables the future of analytics. This is a progression. The analytics 1.0 2.0 3.0 4.0 that actually is a is an excerpt from the Tom Davenport so credit to him as well in terms of how analytics has progressed over time. The idea is that when we're looking at, you know, the the 1.0 where the user was a specific persona or role designated to do very specific things that type of specific analysis was supported by specific data set and that was supported by specific tools and technology. And then as we move into more of the 2.0 that user tends to be looking at various data sets and they want to be able to leverage data in a much more flexible environment where they're looking at all kinds of different types of data. They're looking at traditional in house data combined with external data. They're looking at sorts of technologies that can support analytics everywhere that can support the experimentation and all of this is ultimately leading into deep learning. Now, one of the outcomes of this slide in the previous webinar was the recognition that deep learning is in fact an its own and unique capability in and of itself that is leveraged that leverages data science and that that deep learning analytics and the ability to trust the machine so much to be able to predict an outcome is where this is going so consider self driving cars consider machines playing games so that the releases that are coming out from Google and IBM and what have you. But that's kind of where this this is headed so quick wrap up and key takeaways. The definitions for bi and analytics are not clearly delineated. It is a spectrum architectures will vary widely both over time within a single organization and across the spectrum from traditional bi to sophisticated advanced analytics. So focus on fit for purpose or best fit architecture. Use a formal process to determine where and how you want to support the data supply chain. This is something where sometimes that formal decision making is good so that you can have a an agreement upon how you want to support your analytics organization with a scalable architecture versus just adopting one that is available on the market. And this will continue to evolve and so those organizations that fail fast that can experiment and they can be comfortable within a cost structure that enables that will be able to take advantage of these new capabilities. And with that we're at the top of the hour. Well thank you Kelly for a great presentation today. Thank you to our friends at Looker for their sponsorship program. There was an unanswered question about governance of unstructured data. A little bit off the topic for today but there's a September 13 webinar coming up on a similar topic to that so take a look at our website for that. For those who may be interested let me remind you that the Enterprise Data World call for presentations is open until September 22. So feel free to make a speaking proposal for EDW next year. And then just to remind everybody finally again we will be posting the recorded webinar and slides to Data Diversity within two business days and you will receive an email message following up from your registration for this session. So thank you everybody for attending. Thank you again Kelly. Hope everybody has a good day and for those of you in the path of the storms we certainly send you our best. And I wish you Godspeed. Thanks very much. Take care. Thank you. Okay. Bye-bye.