 Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager 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 discuss Enterprise Architecture versus Data Architecture, sponsored today by CouchBase. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them via the Q&A section. If you would like to tweet, we encourage you to share highlights or questions via Twitter using hashtag DA Strategies. We very much encourage you to chat with us and with each other throughout the webinar. To do so, just click the chat icon in the bottom middle of your screen to activate that feature. If you would like to continue the conversation after the webinar or follow Donna further, you may do so at community.dativersity.net. As always, we will send a follow-up email within two business days containing links to the recording of this session and additional information requested throughout the webinar. Now, let me turn it over to Thomas Song from CouchBase for a word from our sponsor. Thomas, how are you? Hello and welcome. Great. Thank you, Shannon, and thank you very much for inviting all these great attendees today. CouchBase is very pleased to be sponsoring today's webinar because with Data Architecture, dealing with data management platform decisions and database strategies in particular and letter the requirements of modern data intensive business applications, we are finding that architects are increasingly concerned with moving to multi-cloud database management systems or choosing between a NoSQL or relational database. That's exactly where CouchBase and our enterprise class multi-cloud NoSQL database comes in. Now enterprises are becoming increasingly comfortable with the idea of modernizing their existing workloads onto a NoSQL system, especially as NoSQL begins offering feature parity with relational database management systems illustrated here with NoSQL in the Venn diagram encroaching more and more into transactional and analytical database workloads. Many NoSQL now support ACID compliance for transactional workloads and support querying operational JSON data for analytics. Now that said, relational databases will continue to have a role to play, albeit diminishing, as modern data incentives, web, mobile and IoT applications emerge with fundamentally different requirements in terms of scalability and high availability. In fact, this is precisely why Oracle Stranglehold on the database market is loosening. Traditionally systems have been dominated by high value, low volume transactions for general ledger, in banking or purchasing items like airline tickets. But for a given transaction, think about all that happens in support of that single operation. From the systems of intelligence to the systems of engagement, the number of interactions between humans and machines or machine-to-machine are exploding and we're talking about massively interactive and highly data intensive applications today. Think for a moment of look-to-book ratios, for instance, of about a thousand to one for a given airline ticket transaction. Consumers like us are interacting with systems as they research flights all the while retrieving and creating new data at unprecedented rates. Entering machines in IoT and interactions with data increases orders of magnitude even beyond that. So very simply, legacy databases were not designed for these modern workloads and data structures. But with so many flavors of NoSQL available, determining the best NoSQL database must begin with an understanding of the use cases and the application requirements on performance both today and in the future. At CacheBase, we're focused on modern massively interactive web, mobile and IoT application development with a high-performance Cache and integrated document database. We're the only database that combines the best of NoSQL with a power and familiarity of SQL. That is a fully SQL compatible JSON database that can securely sync and manage data from any cloud to the edge. And with our cloud-native distributed database platform, helping organizations innovate their enterprise class business critical applications. Some examples of these major enterprises adopting CacheBase include the likes of LinkedIn, Tesco, Amadeus, Comcast and United. In each of these instances, because unlike other NoSQL databases, CacheBase offers robust database capabilities on a highly scalable and available NoSQL platform. And we've uniquely built it on top of open standards to simplify the transition from mainframe and relational databases. Now one common theme across these customers is the critical need for performance at scale. Let's first look at LinkedIn. They needed a single view across their 450 million accounts. So you can imagine their performance requirements, over 2 million reads per second, 10 million queries per second. You've probably heard of Tesco, now the third largest retail in the world. They needed to store and update product data for over 10 million items and had to scale to support 35,000 requests per second, as well as peak Black Friday traffic. Amadeus, the well-known travel platform with CacheBase, they can handle 7 million requests per second with under two and a half millisecond response times. Now Comcast, like LinkedIn, also needs a single view across all their customers from the call center to the technician in the truck outside your house. Today they have 100,000 internal users accessing over 200 million documents. Finally, United where they have an app for employees and the 41,000 pilots and crew members who use CacheBase every day to make sure your planes and flights arrive safely. Now, these are all impressive performance characteristics. IDC also independently interviewed seven of our customers and released a study that highlights the business impacts of CacheBase. In terms of performance and ultimately customer experience, the 40% faster response time. In terms of ROI, a 274% five-year return on investment. And to bring it all back to data and enterprise architecture and the impact on data and processes, 37% more efficient database management. So with that, let me pass the floor back to Shannon to introduce today's speaker and our topic on data and enterprise architecture. Thomas, thank you so much for getting us started here and thanks to CacheBase for sponsoring the webinar today. Always appreciated enabling us to get these webinars produced. And now let me introduce the speakers for the series Donna Burbank. She is a recognized industry expert in information management with over 20 years of experience helping organizations enrich their business opportunities through data and information. She is currently the managing director of global data strategy and 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. Thank you. Always a pleasure to join these and thanks again for Thomas and CacheBase for the sponsorship as well. And as many of you know and as always, I always check before the call and a lot of familiar faces for the familiar names on the attendees and I appreciate a lot of folks come back month after month because this is a series. And sometimes you come up and say hello at the conferences, which is always nice as well as you know, data diversity has a lot of great in person events as well. But for those of you who this might be new for all of the idea that's always a common question, yes, the slides are available for both of the sessions today. And all of them are on demand, I think in perpetuity, correct me if I'm wrong Shannon, but all of the sessions if any of the ones that from earlier in the year on data modeling and governance and master data, as well as the other data versus the webinars are all on demand. So you can see the next ones as well. But today we'll be talking about enterprise architecture and really that's role within data architecture and are they the same are they different and where that overlap is. So one of the things if you've joined my sessions before, you know, I love sort of this idea of the visual blueprint, whether it's a data model or customer journey map or et cetera, et cetera. I think so many of us are sort of visual thinkers and visual learners. One nice thing is about doing that. I'm going to steal from one of my clients at a great view as we were building some of these, you know, when in doubt zoom out. And I think that's a really nice way of looking at it, especially in the complexity that Thomas was mentioning. It's hard to really get a detailed view of everything to start. So really zooming out with some of these high level architecture diagrams gives you the big picture even to answer some of those questions. Is there no SQL database and or is it relational for what use case for what process? You really can't answer those questions until you've got that bigger picture. So that's where enterprise architecture and specifically data architecture can fit really nicely because that's really where data is put into a wider context. And for me, as many of you know, I run a consultancy company where we really focus on that business value and context is everything. You know, there's no SQL databases are wonderful. Relational databases are wonderful. They're terrible when you put them in the wrong use case, right? So I think some of the problems we often run into is just not fit for purpose. And I think, or, you know, there's only so many resources and or in an organization and where do you spend them wisely and what's the focus? So, you know, back to definitions because another thing we do well in data management is all about definitions, right? What is EA and enterprise architecture? Everyone just because what's the saying cobbler's children has no shoes. Often we in our own industry are not consistent on our own definitions and acronyms. But I took this one from Gartner because I thought I like the different aspects they hit on is one as I mentioned the beginning and Thomas touched on as well. There's just so many disruptive forces in the industry, which are generally good, right? There's new technologies happening every day. There's new opportunities, increased innovation and competition. The number of choices that are available to us now in terms of technology is a massive and it's impressive and it's fun. But it can also be overwhelming. So one of the nice things about these architecture diagrams, they really sort of hone in on sort of root cause need and analysis. And you're able to sort of have that communication mechanism between both business and IT to really have these conversations. Especially if you're not technical and you're trying to make decisions like what sort of database platform do I go on? It should and does generally come down to business value and use case. So it's a nice communication mechanism to really do that. So I see enterprise architecture is that nice link between the innovation that can be happening today as well as that foundation. And as many of you know, I've been in the industry for a long time, probably going on 30 years now. And it's funny to me a bit of that some of these quote old school technologies are really coming into fashion. And I prefer not to think of them old school, but foundational. You know, things like a data model, things like an enterprise architecture capability model are even more crucial now when there's so many more choices. You know, if it just was about the example in the introduction about getting my finances right on Oracle. Well, that's not as hard of a conversation, but now when there's 17 other use cases and Internet of Things and a lot of other options, it becomes more complicated. So some of the tools we'll talk about today and there's many, and there's many different viewpoints in enterprise architecture are the idea of and I had an evolution myself from more of a pure, well, starting out as a business degree earlier in my career, then going into data and then zooming back out again. And what I sort of liked about that is that if you are a modeler, it's really looking at an organization with a model. So say you're a data modeler, you should very quickly be able to sort of understand the idea of maybe a business process model if you have an or a business capability model. It's that same idea of just getting core concepts and drawing them out in a simple way, because that's really where you can have these high level conversations and really do the planning of an enterprise as a whole. And I think that's the difference between some of the maybe technical artifacts, maybe a physical data model you might have looked at, because it's really zooming in. And when we think of enterprise architecture, it is more about zooming out. And so back to that idea of context. An enterprise architecture really is that holistic view of the people, the processes, the applications, and of course the data. And this is one view you can look at it if you think of sort of what's the business view, whatever our motivations, what are the capabilities, what are the business drivers, there's sort of a set of tools around that. One of the business processes that support that, so either at the high level macro view or detailed, you know, really down to the operational level of step one, step two, what data is touched by each process. So for those of you who are familiar with the data modeling world, kind of that idea of conceptual, logical, physical, there's that same concept with process modeling. Just like anything, this is helpful when you zoom out, it's helpful when you zoom in, and you just want to use the right tool accordingly. And as I just sort of talked about, there's also value in starting to map some of these or overlay them together. What data is used by what process? What's the right use case for this particular data application? What business capabilities are being supported by this data, et cetera, et cetera. So we'll sort of talk about a lot of these with anything, even if you go up a meta level. If these are the models to describe the business, there's models to describe the models to describe the business, right? I guess that's called the framework, right? So then, and again, because we can never agree on anything in our industry, or we like to provide people options, there's several different ways, several different frameworks for enterprise architecture. Many of you, I'm sure, are familiar with John Zuckman, and he comes to a lot of the Data Diversity conferences, actually, lovely settlement. And he had put together the Zuckman framework, and what's nice about this particular framework is it's very simple, it's the who, what, where, why, and when of the organization. And data often fits rather nicely into that kind of what. What are we looking at? But when you look at data holistically in the enterprise architecture, who is using this data? When is it used? Why is it used? I think so many of the problems I've solved going in with consulting, if we had just started with the why, would have been solved in the beginning. Why and then how and who and all of that. But really stepping back can be helpful. And then his model is sort of nice in its simplicity that way. Another one common in the market and has a lot of different tools around it and some certifications as well as Togaf. And similarly, they all have the same concept in mind. It's this idea of really looking across the organization from the enterprise view to the business view to the technology applications. And again, a lot of us on this call, when we think of tech, because it's the coolest thing, we think of data, right? This is sexy stuff. But there's applications. There's code. There's a lot of other types of technology. There's actual technology. You could be looking at medical devices, right? Those are technology. They're just not data. So you're good to look at everything across the organization. And those are at least two very good options to really start with. And it's depending on your use case and your flavor and how rigorous you want to get with some of these. What I thought might be helpful, one of the things I like to do in my consulting practice and in this webinar is to keep it really realistic in real world. I am as big a nerd as anyone. And I would actually find fun to go into and smell of detail a lot of these models and build it out. I mean, modeling is a joyous activity. But we all have many things to do. And I think I'd rather go skiing than if I had my Maslow hierarchy of needs. I have other things in life as well. So what is realistic and what's usable? And my other rant is that I think you can get a lot of value out of just doing a few of these very simply, a few step back and ask the why question or who question. It's going to be a lot better than not doing it at all. So one of the surveys and you lucky participants of this webinar will get a sneak preview into a survey that's going to be released in the September time frame. And I've sort of been dropping the carrot of hint this is coming in. It's finally very close to being in print. Each year we put together with that with the diversity a trends report. This is trends on data management. And one of the questions was, what models do you actually use in your organizations today when it comes to enterprise architecture diagrams? So yes, I know a lot of you are analytical on this call and the survey wasn't particularly, you know, completely unbiased because this was for diversity people. So I'm sure you'll see a very heavy focus on the data side of this. If you were at a process modeling website, you know, university, then maybe it would be heavily more on the process side. But that said, you do see a very high concentration of logical and conceptual data models, which if you know me well is very near and dear to my heart. Because what I think is nice about those that definitely is the zoom out that really is where you're getting the business value and business meaning. What do we even mean by customer or a member or a product or, you know, the very high level definitions and especially at this level, it's nice. They're very easily mapped to things like business process. You don't need to know what table necessarily to start with is used by business process. You just need to know that product data is touched or maybe what attributes and product data, for example. And then, of course, physical data models are also being used. You know, they obviously are necessary in any architecture as well, excuse me, as things like data flow diagrams. And again, any of these can be done at a very high level or detailed level. I often start in my practice, even just whiteboard a data flow diagram just to get the very high level understanding of where these pieces fit together and then go into detail. Business process models, as I mentioned, other big popular under release understanding how this data is used. And then system architecture diagrams. That's really the systems we talked about what's being used by my ERP system. What about the point of sale system, et cetera, et cetera. And that is really that is almost a business view of what applications are using that. If we can keep going data lineage, you know, I was curious that this was done in a diagram. That could be true and or there's a lot of good when we talk about data catalogs and metadata. Actually next month's webinars on metadata and some of the lineage tools that are out there. That's done as well. Card matrices I'll talk a bit about today, too. I'm a fan of them. They are definitely one of these old school things that are still in value. Where is data created, read, updated and deleted? I was a little disappointed to see that business capability models are sort of lower. I use them a lot. And again, I'll show one today that you can. Excuse me, I'm fighting a bit of a cold here. So if I sound funny, I am. I'll show an example of one of those today. And then you'll see some of these when we get into class models of things of the UML world, which I did not talk about, but the unified modeling languages is also another good way to kind of see that bigger picture. So hopefully that was just kind of helpful to see what are other people doing in the industry and sort of what some of the trends are. If you are new to do any of these, and many of you I'm sure are because that's why you're joining the webinar, I thought it might be helpful just quickly at a thousand foot view just to show an example of some of these and maybe talk about why they might be helpful. So when we're at the conceptual data model view, I'm a big fan of these particular modeling notation that's used over the modeling tool that actually shows the definitions right on the entity. So this really is another relationship diagram. This also could be a PowerPoint. You know, I'm not proud. I have done conceptual data modeling. And a PowerPoint, especially when you're presenting back to a business user, you know, I've done a picture of an employee, a picture of a support rep. But this is nice because it starts to get that semantic layer on top of your data right away. So we very clearly understand as an employee only a full-time employee, what about part-time? What about interns? What about volunteers, et cetera, et cetera? And as many of you data modelers on the call, that could be a whole work group definition of what do we even mean by employee? You know, does it need to be what's stored in ADP or is it things that are, you know, it could be a contractor. It could be an employee if they're long enough, et cetera. Probably not actually, but you get the idea. How do you start telling that story about your data? And a conceptual data model is a very nice tool to do that. As we go lower into the stack, this idea of a logical data model is still very business-focused and you see things that a business person, even if you're not technical, should be able to understand. We have a customer that plays an order for a product and then, you know, they have a part that are part of that product, et cetera. You'll see here that there's some attribute names, that the customer has a first name, middle name, last name, et cetera. Generally, I would put some data types on here. So you're starting to get some definition, but we're not down to the physical layer. And I would say instead of my high-level business view of an enterprise architecture, I wouldn't necessarily go down into the physical layer. Those are definitely needed once we start implementation. But again, when we're just doing that high-level planning view, I think it's enough to even be at the conceptual view or if you go a level higher, even do subject area view. That's fine as well. Another tool that was not high on the Dataversity Survey, but I have used quite successfully often, is this idea of a business capability model. What I like about this, as any of you know, who have been in the industry for more than 15 minutes, is that politics often have a big sway on anything we do, right? And there's a benefit to sort of see where data is used in the organization, not just in the system. So is product data used in marketing and accounting, et cetera, et cetera. But often if you go sort of by org chart, either that's too political, or maybe that's not the best, maybe org charts are fluid and they change, often it's very helpful to look at just the core business capabilities. It sort of takes the people out of it. And this is also a great way to do organizational change if you are doing a reorg. Let's strip, just like you would with a data model, strip everything out and just think it's basic core. What does our business do? We have products and customers and sales and staff, perhaps, if you're in retail. And this, at the same way, breaks out the capabilities just to have a very high level. So if we are in a retail company, what do we have? We have sales, we have marketing, we have product development, we have human resources and legal, that are kind of shared services, perhaps. And it really steps back at a very high level. What's also nice, and again, these are simple, and I recommend that you do them even if quickly. And I know we all have not enough time and there's a million things we could do, but I'm a big fan of doing things in a very quick, agile way. And even if you do some of these on a whiteboard for an hour in a meeting, I think a lot of these issues might be solved for all of these diagrams I'm showing. But what could be helpful here is to just sort of say we're at the conceptual or subject area model. You know, kind of do an overlay or a heat map. Where is customer used across these systems? Where is product used? Where is account used? And again, the number of problems that could be solved, even just doing this, you know, master data management is definitely one of those areas that, what old is new again, and often when master data management projects fail, if they fail, it's not necessarily the technology. Yes, it's hard to get your matching rules and your survivorship rules, but generally we didn't talk to branding in this example and they're using data in a different way and therefore they won't use the system or we're now trying to integrate with the system and we didn't get the business rules right, et cetera, et cetera. So this is at a very high level, a heat map of who to talk to, and maybe their definitions are different. So I've used them very successfully. If you haven't seen them, it's worth taking a look at all of the notations that I mentioned kind of have this concept. And if you do do them with all of the models I've shown, don't cringe if you use a different notation or mine seem rather simplistic because they do. And I will be the first to say with anything, I've done data modeling for decades now, and I am the first to just mix it up, you know, put a picture of a person instead of the person, put in a PowerPoint if that's the best way to communicate. And at this level there's some value to rigor and going against the notation, but don't be so held on that that we forget the bigger picture. So if this gets the point across and you're still getting the same core, you know, information, especially as we're communicating with business people, I think it's good to be a little flexible. But as we talk specifically about these business capability models, again, another great thing is politics and complexity. In the use case I'm going to show head bowls, obviously. So this was a massive merger that we supported their data strategy for. It was a financial services insurance corporation based both in the UK and the US. And there was a merger acquisition depending on which side you were on. You looked at that, so that's the politics. But one of the main reasons for this merger from the CEO level, the new CEO, he said basically the combined information assets of both companies is one of our biggest strategic advantages. And if any of you are in financial insurance, you know that you've been data driven longer than most industries, right? It's all about the data, data on your customers, data about your products. So one of the first things we started with, because we were doing talk about, you know, shifting priorities and a lot of complexity. Not only were we doing a merger and acquisition of the companies and their organization and how those merged, but also the data and I guess the easy thing might have seemed to be, well, we'll just skip the org change and then just merge the systems and get that done because it's hard enough. But we took the opposite approach and said start with the business capabilities. And we really were able to talk to the very high level strategic teams as well because we were A, speaking their language and B, we were able to avert a lot of problems and eliminate some systems that could have been redundant and say it's not about John or Mary or Samantha. It's about we have accounting and we have sales and what are the core, you know, et cetera, et cetera. What are the core capabilities of these companies and stepping back from all of it? What sort of software and what sort of data is needed for these core capabilities? So even though this was one of the more complex organizations I've ever worked with, I have to say, when people think their system diagrams are complex and I'm sure they are. I mean, these had thousands, thousands of systems and when we talk about redundancy, we're talking, you know, dozens of implementations of a CRM system, you know, but in the same CRM system in a different way because there have been so many historic acquisitions and people hadn't done this before. So we were biting off a big chunk. And this is a perfect example of when and don't zoom out because we were able to really step back and say, okay, if we're just looking at customer relationship management, what's the data part of that and how can that be best managed? And it was really helpful in this particular case. So that is one great example, both the complexity and the politics of that were just sort of stripped aside by just going back to kind of core principle. And then when we did the data mapping, it was at that conceptual data level. Again, very, very high level product data, not the field of a particular, you know, data type and all that. Just very high level, which was helpful. So then if you think of, or if you think of capabilities as just as what they are, the capabilities, within each capability there are certain processes or things that happen. So within accounting, you know, there's billing, things like that. Very, very helpful, especially as I mentioned with MDM or master data management. This is really getting at the crux of how data is used. So this is an example. Again, you may have seen this is sort of a swim lane style process model, sort of loosely based on the BPMN notation. There are people familiar with that from the object management group, you know, business process modeling notation. Now this is an example of, you know, I was on the committee of the object management group to help finalize the BPMN notation. I get it. I know the notation, but I am the first person in the world, this thing that bugged me about the notation. And if I want, well, especially if you're going to present to a business user, I'll put a big stick figure of a person or an email or a picture of a spreadsheet to show where there's a manual process. You'll see here I've added a data layer, which the BPMN has, but I went a lot detailed. We're not only getting product, but we're getting, you know, the codes of that product, et cetera. Because the idea here is to tell a story. So tell a story. However, it makes sense. If this were a more complex diagram, you probably wouldn't have put all the detail here. Maybe you just have an overlay like we did with the capability model. We'll just say customer. But maybe in this case, we were looking very detailed for master data. We did want to get down to the attribute level. Isn't the database, isn't the spreadsheet? Does Mary type it in with her fingers or do we automate it? All of that can be really nice to show not only how the data is used, but the core insert dependencies and where it's shared. Which brings up my next most favorite artifact, which has the most awful name. CredMatrix. It's a terrible name. I got drunk or something else. Move the layers around in a different order. But again, so many of these things are so simple. It's sort of your shopping list of what you're going to buy at the grocery store. But you don't forget things when you write them down, right? So this idea, and again, I'm loose with these. It could be the, these are the business processes along the left. This is along the left. It could be the capabilities along the left or whatever. Where is this data used? So in this case, these are sort of the, you know, high level entity or attributes. And then who across is using it? Is it product development? Is it supply chains? The counting? Is it marketing? And the CRUD, where is this created? Where is it read? Where is it updated? And then where is it finally deleted if it ever is deleted? And again, the number of times a large organization, a very simple problem could have been avoided. How do we even look at this? And my friends and family get very annoyed with me because I bring this up all the time. We've all had that sort of thing. You get a credit card and you want to change your name and you can't go to the website to update your name because even though you sent your name, they don't have a field to change this particular, and did anyone really think of the business process around it? Or you changed your name online and then you get your bill and the bill still has your old name on it. And that drives you crazy because you've changed it. How come they don't know? Well, they don't know because there's 17 different systems and they're not talking to each other. And again, if had you done a kind of a business process or a customer journey and then said where is this data updated and deleted, you can save a lot of either customer experience issues. Also, again, master data management is so tricky because it has so many moving pieces and you can do your best to master the data in a certain system. But if you forget that downstream another system is going to overwrite that data and you haven't accounted for that, it can cause a lot of problems. Or deletion, if we're thinking of things like I have a cold and I can't think of the word. Retention rule, right? When is this data deleted? We're trying to be compliant with this sort of thing. Is it seven-year retention? Do we need to keep it forever? Should it be deleted? When is it deleted? Who did it delete? Is it effective we delete? All of these have a lot of implications so just keeping it very simple can be helpful. It's also nice to put this crud matrix and the process model together. Each of these swim landers or the people could be where across the process are things updated. When someone receives the order they might create it and do something different. It's also nice it could be some conflict when two people think they created the same thing and maybe that's true but maybe it's different. Do we need to have those people talk together and make sure they're doing it in a consistent way? Et cetera, et cetera. It's kind of a nice simple way to look at these things. Another use case that might be interested to you I've mentioned on other web I think I mentioned last month too but it does actually work a lot with some of these high-level architecture diagrams. This was a master data management process that we didn't know was a master data management process until we actually talked to all the business users, put together some of these workflows. It was a restaurant chain and they were trying to get a single view of their menus so they really couldn't make that menu experience consistent across the in-store experience, the online experience, the pricing experience, et cetera. So we talked to all the members and we actually did a process model. We did a BPMN diagram. We did cred matrices to see where this data was updated. Huge a-ha light bulb moments at a really high level and then from that we realized that we needed to master the data. We needed to have the right roles in place but once we started with this business view, data stewardship was really easy. Well, that's the person who is in that process that touches the data this person plays. The master data was made more easy because we knew what attributes were touched by where. So it's a holistic thing and whenever you start using words like holistic and bigger picture, that's where some of these enterprise architecture tools can come in. I don't want to get so up into the business level though that we forget about the tech because that is why we're all here and we love data, right? And data is that fun mix between the both. I think when you are looking at an enterprise data management or enterprise architecture, part of any data strategy or any enterprise strategy is really that idea of fit for purpose and this really comes back to the introduction by couch base of when you see kind of the growth and things like no-SQL databases, it isn't because relational databases are bad. Relational databases are great for what they do and this whole idea of asset transactions and consistency and et cetera that are have their fit for purpose. And I think where I see companies go wrong and maybe do go into the latest hype that everyone has a certain type of database, make sure that that's the use case that I know it seems so obvious but we can all get bought in by excitement or vendor pitches or whatever. What is your use case? Is it operational data? We're trying to make more efficient? Are we trying to store internet of things data? Or if we're trying to do basic historical reporting by week, by region, by sales rep, sounds like a right day to warehouse to me. Or are we trying to take the internet of things data and store it for analytics? Maybe that's the data length, et cetera, et cetera, which is different from your master data and then what is the metadata around that? So I know this is a very simple obvious comment but I often do these at most of the companies I work with just tell that story for each one of these. What is the fit for purpose? What is the story around it? And then start looking at your technology. Is it a graph database? Is it a combination of all of them? Even in the beginning, some of the reference customers, I'm sure, they have many other types of databases to augment the NoSQL, right? Because there's that fit for purpose. One of my favorite use cases that I've mentioned on this webinar is Facebook a few years ago now did the keynote at the TWI or the Data Warehouse Institute. So Facebook, which is leading edge on some of these new technologies at the end of the day, couldn't say how many customers they had logged in at once and part of it was, what do we mean by a customer? Does a customer have to be logged in? Does a customer need someone that owns an account? Does a customer, et cetera? And then when they wanted a customer by region, by sales, they had a warehouse, right? It doesn't mean that all these great NoSQL technologies they're using weren't valuable. They obviously were but they had to augment their toolkit and I think that's what a lot of this idea of enterprise architecture is is how do you augment your toolkit because I bet I can guarantee that all of us could learn one of these new technologies. If you are in the relational database world only, take a look at NoSQL. If you sort of started in the NoSQL world maybe go back to basics and just understand maybe where relational would kind of augment your toolkit, right? One of the ways to look at that and again this is super simple but when we're talking about system architecture, what is our big picture? Do we have a platform for kind of data analysis and discovery? We're just doing exploration. That might be a great data lake type technology but if I'm going to do something like master data or my finance and accounting data with my system of record, kind of where relational databases grew up right now, those are sort of still a very good option for that. And then across all of those when we think about enterprise architecture, what's the security and privacy enterprise-wide? What's governance enterprise-wide? How do I report, et cetera? So again, boxes and lines in the diagram we can all sort of joke. It's a PowerPoint where but starting there and just using that as context for everything you're doing is so valuable. So I highly recommend these and I often do sort of a current state. Where are we today? Just trying to get a sense of how all those systems fit together and then go ahead and do a future state. Where do I want to be? But you really need to do both. And one of the reasons to do that and really ties in nicely to kind of the sponsor here is this is from that exciting survey that I keep promising you that wait till September. It is out. We have pictures now. It does live. And this is a survey that we took of the respondents and thank you for anyone on this call who took it. What are you using today in terms of platforms? And you can see that this is a long list. And so still the leader in the market right now what people are using is on-prem relational databases. And this next one is what keeps me up at night and makes me want to cry. That's still spreadsheets is number two. We're improving. We're proving it's fine. There's nothing wrong with a spreadsheet. Again, spreadsheets have their place. I wouldn't say they're a great enterprise but they're anonymous. Again, ERP and CRM. I think a lot of great uses for that. Also a lot of misconceptions. The number of times we've come in later to add an MDM true master data system to someone who thought CRM was master data and had sort of the best intentions but the wrong technology. I could be a millionaire if I counted the number of times. Maybe not quite. And then this idea of relational cloud base. So yeah, relational still may be a great solution but everything does not need to be on prem. We think of some data exchange, things like JSON, XML. And really glad to see this one. For many, when we think of, it's so easy to think of the new technologies when we're thinking of future state but don't forget especially I know some of the financial institutions on the call probably still have some COBOL in mainframe that's out there and still working so we can knock it. I wouldn't say any new technology should probably be implemented on prem. If it's still around and still working you can't necessarily knock it so we can all be techies knobs but should kind of give that some thought too. Big data we mentioned and then you'll see here that this non-relational on prem database or even cloud, sorry, skip that one, they're there but as was mentioned in the beginning they're growing. There's still that sort of you know pension for relational which is changing to look at kind of the future state and where that things are headed. So you'll still see that relational kind is the main winner still in this particular survey and again this is diversity people so maybe that's self-selective or a certain demographic but you'll see that instead of being just mostly on prem databases there is a massive switch which was different from the previous one where on prem was higher cloud is definitely kind of ruling there. Things like package applications still exist but you'll still see the spreadsheets at least people are being honest right but you will see that now kind of this idea of non-relational you know cloud-based or you know your NoSQL databases are definitely moving up which I think is just showing the different options that people have graph database moves up I'm a big fan of those if you've heard me kind of rant about them and again even in the future people realize that things like legacy systems are going to stay right and I remember even when I graduated from university which feels like ages ago I had to learn some cobalt and I thought that was ancient then right so again sometimes when we're sharpening our skills toolset it might not be only the new stuff learn how to read a copy book right which I still probably could if I were held up at some point I could probably read one so anyways this kind of shows that again this is complex like you know this is fun and I like it but some days especially after a long one I sort of get overwhelmed and I think all of us again that zoom out that's where some of these system you know okay so we have all these options what do we do where do we go think of the why think of the capabilities what are we trying to support what are the business motivations and drivers and maybe do a simple heat map like this okay what are the basic use cases what are the main system components what are the fit for purpose what are the obvious but you know so many things I know I do a lot of dangerous hobbies like backcountry skiing and rock climbing and things like that and if you have done some of those things they are super set on simplicity you tie your rope before you rock climb and someone asks you have you tied the knot and you say yes I've tied the knot and thank you for telling me I've tied the knot and it seems ridiculous but when you think it was escape which is your life and people die each year by forgetting to tie the knot this is sort of the same idea what are we trying to do where is it going to do what's the best technology and just get really simple the more complex that's where enterprise architectures nice you step back and hyper simplify it and then go into the weeds right you know you still have to climb the rock but you gotta make sure your rope is tied before you even get there maybe a horrible analogy but I'll blame my cold so I do want to leave some time for questions which I'm historically bad for doing but especially since we have two speakers I do want to give so just in terms of that summary when we look at the toolkit of enterprise architecture it is a nice way between these series of models you don't have to use all of them I sort of recommend though using it most of them at a very high level even just or give it some thought in your head if you can do nothing more than that just think of what business capabilities you're supporting think of what business processes before we jump right into a platform or technology and again with a number of diversity of platforms that are an option from both the business level and then business needs but this is a nice way where these tools can kind of help you prioritize before we pass it over to questions just a little informational plug for next month if you are around in July and not on vacation or holiday we will be talking in detail about metadata management both from the techie side to the business side and we hope you can join that so I'm going to open up the floor now to Shannon to ask some questions Donna thank you so much for this great presentation and thank you again Thomas if you have questions for either Thomas or Donna please feel free to submit them in the bottom right hand corner of your screen in the Q&A section and just to answer the most commonly asked question I will be sending a follow up email by end of the day Monday with links to the slides links to the recording and any additional information requested throughout the presentation so Donna and Thomas I can take a shot at that I do think if anyone's not familiar with SWAT that's your basic high level strength weaknesses opportunities and threats that's also a great way to start I would put that almost more at the business strategy layer and I went a little light on that here I often do business motivation models business drivers and because I often talk about that so much in other webinars and there was so much to cover I went a little lightly but I would say the ability is often a business strategy level of this what are we doing what are our strengths in terms of technologies but also from the business and what are some threats so maybe the threat is we have everything on relational databases and only think of our sales process while our competitors are all doing internet of things enabled and we need to change but that's a better discussion than saying we need internet of things because it's going to support this use case hey that seems cool which has this place we all want to go play around with it but often that's more at the business level which is probably a step the first step let me while you're collating next question I think it was a slide early in the presentation where I sort of had this framework I would put your SWAT analysis sort of up here at the business planning view but I don't know if Thomas has any ideas welcome to those as well yeah I've got something to add there you're the expert Donna okay great and Donna going back to earlier as well when you were talking about the diagrams mentioned which belong in data architecture discipline organization and which belong in the enterprise architecture I guess some of that's a meta discussion I would say enterprise a piece of enterprise architecture if we look at either EA you know the Zachman framework a data component to each of those so if you look at Zachman all of them we talked about from the conceptual logical to physical when you get down to the bottom it's physical so I would say all of them I think I didn't show a physical model because I often think and it's my bias when I'm thinking enterprise architecture I'm thinking more broad yes you can also go detailed into all of these as well so I think if we think of the data architecture as a subset of the enterprise architecture and then just think of what level are we talking of the implementation view and where do you draw the line between EA and DA we draw the line around the section that's only DA if that makes sense I think again if we just think of it as a subset a kitchen is a room of a house and the stuff that happens the kitchen is still valuable but it's only one room in a house right so I you know I guess I could draw the line when we're maybe and again it really depends on what angle you are I guess if we're looking at Zachman I think he goes even if we're thinking of the planning layer you know maybe you could say that at this level down at the what platform we're using could be too detailed for the business planning level but yeah I think they're kind of complimentary and I I don't worry too much about that but I think one is the subset of the other and then some of them like the when you're starting doing the overlay like the crud matrix or the overlay and the capability that's probably where they touch right that's probably sort of where they you know the door from the kitchen to the living room gosh I'm full of bad analogies today you know I mean you're one room of the house but at some point you have to touch the other rooms in the house I love it and Thomas do please feel free to jump in at any time any of these questions they're open to you as well and so what modeling languages do you use I so each one of these can have I do a mix so if I'm doing data modeling I'm a big fan of doing the full conceptual logical physical maybe even a subject area or whatever you call that higher level enterprise level I like information engineering or IE or the crow's feet when we're talking about process modeling there's the BPMN notation I like because it's sort of swim lane that's one where I do get very high level I might just do a workflow or whatever there is when you look into EA they sort of have their segments so I think there's some overall frameworks that have their models and then each one of these could kind of have their own some people like UML I sort of like UML first of use case modeling because medium visual one has little stick figure pictures of people and I really don't care and I often do my own I have the Donna Donna's mood version and if anyone's work with me you'll see I'll just put pictures of stick figures of people and I'll put a truck if it's being shipped and you know I think that visual almost business review can be a very helpful way to start you know I choose my audience if it's a very engineering company that's using a certain notation I'll follow that because you don't want to seem foolish but I think sometimes indeed how do you plan quote-unquote plan for analytics data marks in lakes how I plan for analytics data marks in lakes is multifaceted so I would start and I'm kicking myself I had the business modeling slides in here and this layer and I took it out but go back to previously scheduled sessions and I think I've showed you things like these business models or the business motivation models and then I did show the business capability model so I do have so I think what I would so recommend is saying why the why first and so I would say you know what is the use case for analytics you know a data lake or a data warehouse and do you really need one and what's the use case for it and not everything goes in a lake and some of it goes in a warehouse and where I tend to start documenting that is more at this high level with the system architecture and again that simplicity and this is a good idea to have, you know start in a lake and we've got some you know storage and rationalization and standards and enterprise system of record and they work together and I think this also helps some of the politics because it's different facets and different using it you know your data scientist might just wanna be in the lake land and your master data people could be getting rightly nervous about what we're putting in the lake at a very high level. I think this is the great way to start. And then from there, once you've decided what this looks like, then you can think, okay, what's the technology I need for this lake? And what, you know, do I want my master data on Oracle or on, you know, graph database, et cetera, et cetera. But I think stepping out here is a high level view to even start the discussion. Thomas, you wanna add to that? Yeah, maybe just a quick word, you know, once you, in terms of planning ahead, from a technology perspective, there are a number of hybrid transactional or operational and analytical databases out there. These are technologies that can allow you to get ahead of the curve. Maybe you're not running analytical workloads today, but just be aware that there are technologies that will allow you to be able to handle multiple use cases in the future. Awesome. Yeah, I would agree with that. I sort of, sorry to interrupt you, but I sort of oversimplified as if it's an either or, and what's so hard with all of these, and even just beyond databases, but, you know, think of a master data management tool that has, you know, data quality in it, you know, a lot of those tools have it in. And so there's so much overlap. And as, you know, Thomas mentioned that, you know, maybe there's some asset capabilities in some of the NoSQL. So it does add to the confusion of things because it isn't as cut and dried as we put in this nice diagram. So again, if you go back to the functionality, it can help you answer why I'm looking for these technologies and then kind of do a realistic, you know, choice between these, I would agree with that. Sorry, I'm gonna go over it. I love it. Yeah, so is Enterprise Architecture or Data Architecture a group function or it should each business unit have their own? I think at the starting point, it's really helpful to have a group function. I think it's an and, not an or. So again, if you're thinking there's a, especially at the very high level, let's look at the entire, and again, obviously sizes of organization has a play, but I think even in the largest organization, you know, that insurance finance company was one of the largest, you know, one of the largest companies in the world and they started out with, because of that, started out with a very high enterprise level diagram and then each of their subsidiaries had their own and their subsidiaries were the size of a company, right, but even if it's a department, I think there's a value understanding at a very high level and then you can always have the individual then see where that maps, just to see where it fits in and sometimes there's differences, sometimes there's alignment, but at least you know and you're making those decisions wisely rather than just, you know, because you did it separately. So I have a bias to starting with the Enterprise View because I just think that it avoids a lot of redundancies and you can get some actually quick wins even though it seems harder, I think so that starting further out, you know, I'm gonna have more clarity and then at least getting the big picture and consistencies. You don't have two data warehouses that are doing the same thing, you know that kind of thing. That's my bias. You love it. Thomas, any viewpoint on how your customers are setting those functions up? Yeah, yeah, a lot, a majority of our customers are very large enterprises and typically there are enterprise architect or architectural boards that look across the entire organization and then we do see data architects that sit within groups representing kind of the functional or the business needs of that organization. A lot of it. So any strategy recommendation on moving from siloed vision to enterprise vision? Recreation from siloed vision to enterprise vision. Yeah, I think all these tools are helpful in that because it starts to show the crossover points. I think that the night, there's two sides of that is one showing that the facts and then there's the whole human emotion motivation piece. And I've talked on previous webinars about I think always starting with this business view and trying to align. It'll teach me to not include a slide. It's always a slide I didn't include, but I want to show. Starting with high level business motivations and trying to get commonality and why you're doing it because there's the could we merge a warehouse and maybe it's completely rational to do that but you're moving people's cheese, right? So finding a common motivation to get people to want to do it I think is the highest thing. We're trying to launch a rocket ship to Mars and to do that we need engineering and sales to work together so we can get the right revenue to get this done. Terrible analogy, I have a cold. But then that gives you the why if you want to want to do this. And too often if you start at the bottom and try to go up then you get kind of married and the political over that said, I think then you need to also look at some of these system integration diagrams and start to see where the silos overlap. So, you know, started with the why we need to merge these two departments because and then as we mentioned in that financial we started with the capabilities. Is there overlapping capabilities? If so, what systems overlap? And almost kind of hierarchically go down there what systems are overlapping and then also the high level whereas customer data stored is there overlap across there? Just probably a combination of several to try to get looking at things in different ways where kind of redundancies exist and the other part is just the data lineage and things like that. If I do change something, what's going to break? Because, you know, people are nervous for a reason why it shouldn't change things. So you want to be super careful that it might look good at a high level piece of paper isn't going to break once you get into the implementation level. Thomas, anything you want to add? Maybe just a kind of abstract notion on top of that the way that we've advised our customers and kind of how they use data management technologies for limiting between a system of record and a source of truth. And a lot of the work that we've been doing is to kind of recognize that relational databases typically are your system of record but people are looking for technologies that, you know, across a different silos where you have your system of record typically you need some sort of source of truth complete view, customer 360 view for example where you're drawing data across all these different silos and there are technologies that allow you to virtualize your data or bring them all together into one place. And so there's a technical solution to getting away from kind of a natural siloed view of how a business operates and set up the data models originally. Thank you so much. A lot of additional perspective there. And I think we have time for a couple more questions or at least one more. Now we've talked about data versus enterprise architecture but what about data versus information architecture? Yeah, I can touch on that. And then we can get Thomas's view. One of the things I wanted to clarify actually ties into that last comment. I think when we talk about these data silos it isn't just like because of, you know, the technology whether it's relational or it's, you know, graph or it's anything else. It's, I think where you look and I think if you step back and look at it more of an information level, you know, what are we trying to solve? I think that's where maybe the gaps were is that people maybe were so focused on the systems, right? And I think we over try to oversimplify things and maybe in the past of, you know, the classic what is it, I don't know, what do we mean by a customer? And that might be even at the information view. What do we mean by a customer? Is it a prospect customer? Is it a, you know, a loyalty customer? Is it a lapsed customer that we no longer call? And rather than spiral over that just sort of identify, so linking up to that canonical, you know, source but just allowing that these are linked in related terms and they are different and move on rather than kind of spin. I think information, man, if you start up it that way, you know, we also often think of databases but, you know, there's things in documents and there's things in files and there's things in, you know, videos that all relate to customer and prospects and things like that. So I think taking it up a level into information sort of gets into the business layer also goes to a broader set of sources. And I think sometimes we get in our own way about trying to be too pedantic about this stuff and, you know, allow for differences where they exist and then, you know, the different technologies have a different point where they should live and different definitions have a different reason. Different departments do look at things in a different way for a business reason and let that go and sort of embrace that. So that's kind of my thought on that. Thomas, anything to add in this last minute to that? Maybe just on that point around data architecture and information architecture, this is a broader perspective than, you know, as a sponsor, you know, certainly from my past I've seen how information architecture is, you know, driven off of much more synthesized data as Donna mentioned, I think they're sitting in documents. So enterprise content management systems are typically kind of, you know, in the space of enterprise information management and information architecture. I do believe is very different than your kind of fundamental data architecture at your database or data model level. Perfect. Well, thank you again to both of you for these great presentations and joining us in the Q&A today, but I'm afraid that is all we have time for and thanks to our attendees for being so engaged with everything that we do. Love all the questions coming in and all the engagement in the chat. Again, if you want to continue the conversation from the chat section, feel free to go to community.dativersity.net. And thanks again to Cache Race for sponsoring today's webinar. So I just want to say thanks everybody. Hope you all have a great day. Thanks Donna, thanks Thomas. Thank you, bye.