 Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager of Data Diversity. We hope everyone is staying safe and well out there, and we would like to thank you for joining the current installment of the Monthly Data Diversity Webinar Series, Real World Data Governance with Bob Siner. Today Bob will be joined by guest speaker Anthony Augman to discuss data architecture and data governance. Since 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. I'd like to chat with us with each other. We certainly encourage you to use those. Just click the chat icon on the bottom right hand corner of your screen for that feature. And for questions, it will be collected by the Q&A in the bottom right hand corner of your screen. Or if you'd like to think, we encourage you to share highlights of questions by Twitter using hashtag RWDG. And as always, we will send a follow-up email within the next two business days, containing links to the slides, the recording of the session, and additional information requested throughout the webinar. Now let me introduce to you our speaker for the series, Bob Siner and his guest, Anthony Augman. Anthony is the founder and CEO of Augman Data Leadership, a company helping business and technology leaders transform their future with data. But decades of experience in business and hands-on technology roles, Anthony brings better data management to organizations of all kinds. He has led data change initiatives in many industries, serving as project manager, data architect, and chief data officer. Bob is the president and principal of KI Kankofoping and Educational Services and the publisher of the data administration newsletter, tdan.com. Bob has been a recipient of the Damer Professional Award for significant and demonstrable contributions to the data management industries. Bob specializes in non-invasive data governance, data stewardship, and metadata management solutions. And with that, I will give a forward to Bob to get today's webinar started. Hello and welcome. Wow, so Shannon, you're going to want to get through today's webinar. And you know what, when you called the name of this session, this webinar of the real-world data governance series, as data architecture is data governance, I think for the point of this meeting, especially because I have Anthony as my guest today on the webinar, how it is, we can name it, data architecture is data governance. Or we could say with a question mark at the end of it, data architecture is data governance? I mean, are they really the same thing? And there is nobody better to kick the idea of data governance and data architecture around with than my friend Anthony. So I will let Anthony say hello in just one minute. If that's okay with him, what I want to do is here we go. Go to the next slide. I just wanted to share with you just a little bit of information that I always share before we get started on the webinars. And there is lots of information to share. So this webinar series is on third Thursday of every month. And next month we will be talking about building data governance through data stewardship. I talk a lot about non-invasive data governance. So there is information there where you can go to learn more about non-invasive data governance. The book and other information is also available through Dataversity. So I will talk about that in a second. I will be speaking at a couple upcoming events through Dataversity. Oh, I noticed I have enterprise data governance online. That was a couple weeks ago. So I hope you were able to attend that. I will be doing some live online training in March. I will be speaking at Enterprise Data World in April as well. A couple of the different plans, learning plans that I have available through Dataversity are one on non-invasive data governance, my favorite topic. And then I also wanted to talk about non-invasive metadata governance as well. The most recent set of classes is the one on business glossaries, data dictionaries, and data catalogs, which we all know are big tools of data governance programs. Shannon mentioned the data administration newsletter. And so that's out there all the time, free and available to anybody who is interested and KIK Consulting. If you get a chance to go out and visit the KIK Consulting website, it is all a new, at least over the last several months. So please go out and visit us there. And with that, I want to give Anthony some time to say a word or two. Yeah, I've been uncharacteristically quiet so far. So now you can say hi and talk about what you're doing. Yeah, Bob. Thank you, Bob and Shannon. It's great to be here with you. If you like this webinar, you will like the podcast called Data Leadership Lessons because oftentimes it's Bob and me talking as well. Like the most recent episode, we were also joined by Lynn Silverston. We had a lot of fun. And we talk about a variety of different data and leadership types of topics. I think it's a good place to kind of have some of those more casual conversations that you might find having at some of these events that we're not having today. So hopefully check that out. That's a lot of fun. We try to get new episodes out every two or three weeks. I have those also are on YouTube, so we actually do record live video for those podcast episodes. My book on data leadership is available at dataleadershipbook.com and I do a lot of training with Data Diversity. Several different online training courses. Looking forward to hopefully helping some of you get started in the data management space. I know the Data Education Month is coming up very soon, so that'll be very great as well. And then, yeah, and so that's pretty much me. I kind of do this for fun now because I no longer do active consulting. So I kind of just show up to these things to enjoy the conversation. So let's do that some more today. And it's always great to have you as a guest. So thank you again for joining me. It's great to have conversations with you. And I think this is a very pertinent one for today and pertinent for the audience that is the university's audience, which is around data architecture. We all understand how important data architecture is. We all understand how important data governance is. And the question is, are they really the same thing? And so I know that several years ago, I wrote an article on TDAN. It's still one of the most read articles on TDAN that data modeling is data governance. And I had so many people yell at me and tell me, no, no, data modeling is not data governance. But again, my point in that article was that data modeling is disciplined around the definition of data. And I talk a lot about definition, production, and use of data. So there's lots of information out there. So please go check out the stuff from Anthony. And we've got lots to talk about today when it comes to data architecture being data governance. So we'll kind of tear that apart and we're looking to any questions that you may have as well. So please submit them as Shannon talked about. Before we get started, we're just going to spend a couple of minutes talking about what do we mean by data, about two things being the same side or being the two sides of the same coin. So I'll give you some examples. And it's really interesting how in industry, a lot of these things are really opposite. So when we're saying they're two sides of the same coin, are we saying that they are the same thing? Are we saying that they're different? We'll talk about that. We'll talk about similarities between these two disciplines. We'll talk about differences between these two disciplines. We'll talk about how to use one to sell the other. So if your company is very focused on data governance, how can we really make a point that data architecture is part of what we're trying to achieve, like governing data, and the other way around as well. And then we'll make a final decision. And I'm sure all of you will be very interested to know whether we've decided at the end of today whether they are in fact the same thing. So with that, like I said, the first thing that we want to talk about, and then I've got a page of questions for Anthony to talk about. So when we talk about things being two sides of the same coin, typically it means they're very closely related. But in this case, they certainly seem different. So the question is how closely related are these things? And that's what the first set of questions are going to be about Anthony. So you're ready with something to share, some wisdom to share with us. But I also wanted to share some two sides analogies. So when you go and you look up things online and say, I want to see where they are using the expression two sides of a coin, they talk about risk and opportunity. And those as being two sides of the same coin and love and pain and good and bad and good and evil and needing to hang and all of these things. So that's kind of the context that I want to lay here. Are we really talking about things? Are we meaning to say that they're opposite? Are we meaning to say that they're the same thing? So here we go, Anthony. Here's the questions for you. So first of all, is there any truth to the statement that data architecture and data governance are the same thing? And what danger are we going to run into by even saying that? Let's start with that to start the conversation. Yeah, I mean, I guess there's probably a nugget of truth in saying that data architecture and data governance are the same thing. They're certainly related. The more I think about this analogy, because Bob, we've been talking about this for a while now. And I was thinking about this in preparation for today's webinar. And I don't like, I think I don't like the two sides of the same coin analogy anymore. I think the way I'd rather look at it is as two facets on the same diamond. And the reason I like that is that diamond facets don't really exist how you want them unless you make them so. Whereas like coins, yeah, you got a coin and there's two sides and all that. And it almost overly simplifies it. Whereas I think with data architecture and data governance, I think what makes them so similar is that we're in control of our own destinies to a great extent. And that we have to decide, okay, how is this diamond really supposed to be cut so that it sparkles the most? And so if the data assets in our organizations are these diamonds in the rough as in their native form where we know there's value in their data, but we just don't know how to extract it. Well, let's take the analogy one step further and we're going to create a diamond and it's going to sparkle and that's going to represent the value in these data assets. And I can argue that data architecture and data governance, you can argue that maybe they're assets of that diamond or they're steps on a continuum and we'll talk about some of the things with what they mean, what these terms actually are. But I think that really instead of saying they're the same thing because if anyone likes to make oversimplifications for effect, that's me. But I feel like if we're better off, you know, other than just trying to rile people up with that kind of bold statement, I think the real truth is that, you know, they're not the same thing, but they're certainly not going to be successful independently of one another. And let's understand better how they relate and why they're so intertwined. And I think that's really what we want to get at today. Okay. And so I'd like that. I mean, well, we say data architecture is data governance for effect, right? We want people, hopefully some of you on the webinar, those of you listening to the webinar, you understand that. And so we want to make that comparison between the two. But, you know, so we say that kind of ingest as kind of clickbait to get you to come to the webinar to see what the heck we're going to talk about and how we're going to say that data architecture is data governance. Is there any truth to any danger actually is what I wanted to focus on to saying, to talking about how closely related they are and what's the benefit of entering them both into the same conversation? Well, I think the danger may be that either one by itself in isolation is can be a daunting task alone. And I think if we start to combine them and kind of increase that overall pool of what we're referring to, it makes it that much more unwieldy for folks to start doing them and being successful with them and makes it even harder to try to get going with it. It seems just too much. And so I think that's the biggest danger versus, you know, them simply being... I don't think there's a lot of danger in the academic discussion and evaluation of whether or not they are the same thing. I think that the problem is that either one is a challenge enough by itself. And you know, I think the next thing that we're going to look at is the definitions of what is even the definition of data architecture, what are some definitions of architecture, what are some definitions of data governance. And to be honest with you, it took a little while to find data architecture definitions that didn't have the word govern in it, because ungoverned data architecture is missing something, right? The data will not architect itself. I always say the data will not govern itself. The metadata will not govern itself. Well, the data will not architect itself either. So along with that comes accountability for it. And you know, if you think about data architecture as being one slice of the demo wheel of those knowledge areas, just as an example, that they understand that governance touches on that. I think that's the reason why governance is smack in the middle of the wheel, because in order for any of these disciplines to be successful, they need to govern what it is they care about. And so I think it makes sense to bring these things together. Would you agree with me that most people's first reaction will be they're not the same thing? Oh, yeah. Yeah, that's my reaction. That's why you're here today. That's because of that. But yeah, they're not. So we've kind of come to that conclusion. So thank you for coming. No, I'm kidding. We've got lots more to talk about. We'll talk about specifics of what these things are to start with. And so I went to, which is a place that is a great source to get information, and that is data diversity. In fact, Anthony's done a series on what is, and there's a lot of different things that he has, he's talked about what that is on data diversity. I also went to Dama and, you know, I went to their definition. So Dama defines data architecture. It basically just says that it includes anything that we've put in place that describes what we're presently doing. It defines requirements. It guides moving to the future basically it moves towards moving towards an integrated data platform and controlling data assets, and it even alludes to a data strategy. So I think that that's a, that's a good definition to just to let you know that there are so many pieces, facets to data architecture that need to be governed along the way. At data diversity, it's stated very clearly that data architecture brings business strategy and technical, bridges business strategy and technical execution. So you can see that that's, that's what data governance is about all of those things as well. I define data governance as being the execution and enforcement of authority over the management of data. And data diversity talks about it as being that collection of practices and processes. So let's look at the definitions that are out there and Dama and data diversity. And I threw one in from me for a good measure. What does that really have to do with whether these are the same or can we share some of the languages of those things. So here again, is a set of questions for you. So first of all, do you see governance in our definition of data architecture? Do you see architecture in data governance? Do they need to be? What are your thoughts on that? Yeah, so data architecture is never going to do the right thing without data governance and data governance is never going to achieve a whole lot without data architecture. I think of it like, you know, Bob, I've always been a fan of your definition of data governance. Succinct, it's clear, and it's got a little bit of a tooth to it. You've got to enforce the authority. Well, how are you going to do that with data governance? You're going to create, you know, some work docs and put them on SharePoint and expect that to enforce your authority on what you want to do with data and hope people just listen. Nobody listens. Nobody's going to just do it. And so data architecture helped provide the guardrails in actually achieving what you need to do with data governance. And this is where I really get passionate, and I'm passionate about a lot of stuff, but I especially get passionate when it comes to data governance and its relative ineffectiveness in most of our organizations. And I believe that it's because the people determining data governance policies and standards have very little to do with building the data platforms where all the data stuff happens. And so for me, data architecture is that bridge. It is that connection point. It starts to put us towards the how versus the data governance is what. And to get the whole story, you need the what, you need the how, and you need a bunch more stuff to actually achieve the goals that we have with data in that organization. That's why I come back to that notion of like the diamond. These are two facets, but two facets on a diamond does not make the thing sparkle. There's a lot more work to be done, but today we're focusing on these two aspects of it. I think it also highlights we love to break down data and data governance and all the different aspects of like the Dama wheel and, you know, just go pick anybody talking about data. They have their framework of whatever. We love to think about the details because they make it feel more actionable. But what we have to really solve for is the system. We have to solve for the system throughput of how data goes from being whatever this thing is from wherever our operational system created it into something that actually drives the business improvement. And that tap that dance of all these different functions. That's the thing that we really need to be focused on is how do we orchestrate that dance. It's choreography type of question, not just a how do we do data governance the best darn way we can that by itself. One facet does not make a sparkly diamond. Okay, I mean, to me, that makes sense and I typically want to disagree with you just for our in the webinar, but I can't do it this time. So I'll keep looking for additional chances in the future, but architecture being the what in the how. And I actually think that the governance is the through part of that. Well, because even execution and enforcement of authority all has to do with people's behavior associated with the data. So, but people also need to behave when it comes to pulling together the artifacts that are necessary to have data architecture. Actually, it's not the questions not on this page here, but maybe you can talk about how do these things fit into data strategy. This data strategy then include architecture and governance. Oh, yeah, I mean, I think it absolutely has to and I actually think that's a good place to start thinking about it because data strategy is also not the place to start. It's actually business strategy and then he starts saying, well, how can we use data to execute a business strategy and now you can get into data strategy, right. So but at least it's relatively contained but still broad enough to have all of those facets in your sphere of thought. Right, so I think that is a good way of thinking about it because when it when you start thinking about the data strategy, now you're starting to think about how do these different functions relate to one another versus how do we do this one thing. I think, you know, what I've seen with a lot of data governance, you know, efforts that get started is that they get started by having a meeting and they talk about data for a while and then they're like, let's create some rules for folks. And that sounds like a good idea but the problem is that you don't really know what you're trying to achieve with those rules you just are trying to do things that you think makes sense. And so if you if you are oriented first towards business strategy that changes the dynamic quite substantially because now you're thinking about okay, how does data help our business. And what are the things that we're struggling with in using that data to help our business. And then that starts to form the basis for what you are trying to do with data governance. Because you're saying hey, let's remove some of these impediments or some of these challenges that are caused by people trying hard but they're not very coordinated and they're not really knowledgeable on how they should or shouldn't do certain things let's help them out. Now we start to create this path towards improving our businesses with the data versus simply saying, well that data certainly got a lot of risk we better govern that so we don't expose all that risk which is a noble intent but it limits its effectiveness. So what can we do that what can people that are engaged in organizations around the country around the world do is there a place they can go it seems like what I'd like to investigate a little further here is the whole concept of the business strategy. So is there typically a because you would think that a business strategy does for the business what a data strategy would do for the data right and it would interrelate those pieces and talk about how they work together. Do organizations have business strategies that that are documented that are shared that we again I'm trying to look to you say you talked about orchestrating a dance or or something like that. Who who orchestrates the dance. I mean, is it the business strategy mentioned is first, and then there's data strategy to address the things that are detailed in the business strategy. Does it start it does the orchestration of this exist at the data strategy level. I like how you're or each of the groups are they meant to be independent. So I like how you're trying to paint me in a corner but the secret is I'm putting carpeting in this room so no pain is going to block me in but the. So, so let's let's break this. So first off, your organization should better have a business strategy, hopefully an articulated one hopefully documented and synthesized one. If it doesn't you've got big problems but if you do and it wasn't advised or the data folks the data strategy people that the people that are going to create that data strategy. If they weren't involved in that business strategy process. You got a new kind of problem and that is your business strategy has no idea what's practical from a data perspective especially so you don't know what's even in the realm of possible and so this is where the deflect has to come from is that really. Our data experts should be involved in the creation of that business strategy so that the business strategy is not insane and then we can then figure out the execution plan in the data strategy tied to all of that. Once the business has said hey these are our priorities. These are what we want to achieve and the data people can talk to where we get our hands on the business strategy. Well I mean your executives are going to have your business strategy but that should be something that's more widely shared like everybody in your business is and I hope that they are involved in making the business successful. You should at least have an idea on what that business is and what that that success definition should be for your business because that's just a fundamental leadership thing. You see a lot of mission statements. You see a lot of vision statements but they don't necessarily have the breadth of the strategy that you were talking about. Well yeah you need to break those down into an action plan right so it's and this is the thing like we have to recognize that data governance and even just data itself is fundamentally a change agent for organization. That's why data like is useful is to help us do things better and they could help us manage risk better, could help us make more money, it could help us save costs, it could help us be more efficient. All those things are good things but the fact is that data only helps when you do something different and that to me is why like the business strategy is all about doing something different. Well couldn't you do the business part of their business better if you're informing it with data? And so it's all an intertwined system and the more breakdowns there are because I think Bob you're raising some very good arguments here. And that is most businesses don't actually do this very well and it's and it's there's all these breakdowns and there's all these oh they're going to be over in this place developing a business strategy and we're going to be over here and they're going to be over there. Like that's the problem right like that's why data governance is so hard is because we're trying to string together all these disparate groups who don't talk to each other very well under good circumstances let alone when you're like hey let's do this really hard work around data that nobody quite understands. Like that's a really big ask even in isolation of just the data governance question data architecture now takes it to another level because there's probably an implied resource commitment to doing data architecture means you're building something creating some sort of probably technology driven mechanism to further the changes driven by data in your organization aligned with your business or data strategies. And so all of these things are so interconnected that when you see big gaps between the people that should be working really closely you know there's probably something there that you want to start to address there's a bottleneck there there's something there's a disconnect that should be resolved and I think that's where you're coming back to one of your earlier questions is that when you think about you know what is it that you really want to do in your organization to be successful and what are the things standing in your way. None of those are fundamentally about data data as an influencer it's an attribute but it's not the fundamental purpose of your business under most circumstances and so you have to think about how can we accelerate I like to think of it. As an as an amplifier like if and I love the audio quality and I like to think about this it can often be this this tricky solution. Right but if you if you're amplifying something and there's a lot of static and there's a lot of feedback you're going to make that loud version of it bad it's not going to be very pleasant to listen to but if you have a very clean source and a very good amplification quality. You're going to have a much louder much richer sound projection and that's really with data the same kind of scenarios that if we start to add all of this noise into our data processes and into how people are working with it or these gaps. You have all of this noise in the amplifier of technology and that's that's what's really problematic and that's how it manifests for when businesses struggle using data it's because there's too much noise amidst where there's there's real value inside of it. You know what we could we could talk about this easily for the next half hour we got other questions. I'm going to fundamentally disagree with something you said and it's that you said that it well maybe I just kind of read something into what you said you might have to leave an opening for that potential to take place but you talked about data not being the fundamental purpose for an organization so you know I work with banks I work with biotech companies I work with government agencies I work with manufacturers anybody who is looking to put governance into place and metadata management into place. And it seems as though the data is it has it may not be the fundamental purpose but even though a company might not be what would be recognized as being a data company they all are right and they all. So we need because you just talked about connections making connections with between these things and getting you know basically getting the almighty light bulb to go off above somebody's head to say okay we understand that these are connected fundamentally and that we need to address this. Finding that person in the organization that's going to take that and move that forward. You know maybe what we're talking about here with data architecture and data governance is really very far down the food chain when it comes to. You know where these things should be positioned within the organization so I'm going to go on to the next set of questions but. Let me address that for one minute though because I think it's an important point and you're not wrong but I want to articulate a little bit more clearly what I meant by that and that is data is the closest thing we have to truth in our organization. And that's a really important part of helping our organizations be successful. The thing is is that it's a means to an end it is not the end itself it is an important cog in the machine and the machine doesn't function without that cog. But it is not the fundamental purpose for that machine to exist and so I think about it as as yes you need data you need to leverage that data to achieve your business goals but simply acquiring data for most organizations is not the end. It is an important part of that journey but there's something else that's compelling you and if we mistake those two things and treat them as exactly the same we will lose our way because we lose that anchoring to what really matters to the business. We start treating data as important and an end into itself and that leads us down paths that are suboptimal compared to if we were orienting more clearly to what the business is really about. I've got a great analogy for this. It's like it's a diamond facet. Yes, well done, well done. It makes perfect sense to me now that it is truly not the end all and be all but it is a piece of what is going to make an organization better if they're looking for continuous improvement. Okay, so that's kind of it was kind of brought that full circle that whole discussion full circle, which is, you know, that is really a great analogy. I think I saw some people mentioned in the chat that that's that that makes sense as an analogy. But now let's kind of get back to the topic of hands here the data architecture and data governance. You know, can we for anybody who's thinking that data governance is as a data architecture is data governance. Can you explain very simply what you know how does data governance relate to data governance or how does data architecture relate to data governance and the other way around. And, you know, why is it important to make that distinction if it's important to make that distinction. Yeah. Well, I think data architecture is still one of these terms that has a wide variety of interpretations, even with the definitions that you put forth when we think about it in practical terms. Data architecture is hard to put in a box is data governance. I think data governance is something that, you know, in actual practice can mean a lot of different things. And so I feel when I think about data governance and going back to your definition of enforcing authority and help clarifying things around what our data assets are. I think that's, you know, a good high level directional mandate. Right. And I see this as being the driving principle. It's like the mission statement. It's like, okay, we got to do these things. And it can break into more detail and governance really gets involved with that stuff. But at some point you have to decide, okay, you know, here's the rules that in front of us. How do you go play the game? And to me data architecture is like building the field on which the game is played. Like the data governance is going to tell you the rules and it's going to cover the game that's about to be played on that field. But the data architecture is interpreting those rules and putting together a framework in which those rules can be implemented in the most effective manner possible. So I'll go with a baseball analogy because that's pictures and catchers and I'm so done with snow here in Chicago that I need to think of spring. And so baseball I think is a fair analogy for this. And if data governance is the rules of baseball and data architecture say, okay, here's the field, here are the balls, here are the baths, and here are the players. Like how do the players get onto the field or how do they do it? Like that all gets involved with the architecture, but it's not the same thing as having those players play the game. And I think that they're intertwined. Neither one really does a whole lot by itself without the other, but they each have functional responsibilities. That's where I think they fork and separate. That's where they deviate from one another. Is that the data architecture responsibilities are about building the structures and framework in which data governance can be achieved. Data governance is about helping data architecture build the right thing for the right game. Like instead of, you know, if you don't have data governance, you're going to go out to that field and you're going to say, let's put some lines on that field. That sounds good. You know, you're going to end up inventing a game like my children do. And that may be a fun game, but it's not very extensible to people who haven't played it before or were involved in the invention of that crazy game that, you know, the children are playing. And so I think that may be, and again, I run a big danger when I start doing analogies on the fly, but I think there was some truth in that one. So I think I think there is. And it's a very timely, I guess, pictures and catchers reported yesterday or something like that. The pirates have pictures and catchers that'll be a good for this year. We're not sure that they even have them yet. So it's almost as though data governance is kind of the protocol and that data architecture is the execution of that protocol. Or, you know, it's because people that can relate to being a data architect are not necessarily, they play a role in governance, but they're not, they're not stew, they're stew. I say they may be technical stewards of the data, but they're not business necessarily business stewards of the data. Is there a clear, is it a necessary distinction to make between these two so that companies can articulate this that you can't have one without the other? Well, I think there is. And I think the data architects still have to do a lot of interpretation of the broader rules set forth by data governance. And they exist. Data architects really exist at a metadata type layer. They're creating structures that data flows through. I think of it sometimes as pipes that the data flows through, right? And oftentimes the folks that are building out those structures from a functional and career perspective, they are not the ones that should be developing the rules for data in the organization. Like, I would identify more as a data architect than a data governance practitioner by trade. And I would say I really want to have more insight coming directly from the business and I coach them into what we need as data architects to help us build the right thing. But I really want somebody who's deep in understanding what that business strategy is, deep in understanding how we execute our operations of our business, and where are the struggles that we encounter with data? What are those reports that are just unreliable? What are those things that have caused us to make bad investments? All those stories of where data has not achieved its potential, those are the things as a data architect I want to understand. So I can build out structures and lead development teams so that we're creating the right kinds of technologies and artifacts that folks that are putting data to use get the most benefit from. Otherwise, I'm just flying, I'm guessing too much, and I still have to interpret because I have a whole function that I have to do that the data governance folks aren't going to necessarily do. But I need that help. I need that guidance or otherwise as a data architect, I'm just making too many assumptions and that increases the risk to the business as well. Though I mean well, it's not a guarantee that I'm going to build the right thing. Are organizations more sold on that they need data architecture than they need data governance? Oh, it depends on your context. I think that a lot of folks might say that that's the case. A lot of data architects are saying, hey, with all of these tools that come out, these in-memory data platforms that make it so that you don't need data modeling or data architecture anymore. I'm not a video, but I'm waving my arms wildly in hysterics right now because there's a constant pressure on businesses to buy that easy tool. Oh, this is going to solve all the problems. It's not. And there's still a need for data architecture even though technology is more capable now than it used to be. But there's more data to deal with than there used to be. And there's more confusion and complexities and what people are doing and how our businesses function in that data landscape and the technologies that are available to us. So yeah, I mean I think maybe some businesses are more aware of the need for data architecture, others are more aware of the need for data governance. The fact is that they're all important and they're important at varying degrees at varying times. It's not like you're going to say, okay, we're going to take $5 million and we're going to put one data governance, one data architecture, one data quality, one metadata management, blah, blah, blah. And just do that for the next 20 years. Really, we need to have influence. Okay, where are we weak? Where do we need to help? We've been doing it that way for so long. Where I mean organizations don't connect the dots as well as they need to connect the dots and to understand that to understand the relationship between these two disciplines. Because as you said, you can't have the field without the players and you can't have the players without the field you're not doing you're not getting anything done. And in fact, these things really, I would think that data architecture would end out that a good data architecture would result in data governance and that good data governance would result in the appropriate data architecture taking place. So these things are, that's why I asked the question of which one do people feel is more important to their organization. And can we use whichever one is more important based on the context of your organization to bring the other one along with it? You know, when I say so, we know that these are both data disciplines. We know that they both basically require people and process and technology. And we certainly understand that without having senior leadership support, sponsorship and understanding that any of these disciplines are going to be at risk. And so there's a common understanding between those things, then the kind of the question becomes, should we sell these things together? Should we even mention them together? Can you do one without the other? Which one really needs, is one of them dependent on the other one? Maybe you can address that for us. Yeah, well, and I think, I was just thinking that one of my favorite things to say at the conferences that we're not having right now, but like when I'd stand up in front of a room, I'd say, you know, this right now, this is the easiest part of my job. And this webinar, very similarly, very easy for me to sit back and tell you how I think things should be, right? And how, you know, data architecture and data governance are combined, and then we've got, you know, strategies and all of the stuff that we've been talking about. And that's great. But when we get to the real world, things get muddy really quickly. And there's failings of leadership and structures all over the place. I was just thinking about, like, you know, we think about the way we've been doing these resource allocations for so long, Bob, like you mentioned. It's like, who here has been in a business where come December, anybody who has money left in their budget starts spending it on just random junk that they don't really need services and tools and whatever, because they don't want to have their budget reduced next year. Oh, insane is that. Like, that's a normal thing. You should see my face when I got like aghast by that. I mean, we have to recognize that logically that is just insane. But that's how it goes because the alternative is much more work. And there's only so much effort we have to work with, right? And so I think that that's what it comes back to is to say, what is worth putting the work in? Where will an architecture argument versus a data governance argument land in your organization? How does your organization think? What is your senior leadership oriented towards? Are they already very data driven? Are they very interested in it? Are they motivated by some of the latest and greatest things? Like artificial intelligence and machine learning? Are they throwing those terms around? Like, figure out what is most important really to your business and then figure out how it resonates with what is most interesting to your leadership and see how you can bring those together in a harmonious way. I think that's key is to recognize what's important to your leadership. They're your leadership for a reason, whether you agree with them or not. You need to respect that they are in charge of certain areas that you want to influence and help. But you have to recognize that it's not better to be right but ineffective. You want to be effective no matter what. Even if you're right, sometimes meeting in the middle will accomplish more than simply saying, if we don't get this money for data architecture and data governance, we don't do it this way, then we're going to be wrong and everything's going to be broken. Well, you can be right and not make any difference. Or you can find a way to work with when all of that chaos and craziness around you and find a way to be effective and move that needle forward however you can. The terms here, the priorities here, all of it is useful knowledge to have as you go and break all the rules in real life because you have to make accommodations that I don't have to make when I'm talking in a webinar. You just hit it right on the nose. I mean, it's easy to talk about things theoretically, but as you mentioned, the things are not clean. And everything goes the way in the decision making is the way that you need it to be in your organization. And some of those things you can have an impact on and some of them you can't. And we as practitioners are spending a lot of time trying to match exactly what your data governance council or what your steering committee or what your board wants to know about this. And we're thinking that, you know, if we put the words a certain way that all of a sudden the light bulb is going to go off. But, and I think it is continuous education. You don't bombard them continuously with information, but you want to constantly be communicating about the importance of these things, getting the opportunity to present a case for why even a limited number of resources should be spent on either data architecture or data governance becomes really critical. But we all seem to be wrapped around that axis of, we have the word, in a way that needs to be a word, it's better that no, they'll see the picture. You know, they've got a lot of other things to think about. It's like the facets of the diamond. Again, they've got other facets that are being looked at that we don't even know about. And you know what? A lot of those could probably be tied to data too. So like I said, we could talk about this for another hour, but we're not. We're going to kind of wrap up. I do want to highlight. There was one thing you said in there and you went past it really quickly that I really want to highlight. And that is, you know, the question is, how much does your leadership really need to know or really need to care or understand about all of these nuances? And the key point, I think, is that's an important question and be very deliberate in how you scale up and down your granularity or abstraction of the conversation. And when you're talking to data architects or developers, it's going to be at one layer of granularity. When you're talking to senior executives, it's going to be at another. But just recognize the most important thing in any of those conversations is what is the recipient getting from this? What is in it for them? How will they benefit from this conversation or from this evaluation? And their need for detail varies considerably depending on their role and depending on what their decision framework is and what they are actively engaging in their own role. So be thoughtful about that. I think there's often not enough thinking deliberately about what layer of detail does this person really need. And you know what? The word I've been using a lot these days is the word resolute. I mean, there has to be a resolute effort. So there needs to be someone that has the time to put that thought into it and to get it in front of people so that they're understanding what it is that we're doing. So basically in this discussion so far today, we've basically decided that they're not the same thing. At least when we peel it down several layers to get to the pieces or the components of a data strategy of which data architecture would be one and that governance would be one as well, that when it gets to that level, they're not the same thing. They are different. They're related in a lot of different ways. You know, if we just added the term governing to the definition of data architecture where it says it's the form of governing the specifications that are used to describe the existing state, the data requirements and those types of things. And that's basically stealing from the definition that I used earlier, but just putting the governance aspect into that. So we know that they're related. We've kind of come to the conclusion that they're not the same thing, but we've also kind of come to the conclusion that doesn't really matter and how much does the executive level of the organization really need to know about that. So any final words on that, Anthony, as to that they're not the same, they are, they're closely related, and then we'll see if Shannon has received any questions for us. Yeah, I think you're right on, Bob, and I think that at the end of the day, the differences and the similarities are less important in comparing data architecture and data governance to knowing that these kinds of functions are very important to the overall story. And it's not just these two things, there's so many more of them. But I like this discussion and I think that that last point on this slide is an especially good one because it really helps connect the two versus the earlier definitions, which were a little bit more isolated and they are very intertwined. Okay, and so we'll just leave it at that and let people draw their own conclusions. You know, basically over the last 50 minutes we talked about the whole analogy of the two sides of the same coin and the diamond facets analogy that Anthony spoke about. And I think that really, really describes it perhaps better than saying that it's really two sides of the same coin. We talked about some of the similarities. We talked about their place in the overall strategy for the organization from a business strategy that has a data strategy that's involved in the, that's kind of connected directly to the business strategy. We talked about the similarities between these things. The difference is we talked about how to use them, how to try to use one to sell the other, or is that a good idea to do that? And we basically come to a quick conclusion that they're not the same things, but they are similar in so many ways. And they're all a facet on a diamond that can be used to improve the way that we are data centric and digitally focused as an organization. So with that, I am going to toss it back to Shannon to see if we get any questions from our discussion today. We did indeed lots of questions coming in here, and we'll get to as many as we can. If you have, if we can't get to it, of course, we'll get the questions over to Bob to include in the follow up along with links to the slides and the recordings, which we'll get to in Monday for this webinar. So diving in here, so where do they intersect? Where there are two key governance things that need to be considered when data is architected, data retention and data classification, personal info or confidential. If not architected properly, turn DG, they turn into DG issues. Any comments on that? Well, Anthony, I'll let you talk about it, but I would think that even the things that were just mentioned within that question are only two of the facets within data architecture itself because classification is very important and protection is extremely important, but there's the whole quality perspective of it. There's the consistency and the duplication and things that cause problems within the organization. So I don't know, Anthony, you've got a way to address that? Yeah, and I kind of agree with you, Bob. And I just know I won't do it justice in the short time, but I did an online trading course in data architecture for dataversity. And we explore a lot of that because I think that data architecture and though those two points are pieces of it, it's gotten much broader in its scope. And it's really taken on a lot of things that sound like enterprise architecture or sound like a technical development type of role. And so there's a lot of facets to this that aren't just purely data architecture isn't just about data anymore. And I think that it goes much bigger. But I do think at the end of the day it is interpreting and implementing the standards and policies of governance and connecting them to those technology amplifiers that you have in your business. And there's so many different aspects of it. It would justify its own online trading course, which I created for you. I know where people can find that. I love it. Are all artifacts of data architecture useful for data governance? Oh, yeah. I mean, I think that it gives... Well, I think that there's a give and take. And I think, and this is just a good rule of thumb, is anytime somebody is doing a lot of talking at the recipient and not doing much listening, there's an imbalance there that probably would benefit from being corrected. And so if you interpret data governance just sends it down the mountain to data architecture and data architecture has to deal with it, it's just like that relationship between data strategy and business strategy. And that if the business strategy isn't informed by what the data can actually do or what the data really is, then you're going to have this not coupled connection to reality. And similar with governance, if you can decide all you want, but if you don't have a way to actually anchor it to the assets that you have, then your data governance is just going to be floating out there without any real relevance to the data that you have in your business. So by all means, see these patterns. They exist at many different layers of granularity and abstraction. I think it's very interesting how these patterns exist in so many different places. The question was asked was, are all of the artifacts of data architecture, are they useful to data governance? And you talked about that some of them are really, really detailed and some of them are more high level. You know, I would answer the question that if the artifacts, if the information in the artifacts that are being developed by data architecture is going to move the organization, move the arrow the way that it needs to go. You know, that information, it becomes useful to data governance. If it helps to improve the literacy of the organization, if it helps people to know what data exists, where it exists, how to get to it, then it is something that is useful to the data governance. I don't know enough about data architecture and all of the things that a data architect does and keeps track of to know that everything that they keep track of is going to be a value to somebody. That's why, you know, when I talk about metadata governance, it requires because there's a lot of different types of metadata that can address a lot of different things. So there's not somebody who is somewhat selective and saying, we need to manage this specific information. And you know what, by chance that happens to fall in a data architecture artifact, that it's valuable enough to make that information available to somebody else. So, I mean, again, I think that it's, a lot of it will depend on the organization. But, you know, again, depending on that level of detail that the architects are managing, I would say probably most of it would add value to somebody if you can make the connection to that somebody. Well, and I want to add one thing in that your data governance should be creating orchestrations with leverage where you can extend far beyond like your data governance council. Like is your data governance council going to be looking at code that was involved with data architecture? Probably not most of the time. If, though, say you had an audit finding or a GDPR fine type of thing that all of a sudden you're staring down a, you know, seven or nine figure type of fee, you're going to get real detailed real quick. And so how do you extend the policies at the governance level where they're actionable out to architects and developers and the people that are entrusted to build those systems in compliance with governance. And then when issues arise or new circumstances warrant, you're going to want to be able to dive all the way very deeply, maybe with some help, certainly, but need to be able to get to that level of detail and make sure that our governance enforcement of authority managed to percolate out in an unfettered manner all the way to the most detailed granular aspects of the organization. So you're saying, yes, it's potential that every artifact is useful to governance. I think that potential has to be there. Otherwise, not really data architecture. All right. Well, we have less than two minutes. So if I can get your elevator page on this next one, what is data governance? What is data governance drive? Does data governance drive data strategy or does data strategy drive data governance? I say that data strategy, and I did a session on this recently, I think it was a recent data diversity event where data governance is a component, at least in my mind, it is a component of a data strategy. So there is the people aspect of governing data. There's the organizational aspect of it. There is the behavioral, the whole behavioral aspect of it. And there's the culture of the organization needing to become more data literate and being more data aware. So I say that data, in my opinion, data governance is a piece of an overall data strategy. What do you think, Anthony? I'll let you have the final word. Yeah, I think that data governance, just like business strategy and data strategy, data strategy can inform the business strategy. I think good data governance should be probably more quantified than it often is. And I think that that can help drive what that data strategy prioritization set is. Where are we weak? Where are we strong? What are we struggling with from a data perspective and data governance's view? And that can inform what do we want to do about that? And I think that's where that feedback loop exists. But I think under most circumstances, the data strategy helps set the priorities for data governance, but then the data governance outcomes can influence what those priorities are. Oh, that was awesome. I know I gave you guys like a massive question to answer in a few minutes because you can be amazing. Well, thank you both so much for this great presentation. Thanks to our attendees for being so engaged and everything that is all the time we have for this session. Anthony, what's always nice to have you on and really appreciate you joining us. And just a reminder, I will send a follow-up email to everybody by end of day Monday with links to the slides and links to the recording of the session. Thank you both. Thanks, Shannon. Thanks, everybody. Have a great day, everybody.