 Hello, and welcome my name is Shannon camp and I'm the chief digital manager for diversity. We want to thank you for joining the latest in the monthly webinar series data architecture strategies with Donna Burbank. Today Donna will be joined today Donna will be talking about enterprise architecture versus data architecture, 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. First we will be collecting them by the Q&A section or if you'd like to tweet we encourage you to share highlights or questions via Twitter using hashtag da strategies. And if you'd like to chat with us or with each other we certainly encourage you to do so just note the zoom default is just to the panelists but you may switch that to chat with everyone in the webinar. And to access the Q&A or the chat panel you will find those icons in the bottom middle of your screen for those features. Next you will send a follow up email within two business days containing links to the recording of the session and additional information requested throughout the webinar. Now let me introduce our speaker for the series Donna Burbank Donna is a recognized industry expert in information management with over 20 years of experience helping organizations enrich their business opportunities through data and information. She currently is the managing director of global data strategies limited where she assists organizations around the globe in driving value from their data. She has thousands of Fortune 500 companies worldwide in the Americas Europe Asia and Africa and speaks regularly at industry conferences. And with that, let me give the floor Donna to get today's webinar started. Hello, and welcome. Thank you Shannon always a pleasure to join you guys. And as, as Shannon mentioned, this is a monthly data architecture series so if this is the first time you have joined us welcome. Any of the previous webinars are of interest to you and you miss them they are all on demand. And one of the questions that we always get asked is will this be on demand and when we get the slides and yes to both. That's one of the benefits of diversity, everything I think since the beginning of diversity is still online and accessible which is a really nice resource. What we'll be covering is enterprise architecture and it's specifically enterprise architecture in its relationship to data architecture so this is the data architecture series and we'll definitely have a bit of a bias on data architecture but the beauty of enterprise architecture is that it really takes a more holistic view of the organization as how data relates to process business process, business capabilities, and most importantly business value. So if you've been on my webinars before you'll know that sort of my, my passion is really how you use data, but most importantly use data to drive business value and this is a really good time in the industry if that's of interest to you. I mean most organizations are trying to be data driven. And enterprise architecture is a really great way to support that I think for whatever reason often architecture and particularly enterprise architecture can be seen as well something academic or, you know, not not very practical but I would say very contrary, when you're really trying to drive business value it's almost impossible to do it without some of these enterprise architecture artifacts so if the enterprise architecture is new to you this may be a helpful webinar. If you are enterprise architecture expert you may think some of the things I'm looking at doing are rather light, and it is I have a one of my other passions is, how do you do just enough architecture to show that business value because, you know, you are just doing data models and process models and all of that, but how do we get that time to value and really focus on that. So what are the business value. So, because we are data architects we love our definitions. So I always like to start with a definition of what are we even talking about I'm a bit of a fan of the art Gartner glossary they tend to have a good definition of a lot of the RT terms. And what I liked about their definition of enterprise architecture is that it talks about not only kind of that foundational aspect of the building blocks and what you need to define an architecture but it also talks about really how it is a response to the changing of disruptive forces in a business and how it really aligns to business vision and outcomes and that's how I like to use enterprise architecture and that's how I see enterprise architecture. So I would I would agree with them it's. Yes, it's a foundational aspect of anything you're doing, but the real so what but the reason you're doing it really should be aligned with that business vision and business outcomes. So you are new to date enterprise architecture, and you may be a data architect we get we often get a lot of data architects on this call. I think enterprise architecture is really easy. Nothing's easy right there's a lot of skill involved right, but it should make a lot of sense to you because if you're used to modeling data, you're just taking those modeling skills and applying them to other things. You can model people in a way can we model motivation can we model business goals can we model business capabilities business processes, as well as you know all of the other area of application of the organization applications data network etc. You may not need all of the types of models and enterprise architecture ecosystem, but you may pick and choose to the ones that may really help tell your story when you when you're trying to relate that to business and business value. They're also like anything in our industry there's always several flavors several different definitions competing ways of doing things. Some of the more popular frameworks for enterprise architecture. And then you may know john john Zachman he comes to some of the data version is and enterprise data world conferences. And he, his way of looking at it is kind of simplifying things into that classic who what where when how. And I would say that the data is generally that what column. And there's different levels to that there's the business level the executive what down to the very, you know, implementation level of what and everything in between. I think a lot of us on the call are familiar with that. But when we're looking at more enterprise architecture you're going more horizontally across the, the how, and maybe the business processes that support that data, for example, the who in terms of capabilities and business responsibilities and things. So, we'll kind of use some of these aspects in this presentation another very popular and very robust way of looking at enterprise architecture is kind of that toga approach. Again, each one of these could have a whole webinar in themselves, but one of the things I like about the toga if you'll see even at the top they kind of link that business data application and technology is different because they try to do that cross functional breadth and depth across all of those different areas. Because when you're looking at an organization holistically, you can't look at one and not the other you can't just look at data without the applications and you can't look at the applications without their business value. So it's just kind of a nice framework to look at all of those holistically. So looking at data as part of an enterprise architecture, you know, one way to look at this and this is just some of the artifacts you may use but it's how do we take data and put it in business context or the context of the rest of the organization. So there may be the pure business view, you know what is the business motivation why are we doing this gosh I think we've all been on projects where sometimes in the middle of it you come up in the middle of a late night of coding and you're like, what the earth are we doing this anyway, but that's not a crazy question to ask you always should be asking the why, and then what business value are you supporting, as well as business capabilities, business drivers, etc, etc. I mean, all of these arguably are business focused but business process, especially if you're working in a very process centric type of industry like manufacturing is a common one that really like has that nice connection with business process and data. As I mentioned with that document framework, there's different layers of data. Yes, physical data models databases data architecture is very important. But I like to also start with a conceptual data model just that business view, or you could argue even a business glossary is a business viewer taxonomy or etc, etc. And then how do you map them together show for example, and there's others, how do we map data to process for example with something like a good old fashioned crud analysis if you're familiar with that. If you're not, we'll talk about that a little bit later. So hopefully that's one way to kind of give an overview of sort of how some of these things fit together. So maybe I often show some of these kind of, really, what do you call them that were trends and each year. I work with diversity, we do kind of a trends and data management report the next one should be coming out shortly for this year. So stay tuned. But this is a question we asked a couple years back with what types of diagrams do you use in your data slash enterprise architecture so this doesn't list every enterprise architecture, you know model there could be. Obviously, this was a diversity survey sort of trends towards, you know, a whole lot of logical and conceptual and physical data models. I did find it interesting that logical and conceptual was higher than physical. I might have thought it was the other way around but to me that's a great statement that people are really using these for business audiences I have had great success, having conceptual data models as part of the conversation. When we're working with business sponsors data owners, you know, kind of that business side, just a nice communication tool to really get to the nut of a lot of issues. But you'll see other ones that are pretty popular, you know, right below things like data flow diagrams you see business process models. I'm not surprised by that. I often do a process model with data it really sort of gets to the how data is used. We'll talk more about that system architecture diagrams of course I generally do those as well. So a little lower you'll see things like business capability models will cover that today credit matrices, etc. So I found this heartening that a lot of you know I'd like to obviously see a lot of these higher as 100% right but it does show that a lot of people are kind of looking holistically at data as part of the larger organization and I think a lot of that is with with companies trying to be more business driven data driven, which kind of speaks to how do we show data in a business context. So, moving on, I think we've all heard the analogy or use the analogy of, you know, sort of building architecture, you know, we try to if you're a data model or say you're a data architect on this call, and people try to explain you what do you do for a living. Well, it's kind of like when you have the architecture for house, and you try to say how many rooms that has and where the bathroom goes. Yeah, that's what we're sort of doing with the data and it's a very nice analogy. And I think if I'll refer to this later we actually did a webinar with a construction company that was using both kinds of models both data models and design models so that was sort of nice. But I think when we're in the world of building up, you know, skyscraper, it's pretty clear that there's a difference between designing the skyscraper and building it, you know one is very tactical with a hammer and nails for skyscraper permit me the analogy. Yeah, actually building it and getting your hands dirty versus designing it which is more of the before we build we really need to understand if this 100 story skyscraper or five story skyscraper there's going to be a huge difference in terms of the materials you use how long it takes, etc, etc. We're pretty used to that in a, you know, physical building, and we don't question that so much. I think, again, because it's so tactile. This is also a clear distinction in some of these roles and of course on a smaller project, maybe one of these people can do all of the above, you know I did a small edition of my house, and the person who did it sort of did some simple diagrams and quote engineered it and also did the building but that was a very small, you know, kitchen that I wasn't building a skyscraper, but if you are building a larger enterprise type building. You've got the architect you can all if you're on a building site you can probably tell who the architect is he's wearing a suit. He's got the hard hat but he's got the diagrams under his arm. And that person is, you know, working with the owner they're drawing the diagrams they're looking at the vision you can see them almost moving their hands around saying what if we had another floor, and what if we had windows looking out towards the mountains or whichever it was right. You kind of expect that I think there's a lot of parallels with the data architect. You know how do you shut up a data architect tie their hands together right we're always the ones let me give me a whiteboard how can I draw this out right. Engineers, similarly, I think we understand that that's the person that's going to make sure that that skyscraper doesn't fall down, or using the right materials. You know, where do I what kind of steel do I use etc. And then the builder is the person on the side, you know, swinging that proverbial hammer to actually do the building of the house. There's a lot of skills within that are we pouring the concrete are we doing the, you know, you know, the glasswork or whatever. But again, because it's so tactile I think you clearly see those distinctions, especially on a bigger project obviously sometimes in a smaller project here one person, but similarly with with tech or data. It is often difficult to tell folks apart, you know, here we have our hipster developer. We're in the same clothes you're still in front of a computer. How could just the average person understand but I do think there are those that distinctions. I think with anything we have trends and I know these these roles. Sometimes it's kind of what do we call this role of the person we're going to hire. We actually did do a webinar last year on that in terms of roles that that's something you are trying to hire for or kind of do your own job description. But there are still those types of roles, an architect still should work with quote the business owner to understand the needs draw the diagram see their vision requirements. Look at that vision kind of get excited about the owner's vision for your business project engineer I want to make sure the data platform or structurally, you know, sound, should it be on the cloud. What are our data pipelines look like is a performant, a lot of work there but it's different work than the architecture work, and then the builder I might be actually writing the code. And again, there is overlap but I think separating out those types of activities, so that you don't just jump to build, I guess is what I'm saying and architecture isn't just documentation after the fact. It needs to be done before the fact you don't you don't build the size skyscraper and then say huh, you should tell somebody how many floors there were, and if it's not going to fall down is sort of too late. So I think these parallels exist but sometimes it's a little less clear and in terms of some of the roles but there should be kind of these distinctions. When I look at a good data architect, just like probably good architect for house. You might wonder about this one. One of Donna Donna's weird, weird thoughts. But if you're familiar with with Janice, who is the God of the Bay of the word January comes from that. He was the two headed God at the beginning of the year they can both look forward towards the new year and also look back to the past years. In history, I kind of think a good idea architect can sort of be that multi headed approach in terms of the business and technology so a good architect and say okay this is where the business needs to go we really need to do more real time data streaming so our customer support can do, you know, faster response. So what kind of technology we need for that. And vice versa we have this technology what's the business need we could use for this etc. So it is sort of a rare breed of a person that can look both but that's also a very valuable part of the organization. And that's why some of these tools will go through our kind of focused on both, you know we are kind of trying to sum up the business, but it's that technology view. I mean with the quote owner, am I building a summer cottage or am I building a mansion, and why, and so that that's sort of the same thing we did. So, what are these architecture diagrams and artifacts so just some tools of the trade and maybe some thoughts of how to use them. So one we use a lot and you've probably seen it in my presentation. I'm a big fan of what I call the one pagers. I think Shannon actually says I say this one lock out of your elevator pitch how do you sum up anything in your life in that quick one page, five minute summary and I do this in my own life you know what's the so what with there's so much complexity. The more one of my customers said and I stole this from her, you know when in doubt zoom out, the more complex things get, how do you zoom out and see the big picture get up into the, you know, the airplane so you can look down at the fields and really see where you're moving. And so all of these artifacts that I'll be showing a lot of them have that flavor of them up, because we are, we are in a world where things have to move quickly. So you probably can't get away with doing a process model this as a first phase that's going to take you six months or a year raise was just enough of these models that we can get that big picture see the interrelationships, and then keep moving. And then we build that is called a business motivation model, which really sort of sums up of the so what of what are we even trying to do as an organization. Obviously, this is a fictional art company. Art supplies but what are we trying to do with our mission and what's our vision and then what are some of the internal drivers as a company that may be in your corporate report and we're trying to get that 360 view of customer we're trying to grow revenue. It could be, I don't know it could be an insurance company and we're trying to reduce risk, you know, getting that summary of what the organization is trying to do, and then also looking externally. So for example, this is a fictitious art supply company and they could have said you know we only do brick and mortar. We really love our crash people to come into the store and we have sewing circles and we do all of that. They only done that. They didn't look at things like the external drivers of digital self service and COVID hit. They probably still wouldn't be in business right so how can they take their model and look at what's happening externally. We want to do that with your own company. And then what are the goals and objectives from a data lens. So, for example, instead of going to management saying hey we need to build a data governance framework which can seem kind of drawing boring. We need to build these marketing headlines up. We need better accountability for our data we need better data quality, we need to build a data culture to really use data to drive business decisions or something like that but again, this looks really simple but sometimes the, and they shouldn't take a long time. It should be a day or so to build them or a workshop and we do a lot of these in whiteboarding, but it really they're often very hard to do to some of things that are very complex. Okay, another one is sort of a use case model. There's often a lot of things you could do. But how do we break that up, especially the Swiss and anonymized one of a monthly national company we did and everybody had their different ways of doing things. So, you know, maybe for customer experience, whatever those things that we would need to do around customer experience versus customer insight or reporting, and then these different areas around the globe, you know, maybe there's a heat map of what are the areas that most people are using and going to have the most value. You may not need something as complex in your organization but these kind of heat maps I often do. If we're doing say a targeted data strategy we do a lot of interviews sometimes I'll do something like this and just you know the people you talk to, you know, every single person we talk to said they need better analytics around customer. You know, only three people said they need better network analytics. So maybe we pick the customer analytics to the lines of everything else. You know, isn't always you pick the one that's most popular there could be some, you know, BAU things you need to do. But it is a nice gamma visual kind of person I think a lot of people are to kind of showing these in a heat map is a sort of a nice way to look at things. Business capability models I find myself doing a lot more of these. I like these for several ways reasons. One is it abstracts the what what the organization does, but aside from an org chart. And so these can it can be a little tricky sometimes that definition. And then you can look at, you know, yes, maybe marketing is a department as well. But organizations change but the core capabilities of needing to market things remains and that's why the excuse me the benefit of looking at the capability perspective and not the org chart perspective even though there's obviously excuse me some overlap. This is also helpful when say you are trying to go digital, we still need the capability of marketing. But we're now going all digital how does marketing change and what would capabilities may need to change or how do we do those capabilities in a different way. So I find these kind of things very fascinating and you're really trying to get the nut of the organization. We do this for our own company. But I think what's interesting from the data lens and another kind of a heat map type approach is to sort of build an overlay. So if you have your high level data domains customer product account, patient, etc, etc. Overlay would be so product would obviously be in product development and marketing and sales legal, etc. So you can kind of do that heat map of, you know, our say we're trying to prioritize master data domains or something, or do impact analysis to we're making a change to something like master data. This is a nice way to really kind of see that and see that cross functional in usage. Another way I use with these organizational capabilities and also org charts. I think that is a helpful lens to look at is when there's a little tangential to enterprise architecture but had to put it in there because I think it is a very helpful use case for an enterprise architecture is when you're building data governance and the or any, any data organization. It isn't just data governance could be your analytics team or your data team or you know there's so many different ways teams organize themselves now with more kind of business centric teams, but it's important to look at the organization capabilities and org structure and is it a federated model. Is it a top down hierarchical model. You know the one the picture on the right is a very common one that sort of, you know, is more of a hierarchical almost kind of a dama dm Bach approach. That doesn't work for everybody some people want more federated approach. So, and also what what capabilities do you want in your committee you don't just want, you know, I know Joe and Mary so they're going to be in the steering committee, you need to look at where are we having a cross functional approach from marketing to finance etc etc. So I think it's a helpful way to also design your governance organization or your data organization overall. Again to sprinkle in some use cases here of how we use these I think if you join my webinar one of the things I try to offer is some real world concrete lessons learned generally on the positive sometimes I admit some things we've done wrong just so you don't have to do them. I just you know if you hadn't picked up on that I do this for a living around a small consulting company that does this so the more I think I can also show you that these things are used in the real world it's not academic. So this one we used we were lucky enough to support a big merger of two massive insurance companies to global insurance companies. And you can just imagine insurance is extremely data centric so you can see the quote from the CEO there of one of the reasons they did the merger was not only the book of business but the book of data really right was so all of the companies that made combined information assets of those companies they realized was the strategic advantage and another challenge is you're, you know, what's that saying moving changing the wings on a moving plane but even more so you're putting two planes into one. And how do you do that so one of the ways to abstract and then you can imagine the politics of if you had looked just at an org chart. So what we tried to do is look at the different business capabilities of company a and company B. So both companies do underwriting both do whatever one company has this and not this. So we started from that business capability and then we sort of did that overlay of the common data foundation. So that was a really helpful way to sort of a prioritize, you know, certain things like underwriting had to be done. First, how do we merge. How do we get that data in a way that can be used across the organization and it was a really helpful way to speak to the organization that that again, I'm sure you get this a lot to the business knows we need data, or we need, you know, better technology but how we do it or what it is exactly that that's that's way higher than the techie people. So this can be a really helpful way to communicate some of that and help with the prioritization so this was a really, I think great example of literally using a business capability model with a data overlay to really drive a successful merger and acquisition of two major data models you knew I couldn't go too long without talking about data models and they're near and dear to my heart partly because they're so darn helpful. But when you are looking at a data model remember the different layers so I would think in an enterprise architecture you are sort of in those top three levels that the up at the sky of a conceptual with the business sense of an enterprise architecture right though if we're looking to align with the business. You're up at the conceptual and logical and then of course the physical is when you're getting down to the implementation layer. But if we're looking for the business alignment you want to kind of stay in those blue areas or that dark green if you really want a high level subject area view. So a conceptual data model. I find we use them all the time I almost can't start a project without them they can be done very quickly. I think we've had some great experience of, you know, do a white boarding session, you know, now even online you can do things like that. And I find you get to sort of 80 to 90% of the conceptual model pretty quickly, even with people who've never seen one before because it's the business people can understand I've got products and employees and customers and patients and students and all of that. And then you also pretty quickly get to that extra 10 to 20% that may take you another six months. That is the problems of the business that yeah you're right we can't really align our sales reps with sales they made across regions. Everything else is easy let's get to the easy stuff but these are the and then you'll get to the arguments of how we fix that. So I think they can really get to highlighting the core. So what the things we need to do pretty quickly. This particular tool that's being used I like because it shows the definitions. This is to me almost a combination of a business glossary and a conceptual data model, but you can really get again just the crux of some issues just by reading it here it's a full or part time worker on the active payroll the organization contractors employees. And someone say well, yeah contract is right they're not they're 1099s they're not employees but part time no they're not employees either we only consider a full time or whatever but you can see right there you can start some healthy discussions and it gets again, just the number of times we think we're talking about the same thing, you know that classic what is a customer we all have a different definition. This kind of gets to the nut of that you can do anything else. And I do find it also helpful to get down to the logical level. And sometimes it really depends on the use case business customer etc. of how conceptual your almost subject area view I think there's helpful to have that one page of the core concept of an organization, but sometimes you really can't get to that story without going a little deeper. I'll refer back again to the case study we did in March that a construction company and because they were such a complex company we really had to get down in order to make sense to the logical level to really get to some of those so what's here at the bottom we're talking about a part is it a raw material finished good a sub assembly, you know, it just saying we have parts and products maybe it's too simplistic to get to some of the answers so again that really depends on the use case. I mentioned that case study I won't go into super detailed because you can catch the replay because the diversity keeps them all online but I think this case study we did in March from a big construction company keyword. It shows a couple things it shows. Well I just love the story because it literally is that we used you know we always use that analogy of a building architecture with data architecture and that literally is what they do for living they build buildings and do architecture. So, showing how they use both the kind of high level subject area model as well as a conceptual model, and they also sort of aligned to their business capabilities at a very almost a conceptual business capability. Why and how we did that is this is a company of doers they build things. And so everything they did from data it related to what other stuff we're doing we're designing we're building where you know commissioning or constructing. And so it was hard to think of data, not in those that context. So that was an example of using data of how the business works which was by business capability. You might want to catch that it was really helpful. Process is another way and again that construction company it could have been a process model as well. I often see manufacturing is a nice use case for using things like process models because it's so embedded and say the development cycle of we do X we do why we do Z. So you'll see kind of a, you know, fictitious one on the right where this was the product has been developed, it goes to supply chain and then it goes to marketing and here in this case we should have showed that you know the product name is given a code name and development it's given a temporary price by supply chain, based on the costing, but then it doesn't actually get its final name and price until it goes through market testing and product naming etc. Again, I'm a big fan of pictures and things you can literally see the people on the swim lanes of the groups, a little database icon the fact that an email was sent. This is sort of a stylized BPMN notation if people are familiar with that. But it really actually this was sort of an anonymized thing we did from a customer where that actually was the problem that the getting that right name consistent and then the price consistent across different areas was really important. It should also be a nice helpful way to start to develop your data governance. So I would think those swim lanes could be your data owners or your data stewards, or the people in your data governance committee because they all have a vest especially when you sort of say, and I could do a whole webinar on this one but who owns product, you know it's so easy to say okay when we have the product group that owns product well not really because supply chain has a, you know, a voice on product and marketing has a voice on product. That's where these cross functional groups are important, and that's where sometimes these these process flows with the swim lanes can really help with that. Customer journey map is, to me it's kind of like the newer hipster version of a process model. It's kind of like a process but it's from the customer's point of view, and really getting that customers journey. I'm talking about a customer journey map. That's sort of what's often used. We've successfully done student journey maps. We had a good success story at a big university here in the US that really had a lot of value by just trying to track that student journey from when they applied to when they graduated and became an alum and what data was used to support them. You could do a patient journey you could do etc etc. But customer journey map is kind of like the classic when you see, and this could be from again when they're discovering the product and they're browsing the web to when they're kind of looking more detail and consideration maybe they visit the store or request literature online to purchase and then support could be loyalty program etc etc. And again this is kind of a stylized version of it but you can even see on the bottom what data would be used each pieces of these so no surprise one of them is customer, but what attributes of customer. Do you have the same email attract across all of these do you have the same address or did they give the wrong email when they're talking to the sales person but then when they want the product delivered they want the right email and how do you really overwrite that right. So these are helpful way to kind of step back a little and see a from the user's perspective how you're supporting the user. It also has sort of that swim lane diagram approach with you know sales marketing supply chain who who is involved in this journey, and then you can do those overlays in different ways you can do it. In terms of what data is used to the step of the journey and how do we keep that consistent. So, again, a lot of these you'll see are are fairly intuitive. If you're not technically can still understand this, and I also have a lot of experience with kind of workshops and whiteboarding and, again, a lot of these can be done initially with sticky notes, or virtual sticky notes. And you can get to finalize a customer journey map. I'm not belittling that effort for any of these business process can be, you know, really months to really get that down all the detail, but starting at that high level can really get to a lot of value. Good old fast and credit matrix. I think one of the most helpful tools with one of the worst names, we call it drunk or something else. But anyway, the crowd comes from the letters, CRUD for created red updated or deleted. But this is a nice way to think of master data management. This is a really helpful thing there of, we have something like product price to go back to that previous example. It's, it's, it's created in supply chain accounting when they're kind of pricing out the product but then marketing is going to update that when they kind of look at what other customers or other competitors are pricing their product. And then finance is going to use that for their things, etc, etc. And then we've actually solved a lot of problems by oops, we didn't realize there was a you there. So we didn't know that we created here someone else is updating it no wonder things aren't aligned or they're updating in a different way, or, or they're updating into systems that don't talk to each other, all the combinations of this, or I didn't know someone else was reading this. Oh, how do they use it they're using a completely different way that we didn't realize. So, again, that kind of ties in with, with governance and quality and all those other. Again, a lot of these tools and that's why using some of these frameworks that I talked about earlier the toga for the Zachman framework, etc, it does kind of show that all of these fit together in a nice, you know, matrix in a way, the value of these diagrams isn't always just in them individually but instead of connecting them. So I think for example a business process model and a credit matrix can really go nicely together where you can see on the left, they have kind of the swim lanes and I, you know, received an order I filled the order and I shipped it. So across those different activities receiving and filling it and shipping it. What data is created right up there and believe it, etc. And again, even at that high level, it can be really valuable, as you're trying to get to some of the key issues in your organization, especially master data use these a lot for that. Okay, so here, which I've used before in these webinars but it does because it just has a lot of nice tie ins to this so this was a restaurant chain in the US. And they had a problem with their data I think we were brought initially from marketing, but they knew that they, they were very innovative marketing restaurant chain they changed their menu a lot that was kind of their differentiator. And to do that and to price that accordingly and to really understand the market trends, you, you know, their product, you know it's product and customer the product really was the menu, and all the areas of that menu, and the components of that product were the, you know, the ingredients and etc. And just like a product development team a product chef kitchen that kind of really experimented with new menu items and things like that, but they didn't have. I think one of the marketing folks that you know I think our menu printer has a better history of our products and we do. They didn't really look at it that way. So, they had had a problem with pricing some of their products they long story short I think there was a menu item you could add a fancy slice of cheese on top but you know on the point of sale system, they didn't price it accordingly. And they, they lost a great deal of money that year because what was on the point of sale system didn't match what was should be priced on the menu based on the supply chain procurement etc. So we sort of got that seems like an easy solution but nobody really could see that whole issue. So what we started with we talked all the different groups and we did actually draw out a process model and some credit matrices to actually show across the life cycle from the issues was fascinating actually when the chef decides I'm going to make this menu item that has to have farm fresh eggs from Canada it has to be or whatever. Then that same supply chain item has to be on the menu has to be priced accordingly. And so as a result of that, we realized that master data management was really what was needed and then the associated governance around that. So their governance was really tied into product launch. So at their company, anyone can stop a launch. If, no matter what so you know we're launching this too close to a holiday, or the colors in the menu don't match the colors on the, you know, again, I found it really interesting. You know the colors of the store or whatever and so we basically gave the data team a first order saying we can't launch because the data isn't right, you know the product number doesn't align or the pricing on the menu doesn't align. And that really it's sort of integrated governance with their business as usual. So it was really a master data issue, but we wouldn't have seen that had we not done the process model and the capability models and all that. Kind of a nice little success story about really it was data issue but we wouldn't have seen it without the full enterprise architecture. Okay, so we talked a lot about kind of the bigger picture things, you know process and capabilities and customer journeys and things like that. I don't want to forget that there is actually enterprise architecture doesn't only mean the business side. And you do at some point have to get down to the data and technologies and platforms. And I just bring in some of these trends again from that report we do each year that despite the fact that there are so many options in the market today, relational databases, in this case, 75% were still on prem are still kind of the workhorse that drive the business so nothing wrong, I will be the first to say relational databases are great at what they do. They're not going away. I know a lot of vendors who do other technologies say you don't need relational databases now we have a graph. So I found that interesting. What keeps me up at night in fits of depression is the next one of 71% are still using spreadsheets spreadsheet to great I use them every day, but not as a data platform. So, again, fit for purpose solutions, but we'll show that what's also shown is this also a lot of other great choices that can be used to augment those. So you kind of an as is and to be. And so in terms of the technology trends. If you look at what people are using today in the report, still relational on prem databases was the by far you can see the graph up top, the winner. But you'll also see that the spread of other things, even things like legacy mainframe and cold brawl, which are still being used so we, I mean I wouldn't say anyone should start a brand new initiative with a mainframe can't really knock them they're still working. So, but you'll see that again, relational databases on prem cloud is definitely something that's growing, but you'll see that there's a lot of other options out there graph databases no sequel iot streaming, you know big data media, etc, etc. But I think that's what makes something like an enterprise architecture even more important. So we looked at future trends. You'll see that you know more folks are going to a cloud based relational database that fits with my experience and a lot of great reasons to do that. And you'll also see and maybe it doesn't come across unless you look at them quickly together all of those other lines also get bigger. And so even though it's a both and not either or. And so yes, there'll be a lot of both relational and on prem databases, and also things like big data platforms graph no sequel. There's a lot of other options to consider and so as you are looking at your overall architecture, I would, if you are only looking at relational databases to maybe augment with some of these other things not so replaced this I wouldn't want to put my accounting system on. And some, you know, it's real time data streaming but yeah, I think there's a lot more choices which can make things a lot more complex, but also more exciting. So if you draw that out. And so I'm going to continue my sort of mantra of keeping it simple. You know, I think a lot just having a high level system architecture of how these things fit together so the one in the lower right is sort of a simple by version of. As we have an exploratory data lake, which is both a sandbox and operational. We have our enterprise systems of record master data reference data warehouse both are valuable they both can work together. You need privacy across both you know having that zoom out big picture can be really helpful. I'm also a big fan of I call it kind of the cart cartoony version of an enterprise architecture diagram. I often or system architecture diagram. I often see these are missing when we go into companies, probably because people just always don't have the time or the permission or the inclination to step back and do that big picture we have a deadline we have a you know product I need to deliver. I'm exact for an example on the one behind where I'm doing the marketing cloud work. I'm not really responsible for looking at the big picture, but telling that big picture and using some icons. Again is often where we'll see some value a little person where there's a manual effort cloud worse on the cloud. You know we could say that often I have this and it's riddled with spreadsheets and we can say gosh we really don't want these spreadsheets we're going to move these to a system or you have 16 different. You have three different bi tools and they're all be using the same way do you want to rationalize to one tool or something like that, but it's a nice visual way to kind of see things. And then we found amazing things just again when in doubt zoom out and again not to name names because we all know whatever but we've seen things like company that had three different customer master data management systems. You know what master data management is that single version of the truth you see the irony in that or master data management system that isn't connected to the right things. There's a lot of systems that don't integrate correctly with your sourcing from the right so et cetera et cetera. So, you know, it could be something like this in a diagram there's just a line missing and you're like, Aha, that's, that's, that's why it isn't working we don't have a connection between system. So, again, they can be really helpful to tell you tell that. Okay, so I probably ran a mile a minute as I tend to do but we didn't want to leave some time for questions so in summary, hopefully, I know a lot of folks who joined this call have a lot of experience and which is kind of fun with the q amp a, but hopefully there was something that maybe is a different way of looking at it that can might add another tool to your toolbox, or it might just be validation of what you're doing now and you're not crazy other people do this too. There's a lot of different ways to show it my biases, let's do it with this going to show the highest value and get to the end result as quickly as we can. Again, a little bit of a plug before Shannon opens up for questions. Next month that we will talk about metadata management near and dear to my heart and definitely growing in the industry. You can find them on demand if you can't catch them, and blatant plug we do this for living if you need help. And now I will open it up for questions, Shannon. Donna thank you so much and to answer the most commonly asked questions just a reminder I will send a follow up email to all registrants by end of the Monday with links to the slides and links to the recording. Thanks for diving in here, Donna. The first question is, you know, why are all the pictures of men. Why are all the pictures of men. Yeah. I don't think the pictures were of men. Attractive. I don't know. Lady there. There is a lady so people need to pay more attention. Actually, my partner accuses me like this one man I use a lot he's in all your pictures. I'm wondering why you keep choosing him like I don't know. Next question. So, onto business here. So, one thing that mystifies me is why business glossaries are currently popular, but only the very rarely are technical glossaries even mentioned. I don't know if that's true. I mean, I think business glossaries are popular because the business needs to understand the data. I think a technical gloss. I guess I would say a technical glossary is the data dictionary but I guess the questioner could be saying like what do we even mean by iot or kind of those terms. I think I think data literacy is becoming more important in fact when we send out the new trends and data architecture. That is one of the big topics of how you got to get the right balance right I think business people need to know what some of these term technical terms mean but without overdoing it. So I'm seeing a little bit that way. But I'm not sure they're less popular I think maybe the business and I often say the business glossary does come first because that's really getting at the crux of the data we're trying to use and what it means but hopefully you'll see that change because I definitely I wouldn't mix them though I think I often have nixed a technical glossary because it isn't a business glossary and folks are defining technical terms I just think they're different breeds of things, but I still think they're valuable. Yeah, I like it. So, how does one gain knowledge or become an expert on different types of data modeling. Also, are there any rules on which type of model is better for a certain type of situation. I think a couple books out there and data modeling, diversity has a lot of good training on data modeling. I'm not sure what they meant by types I think there's, there's kind of the vertical and the horizontal so there's types of you know conceptual logical physical so the kind of that business centric versus, you know, technical and I think the use cases for that are almost obvious right then we're trying to get the high level scope. And that could also mean, you know, do we need a graph model versus a more of the traditional relational. And again, I guess I would point to resources, I think again starting at the conceptual I think the conceptual should transcend the weather it's save a graph or relational etc because it should just get to that high level business value, and that might help you and some of those other. We've used some of those other models the business use case the capabilities that the different use case prioritization to help decide which model or models, you know it's not all or nothing. So maybe this model needs more of your relational and maybe you want to try a graph on top of that or something. I think resources has got lots of stuff out on diversity is a great one obviously in YouTube even has some good ones and and books there's a lot of good books, books and stuff. But hopefully that helps but yeah and I think also inherent in that conversation that's not at all or nothing there's a lot of different options right now. And what are some of the challenges you know we get this question a lot Donna it's it's in this webinar and every webinar we do you know what are some of the challenges that you face with clients top management will try and understand the data that they have and how do you deal with that, and with them. Can you give examples of smart questions to ask in order to understand how the data flows, especially if they are not open to divulging internal policies. Yeah, I think the most of the tools I showed today have been used for communicating with the business I think if you've tried those and they haven't worked you also have to sort of judge the person like, for example, a lot of that information about that business motivation model. Can you do your own sleuthing and do your best guess from the annual report from the website from, you know your own knowledge and then bring something to the business that's probably a good assumption. So that classic it's easier to change something then develop it out of scratch. I mean I have had some great experience with just brainstorming whiteboarding sessions but I know from my experience of when I'm busy and someone comes to me with that I could just maybe throw something down and I can edit it. So that might be sometimes where you're getting pushed back not everyone has the time or inclination to do it with you. So it could just be do some best guesses try to get in their head a little bit and come really educated to the conversations and then I think a lot of the most of those tools that actually all of those tools I showed, depending on the use case, have been used to tell that story to the business and I guess I would think of all those tools which could be someone from the CEO or whoever you're talking to, are they a process, would they be, you know, excited by the process would they be excited by the customer journey that's a great one. It's a sales organization, are they thinking of it more by business capabilities because they're doing a merger or something so that would be my advice of you don't show them all of them but but what of those would tell the story from that whoever you're telling that story to, or could be financed and you want to put it in terms of money. Yeah, that's how I, that's my advice. I like it. So for a larger organization with multiple projects, what are some of the challenges faced when developing an enterprise architecture strategy and any solutions to overcome them. Multiple projects well out of it is just personality and politics and competing and competing priorities. So I think governing data governance or having a great data governance or a government doesn't have to be just data, but is a great way to kind of get everyone together. I think drawing some of these high level diagrams and showing those touch points is a great way, or even some of those use case diagrams right we're all working on this. And sometimes just being clear on, I don't know the dynamics but sometimes it's great of hey we're all working on this together that's great it shows the value that we're all touching customer data or product data and this is how we can work together. Sometimes it's, don't worry that's your space we're not touching that we're only touching the 10% that's shared, etc. So I. Yeah, I guess even or even just drawing out some of these water people working on that use case model I showed we've done some of those and find out that, you know, three different teams are working on customer sentiment analysis so why are we all doing the same thing. So, sometimes things like that, again not knowing organization that that that could be some tools either, you know, some of these tools could be helped to either understand where there's overlap where there could be collaboration or where you need to kind of put the things up if people aren't working together just saying, you do that we do this and we'll share here. So, Donna, before starting data architecture, do we need data governance to get established first. I don't, I think they work together. I think I forgot which one I was asked to come first. I think I think a good data architecture can help inform governance and I think an architect that back to that Janice picture is going to be worth their weight in gold of that that a lot of these problems. Often when we do a data governance group will have you know what's that quick when you can do to show the value of governance and show the value of data and often it's some sort of architecture related to either show a business problem that can be shown through the data model or data flow diagram showing why things don't work or a data quality initiative. So I think they go in hand in hand so sometimes it could be an architecture that helps identify the problems that can be solved through governance, or it could be the governance committee that kind of helps spearhead architecture to be done but I think pretty pretty quickly they need to come together and both be there. It's sort of depending on the org which one's going to get them both to happen but I think it's hard to do either without you. Anything else. We're good. Did I lose you. Yeah, sorry. No, I'm just, you know, talking to me button. I'm good at that. Who owns that business capability model. Who owns the business should own it organization. Yeah, I mean, who might develop it I guess is what I would say I mean often there's an enterprise or if there's enterprise architecture team just generally who I would say would be kind of the owner of it organization there's generally enterprise architecture team that that deliverable would probably sit there. If you're a data architecture team you might want to introduce yourself to the enterprise architecture team I've gone into groups and those teams never work together and once they meet each other they say oh my gosh we're kind of speaking the same language just with a different accent. And they can find that there's different tools, or maybe the enterprise architecture team had a high level data model but not the detail and the team can collaborate. I think some of those overlays like doing the capability data overlay on capabilities could be done by the data architecture again working together, a smaller company it's probably you. A lot of companies that don't have the, you know, it's 18. I think it could be used by the data governance group. It could be, you know, the data governance lead could leverage that. So, own is kind of a funny word but yeah I think probably if you have say who created it by the team if there's one. But it helps. Yes. Very broad question here so what is the most common client problem that you address. Common client problem. I don't know if there's a common client problem I mean I think more and more companies wanting to be data driven, and at a high level. There's buy in for that. And then what we do to get there is probably the big question and I think where some of these architecture diagrams could come in is either there's high level buy in. I don't know someone could say, you know, Donna you need to, you know, get in shape and I know I do what do I do, you know, I need a personal trainer to tell me what to do together and I know I do but obviously I'm not doing it yet. So management might have the vision but not know the tactics. Sometimes there's people in the field that know the time you know the pain points and they're failing the issues but aren't able to get the voice. That's why sometimes these tools are helpful. I mean digital transformations of a big one I don't know that's a problem or an opportunity but then how do we get, you know, the customer data in a place that people understand I mean that's probably the more general one is a lot of data scattered scattered around how do we make it usable, consumable and usable, trusted, good old fast and trusted data. Never goes away. So I think we have time for a couple more questions here so what is your take on how business capabilities can be used to enhance a quote unquote to be agile organization deploying a DevOps methodology. I feel like going back to a capability, because it gets to the not of what we need to do but it could be done in a different way. So it could be we have, you know, if you're thinking DevOps I mean that could be more like technical capability we still need to deploy. But how do we do that differently. Right, or if you're thinking of a, you know, more of a digital transformation it could be we still need to sell to the customer but we're doing in a different way. So I like to step because often with with anything or even we start talking as always start talking DevOps we start talking anything people get right into the tool they want to use or their favorite way of doing things and I think it's kind of stepping back and thinking of the capabilities we're trying to do can be really helpful. Otherwise you people can get really passionate enough for an arguments over are we going to use JIRA or Azure DevOps or, you know, and we kind of lose the so what of it but if you try to think either of the business capabilities you're trying to support as a result of this application, and or what are the technical capabilities we need to do we need to design the test we need to deploy we need to iterate. And then how do we do it sometimes can just that's why a lot of these diagrams I like because you didn't see much tech on that or any tool names or any methodology or it's just this is what we need to do. And then you can discuss the how so kind of abstracts. Indeed. So, my submit one more question here for you. When getting to the stories needs of clients in various departments and companies. What do you find is the best way to solicit accurate relevant and full data flows, etc, etc. For example, interviews meetings questionnaires surveys the process might be known, or little known, even by the clients. I'm sorry, I didn't catch all that how do you get the detail of everything like the surveys and. Yeah, yeah, so when getting to the stories of clients in various departments and companies, you know, I find this best way to solicit the accurate and relevant data. I'm just thinking when especially when the questioner asked about surveys and things like that there was one example we did a university West. And what they did was a student journey map. What they do we had a bunch of different where it was really a helpful way so they had this could be a customer journey map it could be a sale from, you know, all these phases for them it was the customer student journey of when they're applying and when they come on campus and when they do these different things. And we almost we had sort of at this point we were on on site and we had kind of a war room. We talked to the different groups and they all, we kind of again did the heat map of sticking out approach so we had this huge war room wall we did digitize it afterwards. But everyone would come in and say okay at this phase and actually the surveys made me think of it. We come on site and we give the student a survey. And we see if they're happy and then the next group came in said we come in and we give the customer the student a survey to see if they like their dorm. We come in and we give the students a survey to see if like the end just kind of get the point. And like they saw that like first two semesters of first year students were inundated with surveys, and then they forgot them until fourth year when they graduate. And then a student came in they said yeah it's pretty much how it feels because then they were able to kind of visualize that all of these different touch points that no one person saw. We kind of use this journey map to show it could be a process model of where do you fit it what swim laner you, and then what are what activities. And the one we did at the university we actually had. This was the customer journey up top and then we had the kind of different university departments at the bottom. And kind of what they did. And then there was a piece in the middle, so that interaction, and it was just kind of a nice visual way and in a way that easily people can see okay there's my box and this is what I do. And because if you just ask them point blank or whatever it might be hard so that was just one example that came to mind when you mentioned surveys that, and then everybody had the aha moment, because nobody else knew that everybody else was sending 17 surveys. And the results of that did with good story all just kind of, I think they ended up with three surveys at the end because they combined them and shared the data, because literally no one saw that everyone else was doing the same thing. Hopefully that helps. I love it. Great example. Thank you. Um, yeah so, um, a lot of great questions coming in but I'm afraid that is all the time we have slated for today and for this webinar. So just a reminder, I will send a follow up email out for this webinar by end of day Monday to all registrants with links to slides and links to the recording as well. So thanks everybody for being so engaged in everything we do. And Donna thanks so much for another fantastic presentation. Love it as always. Hope you all have a great day. Thanks. Thanks, Donna. Bye.