Let's face it. Business is moving rapidly. We've perhaps never seen an era of such transformation driven by commodity hardware, new technologies, the pace of innovation. It's clear that data and AI are the key to that differentiation. But traditional approaches to data and AI projects have been brittle, difficult to implement, and longstanding projects. You need to modernize your data landscape by anchoring on business objectives to deliver measurable value in an agile incremental and transformative way. Ultimately, the right data architecture can align data and analytics capabilities to the desired speed of the business. Instead of the other way around, slowing and force fitting the business into the limitations of a given data and AI architecture. Driving digital transformation, building disruptive business models. You either disrupt or you be disrupted and yet in this era of transformation in innovation, there's an increasing focus on compliance, protecting private and personal data, and let's face it, data security is the heart of your trust and your contract with your customers and suppliers. All of these are needed in consideration of the right data architecture. Ultimately, that right data architecture and that modern data landscape can help you adapt to future needs, while reducing ongoing operational cost. Data can't be an afterthought. As you climb that AI ladder to infuse AI and analytics into your business, into your processes, into every aspect of what you do, you still need the right data and trusted data foundation. It's said that you can't have artificial intelligence without an information architecture. There is no AI without IA, and ultimately, that information architecture should embrace the specialized needs of the business. At a broad level, when you solve a business problem with data and AI and analytics, it will require a combination of one or more business patterns, and each of these patterns require supporting data and technical capabilities. You may want to understand past activity. What happened? This is the traditional realm of data warehousing and data marts. But you may also want to predict a future event, and that prediction may either be based on past history or it may be in a new pattern or a detected anomalies that you don't necessarily have a pattern to understand, discovering insights in content beyond just structured data. What's the meaning? How does this look in context? Using that to interact in natural language, optimizing, providing prescriptive guidance on how all of this should be done. Altogether, each of these has their own individual data needs and technical capabilities and support. A fit for purpose data architecture is necessary to accommodate the specialized needs of the business and the individuals within its organizations. Gone are the days of when you can get away with a single structured data at rest architecture. Today's businesses are driven by data at rest at volumes. We're no longer talking gigabytes, we're no longer talking terabytes. It goes beyond. Data can also be in motion, event-based data, streaming data, the business can't wait for a batch window or 24 hours or 48 hours to get results. You've lost to your competitor. You've lost your opportunity to interact with a client and to do that in a way that improves the customer experience. Data is in many forms. It's not just structured or tabular data that you would see in a relational database or a spreadsheet. It needs to cover unstructured, semi-structured, document images, text, video, all of this needs to be considered in the right data architecture for the purpose-built need, and likewise, data exists in varying levels of quality and trust. Gone are the days when data can only be delivered when it is properly cleansed and curated, and harmonized, and perfect. There are still areas and use cases that that is necessary, and yet other areas need to embrace the fact that data exists in varying degrees of quality and trust. Increasingly, artificial intelligence models are based on those outliers, these differentials in the data and what actually occurs on the ground interacting with customers and with our systems and devices. When we talk about unwinding this big data hairball, traditional approaches to data and analytics projects often start with technology and they often assume some level of centralization and consolidation. The reality is that single source of the truth has been a mantra in the industry for years, and yet architectures that have been built in support of this goal have taken it quite literally. Single source of the truth is not a physical architecture. Single source of the truth or a consolidated view of the truth across organizations is a goal not a single architecture. Industry analysts have told us that monolithic data architectures have high rates of failure. Fifty percent of enterprise data warehouse projects fail to deliver business results. This is not a new statistics. This statistic came out in 2005 and it's still true today, many years later. By some accounts, data lake projects have an even greater failure rate of 85 percent. There is a better and agile way to transform your business with data and AI, and it starts with understanding that a single technology or a data architecture cannot support the specialized needs of the individuals, and when we say individuals, that may be physical users, it may be devices, it may be APIs. A data-centric approach accelerates business results and accommodates those future needs and technologies. Too often we get stuck in tactical projects and project deadlines. Work has to be done, budgets have been made, resources have been allocated, we're building a new application, we're developing a microservice, or we're training an AI model and preparing data and massaging it into the right form that we can actually gain insights and build and train and deploy an AI model. The challenge with these two lifecycles is that the focus is on building the application or a microservice, the focus is on building the AI model or the machine learning model. In both cases, problems are often discovered with the data, and instead of actually going back and doing the right strategic changes to that data architecture, we just bolt-on and do point-to-point solutions and bandaids. It results in the view that you see here with an unconstrained, chaos-driven point-to-point integration, we call this the Big Data hairball. What you need to do is you need to start leveraging data as a strategic asset, and in doing so, architect for the future. Now, you're not going to pivot from the existing hairball and point-to-point data architecture that exists in the business, you can't shut the business down, you don't have the luxury of shutting it down and building the perfect future state architecture, and let's face it, if you did shut down the business and could do that, the needs would have changed by the time you've implemented that future state. So ultimately, this has to be done in an incremental and additive way to the business. So what does it take to become data-centric? First of all, understanding and anchoring on business objectives and outcomes desired. When you build the right Data Architecture and show results to the business, it gains trust and momentum, and it starts to leverage and understand the value of data. Demonstrate that that value of data exists across multiple lines of business and multiple initiatives. Culture and people and transforming that, and acting in a data-centric way and assembling together and removing blocking factors, are also key to becoming data-centric. Let's face it. There are new technologies, new platforms, new capabilities that can enable the people and automate some of the repetitive tasks, to allow them to focus with data insight, data management, and data governance, ultimately in that eventual goal of becoming data-centric. Continuous innovation delivery is well-known for developing applications and microservices. DevOps is well-known and well-proven. Likewise, building and training and deploying an AI or Analytics Model, also has its own development and deployment and continuous improvement lifecycle. Data should be given equal consideration in solving a business need. It can't be an afterthought, and just like DevOps and Analytics lifecycles, data has a path of continuous innovation delivery. Some analysts call this DataOps. The right data architecture can simplify and support the competing demands that are becoming increasingly more challenged in today's hybrid and multi-Cloud world. The fuel of the business and the need to transform and do this in a way that is agile and meets the needs of the business is driving this innovation. Yet aspects of data in varying forms, in motion and at rest, in various different qualities, the AI Machine Learning and Cognitive models that are built on top of that. Understanding the trust transparency and fairness. Doing this in a way that maintains regulatory and compliance, that protects your data and data privacy and ensures data security. These are all different and competing needs that are becoming even more complex in this multi-cloud world. What workloads are appropriate to put on private Cloud, public Cloud, On-premise solutions? Leveraging automation in the process of that continuous innovation cycle across Data, AI and Analytics, and Application development. The key is that practitioner level strategy and architecture is required to avoid designing unicorns. I like unicorns. You probably do too. A unicorn is easy to like, because it's not real. It's not a real creature. My view of a unicorn makes me happy because I have a view of a unicorn that probably is different from yours. A data lake by example, is in many forms a unicorn. Talking about a data lake, talking about a single source of the truth, people conceptually say, "Oh, I think I understand what that looks like." It's a concept. It's not reality. Data lakes are a form of a unicorn. What's really needed is practitioner-led strategy and architecture. It's not sufficient to do architecture by PowerPoint and by pictures. You have to have hands-on experience. You have to have deep knowledge in what the various capabilities and solutions mean. Dig under the covers. In many cases, for whatever reason, perhaps in support of agile and continuing needs of the business, many times the conceptual architecture, certainly the logical architecture is often forgotten and people jump from the business need right to the physical components. This hard-codes the business and it actually slows the path of innovation. The logical architecture and non-functional requirements are more important than ever in this hybrid multi-Cloud world. Consider latency and performance, the laws of data physics haven't changed, locality of the data, not only the data but the users, the supporting services and systems. Regulations and protections are putting increasing limits on where data can be domiciled. Defensibility and security. How does this interoperate with others? What's the reliability? Availability? Is it modular and extensible? What is it? How easy it is to use and how easy it is to support? These are all key nonfunctional requirements that help drive the right modern data-driven architecture. Data Topology is a user-centric approach to develop data-centric architectures that simplify the organization, flow, and management of data in support of given objectives. Instead of starting with a single consolidated datastore, a data topology approach to data architecture, takes the opposite view and starts with the individual needs of users, and devices, and APIs in an overall ecosystem of data. By starting with individual needs, instead of assuming a level of consolidation, we can actually build a data architecture that is more resilient to future business objectives, and that can more rapidly embrace and adapt over time, to support new and innovative technologies. Let's not forget data protection and security. A secure modern architectures embrace data protection and security upfront. It introduces constraints for data strategy, data topology, where data is domiciled, how it is made available to users. These capabilities are impossible to bolt-on afterwards. They have to be considered up front.
