 Hello and welcome. My name is Shannon Kemp. I am the Chief Digital Manager for DataVersity. And we'd like to thank you for joining the latest in the Monthly Webinar Series, Data Architecture Strategies with Donna Burbank. Today, Donna will discuss enterprise architecture versus data architecture, sponsored today by DataStacks and by Couchbase. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them by the Q&A section or if you'd like to tweet, we encourage you to share or highlight your questions via Twitter using hashtag DA Strategies. And we very much encourage you to chat with us and with each other throughout the webinar to do so. Just click the chat icon in the bottom middle of the screen to activate that feature. And if you'd like to continue the conversation after the webinar or follow Donna further, you may do so at community.dativersity.net. As always, we will send a follow-up email within two business days containing links to the slides and the recording of the session and the additional information requested throughout the webinar. Now, let me turn it over to Jeff from Couchbase for a word from our sponsor. Jeff, hello and welcome. Thanks very much, Shannon. And everyone, thank you for attending today. See if I can get my slides refreshed. And that's seeing you. Am I sharing or are you loading them right here? Switch it over. Sorry. That's what I wanted. There we go. Thank you, everybody, for joining us today. My name is Jeff Morris. I run product and solution marketing at Couchbase. And I'm excited to talk about and hear Donna talk about data architecture and cloud architecture or enterprise architecture because what we see is very much the convergence of these two things is we're seeing the enormity of database sprawl, of scalability requirements, of multi-cloud and global deployments is really taxing organizations today. And when we look at that and what's really behind the scenes driving those demands, we see that the developers need to be more flexible and agile with what they're building. They need a high dependence on performance and scale. And of course, for the DevOps folks, they need something that's very, very easy to manage. And that's where Couchbase comes in. Couchbase is designed as a multi-model key value in JSON, a document-based database. JSON offers us a high degree of schema flexibility, which when we start to talk about data architectures, really has some great benefits there in that you can simply change or append your application and the database will follow suit and change its schema or whatever it's tracking as it needs. An example of this might be in this particular age right now where if we're gathering user information, one of a new attribute we might want to follow is what's their temperature as they come on to my property or my business, right? It's a very interesting series of problems that we're seeing evolve right now in the industry. So, Couchbase is designed to scale like crazy. We support a shared nothing architecture that it's a masterless architecture, so you can have many nodes writing and reading all at the same time. It has built-in replication. It's very easy to manage, especially when you're putting it in the cloud. We operate using a Kubernetes-based control plane and we're microservices-friendly as we deploy ourselves. And we support hybrid and multi-cloud and database-as-a-service offerings that database-as-a-service offerings starts and goes live on Tuesday of this coming week. So, we're very much excited about that. One of the more interesting capabilities as it relates to enterprise architecture and moving things to the cloud is the way that we have chosen to deploy our new Couchbase cloud offering is to deploy it directly inside of your VPC. And that gives you a lot of benefits that you may not readily recognize. Like, number one, you get to pick and choose one instances you're actually deploying your cluster on. You can pick the perfect instance to run your workload and actually perform its tune in Couchbase to support exactly that. We have a feature called multidimensional scaling that allows us to specify what services of Couchbase run on what nodes in your cluster. So, your data collection and data service may span across five nodes in a cluster while your indexing service might span three. We elastically scale up and down and we rebalance the data as we're scaling. We do that automatically. And we support migration from existing systems or from eventually across clouds using our cross data center replication capabilities. So, as I wind up here, Couchbase cloud as well as Couchbase itself is an expertly managed NoSQL database, as I mentioned. It's a JSON and key value paired primarily. It offers superior performance, mostly due to our in-memory and our memory-first architecture that writes everything to memory first and starts replicating everything by a memory as it then makes things persistent to disk. We are ACID compliant. I've just mentioned the MVP security and some of the advantages there. When we're deploying a system, as I mentioned, it's that we have a control plane that's based on Kubernetes that is overseeing. It's kind of the omniscient vehicle that's overseeing all of your deployments wherever they happen to be. And ultimately, this offers you phenomenal TCO benefits because we let you capitalize on a number of different levers where you can spend a number of different levers as you deploy Couchbase in the cloud. So you can save 35% if you relax your service levels, for example, or if you choose reserved instances from AWS or Azure or GCP, you can save over 75% on that infrastructure cost. And then we also offer a prepaid annual consumption, a credit model that'll also save you another 20% over our on-demand or hourly options. So with that, I wanna hand it back over to Shannon and say, Donna, very much looking forward to your presentation. And thanks everyone for joining us today. Jeff, thank you so much. And if you have questions for Jeff or about Couchbase, you can submit them in the bottom right-hand corner of your screen. And Jeff will be joining Donna in the Q&A at the end of the presentation here. So thank you very much. And now let me turn it over to Jeffrey from DataStacks for a word from our second sponsor. Jeffrey, hello and welcome. Hello, I'm excited to be here today. See my slide share should be going here. Looks great. All right, excellent. Well, yes, my name is Jeff Carpenter. I work in developer relations and learning at DataStacks. And I wanted to share a little bit about how DataStacks thinks about data architecture. If you accept the premise of the quote on this slide, it's basically that we need to raise the level of abstraction in our applications so that we can all be more effective. And if you buy that, you'll probably also agree that the way that we handle data is a very important part of this. Being able to do a task without thinking about the details means that we're also not wondering or worrying about the quality of the underlying data. But this is held in tension with the fact that the amount of data that we're dealing with is rapidly increasing. And the studies are indicating that increasing proportion of that data is structured data. So we need to be able to handle both structured and unstructured data in our systems when AI and machine learning are actually driving the creation of a lot more of this structured data. So interesting data points. So how do we need to be thinking about our data and what are the attributes that we need from a data architecture? Just a few of the things that we like to talk about are relevance, getting the right data for the decision at hand. Accessibility, which is breaking down silos in the enterprise. Scale, of course, the ability to manage that ever-increasing amount of data I just talked about. Sovereignty has to do with the regulatory and legal compliance regimes that we have to deal with across multiple jurisdictions around the world. Agility is the ability to adapt to changing business requirements and availability, of course. These solutions have to be always on and active everywhere in whatever data centers that we're operating in. So I'm really interested and looking forward to hear more from Donna about strategies for achieving outcomes like this and others in our data architectures. Just a little bit about data stacks. I don't intend to give you a full product pitch or anything, but just to emphasize that we've definitely refreshed our strategy over the past few months and it's really centered around open source. Apache Cassandra is a data technology that's at the core of what we do as a company and we are making a bet that Cassandra is uniquely poised to handle the data availability and scalability needs that you have in modern cloud native applications. So that's the bet that we're putting around the company. So you can see that the Cassandra is at the core of our product strategy and we're pushing more features and new developments into that open source core than ever before. And so a lot of the innovation that used to go into the enterprise product is going into the open source Cassandra, which is a great thing for everyone we think. And then around that, of course, we have Astra our managed Cassandra as a service and we're also offering support for open source customers via our Luna offering. And on the back end, you know, we also have a Kubernetes based data plane that we use to manage Cassandra clusters in Astra, but also we're making that same Kubernetes operator available as an open source project as well. So there gives you a little bit of insight into the strategy which I'm happy to go into more detail with anybody that wants to reach out later on if you have interest. Just one other point about how we think about data architecture is that it's not as if we are just providing a database and want to hand it over to you and say, hey, good luck with that. We think that partnership is extremely important in helping you to achieve success in your data architecture and your enterprise data transformations. We don't want to just be another vendor that you only know by the invoice that you get periodically. So that's demonstrated in a lot of the outcomes that we've been able to achieve with companies that you see listed on this slide and many others. So we think that this technology, a highly scalable NoSQL database is applicable across a variety of different use cases and industries. So that was just a quick introduction that I wanted to share with you about what DataSax is about Cassandra and how we think about that as part of our strategy. And if any of that's interesting to you, I'm happy to see and answer any questions that you have at the end of the time and also for you to reach out directly to me afterwards. If you think of the question after the webinar, which is what I always do, feel free to reach out afterwards. And I'm particularly interested in learning in my role and helping people to get up to speed on this technology as quickly as possible. So I'm super interested in your thoughts on that. And now I don't want to stand any further in the way of you and Donna and this presentation. Well, Jeffrey, thank you so much. And likewise, if you have questions for Jeffrey about DataSax, you can submit them in the bottom right-hand corner of your screen. And he will be joining Donna and Jeff in the Q&A at the end of the presentation today as well. So now let me introduce our speaker for the series, Donna Burbank. She is the currently the managing director of Global Data Strategy Limited, where she assists organizations around the globe in driving value from their data. And with that, let me give the floor to Donna to get today's webinar started. Hello and welcome. Thank you, Shannon. And thanks to the great sponsor speakers. So I was learning a little bit myself from these, which is great. So as was mentioned, we'll talk today about Enterprise Architecture versus Data Architecture. And I hate to say versus because I think they're complimentary, but we'll talk about that. Just a quick note, because I want to get into the content, but always great to see some new names on these different webinars. And if this is the first time you've joined us and any of these other topics look interesting to you, all of the previous episodes are on demand and recorded on dataversity.net. So you can catch them and you can also catch this on demand as well if you didn't catch it live. So just that's always a question that comes up and it's a great asset from Dataversity. So you can take advantage of that. So the topic of today is obviously Enterprise Architecture. And how not only that shows key into relationships between data, but also process applications and the other key assets of the business. So we'll get more into this in the presentation, but I want to make the distinction between Enterprise Data Architecture, which is critical and important, and then Enterprise Architecture, which is really modeling the enterprise and as hopefully we'll discuss as we go through, can't be done in a vacuum, right? Because when you're doing data, you're supporting the organization. The more you can interlink those two and really make them actionable is really where you get that business impact across the organization. And hopefully we'll show how you can really combine those well. So many of you who joined us frequently and thank you for that. I'm probably familiar with this framework that generally I show each time, but it has so much value with this cross-functional approach. So when we're looking at any architecture but particularly Enterprise Architecture, we're often up at that business level up top. So a big part of our global data strategy, our view into data architecture is really starting with the business and the business drivers and then how that aligns with data strategy. So of course, to support that is your data architecture. And as the two speakers mentioned, super fascinating, super important and there's so many more options and growth than they used to be in the past. But the more you can align those two so that you're not just following the next cool trend but really supporting the ever-changing business drivers. As Jeff mentioned that there's always new use cases and now we're facing COVID. So what new data do we track? How more quickly can we track that data real time managed in the cloud? So it's a very complicated environment. So the way I think the more you can take something complicated and simplify it into a framework just makes things more simple and able to integrate. And that really lies with the crux of what I feel enterprise architecture is all about. So if we look at what is, you know, where I'm a data architect, so I've got to have my definitions, right? Put it in the glossary somewhere, I'm gonna get metadata. But just to find our terms, I took this definition from Gartner. It's an older definition, but I think it still holds. And what I really liked about this is that it hits at both things, right? So it talks about really understanding the foundation of future state architecture. A lot of what Jeff was talking about, how do we really get that foundation of our data to make sure we can support the enterprise? But what I liked about it is that it really talks to the idea of analyzing the execution and change towards desired business vision, right? So that really gets to the innovation as well. And what I love about using an enterprise architecture approach to data architecture is that it's a nice way to get to those two. So does it matter that we put something in the cloud? Probably. But what business problem are we trying to solve? And how, why are we trying to get faster time to market better scalability? So the more you can link those two together, and if you've heard me speak before, I generally fit this in. I mean, what keeps me in the business? Because I like to think of myself as an entrepreneur as well as a data person. It's this alignment now between data strategy and data architecture with the business. Every company now is trying to, or a nonprofit, or a healthcare company is trying to be data driven because think of the top companies in the world today, Amazon, Uber, you know, all of the top companies are using data to their advantage and you want to as well in your organization. So as we look at kind of the key areas of a data enterprise architecture, the way I like to think about it, architecture in general is a great skill. I use it all the time just in life. So I think if we are architects or we're data architects, we're probably very good at architecting things like data, a system diagram, data model or application integration model network diagrams, right? The technology is incredibly complex and how do you manage complexity, generally by abstracting through things like a data model. But what I like about enterprise architecture, if this approach is new to you, it's really modeling, you're modeling anything. You model the other areas of the business. Have you ever thought about modeling the motivation and goals of your company? That can be done easily in a one major model. You know, again, if you've listened to me before, you know, a fan of high level data models like a conceptual or enterprise subject area model because it really can capture the data of an organization in one page. Can you do that with the motivation, with the why of a company on one page? Can we map out the business capabilities? What does the company even do and how are we going to support that most capabilities through data? I mean, just think about, I'll use Uber because I just mentioned it. What are we trying to do? We're trying to maximize transportation. We're trying to maximize speed to market. If they're looking at the taxi capability and you abstract that into what are we trying to maximize? You know, speed, usability, you know, ease of customer service. Those are the types of things it ties into your motivations and goals, right? And then what are the business processes to support that? So et cetera, et cetera. One of the nice things about enterprise architecture is that it looks very holistically. So again, you can model data, you can model networks, you can model the business itself. And that's the nice intersection I think between enterprise architecture and data architecture. And I will show you some success stories. I mean, one of the, oh, everyone has to have a negative about everything on the planet. But one of the negatives that you may hear about enterprise architecture, oh, isn't that old fashioned? Isn't that big? Isn't that complicated? Isn't that just for the big six consulting firms? No, I'll show you some very practical use cases. I don't know how you can be successful without at least some aspect of understanding what your business capabilities and what the motivations and the why of why you're using your data architecture. And again, as with anything, there's proponents and detractors and there's probably a framework and a model for everything and there's probably seven different standards, right? So enterprise architecture is no different. So two of the popular ones, there's many, you may have heard of the Zachman framework and John Zachman is very active with data management association and the university and a lot of their events. Great man, if you haven't met him, very friendly. But one of the nice things about his framework is that it's this simplicity. He's sort of, again, breaking down a very complex organization and to the who, what, where, why, when. Where I see data fitting is very nicely into this what column and the what column at many levels from the very high level executive perspective, why are we even doing this? How the high level, more enterprise conceptual down into the very detailed implementation level. And again, you need, I feel, you need to look holistically at data from how it exists on the platform, why is it if the organization and then Zachman goes a step further and then how do you then link that with the, how you're implementing your capabilities, the where, the who, your, your organization chart, the when, the why, and all of your business processes and the flows and networks around it. So where are you to do all of these boxes? I don't mean it. If you were to use all of these boxes, then you really do get that holistic view of the organization. Another common framework, again, very helpful is Togath where they look again with their topology of linking business and data and applications and networks and frameworks, et cetera. So no matter what framework you use and there's pros and there's cons to each, the nice thing about that is it gives that enterprise view of the organization. And if we're just looking at basic data level, this is one framework we view. So do we have the business view of data? Again, what are our motivations? What are the business capabilities, et cetera? What are the business processes that drive usage and understanding of data? And then how do we model the data itself? Again, at the different levels from conceptual, logical, or even I mentioned it earlier, the metadata level or the glossary, you know, a lot of the work you're doing in a data model can be abstracted into a very business-centric view, really a dictionary or a glossary of terms. And then how do you map these and link these together? So data to process, data to capability, et cetera, et cetera. We data people like data and surveys and a survey I had done last year with DataVersity really asked about this specific question on enterprise or data architecture of what problems models are people actually using in their day jobs. I, as an unabashed fan of data models, I was happy to see, and probably not surprised, it was a DataVersity survey, right? Were we the process management association? You might've got a slightly different view, but to be fair, logical, conceptual, and physical models were definitely at the highest. Found it interesting that the business-centric models, which are your logic and conceptual, were really the highest used. And, you know, I might've thought physical might've been higher, right? Because often we think let's just get to the implementation stage and skip the business analysis. So I was very pleased to see the high percentage and relatively of, you know, conceptual and logical data model views. And I just, we see that in our practice. And again, maybe because I'm a proponent, self-selecting, but a lot of my customers are coming to me and asking for, can you help us build the conceptual data model? We did a great success story with DataVersity last year with the environment agency in England that used conceptual and logical data models really successfully. But you'll also see others, business process models, system architecture models, business capability models, sequence diagrams, you know, good old-fashioned, UML class models, right? So it's a broad range. And you don't need all of these and we'll talk to you when it's a good idea to use each. But if these are new to you, and again, we all have only so many hours in a day and data itself is hard enough to manage. But maybe, and maybe by the end of this we'll give you some ideas. Maybe I'd want or two of these into your quiver of skills or into your toolkit to really help, especially when you're trying to maximize value, especially in today's economy, it's always great to do that. How you can align with other core areas of the business is always a benefit. So we'll go through some examples of some of these. One of them was not on this list, but we use all the time in our practice. Again, all of these can be done very simply. Don't think that just because we use the word enterprise in front of something, it's going to take months. Generally, we do with this example is a business motivation model. Actually, almost any of these could be a workshop for a couple of hours to get at least an initial draft and that can be so valuable to just stop for a minute or a couple of hours and think of the why and the how and the impact. We do us all a lot of good in projects if we could do that and get that rigor. So the business motivation model does what the name implies. It models out the actual motivations of the business. And again, none of this is brain surgery, right? It's just some nice frameworks of getting the obvious down on paper or things that maybe are not obvious to you or obvious to the organization. One thing I often ask of the data team is, do you know what your corporate mission and vision are? We often cheat and go to the website of a company before we get on site or download. Have you downloaded your company for your public company, your annual report? Often a great place to start. What is your CEO saying to her drivers and maybe a good idea to align with those, right? So we not only write down the mission and vision, but what are those internal drivers? What is keeping your CEO up at night and what's getting them excited about the future? Definitely a good thing to think of. And then look externally, right? You don't want to be so focused on analyzing your own navel that you're doing. You don't think about what this is doing and you're not around next year. I think in this COVID environment, a lot of organizations are moving to digital and faster ways than maybe they had thought, right? So, and then from those business motivations, generally we do something around data goals and objectives. So this particular example was sort of focused on governance and the idea of, what's the accountability around data? Do we have the right quality and do we have a data-driven culture? As I mentioned in the beginning, so many companies now want to be data-driven. What does that mean? And you can have the best data in the world, but if you're frontline people are saying, don't tell me how to do this. I've been in this business 20 years. My gut feel is better than your analytics. Why bother, right? So all of this is a holistic approach and culture. And I often get the question in the Q&A. I was in a webinar a couple of days ago and got this one, so it's tough with mine. Yeah, what's the hardest thing to change when you're doing an enterprise or data architecture? It's the people. We're complicated. And when we do, we often work with companies and do assessments and we may do a maturity assessment year one. We're always honored that often we spend many years with companies helping with their transformation and we'll do an assessment year two, year three, year four. And generally the lagger, you can get your data architecture great, you can get the tech in, it's the culture. That's gonna be getting everybody understanding. You as the data team by definition are gonna be a few steps ahead. You live and breathe this stuff but trying to get the folks on the sales floor, the manufacturing plant up with you is that takes some effort. And that's why some of these tools can help. Another thing that's easy to model or important to model is not only the motivations, but your use cases. And you can do this many ways. This is just one example. This could be a official UML use cases or this is just again, a lot of different types of box, box and lies diagrams, but this particular one that was used at Non-Wise Client Example, is just really document the different use cases and kind of organize them some more around efficiency, some more around marketing, some more around growth and then the subsets of that. What within marketing? Is it customer segmentation? Is it, you know, et cetera, et cetera. And then kind of do overlays. Who in the, this was a global company who are on the globe wants that? But what groups of the company want it? And it can be nice kind of heat map to show other folks. We often use in our practice, we've used these many times as well. Sometimes we'll just do pure analytics on the use cases. We'll do some, you know, interviews and get that and do a nice tableau or be Power BI dashboard or look around and actually use data to report data back for some of these, right? So yes, there's models and then there's analytics as well. So again, think of creative ways to not only understand the holistic view of the business and then put your data hat on and your modeling hat on and think of a great way to show that back. So there's always a modeling aspect and then actual data aspect. So public building your toolkit to really understand always a million things you can do in a company. What to prioritize, especially now, especially the thing being uncertain, especially with tight budgets, picking the right thing to focus on. And that's where, I mean, we're lucky to have a large distributed customer base around the globe. And what most companies are doing right now is that, okay, we had 10 use cases and we were going to do all 10. Now we might be doing two. What's the best uses of those two? And this is a great way to look at that. How do we get the maximum benefit for a small amount of effort? I promise you some use cases and I'll go through a few. This was an interesting one, a large international pharmaceutical company. We worked primarily with the US and the Swiss teams and they were looking to kind of streamline their clinical development and their commercial and their R&D. And we did a few things. We worked, our initial sponsor was IT. Love IT, I'm in data, I'm a techy person that's often is the hardest place to start. Ideally, this needs to be a business-driven effort. So we were kind of working off our back foot to use an analogy, right? So the first thing we did, and this could be a whole webinar, is we sort of put our marketing hat on. So can we even define amongst ourselves and then to the business, what do we do? So what can we offer? Enterprise planning, business capability, technical, analytics, whatever you do in your particular data. Understand that so you can sell that back to the business. But this group did was align with the business needs and the business capabilities. So we did do that prioritization. Yes, in general, we needed to manage clinical and commercial and R&D. If you're in pharma or work with pharma, those are pretty broad swaths, right? So how do we get a little more streamlined and ideally pick something that goes cross-functional across all of those? And then we did not only data models, but for this particular, again, a lot of it was from the R&D was process models. So if you're in manufacturing, you're in distribution process is often how people think, not so much about data. And so overlaying your business processes and adding a data lens on that was super helpful. And I'll show you in the next slide, we talk about culture, how that really had the light bulb moment. So you can do that and that's successful. We've had a lot, often you do a first phase of this, kind of a, you know, agile iteration and get some client and that's great. And you'll have some key fans. How do you keep that going? So because we had that success, they were able to integrate that into their project development and their project life cycle. So they were able to add stage gates into each dev so that every stage gate, did you have a process model and you have a data model and how can you make everything more efficient? So this was a great example of they absolutely look holistically from capabilities, even their own capabilities to business capabilities, to data, to process and then into the actual process of managing processes sort of meta, right? There's the business process and then there's the data process to manage the business process, right? So they did all of that super successful effort. And I wanted to share that because I often get skeptics but you do data modeling, right? You do process modeling, right? Generally the business is your biggest fan because often it's the business people, they know the data because they use it every day. They don't know the tech, that's not their job and there's this massive gap between what they want, what you do and what they do. And that's why these blueprints are the model. Like I hear you working to try to build a house with a house architect. I don't know how to build a house, I've never done it but I can see that architecture diagram and kind of get it and we can talk together through that model to understand I need to addition off the kitchen, right? Same thing with data. So this is a mocked up example but not too far from the truth. What made us feel very pleased was that when we sort of walked around the office they're the business users. And again, I kind of hate that term because their business users were clinical PhD scientists finding cures for cancer and things, right? So they want your average is business user. They were technical on their own, right? But they have these business process and data models on their wall and just kind of as Mark and we call them blueprints. I don't know what they call them. To them, they were a blueprint and that's fine, they were blueprint for data. They actually had them up on their wall and again, their R and D things changed. What just made my heart warm was they were marked up with pencil or magic markers when there was a change. And because we had this nice life cycle into the project governance those changes were able to be communicated back to the architecture team, right? So great that people are using them even better that folks are marking them up and seeing as an active asset. So that was a nice thing from the architecture team that they understood their priorities. They had that communication and everything was more efficient because it was model driven. So kind of a neat success story. It was a nice way to get business and IT aligned. I mentioned data models near and dear to my heart. I think they're a big part of data governance and a part of the architecture, all of the above. And there's different levels of models and again, this can be an entire webinar, so we won't. But I would say get the right level at the right audience. So you're talking to the CEO level or the business sponsors, keep it high level, right? It's so easy for us who are looking at tech to get right into the weeds. I'm guilty of that myself. If you really want to start showing everybody the complexity that might be, this is probably even just a logical data model on the right, right? But it's still pretty complex to a business user. Simplify, simplify. If you're a large corporation, you may want to start at the enterprise level. Conceptual level is also a very high level kind of PowerPoint view. Logical gets more into the detail and then yes, absolutely a physical data model to understand those structures. All of them are valuable. One is better than the other, they kind of work in concert. So the conceptual data model, I like it because it's a very clear way to get at some of these core business rules. It's a nice way to kind of tell the story. If you're not technical, you can still look at this and understand, okay, we have employees that are sales reps or support reps and support people look directly with a customer. Sales work be to be through a company. I don't have to be a data modeler to kind of understand what this company does. This particular tool on this example, I like to actually show the definitions on the conceptual model. It's almost a living glossary because what a glossary lacks is what a data model adds, which is the relationships and the cardinality of sales rep can work with a lot of different companies, but not every company has a sales rep. I won't start reading all of the things, right? But the best a nuance you wouldn't get in a glossary. So these work nicely together and conduct in concert. You do want to get down to the logical because that is where you start to get more of the details, the attributes, the detailed cardinality and that's getting more towards sort of a physical design or your detailed business rules. So all of these levels are critical. So I am going to hold myself back on the beauty of data modeling. And I think a lot of us know physical which actually goes down into the database level. But again, because we're talking more about business and enterprise architecture, I want to take now this data architecture. And again, how can we use this to really understand the business better? So another great tool is a business capability. So all of these just think it's almost everything in the organization thrown on one page, if you could. Of course, there will be more detail in all of these, but even at that one page level. So what are the core capabilities of our organization? I will tell you again now in this type of economy and even before this type of economy with more people going digital, with innovation happening more, a lot of companies are stepping back and going, what do we do? What is our core capability? How does that differentiate? And more and more people are saying, there's aspects of data and even just monetizing data that's our core capability. But aside from that, it's understanding this is a fictitious company and they do research and development. They have branding and go to market and sales within marketing. For example, they have messaging and branding and campaigns and leads and so on. Just understanding those core businesses, those capabilities, what might be shared services. And then a nice way to kind of, I'm a fan of these heat maps because they're very nice and visual. If we're looking at, if you were trying to do customer master data or product master, you can see from these heat maps that who is using customer master probably no surprise marketing and sales. But actually R&D with product management, they want to know how the customers are using your product as well. Legal is definitely looking at customers because they're doing the contracts. Some of those might have been obvious but I know when I do MDM, often the biggest risk of failure is forgetting one of the key users of master data and getting their needs. So again, high level going broad is a great way to start. You don't end there, obviously. There's a lot more work to do but stepping back and understanding that the broad impact is super important. Another nice thing, and I'm hopefully don't confuse everybody with kind of going meta on some of this of there's capabilities of the company and then there's capabilities within data architecture and data management. But I do think they're so closely linked in one way where they're linked is data governance, which again could be a series of webinars in and of itself. But again, when we do implementations, one of the key things we look at in the very beginning is how is the company organized? What is the culture? And then how do you develop a data program around that and governance is a key part of a data-centric program? And because you don't want to say, I don't know, go into a very top-down rigid hierarchical company and say, hey, we're going to have agile pods of quick, you know, everyone's very distributed. That's not going to work. And you don't want to go to a very cool collaborative distributed team and try to put up very hierarchical approach. So sort of this sort of governance structure is almost kind of a dama d'embacque, if you're familiar with that body of knowledge. Kind of, this is very helpful. We use this in a lot of organizations with kind of your steering committee and your reporting structures. That does not work everywhere, right? So really understanding an organization's capability and org structure, which is another kind of overlay, super important to getting your data right there. They are not back in a vacuum. You really need to look at those two together, which as old as I am, was one of my aha moments as I matured in my career of, you can never separate the company from the data and even more so now of how you manage data needs to align with how the company manages itself because they're becoming more and more companies and they're becoming data companies, right? So a great example we had that we use capability models, we were lucky enough to be involved in a merger of two of the largest financial services, I think in the globe, based in New York and London, probably not surprisingly. And what was interesting, we first day of the project was really, I don't know if it was by accident, but it was the first day of the merger and the CEO got on and we were sort of there at the town hall and he said, one of the main reasons for this merger was the combined data assets of both companies because that's our strategic advantage, is the history of data between these two companies. Well, if you can imagine two companies that have been in business for, one was over a hundred years to try to organize, there's some data redundancy, but more importantly to even start with the business capability redundancy, you're trying to merge two very successful, already running organizations with a common data foundation. So the first thing we did, as you can imagine, there's politics, right? So to even step back from the politics or the culture, which was very different, we step back and we said, what are the core capabilities of this company, of this combined company that is now one company and how do we create a common data foundation? So this was a great example of now, what do we do maybe differently? Some of these core capabilities were no longer capabilities with a new company. That's not something we were looking to do a new. Some we had two of, some one company had better than the other. So we started with a business capability and then we aligned how that common data foundation really was leveraged across the organization. Super successful way of doing that that also tied into their governance, that tied into everything else, but they really just stepped back before they even looked at the data which they knew was their biggest assets. What are we even trying to do here with it? Which again, seems obvious, but isn't when there's so much complexity. Another way we look at things a lot is through process. Big fan of process models. They're nice visual. I was actually on the finalization committee for the BPMN, the business process modeling notation way back in the day. But again, especially if A, you're a manufacturing company or a very process driven type of company, helpful to have your business stakeholders look at it this way. I also think with master data management or MDM, a key part of MDM is understanding how the data flow is used by your different stakeholders. So where is good, I'll talk about that in a minute, a goal of good old fashioned crud matrix. Where is created, data created, used, updated, deleted. You need to understand that to really get that holistic view of the product, of the data lifecycle. Maybe more, I like to think of this next one, kind of a hip version of the process model is the customer journey map. Or I don't want to say just customer. We have done these at universities for student journey. We have done them at hospitals for patient journey apps. So again, how, if you think of a business processes maybe more internally focused, what is your customer external journey? Do they come to us from the web? Do they go to a trade show? Do they go into our store online? And then from there, how do we engage with them? And then what data is generated and how can we leverage that? So this is a simplified version. But again, if this is your customer across all phases of their interaction with your team and their journey across discovery to support what data is being used and how do we maximize our understanding of them and maximize their customer experience. So again, this can seem like a big deal and it is. And I don't want to belittle, I mean, this whole orgs that look at these and I don't want to belittle that, but a lot can be done with a lot of aha moments just getting the marketing team and the IT team together for an afternoon workshop and think this through. And you can get a lot of aha moments without having to go into a lot of detail. All of these can be done. All of these can go into year long effort for each one and or you can start with a workshop and also get a lot of value. So don't be afraid of a lot of these layers. Put it on a white board, put it on the back of an envelope. It's a great way to start. So once you understand process and the business capability, I'm a huge fan of an old-fashioned and horribly named tool called the CRUD matrix. Terrible name, but it's just such a simple thing, but we have averted disasters by looking at that. We were close to go to market with launching and master data management and we showed this to someone and said, yeah, that's great. These are all the systems. By the way, we don't use those systems. The data's actually being created somewhere else. Thank you for telling us now. We were just about to build integrations and again, a simple view really highlighted a big horrible oops that would have happened. Again, it was really technical to integrate these systems. We just forgotten or didn't know about a system but showing this quickly to a business user or understanding another thing that happens is we create the price when we're kind of looking at the supply chain costs and we understand the price of the product, that's fine. But then actually marketing goes and overwrites that price later because they're looking at market conditions and then finances reading that are they reading the right one? Did we talk together when we updated it? It says often these kind of updates down the road that can really cause you pain. So kind of looking at it in a very simple way can be super helpful. So... Sorry, I want to interrupt a little bit and just let you know we're at a 12 minute mark. Awesome, thank you. So process and data work really well together. And again, you can kind of link those with this CRUD matrix. It's really get a full understanding of that. So again, with a use case and I've talked about this one in the past but we did a it was a master data management effort with a restaurant chain which turned out to be very successful but it wasn't a data problem. The main problem after we did all the analysis was really a process problem that each silo had some great data. The problem was from when the chef at the beginning of the process developed the ingredients that went to menu that was priced in the supply chain that was bought at the restaurant point of sale. There was breakdowns in basically this. So again, we did a very detailed data architecture but before we did that, we started with process and we kind of did the overlay of who's using what and who's updates what. This was a perfect example of some of the pricing that was developed in supply chain was actually very different that what was priced at point of sale and it actually had some business losses. So it was a great way to look at that. So I talked about everything else but data. So I do want to end with data because that is why a lot of us are here interesting and helpful to architect that itself. So the next slide is a busy one and I don't need to walk through all of that. Just the overarching thing is that data or data strategy or enterprise data management think of fit for purpose. All of us are techie. All of us would love to roll up our sleeves and get into the tech but think of the why and understand often when we go in and do a strategy especially larger organizations have all of these things on the slide but often what goes from operational to MDM to data lakes or multiple MDM in some cases the problem is often using a hammer to screw in a screw right and that people are trying to just use the thing they have. So often just telling you I don't give you some really good examples what are we using each system for and how do we integrate? Because it is diverse. Although it's interesting we've done some surveys although things continue to evolve 81% of a recent survey are still using relational databases. They're not a bad thing. There's more options now. So a lot of folks are looking to do more graphs and SQL big data but it does not mean that relational databases go away. They're still valuable. This figure keeps me up at night that people are still using spreadsheets as a data platform but that's okay. It's not okay. I'll just not think about it. The least people were honest. So this is a survey and Shannon will probably give you the link and there's a link in the back of this deck for the actual survey. But when we did the survey current adoption again a lot of relational databases over the top relational and spreadsheet. So probably you're not most diverse. It's got old school. If you look at it, right? There's some folks trying a lot of different things but what was interesting when you look at the future is that yes, relational databases are still hot. I mean, because they do what they do really well. There's algebra behind it. There's math behind it. They do what they do very well. You will see that a lot of more folks are going to the cloud and that's a good thing as well. You saw with some of the sponsors why that's a good thing. You'll also see a lot more diversity and I think this is healthy. Yes, relational database is great and there's a lot of different options and different use cases fit for purpose. So one size does not fit all. If you walk away with anything here don't just look at relational, don't throw it away. There's a lot more options now where you can integrate. One way to leave you at the end is no surprise. A great way to kind of get a sense of this is through an architecture diagram, right? Again, sometimes simplicity can really help. Even if something as simple as yes, we have a data lake and yes, we have master data and we have a warehouse and governance needs to go across all of them as well as security and analytics. And we've used a lot of these and of course you go into each one of these that has their own but sometimes again, step back, simplify can be a super helpful way to understand all this complexity of how things fit together. Kind of a high level system architecture diagram can really help with that complexity. So hopefully some of these tools will help. Simple tools understand how the business fits with data and please join us next month is on metadata near and dear to my heart. And without further ado, I wanna open it up for questions and as Shannon does that, don't forget us if you need help. And the survey I mentioned can be downloaded on both data versatility as well as our site. So Shannon, I'll pass it back to you for Q and A. Donna, thank you so much and thanks to all of you for the great presentations today, just to dive in and to answer the most commonly asked questions. Just a reminder, I will send a follow-up email to all registrants by end of day today or by end of day Monday with links to the slides and links to the recording. So it's time for a few questions here. How do you connect and relate to the data models to business processes and process flows? I didn't hear the beginning. How do you relate business with data? How do you connect in or relate the data models to business processes? I saw some in the chat. There's some tools that do that well. There's one of the ways is to do sort of these credit matrix is business process models. That's one way. Sometimes I'll even show in the BPMN that it has this and I always add it my own even on the business process models to show a piece of data. This actually shows where the data fits in a lot of different ways, but those are kind of two popular ones either in some sort of graphical format of literally doing a matrix or a mapping and then I've also used it kind of visually on the process flow itself. Literally show where data is and is it a database, is it in the document, et cetera. And Jeffrey, we invite you to join back in. Anything you want to add to that? Oh, this is Jeff from CouchBase and one of the things that we found successful actually in one of my past experiences was to apply the concepts of design thinking to which actually helps you flush out both the process requirements as well as the data elements that you need to be using in a sprint oriented kind of program. So within a couple of days or a week's time you can end up going from process sets of ideas all the way through to prototyping a demo or an example and gain user feedback or gain participant feedback along the way. It's a really, really effective way to expedite the exercises. Agreed. Yeah, this is Jeff Carpenter. Hopefully that's not too far out of left field but one of the things that I've been thinking about a lot as a recovering architect is the importance of UX, the user experience design as a way of kind of gathering requirements and capturing flows and thinking about what is the end user going to want to get out of this design in this system and really starting with kind of like an outside in perspective and thinking about how are people going to really use this as a good counterbalance to maybe spending a little bit too much time thinking about what are the entities and relationships. Not that that's not important but to kind of balance it out with the user experience perspective I think it is really helpful. Donna, we're getting a lot of shuffling guys, I'm not sure. But let me know, it's a, driving into the next question here and nowadays there's a massive trend towards agile, lean frameworks, sometimes quick, dirty and fast. In your experience, how are companies leveraging enterprise architecture and data architecture and slow, steady, deliberate robots? Which can be counted as that? Yeah, I'll answer that one. I mean, I think agile done poorly is no modeling at all or no documentation. And I think companies are kind of moving away from that sort of teenage view of gosh, do we have to do our homework? And yes, you do. But I think also on the other extreme of that is let's take a year to do a full, as Jeff mentioned, fully attributed enterprise physical data model. Like that's the other extreme, right? So I do think stepping back with some of these high-level models to start, high-level one-page conceptual model just so you need to have some sort of scope. If you only go right to the sprints, you miss the big picture. So there is a bit, and we've done that in the sprint, kind of a pre-development sprint just to do the conceptual model which is kind of a different way of looking at it. And then we can add little agile pieces. Sometimes it's as easy as a stage gate before each sprint. Are you adding any data? Are you touching any data? If yes, either compare it to the existing model or add to the existing model. It doesn't have to be, you can do that in a two-week sprint. But just look at the model and add these little pieces of the model. Again, as long as you have a big thing to go against to do that. And there's no reason why you can't, and as Jeff mentioned, doing it in a more agile way, design thinking, doing things smaller chunks. Excellent way to do modeling. It really keeps it real and keeps it actionable. Yeah, I'm a big believer in the necessity as the mother of invention kind of approaches. And we see that quite a bit with our customers in that a lot of times the impetus to get started in any of these exercises is based on a surprise or a shortcoming in their existing systems. They're getting over, and even during right now, they're getting overloaded with internet and online connections. So that they weren't expecting or they had never experienced before. So oftentimes that triggers either a caching solution from a type of solution that we end up offering them. So we'll go through and start the problem with that particular caching design in mind. But then as they're doing that, the ideas do tend to kind of naturally expand and evolve. So a caching solution that is handling sessions for millions of users often turns into a user profile management kind of system, which then in turn turns into a customer 360 kind of solution where you're collecting better and more interesting attributes about the user community and you're realizing I still need to be pretty agile while I'm doing this. But we see quite a bit of that gradual evolution of a project or a series of projects as the customer gets comfortable both redesigning something old and realizing that there's lots of new technologies out there that can help expedite a lot of these exercises. I love it. Well, that does bring us to the top of the hour. It's been a passage into it and lots of content, lots of education. Love it. Thank you guys so much for the again, for these great presentations and thanks to our attendees for being so engaged in everything we do. We just love the community here. Again, as a reminder, I will send a follow-up email to every all registrants by end of day Monday for this webinar with links to the slides and links to the recording and everybody's contact information. Thanks again to do all these options. And I hope you all have a great day and stay safe out there. Thanks everyone. Thanks Shannon. Thanks Shannon, thanks so much Donna. Thanks Jeff. Bye. Thanks guys.