 Hello, and welcome my name is Shannon Kemp and I'm the Chief Digital Manager for Data Diversity. We want to thank you for joining the latest in the monthly webinar series, Data Architecture Strategies with Donna Burbank. Today Donna will discuss data architecture, solution architecture, platform architecture, what's the difference, sponsored today by DataStacks, just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be needed during the webinar. For questions, we will be collecting them by the Q&A panel, or if you'd like to tweet, we encourage you to share highlights of 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 in the chat panel. To open the chat and or the Q&A panels, you will find those icons in the bottom middle of your screen to enable those features. And as always, we will send a follow-up email within two business days, continuing links to the slides and the recording of the session and additional information requested throughout the webinar. And just to make a note, Monday is a holiday in the United States, so this will go out by end of the day Tuesday for this webinar. So now let me turn it over to Brian for a word from our sponsor, DataStacks. Brian, hello and welcome. Thank you, Shannon. I'm glad to be here to introduce this session and to share a point of view about how we see data strategy meeting data architecture at, quote, unquote, fast. So with without further ado, let me dive right in. You know, architecture is an incredibly high-leverage discipline. Great technical architecture choices mean dozens, hundreds, or even thousands of developers will be happier and more productive. But those choices have got to be made in the context of business strategy because at the end of the day, it's happy customers that are how organizations stay competitive and grow. So I want to spend this few minutes talking about what do we see of winning architecture needs to include to make developers happy and productive at creating happy customers? So I'm going to start a little tongue in cheek. I don't imagine it. Oh, Brian, sorry to interrupt. I don't see your slides in present mode. Oh, sorry. It's like how to present mode. That is odd. There we go. OK. There we go. Sorry. It keeps. All right. Thanks, Zoom. I think I got in the hang of it after the last four or two. So imagine an app that says to reach your destination sooner. You should have avoided the freeway. Or after the fact, your order could have shipped free from a different seller. I'm being a little tongue in cheek here and we can all laugh. Ha, ha, who would ever ship such a broken, frustrating app? But the serious point is to satisfy customers. Increasingly, we need to ship apps that are smart in the moment that do something useful with data to help us out, prevent a mistake, delight us at the time it matters most. And that means latency for data that's maybe in the milliseconds, maybe in the seconds, probably not in minutes and definitely not in hours and days. That's what developers need to be happy and productive doing, shipping those smart, fast data apps applications. So we see the stakes being really high. So we do a lot of benchmarking, not just to help us make decisions, but to help our customers make decisions, both business and technical. And this is data from a survey we just completed of over 500 organizations. And one thing we do with this data is we segment the market based on how the degree to which companies are leaning into change, not just changing technologies, but also changing their business, changing the culture and so on. And then we find roughly five segments with with the top 10 percent or so we call the leaders, because they're the ones leaning furthest into change. And when you map out the behaviors and the outcomes, you see something pretty clear. The leaders are much more likely than the other segments to describe their fast data strategies, differentiate and lead. And they're also pulling ahead at driving customer satisfaction up by double digits using data and analytics. This should all seem pretty intuitive because of the current moment. I think we can think about delightful fast data experiences going beyond Netflix and Spotify into, you know, a great curbside pickup into bang on delivery time prediction and so on, particularly over the last year or so. But we think this is a generalized and important pattern. So what are the implications? Well, again, in our data, we see the leaders much more likely to be using these technologies in combination. And you can read great technical blogs by folks at Intuit, Condé Nass, Walmart about how and why they chose some of these technologies in concert to deliver these great fast data experiences. Now, the key point here is that this shouldn't be a random grab bag of tools for talking about architecture and we're talking about platforms. So the meat of the matter is we'll get to how do we think this coheres as part of an architecture and part of a deliberate approach to making developers happy and productive. I want to say I'm sure people are experiencing some pain now that I didn't present this in a logical architecture. I know everybody's probably saying, why isn't Kubernetes at the bottom? But we'll get there. So here's our point of view on the fast that the stack for fast data. I'll go right to the middle and we love Apache Cassandra as a fast data store. Right by its nature, it's awesome at fast rights. It scales linearly and it's highly resilient, always on, never loses data for applications that are critical to customer satisfaction. That's great. It's also multi-model. So when you need speed, it can function as a key value store, a graph type database or a document database. And it works extremely well with streaming. And if you look at design patterns for some fast data apps, once you're using streaming and stream processing, you essentially need a data store that can keep up. And Cassandra is really great at that. What we're excited about at data stacks and what we think is getting into a deliberate architectural approach and some platform thinking is wrapping the data store intentionally. So if you want happy and productive developers, don't just offer them a multi-model data store. Enable them to interact with that data store with familiar APIs, abstract away the details of the database. So we've bundled up developer APIs into an open source project we call Stargate. And so folks can interact, developers can interact with Cassandra through REST APIs, graph APIs or a document API, for example, not having to know anything about the guts of the data store, just using their familiar vernacular. And of course, if you think about modern apps, particularly fast data apps, we think they should run on Kubernetes. And this probably can make some intuitive sense, right? Marrying horizontal scalability for compute to linear scalability for data. So we think that's a very exciting and important approach and stack to have inside of data architecture and a good platform thinking about how you extend it to relevance to make developers happier and more productive delivering fast data apps. Finally, as a company, here's how we walk the talk and put our money where our mouth is. So as a company, we operate Astra, which is Cassandra as a fully managed service running on Kubernetes. And we've done the engineering work to also make it function in a serverless fashion. So Cassandra by its nature is always able to scale elastically up. Astra can scale elastically down as well. So you're not paying for over capacity. We offer data stacks enterprise, which is self-managed commercial version of a passion Cassandra on-prem or in any cloud. We think most companies, we know most companies who are excelling building fast data apps are also doing a hybrid cloud architecture and multi cloud architecture. And finally, because, you know, at the end of the day, great decisions about architecture and platforms are much more likely to happen if you have intimacy with the underlying technology and with customer use cases. We also support Apache Cassandra, open source Apache Cassandra. So, you know, I'm glad to have these few minutes to share what we're excited about, where we think data strategy and architecture combine to have a great data store for fast data apps to make developers happier and more productive delivering those. And we're hard at work. If you want to make this a reality in your organization, please let us know. We hope we can help. So with that, thank you very much. Unfortunately, there is a very hard constraint on how leveraged I can be. And I do have an obligation that's going to call me and wait about the half hour. So if you do have questions, don't hold them to the end. Please plop them in the Q&A and I'll do my best. Thanks so much. And I'll hand it back to you, Shannon. Brian, thank you so much for this great presentation. And as he mentioned, Brian will be hanging out a bit to answer questions in the Q&A panel if you have questions for Brian or about data stacks. And thanks to Data Stacks for helping make these webinars happen. Now, let me introduce our speaker for the monthly series, Donna Burbank. Donna is a recognized industry expert in information management with over 20 years of experience helping organize organizations enrich their business opportunities through data and information. She is currently the managing director of Global Data Strategy Limited, where she assists organizations around the globe in driving value from their data. And with that, let me give the floor to Donna to get her presentation. Hello and welcome. Hello, Shannon. Thank you. Always a pleasure to do these webinars and see some familiar names and faces on the attendee list. So thanks for those who a lot of you I know attend every month. So I appreciate that. So on that note, if this is your first time joining a university webinar or webinar in this series, just a call out that if any of those previous topics that you see earlier in the year are of interest to you. There was an interesting case study, for example, earlier in the year. These are all available on demand on the university website, as well as ours. But the university does all of these webinars. Excuse me, and I hope you can join us for a few of the upcoming webinars next month is sort of a sister webinar to this. We'll talk about enterprise architecture versus data architecture. As Brian mentioned, there's a lot of different flavors of architecture and we like to be very specific as architects. So there's a little bit of a series within a series there, as well as some other topics throughout the year. And as always with Shannon's webinars, they are free and open to everyone. So pass them along. But today we are going to cover some of the flavors of architecture. And it can get confusing. I mean, this series really focuses on data architecture. And I will talk of the various architecture types in the title platform and solution architecture, but just a caveat there that we will do it in the lens of data, because this is sort of a data series. One could have a whole webinar series just on platform architecture or solution architecture, but we're going to kind of take it from the lens of a data architect, which I think is a lot of you guys on the call. And then, as always, what I try to promise and deliver here with this webinar series is that last bullet of kind of demystifying it. And we'll get a little into this. All of this can get very academic very quickly. And I think what I try to do in life and hopefully this webinar is to try to get down to the so what. And I think Brian did a good job of that as well of, yeah, there's a lot of cool architecture out there. And a lot of us will learn out really quickly to get into it. But what's the so what at the end of the day? How is that going to help our customer? How's it going to help our organization? So I'll try to throw that lens on it as well, because there's just so much we can learn in this environment. And on that topic, we in data architecture, especially more in the business side of data architecture, love our definitions. In fact, that's what a lot of us do for a living. We create business glossaries and data models. But what's that saying? The cobbler's children have no shoes. And I am often just flabbergasted of how poor we are as an industry. And what some of these core terms mean? What do we mean by architecture? What's the difference between a platform and architecture and a data architecture? We did a webinar last year on titles and it was similar. What's the data architect? How's that different from a data engineer? And there is a lot of overlap between these. But as architects, I like to be sort of clear and kind of get down to the use cases and some definitions. So I will offer you some. I'll also offer you some of the different opinions that we see out there. But hopefully we'll get better as an industry, but probably not. I think we love to argue about some of this stuff sometimes. So just a little intro there. So here we go with our definitions. So I'm sure a lot of you are members of or are very aware of the DAMA or DAMA, depending where you live in the world. And there's a dictionary of data management that did attempt to put some shoes on the cobbler's children and go with some terms. So I would be remiss if I didn't use this for the data architecture definition. And what I do like about this definition, I could probably argue about each one of these for a whole webinar, but I will not. I'm learning to filter. So what I like about this one is it does separate out the physical data architecture, which is number one, the physical technology and also heading towards data management as a wider practice from the business data architecture. And I think they are separate and equal and related. And we'll kind of go through that. But when you want to keep those separate and really understand that they are disciplines in and of themselves. So this one I'll go with there's other definitions out there, but this is probably a solid one we can go with when we're talking about data architecture and the different flavors of that. Solution architecture, there was a whole bunch of those. So I went to the good old Wikipedia, which, you know, this is pros and cons of that as well. But you'll see several from Gartner from Open Group and Togaf. But when you really look at it, that's, I guess it's been in the name, right? You're defining a solution or a particular application or the one I sort of liked was Gartner, the architectural description of a solution and really getting, excuse me, all of the areas around that. When we go into the platform and that's sort of more what Brian was talking about, where we're getting into how are we creating that core platform around the software, the hardware and more in the old days of the hardware that really enables some of those other products or services. So here's some from Gartner, from Wikipedia, from Refuge, and then they sort of all were kind of starting to go around that similar idea of it's really that enabling foundation on which those other architectures sit upon. That makes sense. So maybe this was helpful. Maybe this just made it all more confusing. There's a lot of words on these slides. When we talk about architecture, it's often good to think about enterprise architecture, you know, which will lead into next month's webinar, which is a whole topic on that. So I won't get too detailed into all of the broad areas of enterprise architecture. But Togaf is a very common framework around enterprise architecture. And when they, that sort of top part that's in the box, I sort of like how they've broken out in a lot of areas to do this, but this is a common one. I thought I would touch upon that really breaks out these various architecture domains that are in the title and their way of looking at it was sort of business data, application and technology. Maybe I flipped it on its head, but I kind of saw those in a similar way of, you know, the business is what's driving why we're doing this. I might have put data on a different layer, but again, we can argue all of these. And then you have the applications that may use the data and then the technology that supports that. So as kind of a framing mechanism, I thought that was a good and helpful one to go with. So then how do those pieces fit together to use the words in the title of this webinar? How I see it is when we look at data architecture and again, you could probably say this with solution and platform as well, but I see data architecture in particularly, in particular, as that bridge between business and data. So if we go back to that Dama definition, I think they correctly sort of said there's two types at least of data architecture, that business, whether I took these definitions from the previous slides, if you would map them onto this. So that first, the business data architecture is an integrated data resource that's more business driven, which then ties into more of that physical data architecture that really talks about the infrastructure and the data management and the more technical sides of that. But of course, they should kind of link together. And the solution architecture is describing, probably by definition, a particular solution. And then the platform is more of that foundation or software architecture or architectures and sort of how they fit together is an on-prem that in the cloud on all of those types of decisions. So hopefully that was helpful to kind of take those different layers that were shown in the previous slides and kind of map them a little bit to the different applications. So what do we build from this? And this is only a subset. I'm sure there'll be comments and thoughts that I'm missing something. I probably am. But just to kind of box some of the things that we do on a daily basis, especially the architects on the call and kind of which domain they would sit in. So business data architecture and maybe I went a little heavy on those compared to the others. But I think that may be one that I see maybe is neglected and shouldn't be in some organizations. So I'm sure a lot of folks in the call are familiar with data models. So I would put in the business data architecture, things like conceptual data models, logical data models, and some people go a little higher than conceptual and maybe call that an enterprise or a subject area or stupid names for that. But that's sort of business centric data model. I think a business glossary, you could argue, is that really an architecture piece of architecture? I think so because you're architecting the definitions of the business. They love those glossary terms come from data models. And I think again, kind of a related technology or architecture is a taxonomy. And I find we all have our different camps in the organization. Sometimes there'll be a whole taxonomy group that's separate from the data architecture group or separate from the modeling group. When you think of a taxonomy, that's really a modeling of words and terms and concepts that maybe it's not in a, what we might call a data model or an architecture diagram, but there's certainly an architecture and a hierarchy within those. So I kind of threw out some ones that maybe wouldn't come top of mind. Some probably very much are, but I think those are in the business data architecture because they're architecting the business, the data around the organization. I didn't want to go too far. We'll talk about it again at the end. But when we do talk about enterprise architecture, there's a whole business architecture on top of this. How do you model the business, the capabilities, the business drivers, the somewhat around the business itself. But again, that's a whole webinar of itself. As we go into the technical data architecture, that's where you get into things like your physical data models, your data flow diagrams. I put the logical data model in both categories, the business and the technical, because I think that's to me the handshake between the business, conceptual, a logical data model should have business rules in it. It should use terminology that's fairly business centric. But you're and you're also getting towards some architectural decisions. How do we group the entities? What attributes, what data types might we have on that model? So that one to me lives in both camps. As you get into more solution and platform architectures, they sort of have their own diagrams, Brian showed some in the beginning that are kind of they're all architecture diagrams. And one of the reasons I kind of hosted this webinar is I know when I go into a consulting engagement disclosure, that's what I do for a living, see a lot of different organizations. Often there's this whole little, I don't know, awkward piece in the beginning when we're again back to that cobbler's children have no shoes and we're trying to describe the type of diagram we're looking for. Is there a solution architecture for this? Do you have a data model? What do we mean by a data model? What are we? Is that a data flow? Or is that a solution architecture? And again, just trying to get some core definitions of there are a lot of architecture diagrams that have boxes and lines on them, but they all have a slightly different purpose. And some of the weird design decisions maybe that might have happened in certain use cases is sometimes when that we're mixing them, we're using them for the wrong application. So within a solution architecture, you might be talking about an application like your CRM system, your customer relationship management, or maybe you're designing the data solution architecture itself, the reporting and the analytics and things and really understanding which one you're talking about. Or is it a high level solution that talks about how those solutions fit together, but really that's more of the application type level. And then the platform, to me, was more what Brian was showing, do we have a multi cloud architecture? Is it on prem? Is it both? Are we migrating from one to the other, which is super important, to align with what your business is trying to do? And are we trying to be fast to market and really get to that speed that Brian was talking about? Or, I mean, I'm working with a couple of clients now that they're thinking things are going too fast when we're talking about something like a financial report. I really don't want that real time. I want someone to vet it before you send it to me. And those are two absolutely different use cases, both are valuable, but you don't want to have the wrong architecture. You're not going to use Kafka necessarily if you're a financial report or maybe you do. So anyway, that's why this is all integrated and you really need to look at it holistically. OK, so some examples of pictures worth a thousand words. And again, I'm sure there's some differences of opinion of how I showed these are or what might be included. But I think it's a general hand wave. It's a fair, fair list. So your conceptual data model and there's different flavors of these and I kind of change my style depending on the use case sometimes. The one on the left I like and that particular tool I like because it shows the business definitions right on the model. So, you know, that classic, what's a customer? What's an employee? What do we mean by a company? You can show it on the model and that's when you often get some feedback. An employee is a full or part-time worker. Oh, no, we don't call part-time workers employees. We're only talking about full time. Well, there you go. You see it right on the model and you don't have to kind of have a separate discussion around that. Obviously, you can get busy as you get into bigger models. But for a conceptual data model, they're kind of by definitions should be a bit smaller. That's one example. The logical data model, again, is using business-centric words. Anyone can probably look at this and kind of understand what we're talking about. Customers and orders and products and parts. Is it a raw material or finished good? And you start to see some of the attributes. Yes, you could put data types. You can have different flavors. But that is a good definition of we're still very much at the business level. For example, I didn't know that we as a product would be considered a raw material. I thought we were just selling full products. Right? A business decision right there. Or no, we never sell raw materials. We're only going to sell finished goods. Please change the model. This database shouldn't include that. Right? So that's your logical data model. A glossary, again, is that an architecture? I think so. Because I listed a very simple one. We're basically, it's like definitions on the left. I think conceptual data models and glossaries go hand in hand. But you may have a hierarchy within your glossary. Right? You may have linked terms. You may have versioning. Glossaries in themselves, you know, as simple as this is a list of terms, but there's a whole architecture often behind the glossary itself. So I do put that in the business architecture category. And then, you know, your good old taxonomy that I put one we probably all learned in school. I think I can memorize this eight years old. Kingdom phylum class order family to the species. But there's taxonomies within the organization. It could be a part number hierarchy. It could be product codes. It could be there's a lot of taxonomies that do have their own intrinsic architecture. So again, I put those ones on the right because I think they're often sort of forgotten when we talk about data architecture, because we often think we want to model a thing with boxes and lines. And I just don't want to forget those as well because they should be architected and I'm using them more and more in my engagements as well. So there's your business data architecture. This isn't a business architecture. That's a whole webinar, but they are related. When we get into the technical data architecture, again, there's lots of diagrams we can use there. Some common ones. Again, I put that I put that logical data model there again, because we're right now we're sort of assuming that sort of is starting to look like a relational database. It's not a graph. It's not a key value pair. We can kind of get a sense of some attributes and maybe now there's some design decisions. Look at that subtype. Do we roll that up into a part? Do we roll it down in our separate tables? You're really starting to build the thing on the right, which is more of your physical data model where you're getting more into how we're going to implement this on a database or databases or file systems or however you're going to do it. A data flow diagram. That's probably where I see the biggest difference in how they're shown. There are some standards. I think some of those standards are kind of old school. I tend to often use pictures to kind of show how things are flowed between different systems between databases. Are we sending things through XML or JSON or whatever, but to really get to that flow of information. I often see physical data models are pretty common. At the University in Nye, we do a survey every year in terms of data architecture trends and we ask the survey of which organization is using data models. Logical and physical data models are almost everybody. They should be the bread and butter of your organization. I think data flow diagram should be used a bit more. I often don't see those and I think often when we have a business issue or a master data issue related to data, it's often that flow of data. I think I've probably told the story a hundred times because I'm still so happy about it. We did one engagement where we did kind of a data architecture agile sprints for a retail company because they had problems. They did not want to do the big architecture. They wanted things fast. So we just did sort of mini versions of all of this architecture. We did a data flow diagram brought it to the senior execs and the chief marketing officer said, you know lady, I never thought I would use the word data flow diagram in my life but you're the first one that explained why my marketing campaigns weren't working. Right. Because you had emails coming in from sales system and I think this company had three different master data management systems. If you could imagine the problems there, that inherent problem but it had never really been drawn out in a clear way. So that's why I think data flow often gets to some of those core business issues that maybe have been hidden in other diagrams. So there's your technical data architecture. I think a lot of folks are probably familiar with those or build those in their day job. Now solution architecture, a lot of different opinions here but I think those are more your how does a solution fit together? So the one on the right full disclosure stole from sales force part of the reason I picked that is because this is a CRM system and this is showing how the various components of the CRM are fitting together. In some ways it's a data diagram. You'll see there's tell low there. They is almost like a data flow diagram and you're seeing the different is integrating with an ERP but this is about the solution and I won't do a full rant that a CRM is not master data. It's not it is a customer relationship management our system is a solution for customer relationship management. Yes, a lot of master data is in that system but one of the reasons I picked that is if you're designing your CRM you're designing that solution but yes should fit into these other applications but don't mix the two and that's why I picked this one because it I can see what it has boxes and lines it has arrows it has some data related things but this isn't a data flow diagram and this isn't a data diagram. It's a solution architecture about a CRM system you can also have a solution architecture about your data. So this is a good example of I'm kind of showing the reporting solution or the analytics ecosystem you could say and that's where we kind of do have the lake and the you know the analytics and the governance I put governance in there even though it's a it's a solution the best part of the solution. So again, these tend to be high level it's more about how the various components of that solution fit together at sort of a high level and again, it can be more of an application or it could be the data. So when we get into the platform architecture so many flavors of this and again, I stole two from popular renders out there and actually you could nerd out for as long as you'd like on some of this. So there are so many and Brian alluded to this in the beginning there's so many different design patterns right now for your platform architecture it isn't you know the old days of I don't I'm just been up the server and put a database on it. Really firstly, aligning with that business purpose and can these two are very different am I doing an IoT integration for a factory am I doing a reporting solution or we're doing a digital transformation maybe the one on the right is moving from on-prem to cloud are we doing a shipping system or we're doing a you know there's so many different patterns are we integrating healthcare records? So one of the reasons I stole these from the vendors is because it's fairly neutral and they publish them but if you look at some of these out where vendor sites these are common cloud solutions and a lot of companies are now struggling with do I do multi-cloud do I do a mix of on-prem and cloud and the one thing whether I agree with all their design decisions that are published out there they're a good template and if you sort of look they have you know here's an example of a cloud migration here's an example of a real-time data streaming for a web app and you can kind of see these various patterns because there's a lot and this is as again as Brian mentioned in the beginning this can I'm a huge fan of starting with a business and driving from that but if this platform isn't supporting it and you do have this cool new sexy app and it's not fast enough and it's not performant right or you're doing reporting and you don't have the right governance feeds to tie into it it's not going to be successful so really this is really the core and the foundation of everything that seems like you know the nuts and bolts maybe don't need to worry about it but if the nuts and bolts aren't secure it's going to fall apart so those are some different ways to kind of show them there's a lot of different flavors of this but these are kind of too from some of the energy out there so hopefully that's interesting to you okay so you as if you've heard me speak before you know I like to look at that holistic approach and really look at the so what and I think this example obviously Hakimi Corpus is sort of a fictitious example but this little thought bubble could be so many organizations right now where we're trying to do a digital transformation we're trying to move all over our mainframe applications to the cloud we really want to be faster more digital etc you might say seriously Donna you put mainframe on there yep you can pick on them but they're still running and a lot of them still work are they the best solution for data integration do they have their issues absolutely but yes and often when you are doing a digital transformation and maybe we do want everything hosted on the cloud you are going to have these legacy systems whether it's a spreadsheet or a mainframe or relational on-prem database etc etc so where do we start with this it's tempting to start with this right we're going to I need to move from one but let's pick the one on the right you've all these on-prem systems from flat files to relational to non-relational to you know there's a mainframe type things right there and now we want to move it to the faster cloud that's absolutely important we need to do that I would be careful just don't start there it should be driven from the business question so for example this first one I wish more companies did look at how does the customer journey change now that we're in the digital world what you don't want to do is just lift and shift all of your non-digital processes on to a digital world I think we've all had some of those negative customer experiences where you know literally they're just doing kind of on you know brick and mortar badly online and this is really a great opportunity to not just upgrade your technical architecture but upgrade your business let's step back let's do something like customer journey map how do we really change the way customers or patients or whoever we're talking about our students really interact with us as an organization and some of the huge light bulb moments we've had with our customers are starting there we did a really great one with the university where they just basically started with this that they called it the student journey map and they did a very high level data model with that did nothing else and just said okay if I'm I'm a prospective student what's my best way to interact with us as an university and they kind of started from scratch and they really had some night and they also had you know about to get totally off track from architecture they had a good mix of people from the organization they had people from finance they had people from enrollment they had people who were teachers and they also had students so it was a mix of generations it was a mix of use cases and when you're really trying to do task formation you really have to look at it from all the above you know something is something this would go to retail too right where we're trying to change the business process but yeah how do we invoice right so you want to finance in the room or you know like younger generation is going to have a different perspective than maybe the older generation so don't scrimp on that first phase in just terms of how we design the business that you're missing an opportunity if you only are thinking of the tech right so then as part of that how are we defining things like customer and this is where yes your friends and family or maybe your colleagues start to think you're crazy really we need to do a whole cloud migration and you're going to sit us down and say you know a very academic what do I mean by a customer but man again I've had some of those light bulb moments what do we mean by a customer one of our customers has a they were very they were sort of focused on baby type products and so of course they were focused initially on on moms and pregnant moms because they seem to buy the most when they really looked at their customers there was an equal amount of dads good to see they were grandparents they were friends they were family so who they thought their customer wasn't the customer right when we did the group at the university it was you know not your typical 18 year old it was returning veterans it was parents with babies on their laps you know there was retired people who's a patient right a lot of my kind of more either non-profit or medical customers are realizing the patient isn't just the patient it's the family right so how would we maybe give updates to the family not just the patient so again I'm spending a whole lot on these first two bullets but I do do spend a lot and have those fairly academic because they're not and the other thing you've probably heard me in these in these webinars some of these architecture diagrams can seem overwhelming you could say that's great Donna you on your webinar can say do all of this I have a deadline and it needs to be done next month so that'd be nice but you don't live my world I don't live your world but I would say if you don't have the time just do it in a whiteboard in an hour in a half an hour just sketch it out in the back of an envelope I've had some really and especially actually and the other question is how do we do this now and things are opening up in different areas of the world but most of what I'm doing is virtual I've used a lot of you know whiteboarding sessions mirror boards you know virtual sticky notes and we have had some huge aha moments by getting a lot of people together just mapping out things like a customer journey and a high level conceptual data model in an hour and I think in a way I'm getting slightly off track but I don't think so it's actually I've had you know I've been doing workshops for decades now with kind of whiteboarding sessions and sticky note sessions those are really very valuable and I will get back to those when things open up but there's something about this online almost gamification of data modeling and architecture we had one really transformational moment of folks that we really were having issues getting to and we did a data modeling session where they could drop their own boxes and do their lines everybody participated and we really came to an aha moment at the end I just think because it was kind of fun to drop the boxes I'd like to think we're more adult than that but I think some of the it was a little more anonymous perhaps too people could just drop their sticky note we kind of did it in kind of 10 minute sprints and okay we're going to talk about customer where all the boxes you would put around customer and argue for a bit and some of the you know data architects in the call are going to say great you've got 90% of it in the hour and then that last 10% is going to take you another three months maybe maybe those are your master data domains but you can go very far was especially I'm now become a really big fan of some of these physical technologies you can do voting you know on terms when you get those gnarly issues and things and I'll probably keep some of them even when we're in person so a little tip there and then we get more into the technical data architecture so these are only a few of the many questions what data is being migrating this is another one where I think there's an overlap between business and technical again so many of us and myself included jump probably right to the tech so okay we're migrating to the cloud what databases do we need to move what technology is it you know ELT or ETL or how do we absolutely important but think about the what do we need to migrate everything what data we what is the security around it what's the best business value and can we pick just the high value data first maybe we don't move everything onto the cloud maybe some of the data we've been managing for years doesn't need to be managed right so you're missed again you're missing a big opportunity if you don't start with the why and I have seen that makes me cringe a few companies that in the rest of we don't have a lot of time we just have to move digital have absolutely just I hear you can hear the excitement in my voice have literally just done a lift and shift I could do not from something like a mainframe to the cloud and literally kept all the data structures all the same things spent millions of dollars to do that they got there faster but what did you get in the end you got a mainframe on the cloud that really again you're missing that opportunity to truly transform your business and really think can we be more real time can we be a different customer journey can we etc etc so don't do that you may do that if that's the right business decision but think it through before you just rush to have everything quote digital what does that mean we talked about this in the beginning how do we model the data for past faster performance is moving to the cloud enough do we just you know do we model it in a different way do we is a key value pair for a web application or we want to do a relational database for a data warehouse etc etc so a lot of new technology out there to make it faster how do we have different data transformation pattern and technology I mean all of those are very important and should be modeled out ahead of time that should be a healthy discussion between your architecture team I've had a few my team's on the call and probably not in their head that I can be very vocal in these meetings but that's the time to do it before you build because it's hard to do it after you've built it so just like anything think and then do is always a good mantra so as we get more into the solution architecture again there are architectures just for the solution so I don't want to pick on CRM I mentioned it before and maybe a disparaging way CRMs are awesome so how do we manage that should we go with a SaaS solution how might that integrate with our analytics how might you know web analytics tie with our on-prem and like but again you're doing that architecture with a solution lens and maybe I'm designing my solution for analytics and reporting and then I'm going to do that answer that same question with more of the data lens for this and then again huge decision in terms of price in terms of performance in terms of vendor lock-in and etc etc but you know which maybe which cloud platform should we use should we have a mix of on-prem and cloud should we go with a multi-cloud solution etc etc etc and that's some of those you know diagrams we saw in the previous a big decision as I mentioned there's a lot of patterns out there a lot of things to think about as you go through so don't skip any of these steps right don't only think about the customer journey and then forget you know and go and put it on a main frame if that's not the right decision and again don't jump right to the cloud and think about the other steps don't just move the database to the cloud not look at how that database is modeled there's so many different ways and different technologies that can support not everything is a relational database anymore so again there's a lot of different patterns and think of it this way there's pros none of these design well there's some crazy design patterns but it's not that any of these design patterns aren't intrinsically good or bad it's does it meet the use case and that's why I like to think of these design patterns at each level at each level it could be different even how you define a customer there's different patterns for that there's party models etc etc no one is right or wrong it really just has to match what you're trying to do with the organization which should be obvious but it can't be said enough because I just see it skip too many times okay up for air so in summary there are several architectures that are used together and hopefully I cleared things up and didn't make it more confusing in terms of when we talk about an architecture what do we mean and you might disagree with me and I'm absolutely okay with that as long as we just set our terminology in the beginning if we're going to have a meeting and we're talking about an architecture this is the one I'm talking about and this is how I show it good we're good to go and now we can have a discussion about how we can maximize this value so don't get in that architecture you know I show a data flow diagram in a different way good does it still get to where we want to get to yes because I've just a lot of different flavors out there because really we're trying to focus on that business need and then design a fit for purpose solution with the right design pattern that makes sense to you and there's a bunch of them out there and that's what makes our job so fun and hard because these are big decisions and and again that's why I like to design them before you build them because there's a lot of process so we will open it up for questions and in a moment quick sales pitch we do this for a living if you need help you know where to go and then and as I will just one more quick oops I think I stopped sharing my screen but the idea is we will open up for questions we also have the series and next month will be on enterprise architecture so if you can join us for that please do so I'm going to open it up for to Sharon for Q&A so much for another fantastic presentation lots of great questions coming in just answer the most commonly asked questions just a reminder I will send a follow-up email for this webinar by end of day Tuesday Monday is a U.S. holiday so it's going to be by end of day Tuesday this time with links to the slides links to the recording and anything else requested and if you have questions for Donna feel free to submit them in the Q&A section and if you see a question that's there already that you wanted to ask that you were going to type out I have just hit that little thumbs up arrow so you could just say hey you asked the same question I wanted to know and it's very handy little feature there so diving in here Donna these businesses and technical data architecture artifacts haven't changed very much for a while as we start doing more on the cloud and in quote unquote modern architectures there's a push to use repositories like MongoDB where data is stored and was structured or semi-structured as a result many non-data focused people seem to think we no longer need to model data how do we justify the need to model in this new world um yeah no there's always a data model whether you have explicitly modeled or not right I like to start with a conceptual data model and that or that business layer because that really fleshes out some of those core business rules and I've had many a convert from the business of why do we need to model why are you even disgusting custom disgusting customer and you give them an example and they argue with you for another hour about that definition of a customer so I think it's just showing it you know some of those core the business should be modeled and then from that those are your business rules around data or even a taxonomy or and then from there then yes you might store it in a document database or relational we did show a relational I think at the logical level that that view still shows because there's still rules can a customer have more than one account with the bank yes or no and then whether I model that and really you know some reason some of those look more relational is because they tend to capture those business rules you know maybe I'm doing a key value there because I'm trying to have a really performant website let's just that's just one of the use cases and some of those technologies don't necessarily need to be as closely modeled so these were so that the business models but I would push back the fact that no model is needed I had some really bad customer experiences is I mean I joke about these things of you know what's a customer I just the amount of time we're doing a lot of hiring the number of times I have signed up for a you know trying to post to a job board and they advertise it back to me that I just posted it and they're trying to have me apply for my own job to they have a salesperson contact me after I've already posted the job classic what's the customer right and these are all new their applications and they were fast they were high-performance all of that but they missed the core business rules so that's why I think you always need to model and then you just might have a different display of the model but there's always a model so that's my thought I love it so do you consider a semantic modeling part of data architecture and where does that fit in yes absolutely so I would put in that the kind of that business data modeling I think semantic models are perfect and I kind of see those kind of with a taxonomy with a glossary with a conceptual data model all in that same kind of category and then if I'm not working with a relational database you know again do I still a lot do I still use the logical and physical data models you talked about this a little already but I think a logical definitely and it really depends what you're doing you can be doing xml hierarchical database a graph database I think sometimes those are nicely modeled so it I think everything has an inherent model so that may mean not for everything really depends on the use case but I would start with the assumption that you do but then definitely start with that logical because that's where you get the business rules and then just make sure that the model you're using or the technology you're using is aligning with you know if nothing else you know just the data types or the you know the field definitions of you know could be just a API you're passing the customer name back to me do we mean the same thing by the name you know so everything has a model and I do think starting with some of those cores and just making sure anything aligns with that but yeah you probably don't need a fully attributed data model for everything at the physical hub and kind of a part B to that Donna you know what about graph databases how do you is data modeling still needed specifically for graph no definitely and that's one of the beauty of graphs that kind of ties back to that you know semantic model question so one of the beauties of graphs is you can kind of have those different model layers and kind of how those semantic questions put together so absolutely graphs and data modeling go really well together it's a slightly different style than the ones I showed but absolutely that that's one of the powers of graph is that you can kind of have those those more of a semantic model on top of them so yes can you address the question of moving data physically versus virtualization or some combo thereof how much is really needed in real time and what are key issues to weigh and key misconceptions yeah and then we think we did was it I don't lose track of time with it this year last year we did have a one of the recorded webinars just on data virtualization I think that's a classic case of start with a business name why are we doing this I know it's hot I know a lot of the technologies have nice user interfaces and some I had one customer that wanted to use it just because they like to use your interface and they really didn't have a use case for data virtualization absolutely start with these having some of these more technical platform solution and data models can help you with that decision of whether you need to virtualize I mean some of the benefits is that you and I think the question question pursuit post of the question mentioned that you don't have to you don't only have to move things for example into a central data warehouse to report on it you can have more of a federated model you can leave things in place and then just have that virtual layer so that can be very powerful you can have a kind of a common reporting layer across multiple technologies that can be really powerful so you know especially you can use it for everything in production I do have some people using it kind of almost in that exploration before I move things let's kind of virtually integrate things and see do we absolutely have to have it in a single data warehouse I think the caution of that is some people or some organizations use these virtualization as kind of duct tape over the structural problem you have to almost more so I think model out what data is where how it's integrated what it means what the security levels are so I would argue in some ways you need to have even a better architecture to make virtualization work because you need to understand the systems but the benefits the ones I mentioned if you absolutely know the pattern what one org we used get it really well it was a university like what do you call it consortia where they were able to share data in terms of the they understood the structures but there was no way they were going to move the data between the different universities so they did have a virtualization layer and that was a really good example of yes it was well modeled and understood and yes it was virtualized you know and some people don't model it so much and use the virtualization as a test case but what I would say don't do is just virtualize so you don't have to do the hardware so hopefully that answered the question absolutely thank you so in which architecture uh will you define data pipeline patterns I would say some of the data pipeline patterns are getting more into that that bottom kind of that platform architecture I mean there's a bit of a data flow diagram on top of that you do kind of have that logical architecture but I'm thinking that's more of your your kind of sort your platform of how how are we moving or those pipelines look like what's the timing of it and Donna can you give some more examples of taxonomy um I have seen a taxonomy in I sometimes different categories that the different uh one organization was doing a lot of market research and they had their own taxonomy of these are these are consumer packaged goods and these are healthcare products or kind of the different ways of looking at it some organizations use taxonomies kind of to organize their products these are lifestyle products and these are sportswear products and things like that part numbers and and things like that can kind of have their own and it's almost like a hierarchy of where they're all part numbers right but we kind of have a part number uh taxonomy that really kind of organize them might be another way to look at it so those are some common ones that I've seen in terms of a taxonomy I mean the classic one I had was in biology right though that you kind of had a taxonomy of the different species and things like that but it's sort of like a category they're all categories but you kind of have a taxonomy within them that add that structure in terms of the content if that makes sense probably explain that really badly but hopefully that explains it but if the questioner has additional insight that they would like feel free to submit it in the Q&A we'll get to that uh so Donna um my current case designing the new Enterprise IT strategy with the first time ever integrating data architecture into the well-established disciplines as application and technology architecture the old stuff is straightforward as is to be as is to be uh to gap but how to address and integrate data architecture first time is such an established process so if I think I'm understanding that correctly everything else in the organization is well modeled and well established but the data maybe wasn't I think that's how I'm reading it um I would I would hopefully the other areas I guess I'm just thinking aloud here if the other areas are well documented already I might take those diagrams and kind of add a data layer again this is probably not an official diagram of those ones I mentioned but add a data later on top of those I think a big starting again with kind of that high level of what what data we need to focus and then having some kind of use cases so say it's customer data now how would customer data go through this architecture that you have and maybe it's more like a data flow but it would show the integration of you know maybe these are the applications you've already all integrated that's great but now how would a customer address go through from the CRM to the you know shipping or to whatever else they have kind of maybe that's to kind of tell that data story of how data flow how it's structured and how it flows and then maybe how that would affect the platform decisions so therefore we have to do x as a data architecture to support the architecture that exists that is my off the cuff way of how I might approach it but without more details can't get more specific but hopefully that helped makes sense all right I think we're time for a couple more questions at least one more so any suggestion of good or excuse me let me just kind of check through here layer data modeling to link individual data models in different architectural domains I'm sorry could you say that again yeah so is a layer in layer data modeling is it to link individual data models in different architectural domains um yeah a lot of the enterprise architecture at a high level a lot of the enterprise architecture tools kind of have that layering and they tend to be you know here's my data model here's my process model and then they can sometimes share some of those architect effects across those can also be very expensive and it takes a bit of rigor to do that I'm also a fan of even just things like a Vizio or maybe it kind of ties back to my previous question I often get a little more flexible with the design if it tells the story so for example I'll do a process model and then just oh yeah it's not too far off from BPMN but like you just put here's where the data lives all right or or you in kind of adding a day later literally on top of the diagram with a picture or a graphic you know some of the data modeling tools are going more the enterprise architecture route so that they can take their data model artifacts and then kind of show them on other diagram I mean that makes a lot of sense but I think it's more of that enterprise architecture that seems to do it and you know almost on the other end sometimes good old Vizio can kind of think you can mix and match different modeling paradigms and kind of show it that way those are probably two extremes that helps well I think we you left just enough time for one more question here an elevator pitch I understand the value and the components as a data architect but how have you had success explaining to the executive leadership that I generally so for each of these when I went into the data layers I kind of talked a lot about the conceptual logical physical I think that can also hold true for any of the layers as you know I'm a big fan of storytelling so part of it is how you tell this story but I have so diagram actually firstly I think a lot of the tool vendors these types of even platform diagrams look prettier if that makes sense so they're a little less scary but you can tell the story of these I've done it by say we take their one on the left and we're trying the right and we're trying to say we're moving on prim to the cloud I either take this and do a little like thought bubble call outs like the thing in the bottom that's your main frame you know claims database and the one on top is whatever and we're trying to move that to so you can either take these techy diagrams and do an overlay by telling the story you're giving examples or I've even shown a picture of a customer okay here's this customer buying the thing in this db2 database and then they ship the thing in this database and this is why that's one way and or I often take these type diagrams and do more of a conceptual so you just take off some of the detail and just say okay we've got file systems and relational databases and whatever and we're moving that to more of a modern web storage and we're using this thing called data if they even care but this is how we're moving data something like that so the combination of those two generally works pretty well and I've found that execs are actually much more interested than they have partly because it's the cool stuff now and partly if you show how it affects their business and they're paying for it they tend to be really interesting well Donna thank you so much as always but that does bring us to the top of the hour and thanks to all the attendees for being so engaged in everything we do I just love all the chat and the questions coming in again just a reminder I will send a follow-up email to all attendees by and to all registrants by end of day Monday with links to the slides and the recordings and hope you all have a great day and for everybody in the United States have a great holiday weekend thanks everybody thanks Donna thank you