 Oh. Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Officer for DataVersity. We want to thank you for joining the latest in the monthly webinar series, Data Architecture Strategies with Donna Burbank. Today, Donna will be discussing 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. For questions, we will be collected by the Q&A panel. And if you'd like to chat with us or with each other, we certainly encourage you to do so and just to know the chat defaults to send to just the panelists, but you may absolutely change that to network with everyone. And to open the chat and the Q&A panels, you will find those icons on the bottom of your screen to enable those features. And as always, we will send a follow-up email within two business days containing links to the slides, the recording of the session, and any 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 in helping organizations enrich their business opportunities through data and information. She currently is the managing director of Global Data Strategy Limited, where she assists organizations around the globe in driving value from their data. She has worked with dozens 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 to Donna to get today's webinar started. Hello and welcome. Hello. Always a pleasure to join you folks, and thanks to everyone who's joined on the call. Always good to see some familiar names on the chat. This time a little different. I am presenting from Sonny Riyadh, Saudi Arabia today. So a little bit further, and if I sound a little tired, that's why. So a little later in the evening than I normally present. To anyone from this part of the world, welcome. Hopefully you're on as well. So this year's line up, this is the last one of this year. I guess it's actually November, but close enough, on enterprise architecture versus data architecture. As we've mentioned in past webinars, all of these are recorded and are stored on data diversity. That's often one of the first questions we get. Is this recorded? Can we get the playback? And can we get the slide PDF? And you can get them all from not only this, but past webinars as well on data diversity and perpetuity, which is great. But what will we be talking about today? EA, your enterprise architecture. So what is that? And hopefully, as I do with many of these webinars, I'll try to simplify and make clear. This is some very complex, enterprise architecture can get very complex, but it doesn't have to be added. Simplest, it's a way to really show those interrelationships between not just data, but everything else in the organization, like process and applications and people and motivation. And we'll go through all of that. And I'm a huge fan of enterprise architecture. And if you've seen my webinars before, our consulting company kind of, that's our kind of specialty or way of thinking of, you know, what's the so what around data? What's the business value of data? What's the impact on the organization and enterprise architecture type models are great at that. And to me, that is just sort of, as I mentioned, that's so what or why we're doing it, not just the data piece of it. Data itself is a big part of any enterprise architecture as well. So they fit nicely together. I like this definition of enterprise architecture from Gartin, kind of Gartner, sort of steal their glossary definitions quite a bit. And so what I liked about that was their first kind of line there, but it's really looking at your disruptive forces and analyzing change and how do I get to my business vision and outcome. And I really like that, because to me, that's innovation, that's digital transformation. And I think sometimes, as with data architecture and data modeling folks, and I don't know where this comes from, because I don't feel this way. But there's a little bit of, oh, isn't that old-fashioned? Isn't that what we used to do when we actually plan things and didn't just build stuff? And I think absolutely not. How do you plan for a new digital transformation without understanding your current state architecture or without understanding your customer journey or the processes that you need to transform digitally? So the worst thing to do is when you do some sort of digital transformation is take the same paper processes and put them online. We've probably all been on websites that feel that way, right? So a proper way to do that is really looking at these holistic forces and really looking at that entire enterprise architecture. The other thing I like about the Gartner glossary is that it talks about both business and IT working together. And as with data models, if you've heard me speak before, that's one thing I love about data models. It's a great communication tool between business and IT, as with these other enterprise architecture models. You're trying to do master data management and talk to someone who owns the process of putting data in, speak their language, show them the process and see how the data they enter affects someone downstream or vice versa. And that last bullet, I love because we do this all the time. It really is part of how do you design the future state architecture if you don't know where you are today, right? So really, I think it's a forward-looking type of methodology, the thus the innovation, but it's also that foundation of making sure you do it right. We can rush into the future, but if you don't have that plan, it's not going to be successful. And enterprise architecture is really that holistic plan across the organization. And enterprise architecture can be at many, many levels. And those of you who are maybe a data model or a data architect, maybe build data models or data flow diagrams. A lot of these diagrams, if you haven't done them before, should feel comfortable to you. And I always laugh about myself. One of the things we do is business motivation, or we have some personality models and things like that when you're doing organizational change management. And I kind of laugh at myself as I'm training people almost like data architecture, right? You model them and there you figure out how they work. I'm not that anti-social close maybe, but sometimes I do feel that way. But people need to be analyzed, motivations. What's the goals of the organizations? What are the business capabilities, which are really people when it comes down to it, right? What does this organization do at its core? We'll talk more about that. And then I've already talked about the business processes. So that's kind of, and there's many more for those of you who may be thinking that in your head, but those are just kind of a subset. But the other part of an enterprise architecture is the technical side as well. So your applications, your data, your networks, anything that touches data can be modeled as well. And then you can see those overlaps. I can move my own slides. There's several ways to look at enterprise architecture. And again, if you heard me present, I like to be both agnostic and very practical. And so all of these are fine. All of these pros and cons to each approach enterprise architecture. I always say, just do it. Just start to whiteboard it. Who cares? At the end of the day, maybe what process modeling notation you're using, BPMN or some UML or something else. Just start to whiteboard it. Use a flow chart and people just starting that can be a big benefit moving forward. Don't get hung up on making it too complicated. Zachman framework is a very popular one. One of the nice things about Zachman's approach, he sort of simplifies it, which I like into that who, what, where, why, and when of data of the organization. And data fits nicely into that what, calm. And I think a lot of us can kind of resonate with that. And he also looks at it at the different levels. So he might think of kind of mentioning executive business, architect, engineer, you know, to me that subject area conceptual, logical, physical model, right? So, but you could do that with process and you could do that with application. And I want to touch on that. We were just doing an architecture review with my team earlier and we were having, with any project, you kind of get stuck in an area and we realized where we got stuck is one of the folks and the team was thinking kind of physical. And we were sort of up at the business conceptual for the system architecture diagram, right? And so you need to do all of that, right? If I'm just doing a high level, how do our systems fit together? You don't need every box in line and every system known to humanity in all of the interactions. You're trying to do an indicative, you know, flow. So, so I like about this. John Zachman is also a very nice guy. He comes to a lot of the university conferences. So you might meet him there. Togaph is another one. There's Togaph certification. And they have, I won't go into all of the details there as well, but, you know, if you say look up top, they have that same idea of linking business to data to applications to technology at the different levels. So it does both the breadth and the depth. So kind of in a similar way to the Zachman framework, it looks broadly across, you know, people and capabilities and process, but it also goes to the different levels of depth, your level one, two, three and that sort of thing. So again, there's others as well, but those are two very popular ones. I'll remain neutral on all of them. Just start doing them. That's my request. And here's just kind of an absolutely neutral view of it. But again, enterprise architecture is that nice view of the people process applications data. You know, it can put it into context and here's kind of a subset of some of the deliverables we sometimes do. And in our projects, you know, it's putting that data into context. So what's the business view? With motivation, model, why are we doing this? What business capabilities are we supporting? Down to the process view of, you know, how do we do order to cash or procure to pay or whatever the onboarding a patient or, you know, in taking a patient or whatever. And then the data view. And as I mentioned, there's different layers of a data view, conceptual, logical, physical, maybe a business glossary that's kind of separate from a lot of different ways you can look at data. And then how do you start to layer them together? Popular one is mapping your data to process the good old fashioned crud matrix or where data is created, read, updated and deleted. So these are kind of nice ways that fit together to kind of tell that story. We'll start in a few slides on that first view, which is that business view, which I want to stress not to forget, it's easy that the business-minded person to jump right into the processes, right? And we just got to document everything and really understand that. But stepping back a step before and looking at the why, you know, what are the motivations? Are we looking to put everything online? Are we looking to make existing processes more efficient? Are we looking to downside? You know, you're really understanding the why before you go into all of the what's and how they fit together is always important. So a little bit of data around our kind of different types of models. As you may know, we do a survey of both global data strategy and data diversity every year on trends in data management. And one of the questions we ask are what types of models do you use in your data or your enterprise architecture? And you can kind of see the results there. And then no surprise to me. And again, this was a data architecture or data management survey. So probably not a huge surprise that data modeling kind of things were up there first. You know, if we had done this to the process modeling association, maybe that would be flipped a little. But you see, you know, all levels of data models are shown, data flow, you know, how data flows from system to system. System architecture diagram is not a surprise to me. But you'll also see that business process models, business capability models, those cred matrices, which are that interaction between process and data are all used as well. And a little bit of UML-y stuff down at the bottom with classes and things. So it's a mix. And it should be a mix because there's a lot of different areas of the organization that need to fit together. So I thought that was a little interesting and kind of what other data diversity type people tend to do in their organizations. And again, I don't see too much of this because we tend to do a lot of successful projects with this. But I have seen it that sort of, I don't know, discounting or scoffing at the design phase, right? So that's just a pretty picture or it's way too high level to be helpful. Oh, contrary, right? You wouldn't build a skyscraper without any sort of design documents. And those design documents, one is the very high level. We're building a skyscraper and not a shed, right? At some point, you want to understand how the rooms fit together and the wiring diagrams, right? And other industries that's very, very common. And partly because it's really hard to mistake the person in the suit in the office designing the construction building to the person getting their hands dirty on the right. And it's just a very physically different thing. But with software and data systems, sometimes it's a little harder, right? They're all on systems and easy to kind of jump right into the physical and then those distinction are as clear as designing a building versus putting swinging a hammer and actually building the building. But there is a distinction in software architecture or database architecture between designing and the building. So don't forget the design phase or, you know, just imagine a house you hadn't designed. It's not going to probably fit together as well as you'd like. And that's why, yes, there's one of one of these weird Donna slides. What is she talking about this time? I think a good architect, whether it's a data architect or enterprise architect is like Janice, the God of January. And he has two heads and one is looking at the old year and one is looking at the new year. He can kind of play both worlds in a way. That's how I think a good architect is they can spin around on the same day and the same hour and be talking tech and database platforms and cloud versus on-prem. And, you know, I don't know, is it a key value pair or a relational database, right? And then turn around to the business and talk about, you know, the business motivations and the marketing campaigns we need to build and what are the business rules for procure to pay, right? Those are your, we call them unicorns, right? But a good architect can be both. You're not a business person. You're not, you know, responsible for driving sales, but you should understand the sales process. And you're probably not a database administrator or data engineer, you know, actually implementing the databases, but you should know how they work and how you're kind of that intersection between both. And I think it's a rare breed in a, I don't want to say a lost art because people still do it, but that's the real, it's a tough job to be able to kind of live in both worlds. Maybe you feel like you have two heads some days. Okay. So what are some of these architecture diagrams I talked about or some of these tools of the trade? And I'll, you know, there's many more that I won't cover, but some of the common ones we use in our practice. And I'll share all our secrets and you won't need it. Here's a common one we do all the time. And I maybe thought it was silly the first time I did it, but the more I do these, they are so, so helpful. This is almost the first phase of the why. What are we doing? What kind of company are we and how can we use data kind of our tag lines around data? So this is a fictitious art supply company. And what's their mission and their vision? They want to be a full online retail experience for art supplies and crafts and be the respected leader, right? And so what are some of those external drivers outside their company that they need to look at, right? A lot of people are going digital now into these online communities. It's kind of the Facebook and Amazon era, right? So if they want to be the leader and have a better brand reputation, they probably should be thinking of digital, right? So all these, you can't just think of your own internal drivers that, yes, if you want to have revenue growth, well, if you're not looking outside the company, you're going to be missing things as well, right? So we kind of look at both and then mission and vision, hopefully set by your organization, right? All that kind of above the middle, the areas, what's the company? And then the bottom is tag lines around data. To get to the stuff at top, is it about accountability or probably governance or data quality or having a data driven culture, right? Those are kind of your tag lines. You probably don't want to start with saying, you know, for someone who's trying to build the company and grow the brand reputation, well, we need a data governance framework with data stewardship. Well, you might, but you kind of want to summarize it. What's the so what? What's those catchy phrases? We need better accountability for our data, better data quality and have a culture of data sharing before we start putting customer data communities with people's PII up there or whatever, right? So just kind of thinking that through. So it's a one pager. A lot of the ones, you know, again, enterprise architecture can, in many cases, should be very detailed and on plugs, but just to start at this kind of scoping, a big fan of the white one pager, simplify, or even this whiteboard, if you don't know where to start, just to, you know, because you can get a lot from these in one page doesn't mean they're fluff. It needs you spend a lot of time getting it clear and concise onto one page. What's that phrase? I didn't have time to write you a short letter. So I wrote you a long one, right? It's like, it's a lot harder to be concise than to ramble on for 25 pages. So there's one, a use case model is one we don't use quite as often, but we have you, it gets bound to the Y of all the different patterns we need to do for customer insights or, you know, consumer marketing. What are all the different groups that might be using that? And I, you know, I'm a visual kind of person. A lot of people are. So it's kind of helpful to have these. You can kind of see here, even the heat map here is some of those KPI reporting and network analytics for this particular fictional client here. And you can kind of see who's using what, right? So just kind of mapping out some of these areas can be really helpful in prioritizing what you need to be doing. Business capability models, I find super, super helpful. Even me, I tend to see, I mean, if you saw in the data versus survey, people do use them. I don't see them used enough. I see a lot of process models and I see a lot of data models capability models are out there. You see org charts, but that's different than a capability model. This is really just describing your business. Again, not by the org. Sometimes it might align with an org. You might have a marketing department, but marketing is a capability and sales capability and product development is a capability. And that it's nice to do it that way because organization changes, but you still have functions or capabilities that are done in the organization. And it's another way, especially when you do these data overlays, right? So where is customer data a priority or use? And you can see here, purples, customers and campaigns and lead gen and sales and also illegal. Maybe we hadn't thought about legal and been really kind of doing this also in R&D because when you're trying to do product development, you need to think of the customer, right? So again, when you're thinking of master data or critical data elements for metadata or whatever, it's a nice way to really look at the capability and we'll show some case studies where we did this really, really effectively by kind of stepping back and I always say, you know, what's the so what? I'm really kind of linking this to business capabilities. Oops, wrong direction. Here's one case study we had done. We helped a merger with one of the biggest oh it was a insurance company and both sides of the pond. It was in London and New York area. And one of the main reasons, of course, there were many reasons why an insurance company would merge, but I remember in the CEO's kind of first announcement to the new company, he mentioned that data was one of the big drivers of the integration of these two companies. When you think of insurance, they've been data driven before that was a cool word, right? When you, you know, how to write your policies and price the policies and calculate risk and all that, that's all data, right? So they needed to integrate that, but they also were integrating two organizations, right? And so they wanted to build that common data foundation. And of course, there was also a lot of politics and you know, how do we meld the orgs and how do we meld the data and who wins where? And they kind of stepped back and we built these business capabilities for company A and company B and then mapped the data to that probably in a fairly similar way to this is obviously was not an insurance company, but we did something very similar for them. So it definitely helped with that, both to prioritize that common data foundation, but they were also able to use it for some of their business integration too, rather than say, hey, we have two HR departments and how do we merge them? It was like, what are the functions, what are the key capabilities we're trying to integrate? And that was just a little clearer in terms of stepping back from org, you've been stepping back from data. So that was one use case where we used business capability models really, really hopefully also helped. We won't get into it in this, but also helped with their data governance and they kind of did their data governance kind of aligned with some of these business capabilities as well. So again, a lot of these models can be reused for a lot of different ways. Speaking of that, so one way when one is designing kind of a data governance framework and it's a whole other webinar, probably one of the recorded ones we have. I've talked about this of, you know, when you have, say you have, you don't always need a committee for governance, but it's a very common way to do things. And you have a steering committee, who sits on that committee? Is it by different organizations? Is it by different data domains? Is it by, you know, one way is to do it by different organizational capabilities? Who's kind of represent, if they have their product marketing or, you know, or product development here or human resources, right? All these different areas could sit, it's often a way to kind of organize your data governance framework or councils, not always, but it's a way to map that out and even see where that looks like. Data model is one of my favorites. So that's probably one that's maybe most familiar to a lot of people on this call. And like with any type of model, they have different purposes and different layers. So that very top, not always used, but that might be your just kind of enterprise subject areas. You're definitely kind of your one pager of the org. What are we even talking about here? Once you get to the conceptual, that's going to be more of your big business concept, your customer, your product, your patient, your student, you know, your big boxes of things. As you get down into the logical, that's where you're going to start adding some business rules, some attributes, you know, a customer can have more than one account and a customer has a first name and a family name and a gender and a sex and all that kind of thing. And then physical is when you start to get down into the nitty gritty of the tables and it looks like a pyramid because often you have many more physical tables than you may have at the logical level and certainly at the conceptual level. And often that's the beauty of a conceptual model is it takes a lot of that complexity out of the physical and just summarizes your business up on and kind of a one page. Here's an example of a conceptual data model. One way to show it, there's a lot of different ones. The one reason I like this particular display from this vendor is that it not only shows your entities like employee and customer, but you can show the definition right there. It's almost like a glossary on steroids, right? It's got a glossary with the business rules around it. And what I like about a conceptual data model even without knowing this company, you can kind of already understand there's customers and and some customers have a support rep and the companies have a sales rep. There must be the larger companies and you can start to understand the business just by that story that the data model's telling. And that's kind of the beauty of highlighting some of those business rules. Logical data model again is still pretty simple. It should be your simple boxes and lines if if you're a non-technical person, you can probably still look at this and say, okay, we have products and parts and there's different types of parts and they have different things about them. A product has a product name and a description and that kind of thing won't get into how to data model here, but this idea of cardinality or the one to many, a product can be on more than one order. Can a customer more than one account? Often the gnarly problems of an organization are just a box and a line on a data model that are causing trouble. I think all of those that I mentioned have caused serious issues with the company. Can a customer have more than one account or not? It's not always the simplest thing just in the simple company. So I'm not going down to the physical level and not that enterprise architecture can't do that, but I think one of the beauty of an enterprise architecture is often starting at that high level. Another case study, and then I like to call this one out because this one is also out on the Dataiversity website a couple of years old now. All right, before the pandemic, we had Keywood, a big construction company, kind of talk about their conceptual data model journey. Love that because we all, in fact, I did it on this call. You always use the analogy about building a house or building a building and then how that relates to data models and they literally were doing both. So thankfully, they were building the big buildings with architecture diagrams and they were building their data architecture with architecture diagrams. So to them, this idea of the different levels of diagrams and everything was super, super easy because they looked at diagrams all day. How can you build a nuclear power plant without a diagram that was not lost on them? So because their business was so complex, how to organize all of those conceptual, having just a simple one-page conceptual data model was just not enough. They needed to get to a detailed level here. So they organized their conceptual model by capabilities. One of the things I loved about working with Keywood, they were definitely a company of doers, like just very practical and they kind of almost self-deprecating in that they build some of the most complex, you know, transportation systems and factories and that kind of thing and they break it down to we get work and we build work and then we take care of the assets that help you get work and build work. So when the more you have something complex, they simplify. So all of their data models were kind of broken into that. Are we in the design phase of building a power plant or in the plan phase or the procure or commission or construct and then all of the data kind of grouped up that way. So that's another way to use those capability models. Of course, this is almost not a capability model and then it was so high level. That's definitely your conceptual level but those were their business capabilities. And of course, they went down to lower level of detail as well, you know, construct and a lot of other capabilities underneath it. But it was a really nice way to high level the group, their data and that made a lot of sense to them. So hopefully some of these give you some ideas of things that might work in your organization. Process is what I use absolutely all the time and it's such a nice way when you're working with something like master data management or data quality, anything where where business effects data, which is almost everywhere operationally, right? So if you haven't seen a process model, this is kind of a high level BPMN type one or almost like your flow charts, right? And you have swimlines that represent the different people or the organizations you product development that does things and then that gets passed over a supply chain. So here we have product development, developing the product and then they send it to supply chain to cost out the components in that project and then they send it to marketing to actually do the market testing and come up with the final name and the final price, right? So super simple flow chart there or a process model. But what we've added is the data and then almost here a little hint to your credit matrix. So the code name here is created and the quantities of components are created. This actually is an anonymized thing of a real world problem we found of their problem was there, they had a problem and they priced the product incorrectly and they lost a lot of money because on the point of sale system it wasn't, it was costed too low. When they did kind of the process models and everything, they realized that supply chain had come up with a price and by the time we got to market testing and the actual price that was on the product when it went to be sold, there was a miscommunication there and they were able to fix it and save all of it and work it through with master day management and all of that. But it was a simple model like this, that where is the data touched and who owns what, also obviously tied into data governance there as well. But it's a nice way to see kind of who touches the data because I've been in this business for an awfully long time and I've not met someone who came to work and said, I'm just going to go try to mess up the data. Maybe one person who's in a bad mood once, but most people trying to do the right thing by getting their job done or they don't, I'm not saying I'm guilty, I do it because I'm smart. You have a form with a million, a million, a million bills. I skipped the ones that I don't have to put in unless I skip that little star that I don't have to fill in. I don't, but you may not know that where is that data going to be used downstream? Am I making somebody else's job difficult because I didn't put in the right price of the supply chain product? If I knew it, I'd probably put it in, but we all have a million things to do. I'm trying to optimize my business. That's why often we're getting, we do a bunch of these this year, just getting all of these people in a room and mapping it out and there's your, most people figure it out by themselves. You have supply chain and marketing and they say, oh, I didn't know you used that data. Sorry, I'll put it in and have people kind of figured out together. Again, generally, people are trying to do the right thing. Or if there is a question about who owns it or who owns it and what part of the process is, you know, it's a good way to hash it out of kind of showing some of the complexities here. Other thing we've noticed here is two people creating it, not knowing someone else created it, right? We have a bunch of creations all over the company thing. Oh, I thought I owned that. Oh, I thought I owed it. We're not integrating, right? Anyway, nice simple way to kind of do things. Customer journey map. We do a lot of these as well. And it doesn't have to be customer where we've done student journey maps, we've done patient journey maps and maybe knowing when the things this, but I think customer journey is almost just like the hipster version of the hipster cousin of the process model. It's kind of the process from the customer's point of view. Again, simplified, but right. So we've all done it. We're on the website and we're looking for the product and we put all information in and then you get the product and they still have your wrong address that you put in correctly somewhere else, right? No one's kind of looked holistically of all the steps where I talked to the sales rep and I told her one thing and then when I got it shipped from the pyramid version, they hadn't talked to her and whatever, but this is really helping not only can we get the data across that customer journey, but back to that digital transformation, can we optimize that customer journey? Can we make it easier for people? Can they put their own information, have a portal or choose what they want to share or whatever? It's kind of a nice way to look at that flow of data. Obviously, this is a super simplified one. You can also look at different personas, which is kind of nice to what kind of all customers don't have the same journey. All students don't, all patients don't have the same journey, etc. So have a neat way to look at that as well. And then sometimes that's just asking around. Doesn't mean you have to do all these often with customer journeys and I've probably offended a few people because I am a fully disclosed fan of let's just do just enough to start. I am certainly not an expert in customer journey mapping. Okay, but you can get to, I mean, if you come to marketing, they can spend months on it. That is their day job and they're really going to a lot of level of detail. So, you know, they may have this already and you may have a really great conversation with them because they have this already and the type of data they want to see in each part of the journey and how they could optimize. So, I'm showing a lot of these models. It doesn't mean that if you're a data architect, I'm saying next to a lot of data architects and diversity, that you might try some of these process models or you may work with the enterprise architecture department or there may be other folks doing some of these. Or even if you are the EA department, you might still want to ask around and see if people have these process models or one. I often find a lot of different people have them in silos and didn't know other people were doing the same thing. So, often because they're so intuitive, a lot of people just kind of do this naturally. So, you might kind of, you don't have to be an expert in all these because that's why they have enterprise architecture certifications. It is a thing, right? But it's good to do a little bit of this just on your own to try to map out things. Card matrix that I mentioned, great, great product with a terrible, terrible name. Druck, maybe I think some better way. But it basically means created, read, updated and deleted. And for example, the example I had of product price, that's an attribute on product. And then these are all the different processes or groups across that might use or create it. So here we had the product price was created by supply and chain accounting. It was updated later by marketing and finance and a lot of other areas could be reading that. But which one do they read it from? This supply chain, marketing, master data, this can help kind of highlight a lot of problems and also help with some of the planning when you're kind of developing new systems and such. I think process models and cred matrices fit really nicely together. You can either do them sometime. And again, I mix things around whatever works to be intuitive and purist and if our architects might be cringing. But I sometimes put it right here on the swim lane. You'll see I put kind of the C R U D right here because you can literally see where in the process it is updated. I find that kind of intuitive. But you can also, especially that doesn't scale when you may have thousands of processes and thousands of attributes and things. This is also another way to do it in more of a pure matrix, right? I have my product price. It's created by supply chain, updated by marketing, by finance and might be read by 16 different processes. Sometimes that's forgotten too or in governance, right? We're working with a company now where they are doing their, they are doing their governance by domain. And what often got forgotten was like when they thought of a domain, you know, who created the product information. And it was all about the creation and we sort of, you know, help the light bulb go off of what all the people who use the product information, shouldn't they be on that committee? Because they have a voice, they need that information too. And they need it in a certain way in a certain timeliness. And sometimes this CRUD matrix can kind of help you just because you're only reading it. Reading it's pretty important. You're using it to do things, right? I'm using it for finance to generate some financial reporting or I'm using it for supply chain to get you the product, right? So don't forget the people who are quote only reading it though. They're pretty important too. Or maybe they're the most important depending on how you look at it. So yeah, and they kind of fit nicely together and you could often, you know, kind of some of your swim lanes or some of the processes can be in your CRUD matrix. Another kind of success story and hopefully they're helpful to you. To me, it makes a lot more sense when you kind of under, not as a theoretical thing where they are these diagrams that are kind of fun to build, but how can you actually use it in the real world to get some business value? This was a, I've used this example before but I love it because it was a fun one, a restaurant chain. And their problem, similar to that previous example I showed, they had a pricing problem. And the price that was on the point of sale, you know, restaurant system wasn't the right one and they had actually, I don't know if they lost money, but they weren't optimizing their revenue because they didn't have the right price. So we kind of actually walked through and did the process from the test kitchen to the menu, people with supply chain and no one had really mapped that out. And what it was, it was a master data management problem, but the master data management was getting a single view across all of the processes. And once they did that, then governance made a lot more sense. And they were able to kind of get those groups working together. I know our sponsor, this isn't a data strategy or data governance workshop, but often we say, you know, when you are trying to get by and bring someone else in the room with you, if you on this call are a data person. And in this case, we went to the CEO to help sell and it was marketing that came and spoke on our behalf. And they said, you know, our menu printers have a better sense of our menu products, you know, that really was their product was the menu. We need a master data system. They wouldn't have used the word master data until we mapped this all out and showed that the stuff that got the menu came from product and it came from supply chain and link with point of sale. And so the whole team kind of came together and said, we want to fix this together. And that kind of, but marketing was the one that stood up and actually put some revenue goals across it. I said, if you help us fix, we will promise you will get better revenue by fixing this, but the pain point is so great. So that's a lot of a lot of reasons why I like this story. But the reason we had all that buy in and the reason we are able to fix it, a lot of it has to do with mapping the data to the process. So which turned into master data management. Another one that I really like, because it kind of touched a lot of the architecture diagrams, this was a pharmaceutical company. And I like this example too, because we often, if you're an IT person on the call or a data person, we kind of talk about the business as if that's just this amorphous blob of non IT people. The business could be a doctor, the business could be a construction operator, the business could be a scientist, right? So we tend to, the business could be a sales person. In this case, quote, the business were pharmaceutical developers that have their PhD and biology and all of that super crazy smart people that really liked models because they were kind of logical thinkers and it helped show their clinical development process and how data was used. And it was helped with clinical development with some of the commercial processes, R&D, several, several things we did. One was almost just a kind of a marketing of how enterprise architecture could help the business. And then they did have kind of their business capability map in terms of what data was used where and then they had for every stage of every product, they had a mapping of data and process of all stages across the clinical lifecycle, which was super complicated. And what's always fun is that when you do data modeling, you know, by the end of these, you start, you can almost talk like a clinical development pharmaceutical person, right? Or you can talk about someone building constructs and sites, or you can talk, you know, because the data models should really be that specific. So they loved it. And the, they, they didn't like the word data model, they called it blueprints. But all of the clinical staff had these blueprints on their wall of both the clinical development process and the data and kind of that overlap. And what was my happiest moment, not only did they have it printed out on a big poster on their wall, you would go in and they had kind of markups when something changed, or they had a new piece of data, they would add a box and add a line. And then that worked with the people on the right, which were the architecture team. And it was really clear what they did. It was not philosophical at all. People were really clear was when there was a change in the process, who to go to, how to drive governance and how to drive your data and architecture. So that was kind of a neat use case for all of these things that worked out really, really well. So another part of an architecture, I've talked a whole lot about the business side. And you should because that's a big part of enterprise architecture. But I don't want to forget, you know, the platform side and the system component architecture and all of that is a big part of it. So you also know, I love my surveys. This is also from the trends and data management survey that we did this year. So it's a 2022 hot off the presses survey. And I like this one, we do it every year. And I don't want to say it's getting boring, but it's amazing that it does stay consistent, that there are many, many types of data platforms out there. And I think the distribution gets a little more normalized. It isn't only relational databases, but relational databases continue to be at the top, whether they are on premises or cloud based. What does keep me up at night is that spreadsheets are number two, nothing wrong with the spreadsheet. It's just not a great enterprise data management tool. So, yeah, but the people are being honest and they are a number of master data and reference data systems I see in the spreadsheet does give me up at night. But there's a lot more. And I think that is what's changing. Relational databases are begin rant here. Relational databases are not going anywhere. They're excellent for what they do. And there's also a lot of other platforms, whether it's big data platforms, graph database, real time streaming, data lakes, all of that can be used in conjunction. And I think that's what we're seeing over time with the survey is those other lines are getting more frequent. But the top lines, the relational databases aren't going anywhere. They're just being added to, added if not replacing. We also like to look at what's kind of happening in the future. What are people looking at? And no surprise, relational database. But I think the difference is a lot of people are heading more towards the cloud. And I think what does keep me up at night is people actually are saying they will be using spreadsheets as their go forward platform. Love the honesty. Don't love the reality. Again, I use spreadsheets every day. Just don't use them for your master data. Not a great solution. But in you will see the distribution is still very wide. So, yes, I like to show that slide, those slides, because I find it really interesting. But how does that fit with enterprise architecture? How do you map this out? So that's your typical, or I'll do the current state because maybe that's more realistic. If that's your real world company, a real world company probably has three or four or more on-prem databases and gazillion spreadsheets. Some relational on the cloud databases, probably some ERP and CRMs and some JSON and XML and graph database somewhere and IoT data from sensors on their machines. And how do you make sense of all that in a nice clear way? Here comes enterprise architecture. That's a nice way. We talked about simplifying the business. It's also a great way to simplify tech. These are two very drastically different ways of showing things. In our practice, these cartoony ones in the back, maybe because I'm a big child, but sometimes it's just nice to say, okay, there's people doing a manual process, put a little person, or this warehouse is in the cloud, or here's the different types of VI architecture we're using. It may be certainly not your pure system architecture diagram, but it tells a story. The one in front is a little more of a component. How does the data lake and your warehouse fit together and do you have common components of security and governance and analytics? Also a really helpful and clear way of looking at things. I use them all. It's really what story are you trying to tell? Yeah, and what types of data are shared? What's in the database? What's in a bucket in the cloud or whatever? You can tell that story a little bit. If you're not using them, again, I almost cannot. In fact, I was at a client here today in Riyadh and I was like, where is the whiteboard? I almost don't believe you if you say you're an architecture and you could talk for more than a sentence without looking for the whiteboard, because I was trying to see how their metadata and their master data and their data lake fit together, and there wasn't a picture. I just couldn't think of it without the pictures with the lines and nearly showing that architecture. Again, if I had my whiteboard, I finally just drew on a wall somewhere. I hope it'll come off tomorrow. It didn't take that long, and it was just a clear way to frame that conversation of what we're talking about and what fits where. You can also see gaps of what doesn't fit together. People can get scared of these things because people say you want me to map my entire organization of all the systems. Yes, at every nth level of detail that would take you a long time, but start. Are you missing some big buckets of things by not mapping it out at all? There's my question. We worked with one retail company in the Midwest in the US, and it was sponsored by marketing. They love these architecture diagrams. I think I've said this quote a million times because I love it. It was the head of marketing issues. I never would have used the word data flow diagram, but you're the only one that showed me why my marketing campaigns wouldn't work, and they sponsored that. They had the enterprise architecture. I got a lot more detail than this, printed on the wall, and no one could make a change until they went over and pointed on the wall what that was going to affect because they just liked that so much of that their problem was that teams weren't working together and they weren't seeing the impact of a system change on someone else. Anyway, some success stories around system architecture as well. In summary, and we will open it up to questions because I see a few coming through, enterprise architecture is a great way to really maximize that business value for honing in on interrelationships, on honing in on the prioritization and the so what, as well as that diversity of tech platforms and really understanding of how do you design a fit for purpose solution if you don't know the business value and how do you design a fit for purpose solution if you don't know the tech, and that can paralyze you, right? Because if that were your job and you enter a new company and they say just design this brand new system for this new business, you know, priority that could be overwhelming. These are a really nice way to kind of frame that conversation and kind of plan out your roadmap. So, this is with mixed feelings that are last one of this year. If anyone's coming to the DGIQ conference next year and next year, next week in Washington, DC, I will be there and I'll be presenting live. I'd like to see, please do come up to me if you do because it's always nice to put a face with a name. But if you're not there, we have a whole lineup next year from January to December with some new topics and some good old favorite topics as well. So, I hope you can join us next year, blatant plug for global data strategy. We do this for a living if you need help with anything consulting-wise with any of what we talked about, call us. And without further ado, I'll open it up for questions. So, over to you, Shannon. Donna, thank you so much as always for this great presentation. If you have questions for Donna, feel free to submit them in the Q&A portion of your screen and just remind them to answer the most commonly asked questions. I will be sending out a follow-up email by end of day Thursday for this webinar with links to the slides and links to the recording along with anything else requested throughout. So, diving in here, any thoughts on Arcite for Enterprise architecture? Like Arcimate, the framework software. Yeah, I mean that is a good one. I'm going to kind of rename you for all that. But yeah, that's definitely used, I think I would say, just start. I think, yeah, there's a lot of good tools and a lot of good methodologies and I don't want to particularly do pros and cons, but yeah, definitely it's a common out there. How is effective the Enterprise architecture of a given organization that is adopting the data mesh approach for data management? I just had a jet lag moment. I'm going to read it because I can see it. How is EA effective? Oh, data mesh, that is one of the topics for next year. I don't know how you would do a data mesh without at least having one of those system architecture diagrams. I think you also need to kind of look at that organizational capability. I mean a big part of mesh is that kind of people own their own data. When is that true? I won't do my full rant on data mesh that will come next year, but one of it is when does that make sense to have the federated approach and people own their own data and when does that make sense to have more of a master data or centralized approach? And I think you have to draw that out. And you have to draw that out both from the process, well from all of the above, from the data integration and from the business capability and from the process and all of that fit together. So I think data mesh is a great use case for doing some of these architecture diagrams at a very minimum, some of those system architecture diagrams. So you can kind of see those interrelationships somewhere they go. Donna, can you discuss how unstructured data fit into the grand scheme of things? That's a great one. We think they definitely fit in. I've had some good success and I've had people argue or we have had healthy arguments of this conceptual data model fit with something like unstructured data. And I would say absolutely, we're talking about a customer, right? Is there social media data around a customer? Are there pictures around the customer? If we're just talking of that conceptual layer, super, super important. I would also definitely say at the architecture diagram, I almost can't talk about like one of these ones in the back. Where is your date? What is your unstructured data? Where is it coming from? What lands in the lake? What needs to go to the warehouse? All of that to me is a super important unstructured data on business capability. I mean, often we kind of forget about unstructured data. I don't know. We work with one company now and we tend to be, I will be full disclosure, kind of thinking first about relational type data, because that's January or master data and everything. But this company had a lot of IoT data and a lot of video data. And as we prioritized their roadmap, it was the video data that was probably the most important, even more than their kind of customer master. And we probably wouldn't have done that. Have we not looked holistically across all of this and kind of thought, I think that's one of the nice things about enterprise architecture. I had one client, I always steal her words, one end out and zoom out. And you're really just looking at the problem kind of abstracted from actual systems. And so we probably would have continued to have forgotten the video stuff. Had we not kind of stepped back and looked at that and also gotten those different voices about what processes and what were some of the business capabilities and priorities. So yeah, that's a good question. Hopefully I answered it. Indeed. So what do you think of the usage of SIPOC matrices? I used, I tried to use Archimate for this, but it was too general. SIPOC, I think are great. Actually, this, I won't speak to the actual tool. I won't, or even a methodology. But at this pharma company, we used SIPOC, which is now two way at night and puts outputs. But actually, the simplicity of it was very good. So I didn't list it here. Maybe I should, that's probably a good feedback for the next presentation. But no, I found them really helpful. And again, I don't know what problem you were trying to solve, but I know a lot of the problems I try to solve by getting more simple. It kind of, you can, it clarifies a lot of things. So I wouldn't blame SIPOC if you had not, I have had a good experience with it. We don't always use it, but we have. And it's been, it can be a really good way to kind of simplify things. So, and we did use it for that pharma company. Yeah. Anything else? Yeah, that's also great questions coming in here. Any tips on getting GIS people to collaborate on a company wide data architecture? Well, I'm not sure why they're not collaborating. I mean, one of the nice things we always start with is that motivation model. You know, why should they even be in the room? Right. So what their motivation and what kind of their priorities often through governance, we have, you know, any of the governance committees should, it shouldn't be full GIS people, but they're almost your advisors that, you know, they should be on the committee to kind of, you know, they should be mostly from the business, but a few reps from GIS. I had a success a couple of weeks ago, sort of, we were trying to do a master data process and I felt folks were getting way too in the weeds and we had like the fully attributed data models with hundreds of entities and things and we just started to draw out on our own what a conceptual model and some of those process models and that person said, oh, I see what you mean now. And because it was simple for him to, and maybe just doing a few, they kind of get, you know, so maybe those are at least three ways, involve them in the governance and they start being part of it, you know, map out the motivations, what's in it for them or, you know, maybe show some examples and then kind of link it back to their worlds and hope that'll help. Perfect. So how involved should a data governance team be in creating enterprise architecture diagrams? That's a really good question. There's always that age old question of what's data management and what's data governance? Yeah, and I would say data governance has to use some, I would think absolutely has to be a user or a consumer or use some of these diagrams to be a decision maker. It often is the data management team or the data architecture team or, you know, some people call it the data governance office or whatever, but somebody, you know, I wouldn't expect a business person on the data governance team to, you know, maybe they draw out the business process models or maybe that's your enterprise architecture team, but they should be able to be, often the data governance process would have workshops or a work group to help with that. But yeah, generally, there's some sort of data management or data architecture or enterprise architecture team that creates some of these objects, but works with the business owns the rules and the content and what's in it, but generally enterprise architecture, data architecture, whatever creates the, you know, diagram themselves as kind of a facility if that makes sense. I mean, I don't know how you do governance without some of these. And that's often a problem with governance. You get people on a governance committee and you, I don't want to solve the problem, but how do I map out what that problem is and what the solution is? You need, that's why I think architecture and governance are super intertwined. It's a whole webinar, at least. It is a whole webinar too, yes. Cold conference. Let's do a conference. How about next week? Indeed, so practically recommend the, recommend the best modeling quote unquote language for higher executive presentations to sell enterprise architecture concepts or tools, just block diagrams, should I just do block diagrams and PowerPoint? We're new to this and trying to get highest levels of leadership to buy in. How about I give the awesome consulting answer? It depends. Haha, no, I won't. In general, I think, you know, do the hard work on the more robust diagrams and then think of your audience and I am shameless. I have, and I've even shown some in some way. If you look over and some of the recorded data modeling webinars, like I will do a picture of a customer with a person or, you know, or a picture of the product with a picture of the product. If they're selling, it's the beer company, the product is a picture of a can of beer, right? That makes it in the story, do the hard work to tell a story and then tell the story like you're telling a story. So don't be afraid. I think I've told the story, speaking of telling stories, to a very snooty New York insurance company that was very conservative and I did literally that and they paused and I thought I did it wrong and they paused because it clicked with them like the picture of their customer and their policies and what they were ensuring clicked because people don't always resonate with the boxes and lines. That said, when we talked to Keywit, which was a construction company and they did architecture diagram, they really liked the box and line, right? And we did one with another engineering company and they really liked that approach. So we always just kind of say, what company, right? We did one with a school and we literally used blocks, like with ABC and those were the data because it kind of looked like school, right? So I would just say, I don't know what kind of industry you're in or who your audience is, but yeah, I am shameless and it's not shameless. It makes sense. So do the hard work but tell the story. It doesn't have to be a purist diagram or even those architecture diagrams where I have a picture of a cloud or I have a picture of a person entering data. Sometimes that tells the story and if that's gets you across, I absolutely do that. Otherwise, not everybody likes to see or put that more storytelling one and the main presentation and hyperlink to the one in the back to say, hey, we did all the hard work and I'm summarizing it for you so they don't think you only did the fun diagram. That makes sense. I have a lot of fun with those. Yeah. Okay, go ahead. What do you think about a use business fact map or before conceptual data modeling? Yes, often there is an ORM session at some of the diversity sessions. I personally don't find it intuitive and I think it's hard when you get a lot of data. I do know people who love it so I don't maybe don't ask me. For me, it doesn't resonate with me and I've seen it and maybe I'm not the expert in it and someone who is could explain that to you. I found it a little bit complex. I think for solving a problem, I definitely see the use case. I find it a little hard when you're going out with too much volume. But yeah, that's just my opinion and I know there are people who love it. Maybe there is a good book on that as well that's out there. You can kind of look through and make your own decision. All right. Just one more question here. I think we've got time to slip it in. Do you use integrated enterprise architecture tools and your engagements or what do you use what the client provides? What are the challenges in keeping the repositories current? I think there is pros and cons to each. I think a simple whiteboard is a great way to start to answer these questions. I would not want to have to keep my enterprise architecture. So yeah, if you can afford and you have the budget for a true EA tool, please use it and buy it and whoever asked the question, touch on one of those main reasons because there's metadata, right? I want to show you update a name and one is going to cascade across often the lineage between these diagrams is stored. You do a credit matrix and a process and a data model. It all integrates. Kind of the frustration with a lot of these though, I find it with data quality tools, totally different product, but it's often hard to sell the need for the tool without showing what the tool does. Sometimes you can start with a Visio or a PowerPoint or there's some Lucid chart. There's some less expensive ones on web-based or whatever that get people to see, mirror boards even, I know, or sticky notes. We've done a data modeling session with sticky notes, right? I wouldn't stay there. So yeah, if you don't have an EA tool, you're not stuck. If you have an EA tool, please use it. They're excellent. And then to the other speaker's question, if you have an EA tool, you might not want to show the pure diagram to your business user. Use the EA tool and then tell the story in a different way. So hopefully I answered that one as well. You did indeed. Well, Donna, thank you so much for another fantastic webinar. Really appreciate, especially given your current local time zone. Thanks to all of our attendees for attending and being so engaged in everything we do. We'll just love it as always. And again, just a reminder, I will send a follow-up email to all registrants by end of day, Thursday, with links to the slides and links to the recording. Hope you all have a great day. Thanks, everybody. Thanks, Donna. Thank you. Good day.