Hi, my name is Seh Lili. I work on Asia-Pacific policy, but also war game and crisis simulation design. And I'm here at USIP to support the design of a peace game. I think it's important to be able to examine foreign policy crises or natural disasters before they actually happen. So with the luxury of time, crisis simulations have a lot of utility in being able to take time to think through ideas or crises well before they happen. So you can in some ways suss out or consider what are some of the big thoughts or ideas that you would want to know about before you walk into the crisis or simulation. I think we know from having simulated a lot of political crises or humanitarian disaster response cases that in the moment organizations don't have time to revise or suddenly change policy. And so in a no-notice crisis or disaster, you would want to be able to at least have policies or personnel in place who are best represented to respond to those crises. Games or simulations give you a way or element to test those well before the crisis happens. So it's a piece of preparedness and I think that's the key utility of being able to leverage or use simulations, games to think through those. Ideally you have participants who in real life have some peace or role in responding to a crisis or a disaster. And so in designing games or simulations, your invitee list is an important piece of making sure that you have the right participants so they can actually provide novel or authentic information how they respond to the actions or how they respond to a crisis. In some cases it's also important to invite participants or players who might not be responding but they do have an organizational role in deciding how their organizations are staffed, who they've hired and how they might react or respond. So I think in disaster planning or disaster simulation, first responders themselves might have many rehearsals or repetitions but their senior managers or their organizational leaders who either buy political appointees or just through rotation and staff might only be in that role for one to two year at a time. A game without knowing whether or not there's going to be a real crisis in that two year window is a great way to introduce a new leader to a role. Whether they're responding or not so that we can think through whether or not they have the right people in place, are they funded at the right levels and do they have the right material assets to respond to a crisis. Whether that be natural disaster or man made political crises that might also have some sort of security or military attention. One way of exercise design is called synthetic design where you attempt to take a previous experience like a major economic world crisis in 2008, lift a lot of the details about what actually happened in that case, what was happening in global trading, what was the impact on poverty levels and then transplant them to a new time. You may make some adjustments about the countries they happen with or who's being affected but that's one way to design a more authentic game. Partly in case where actors or participants are sort of questioning the authenticity it's easy to point back and say hey these things really did happen. We're just moving the details forward but this is actually something that happened in the world and we can take some confidence in having participants and role players accept those new facts and react to them knowing that real policy makers had to actually contend with these issues. In particular simulations or crises especially those that are involving disaster response with tactical or very technical details for response. Role players or actors will try to simulate either wounds, injuries, perhaps simulate how actual first responders would be interacting whether that's over a phone call or in actual live situations. But all of those are different pieces that help make for a simulation or a crisis feel authentic and get better results from the players which ultimately leads to better data and ideally a better outcome when you're preparing for the next crisis or simulation.


And welcome, my name is Shannon Kemp and I'm the Chief Digital Manager of Data Diversity. We'd like to thank you for joining us to the latest in the monthly webinar series, Data Architecture Strategies with Donna Burbank. Today, Donna will discuss best practices in, excuse me, we'll discuss data architect versus data engineer versus data modeler and sponsor 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 by the Q&A section or if you'd like to tweet, we encourage you to share highlights of questions via Twitter using hashtag DA Strategies. And 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 right hand corner of your screen to activate that feature. And as always, we will send a follow-up email within two business days containing links to the slides and the recording of the session and additional information requested throughout the webinar. Now, let me turn it over to Rick from CouchBase for a word from our sponsor. Rick, hello and welcome. Oh, you're muted. Rick, you are muted when you're ready. Donna, can you hear me? Can you all hear me? I can hear you. Yes, but we cannot hear Rick. Yes. Okay. Rick, you got a mute button in the bottom middle when you're ready. We can see your slides. You want to put it in presentation mode? You are sharing. Okay, I'm going to unmute you, Rick. Thank you very much. Thanks a lot. Can you guys hear me? Yeah, now we can hear you. I was struggling to find that mute button. Sorry about that. Don't worry. I'm Rick Jacobs. And again, thanks for taking the time to meet with us today. I'm going to run through a few slides really quickly and then pass it over to Donna. All right. So, first of all, I'd like to take the opportunity to talk to you a little bit about the data modeler, data architect and data engineer personas and how coach-based can facilitate those people and how to help them do their job in a more effective manner. Quick disclaimer, I took the definitions that I'm using today from a article on dataversity.net. That article was entitled Data Architect versus Data Modeler versus Data Engineer. And it was written by Amber Lee Dennis. So a data modeler is basically a user that translates business rules into usable conceptual, logical, and physical models and does some database design. Data modelers tend to be interested in obviously data access. They want to have flexible schemers and they want to be able to design models easily. So coach-based enables data modelers by allowing access to data in S3 from within coach-based via a functionality we call remote-based. That means that you can have data outside of coach-based in a repository like S3 connect to that data and then query it as if it were within the coach-based cluster. We also support ingestion from multiple data sources, whether that be streaming sources like Kafka, viral Kafka connector, and also IoT devices using coach-based mobile. And modelers can query coach-based using a SQL-like syntax. So there's no need to learn a new proprietary language to query data within your cluster cluster. What's a data engineer? Data engineers specialize in big data solutions. So they generally work with data lakes, data platforms, and their warehouses in the cloud. And they tend to be data-centric and very cloud-oriented. How coach-based enables them. We provide them with tools that they need to access data quickly and easily, and then we have an intuitive database UI. And then we also allow data engineers to model those tools using BI tools by our variety of connectors that we have to the most popular BI tools. Data architect. As you can probably tell, these positions overlap. So these data-centric positions, personas overlap. An architect is basically a generalist. So they have similar concerns to the other data personas, but at a more comprehensive level. Architects want systems that are highly scalable, they want maximum performance, and they want to be able to integrate data from disparate sources while also minimizing costs. So to summarize quickly, coach-based is a top-performing no-SQL database because of our memory-first architecture. And we provide tools to easily ingest and query data within your coach-based clusters. We have support for all the major S languages via various SDKs. We have ODBC and JDBC drivers to allow you to connect the data within coach-based. And we have a UI that's very intuitive. And we allow you just to query that data within our clusters using SQL syntax. And we also provide all of this functionality in the cloud. Our cloud offering is a cloud-native DBAS offering. It gives customers the scalability of the cloud while also allowing them to keep data within their VPC, which is very important.  We manage that data, but you never really wish to go with your data. All right, thank you very much for your time and now I'll pass it back over to our host. Rick, thank you so much. And if you have questions for Rick or about Couchsates, please feel free to submit them in the Q&A section. He'll be joining us at the end of the presentation here today in the Q&A portion of the webinar. Now let me introduce to you the series speaker of the monthly series, Donna Burbank. Donna is a recognized industry expert 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 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 webinar presentation started. Donna, hello and welcome. Hello, thanks Shannon and thanks for everybody for joining this session. And thanks for Rick for a good introduction from Couchspace. So as many of you know, it was good to see some familiar names in the attendee list as always. This is a monthly series. And one of the most popular questions that Shannon is pretty good at answering is will this be recorded and will we get the recording in the slides? Yes, you will get both. So the good news about that, if any of these previous topics look interesting to you, anything about data quality or master data management, these are all on recording and available on the Data Diversity website for I think three turns each. So today we'll be talking about data architect and the engineer and data modeler and what those terms mean. And then next month we'll be talking about graphs database before we begin another lineup next year. So hopefully you can join that as well. But today's topic without further ado is on that tricky topic. It shouldn't be tricky, but it is for an industry whose one of their main goals is semantics and getting common meaning were really bad at that. What do we mean by a data architect and a data engineer and a data modeler? And I think if anyone knows me, you'll know I'm not shy and I'll probably even disagree with it with rich definitions. And that's not uncommon. Again, we all, it is unclear. There's definitely some overlap, I would agree with that. But there is confusion and there is ambiguity, but there's super important role as the organization becomes more data centric, we do need to get some consensus in the industry and there's a lot of confusion out there. So hopefully I don't add to the confusion and I can help with it or at least get some good discussion. I know you folks are not generally shy either. And there's always a really great robust chat going on as well. So please do continue with that tradition. This one is always interesting. We often do in the series sort of a career-based one or a roles-based one. More than any other this year, I had very proactive engagement from people reaching out to me even ahead of the webinar. Oh, I'm gonna miss it or I'd like to join it, can I get the recording? Yes, you can. I'd like to cover this. I have a lot of interest. And there were sort of two big buckets of people who were interested. Probably obviously those looking for work, anyone who's catching the recording in the future, this was recorded in mid COVID times, which is a difficult time for anyone right now, kind of in the career trajectory. Not so much for data. There's still a lot of opportunity out there. But that said, it's a very unusual time. So if you're one of those looking for work, how do I position my skills? How do I find that right role that fits my strengths? And what's that right opportunity for me to really grow? This should help you a little bit, maybe give some ideas. But I've also had several people reach out to me who are hiring right now, who are building their team right now or a CBO or a hiring director in HR. And they're looking for these roles and there's a lot of confusion of what type of person I get. And unfortunately, I also work with a, well, unfortunately and unfortunately, I do a lot of consulting, as Shannon mentioned. And either we help people with this confusion and say, if you were to hire, this is what an engineer does versus what an architect does. Unfortunately, there isn't always a good fit because there is confusion. And I've seen some really awkward first starts that end up kind of going separate ways at companies because there was a misunderstood expectation. So I think hopefully we in the industry can get a little clarity. Hopefully when either you're a hiring manager or you're one of those looking for work, maybe this will help you kind of get that clarity for what you're looking for. So we don't end up in a role that isn't a good fit because that doesn't help anybody. The other thing, as I mentioned, there is always a healthy chat in this conversation. And I'm sure on this call, there are people in both categories. So as they say, talk amongst yourselves. Maybe we'll connect some of these people that are both hiring and looking for work. That's not the purpose of this webinar, but you never know, you know probably, right? So hopefully both of these audiences can get something from this presentation. It is COVID times. It is unprecedented in terms of difficulty. That said, data is continually to be hot. We can always use things like buzzwords, like data, digital transformation. And we're going through it. It isn't a buzzword, 100% of my clients had to basically overnight switch from being in person to being digital. And that's not a theoretical thing. It's not a buzzword. It's how they do their business. And a lot of the folks that we had been working with did that very smoothly because they've had great data. The other great thing, I will talk a lot about this in the presentation. If you are the type of person who wants to have that seat at the table and a data-driven business. Again, you could say that's a buzzword, but it's real. So many companies, why the people on the previous slide are looking for help is data is hot, data is strategic, the data-driven business that generally do better ahead of their competition. So organizations, and why we get a lot of business is organizations are looking for someone to help navigate that. I might be the CEO of a retail company. I am super smart. I am very interested in growing my business. I know data is hot, and that's where it ends, right? It's sort of like me, I may wanna do an addition on my house.  I would be the first person you would not want to do to build your house and put at the foundation and put the electrical end in the plumbing and all of that sort of thing. I would be lost, right? Or my car, I know how to drive it. I know the basics of I need to change the oil and then that's about it, right? So if it breaks in the side of the road, I wanna bring it to an expert. And I'd love to have that expert explain things to me, not in a condescending way, but in a way that really makes it clear. And that is where I think a lot of C-level people or anyone in the business is really looking for that kind of data translator of this is what data means, this is how you can use it for opportunity. And that's why I think it's an exciting time to be in business and if you're that type of person that likes to wear two hats, you're in a great place. And there's a lot of people looking for that role. So yes, data is hot. And unless you've been looking under a rock somewhere, which maybe is not a bad idea in today's world, you've probably heard this famous Harvard business review article about the data scientists being the sexiest out of the 21st century.  Everybody has data quality issues. I think they had a typo there because it's really the data architect, which is the sexiest out of the 21st century. I am not biased at all. And I'm sorry several of you in the call will agree. So I say that a bit tongue-in-cheek, but not really because I think one of the reasons a data scientist is a popular role and not the littleing data scientist, but often that elusive or what do they call it? The unicorn type role that can be a great data scientist can understand analytics and understand statistics and then can translate at that into business opportunity. They're hard to find and that is why because it's very rare. Just a great breed of person that can be great at both be a great communicator and also be a great statistician and analytics person. Similarly with an architect, right? So we'll talk a lot more about that. I think a great architect and we'll compare that to engineers and modelers and all of that sort of also with a data modeler. You can speak the language of the business. You can speak technology as well. The guys. Yep. You can also speak technology as well. And that's really where a great data architect can shine and often data architects have a great sort of that advisory role in an organization. An analogy I'd like to give if you're familiar with Janice, the god of the New Year January was sort of named after Janice, a little trivia fact. Janice has two heads, one looking into the past year and one sort of looking into the future year. And that's how I sort of see a data architect is that a really good data architect can be talking to the business that I, like I said to myself one this morning, I was talking to a company out of all things. We were talking about the difference between, don't laugh, lard and butter and how that would be marketed differently in different markets. Switch to another call. We were talking about early childhood education. Switch to a different call. We were talking about construction company data, right? So I find that really fun because I think I am a sort of that Janice type of person that loves to understand the business. I really want to understand the business roles, despite it being five in the morning because it was a European client. I was sort of interested in what the difference between lard and butter was. And anyone who's a data model or data architect is probably subtyping that right now in their head. Is that a dairy product? Is there some type of, right? And that can be a very popular trait, right? Then you should be able to also turn to the technical team and say, wow, should we model that in a graph database? Should that be a relational structure? Should we do a dimensional schema so we can slice and dice it? Should we put that in the cloud? What would be the security implications, right? That is a really fun job, but that's also a hard job. And that I think is the difference between a data architect and some of the other roles we'll talk about. Not that it's better or worse, but it's more broad. And it is more broad. So you're not necessarily going to be a specialist in any of those platforms of how you can spin it up in the cloud and get the right performance in the cloud. Maybe, I mean, if you are absolutely a unicorn, it can be perfect and everything. But generally I do see that data architect as someone that can successfully speak the business, translate that business into technology. And there's a lot of organizations who really want that in an organization. So seeing a couple other roles being put up in the chat. Perfect way. There isn't a name.  But there's a lot of data-centric roles. We'll talk specifically about three, the architect engineer, modeler, there's some being put up in the chat. Again, that cobbler's children have no shoes. We are really bad at consistency and naming standards in an arcade discipline that does naming standards and state standards. So here's just a few. I kind of looked through my network on LinkedIn and said, what are some of the titles I have even seen? And you'll see that was just, it took me about six minutes. And that was just the beginning. So wide range from database administrator, data platform, misters, cloud data platform, and then some QC ones. Data guru, data whisperer. That's okay and everyone has a preference. They can differentiate that way. Personally, we're ISCEO. I'm not sure I would want to hire someone with a QC guru titled or maybe, if I'm going to hire an accountant, I generally probably wouldn't go and say, I'm going to go find my, I don't know, money whisperer. Maybe, I don't know. That's just my preference. But I do think kind of as a profession, we may want to start to be a little clear and standardizing on these definitions. Rick started in the beginning by looking at things like data diversity. Great. I think things like the Dama, data management, data management association and their data management body of knowledge, DMBock is also a great start. We are getting better, but it is confusing. So if you are one of those people in the beginning who's a hiring manager and says, I am really confused of what I need to build this platform or what I'm trying to do with my new data center, get us to view not alone. And there is a lot of people that call themselves an architect. That's probably the, I sort of showed my hand on what I consider an architect. We'll go more into that. That I think often wears the biggest confusion. Are you a builder? Are you an architect? Are you an engineer? Think of just in the English language and we'll go more into that. Those are very different meanings. But I think in data land, because data is sort of virtual and nebulous, we can get very creative. And I have seen some bad hires where it's just not a fit. Neither hire nor employee was a bad person. There was just a misunderstanding of what that person does because of that title. So hopefully we can get more commonality or we can at least, when we're hiring, say, I'm an architect, I'm the type of architect that draws architecture diagrams, right? Versus a platform engineer type thing. So using analogies, because we do a lot of that in data, the term architecture is not limited just to data. In fact, we often think of architecture in terms of building houses and we use this analogy all the time in data management. Partly because it is so concrete, we can kind of picture, we've all seen a house being built, we've all seen probably these architecture diagrams. I think that's very clear though, when I am talking about a building architect, it's pretty clear I expect someone to come up with kind of that roll of paper in their hands or nowadays kind of a CAD diagram or they're drawing pictures. And those pictures I can understand even that one you're looking at, you'll see the one on the left probably has a bathroom and some windows in it, right? You kind of get a high level. We generally don't confuse that one with a person on the right that's getting their hands dirty and pouring concrete or putting it in the infrastructure because it's so visceral. Generally not in a very difficult understanding, but we do kind of mix those things I think in data land. So to kind of go in with that analogy, again, I think there's a clearer, obviously there's overlap, clearer distinction in this building houses or building infrastructure between an architect and engineer or a builder, right? So if I'm an architect, again, comes in a suit, not a weird thing. He's got those famous architecture roll diagrams in his hands. He knows enough about the structure obviously because he couldn't build something that fell down, but he generally works with the owner, he draws the diagrams, he understands the requirements, are we building a nuclear power plant? Are we building a vacation home in Hampton? It's very different kind of architecture requirements and he would work with the owner to really understand that. The engineer, they're gonna be on site, probably in the heart of all the wearing hard hats because they're safety first, but he's probably gonna be on site. Is that building that the architect engineered structurally sound? Are the materials equipped to hold up the right weight for this particular piece of equipment? Things like that. More of an engineer in terms of that more classic sense. The builder, again, you probably don't mix him or her up with the architect. You know, they're exactly a little bit, I was swinging a hammer. I'm actually there in the field building things with my hands and those distinctions, again, are generally, there's overlap, I get it, but in general, it's a little more clear when you're actually building something like an infrastructure or a house, right? So unfortunately, when we get into the virtual world in which we live, you know, we can stare at type, but it's a little hard when someone just walks in. You don't have a hard hat on versus, you know, a suit and or architecture diagrams or a hammer or the electrical engineer and all your equipment. The distinctions aren't as obvious and we can sort of get away with a lot more. So the first architect actually, if you probably noticed the subtlety has the same definition of the building architecture. I work with the owner to understand their needs and diagrams and to match the requirements. And just like if I were the owner of the house, the engineer, the architect can show me that and I kind of get, okay, there's five rooms in that house. And a data architect can be able to show the business a data architecture diagram and they should be able to understand, okay, that's how you're classifying dairy products or my customers or my products or mine, whatever, right? And it should be a business-facing type deliverable. Again, when you're now engineering, just like you wanna make sure the platform of your building is dark sleep sound is not gonna fall down and is performing the way you want it to be. A data engineer is in that same category. I'm actually building the platform. I wanna make sure it's structurally sound. I wanna make sure it's performance and I wanna make sure it meets the requirements. When you're building, you're sort of building these applications so maybe I'm coding, maybe I'm generating day-to-day script but you're actually doing the building itself. You're probably not, you might be using the diagrams but you're not necessarily creating them. You're more of a coder or a builder. So to kind of use some data, the picture is worth 1,000 words as they say. Architecture versus construction when we're talking about data. So jumping back to this picture, pretty clear when you're building a house, what the difference between is architecture and construction, hard to mess up a piece of paper and cement, right? But in data land, it can be a little more vague. So on the left, probably a logical data model, that's something I would think a architect would build. This is the architecture that needs to build the business requirements. I can understand the big picture but I'm building enough to be able to build something with. One example, I know there's many, a building might be something like database designs, DDL or something on the right, right? I'm actually gonna be building the tables that meet those requirements. So I'm a retail company, I wanna be able to link buying patterns of my customers. The architect would find the right pattern to design that, put it in some sort of architecture diagram and then pass it over to the builder that can sort of build things as well, right? So that's one view of an architecture, right? To go somewhere that says is that a data model? Well, that's one of the topics we'll talk about. I think architecture is a little broader than just database design. So this doesn't just span, especially in today's day and age, you're not just talking with a relational database anymore. How does that whole solution architecture fit? How do these components and platforms fit together in a design? And that's an architecture. So do I need real-time streaming data? Do I need a traditional data warehouse? Do I need a data lake? Do I put it in the cloud? How do these fit together? How do I understand security and privacy? And the result of that is generally a diagram and that's a very important solution design or overall architecture design that then feeds into the database design and database build and all of that. But somebody needs to see how those pictures fit together. For some reason, I don't know why, there is in some camps a bit of disdain for that. Well, that's not architecture. That's just pictures. Oh, that's kind of what an architecture is, right? If you were the architect of house and you hired an architecture to help you design an addition and the person showed up with a hammer, you'd think that was a little strange. They went, I'm not ready to build it yet. I kind of wanted to sit down with you at the kitchen table and design how many windows we wanted. Oh yeah, whatever. We're just gonna start putting windows in and see what happened. You probably think that was very strange, but we can get away with that in database land. So sometimes that does happen. Oh, I'm architecting that you're building and to be really clear of architecture is design. It's stepping back, it's putting things on paper or CAD or data modeling tools or enterprise architecture tools and designing before building. This is kind of a fundamental principle. So can you sort of do both? Is there an all-in-one? Well, yes. And it depends on a lot of things, size and scope and complexity. And this is a similar analogy in building houses, right? There are certain design and build contractors either in massive construction sites. There's some that do both design and build. Or I did do an addition on my house and I found a contractor that was pretty good. He sort of did a high level design and he wasn't an architect, but he was able to sit in the kitchen with me and kind of design things on paper. Who wasn't as fancy as if I had hired the fancy architects, but it got the job done. And for small projects, that might be the same person. You might be wearing a lot of these hats in a small company in the data industry, but just like for a construction project. If I'm building a massive nuclear power plant, I would be really surprised if the same person who designed on paper that power plant was the same one putting in the turbines and setting up the electrical, right? There's fit for purpose tasks, the same as with the data world. So it is a continuum. Rick mentioned that as well in the beginning and that's where some of the confusion. And so I thought maybe kind of drawing out that continuum might have a little bit in there in the spectrum and there's overlap and all of that. So I kind of step back from just those three particular roles we talked to and just kind of said, were I to start a successful data program or initiative or I'm that CEO or chief data officer that wants to have that data driven company? So what would I need? Well, to start on the left, I'm kind of starting with the business centric on the left going to more of kind of platform on the right. So business to tech. So if I'm fully business person, I'm going to be setting that data centric vision. What does my company want to do? Do I want to be an online company and sell products online? Do I want to be brick and bolt mortar? Do I want to be a FinTech? Do I want to be a traditional insurance vendor? Whatever, that's the role of the CEO, right? And so as we go into, I started in the beginning, this idea of the business centric data person. Yes, and maybe the chief data officer is that at some point though, you don't own the business. Like it's not your decision of whether this is going to be a FinTech company. That is the CEO. So we all have to tread lightly. We might have ideas, but it's not our responsibility. And that's where I think some of the distinctions, where is the actual accountability? So the accountability for P&L and business model design, that's really probably going to be with your CEO. You might have CEOs and strategists, but I've been doing that a lot in my business. You might have an idea, but unless it's your responsibility, you don't really have the final say. So the CEO, his or her responsibility is the profit loss of the business. And if this doesn't work, they're held accountable. So you can have an idea. Wouldn't it be great if we sold data from our customers online? Well, they might nix that, right? So as we go kind of down the chain or up and down on how we want to say it, as we go into more of the business requirements, there's a lot of different roles that can contribute to that. This might be this elusive data architect that I do see as a broad role that can do business in tech.  Some people are more of a pure business analyst role. All I do is not that I'm belittling that. The limitation of that is I'm only looking at the business requirements. I'm not trying to architect it or design it. I'm just, in a sense, it is a whole practice of just really getting those business requirements. An enterprise architect, I think we did one earlier this year or was it last year? I'm losing my mind of enterprise architect versus data architect. There's some overlap there too. Something like a conceptual data model or a business process model, capability models. We do a lot of those in our practice. How can you truly understand your data until you understand the business capabilities that that data is supporting or the process that that data is supporting? That's kind of a design thinking type of thing. That's really where your conceptual data model may live at a really high level. Are we understanding the business requirements? So that's the business requirements and kind of that overlap with data. As we kind of go down to the data vision and landscape, that's really where that data architect may be solution architect. There's a lot of different words there, but that's really where that picture I showed of the kind of this more one on the left. What's the overall integration architecture of all the different systems and platforms from data late to data warehouse to data quality and all of that? Looking big picture around the data, you might be doing architecture, system architecture diagrams, data flow diagrams. Maybe you're looking into these new technologies, whether they're a fit in your organization. Pretty cool role, if you ask me, because you really get to do a bit of all looking at the business, but also looking at the tech. But at some point, like you can design a house all day long, at some point you want it built, that's really where you're getting into executing this data landscape. To me, that's where this data engineer sort of starts. We're starting to engineer and build it. Again, that could be you're considering a platform, you're integrating the data, you're making sure it's performant. A lot of roles there too could be ETL, it could be data integrator, it could be a lot of different depending on the scope of that. At some point, within, all right, let's just jump around a little bit. Within this architecture, maybe there is a, you'll see here's tiny master data or data warehouse or operational data. All of those need to be architected in their own way. There is an architecture within each one of those boxes of how you architect the data. I am seeing more and more of this making me nervous in this industry that people are missing that, like I could begin old lady rant here. When the word data warehouse is so incorrectly used, what do we mean? There's a data platform, yes, there's data on a thing, but is it a dimensional model? Are we trying to slice and dice data? Is it an operational data store? How that data is organized needs to be fit for purpose. I'm not saying one is better than the other, but that's when you're architecting and designing, you need to understand that. It's not enough to say, oh, it's in Azure, on the cloud or it's an Oracle, but what is it? How are you organizing that? That's where I see this. I'm calling it the database design or the data store business, because it's not only a database, it could be a graph or it could be a key value parent rate, but someone needs to design that. That I think is more of your data modeler or your data architect. Also, maybe a data engineer in the sense that it's this type of person that you're wearing several hats. I know as a small database, I can kind of build it, design it and build it. It's sort of an addition on a house and not a nuclear power plant, right? I can do kind of wear both hats. That could be the data models. It could be selecting what type of data store. Again, is it a relational database? Is it a graph? Is it a key value pair, et cetera, et cetera. It could be the glossary. It could be your semantic layer in your BI tool or whatever, but that's really, you're designing the data. I'll talk a little bit about different paths to data. The type of person I think that might be really good at that, might have been an English major or maybe a logic major or when you're getting into semantics, right? It's really kind of a theoretical because it's very practical, but really getting to the core concepts and logic inside how we store this data. And the right kind of person really loves that stuff, which is a very different kind of person that wants to get the platform up and running and being performant. Some people like all, but in terms of buckets. At some point when you've designed that database, you need to execute and build that, just that database. So I'm gonna create a database or whatever data store. I wanna make sure it's performant and build it. That might be your data engineer. It might be a DBA, right? And then that has to sit on some sort of infrastructure. So maybe it's in the cloud, maybe you're getting your own server and hardware and that's sometimes an infrastructure team. Maybe it's a whole different team. Who's getting the backup and recovery? Like where's the hardware or cloudware that it's sitting on? So that's a broad spectrum. I think probably some slight differences in there. I mean, we can argue all day, you know, of titles, but in general, there's someone from the very high business level. And at some point, this business strategy of I wanna be a data-driven company that sells books online, has to sit somewhere on a piece of hardware and make it work, right? And there's a lot of different teams across the organization that have to get that little disk on the server spinning and to do it in the right thing. In that it can be complex.  There's a lot of confusion there and a lot of complexity. So again, to do what was on the tin or whatever of this, what was promised, I do wanna go back to the three roles we talked about, which is data architect, data model and data engineer. And so how I see a data architect is, yes, there's some overlap with sort of a data modeler. That person should be able to design a database, understand their normal form versus dimensional star schema and what a graph database is, that kind of thing. Also though, look at that broader solution architecture of how do those platforms fit together, being able to do a system architecture diagram and be able to speak to the business and understand these higher level conceptual data models and how that fits with the business. You'll see there's a little overlap here with the business vision, again, not always, but if you are that type of person that wants to have the seat of the table or you are kind of working with the CDO to really do business strategy, that's great. And that is an opportunity and a lot of business people are looking for that. You don't own that though. And that's kind of where I show overlap, but not ultimately P&L responsibility. Unless it's your company and it's a startup and you're truly doing everything, but generally, and sometimes I have noticed more time in the business, you need to be a little careful. They may bristle, like, you're not telling me how to run my business, are you? Like, no, no, no, no, I'm understanding your business. And I'm suggesting we might have a really cool technology to help you. It's very different from going to the CEO going, say, you know, you're gonna move everything online. Maybe you're right, but tread carefully because that's really not your role. You're enabling not necessarily owning. So that's the data architect, which is broad. I think that's why it's a sexiest job of the 21st century. I'm gonna go talk to Harvard Business Review about that. Typo, so when we go into data modeler, I do think that is a little more narrow, a huge fan of data modeling if I didn't show my cards there. I think it's really valuable. Generally, yes, there's a database design or data store design of that aspect. And it could also extend to things like glossary and I kind of look at the chat half-heartedly because I don't multitask well. There's some comments about data management and sort of, yes, there's some overlap there. Things like a glossary may not truly be a data modeler task, but there is some overlap. And sometimes that overlap isn't here with things like a conceptual data model. I think a true data modeler could go up to that level from conceptual to logical, a little bit of physical. And then that physical kind of lives with more of that data engineer or DPA level, right? And so data engineer, again, could be broad. So I think typically it's more down to the infrastructure, right? But you should, again, you could be the type that really needs to understand that whole landscape. What platforms are we building? How do they fit together? Is it on the cloud? Is it a big data store? Is it a warehouse? Again, depending on the size and scope, you could sort of get into that design land a little bit. Again, back to this type of role that can design the house and build the house at the same time. You might be that kind of person. And so you might be designing some of the data models as well.  I'm building the data. I'm gonna build it, right? I'm the person with a hammer in my hand or the saw or the electrical wiring. I'm actually doing the work. So that kind of build the work. So building the database, performance and tuning. And you may, again, depending on the organization, sometimes there's a whole infrastructure team that sets that up. Sometimes you're setting up servers. You're doing the cloud platform. You're doing backup recovery. You're doing everything. So again, that's kind of the spectrum and hopefully where some of those land. So some of you, many of you, especially if I get folks that may reach out even ahead of the call, maybe looking for a job or maybe looking to switch. A lot of folks kind of ask me, how do I get in? And some of the comments, how do I even get into data architecture? Unfortunately, and it's just in the beginning of an old lady rant, but there isn't, there's a lot of education around data science or even programming, data management and it's changing. There are programs around data management, but it's not as common for someone to an undergrad say, hey, I'm going to do a degree in data architecture or data modeling, right? It's kind of a subset of something else. And then you get into the business world and you're like, wow, people need this and you scale up and you get there. So because a lot of people just in the past few months have asked me this question, it seems strange talking about myself, but people ask. So I thought I would just go my journey of how I got into data management and how I kind of evolved in different areas. And so those of you who are looking or we're looking to kind of switch into one of those roles and describe that isn't what you're currently doing or you're just new or you're trying to get into data management. A lot of people in data management, there was one data diversity conference, I think people asked, where'd you start? And it was like 30% who are music majors, right? Not what you'd think when I went to Berkeley School of Music in Boston and decided, oh, I'm going to be a database administrator. A friend of mine did just that. He was a jazz musician and now he's a database administrator, right? Because you could think, again, that logic, similar brain patterns, maybe not the most direct route, but he got here. Some people who I know do finance and they're so sick of the data being wrong if he can only fix it with data management. I've had people in chemistry kind of, there's a lot of different roles that can get you to data management. So I mentioned librarian, yes. They kind of think alike.  So way back in the day, before the beginning of time, I was an economics major. So I guess I could say I was the sexiest job of the 20th century back then. That's kind of, I did a lot of econometrics and that's data science in a way, right? I mean, not too far. I was also an English major and it's a bizarre combination for some. I went to liberal arts school and if you did, people loved to pass that major. I have almost come full circle. So I, on that topic, is it better to start with a broader liberal arts or go straight into engineering?  You learn how to think and you learn how to communicate. And then I was sort of always snarky when they asked me for money. I said, well, I could send you a sonnet poem, but I'm not making much right now. And that was sort of true. I guess compared to my colleagues that maybe graduated with a pure accounting degree or something, you didn't get there quite as fast. But now I've almost said I would rather hire, in some ways, a liberal arts major because you learn that critical thinking. I was, because of school I went to, it was just sort of for fun. It's sort of saying, tell me why a telephone and a polar bear, which is better than why? You just discuss with that sort of thing. And I think that does help. So during college, it sort of came my way. I did a lot of bizarro jobs from, I don't know, I did some manufacturing. I worked in a finance company. And looking back, some of those were the most valuable lessons because as I do consulting now, what's the first thing you need to do? You need to understand the business, right? Because I would consider myself one of these data architect types where first thing to do is understand the business. Well, I've actually worked in a shipping company impacting the boxes. So when they talk about pick and chip and all of that, you know what you're talking about. So if you are one of the younger people in the calls and you're doing a job that right now you feel is kind of weird, I know this sounds like exactly what your mom and dad tell you and Goss and I rolled my eyes to. It can really help. Working in a fast food chain, some of our customers are fast food chains. And the more you can understand and keep your eyes open, it can really be helpful. But after I graduated, I went back to BC and I was an economics nerd and worked at a think tank doing kind of economic model. Again, I guess that was data science for a think tank for the government. I though discovered, were I to continue that's kind of a PhD track to really grow in that and that was a lot of school. I kind of discovered we were also building data models and software applications to do that. And I said, this computer stuff is kind of neat. So I went back to computer science and kind of switched tracks. Really, really, really happy I did. I did my stint in programming. I found quickly though, I love programming. What I missed and didn't realize I was doing in the think tank was sort of data architect, business analyst consultant. We'd work with folks kind of gone in the White House and things like that. It was back in the day. It was kind of cool what I was doing. Didn't realize it because you're 20.  But really getting the requirements and then building systems to implement that. So I realized that for me, my kind of spectrum on that spectrum was I would rather work with the business and then do the programming side rather than only sit in the queue. I had an aunt who was a programmer when it first came out. And she was the lovely person. She said, I do not want to work with people. I want to get there early in the morning before people come, get my job done and I just want to do the math. Fine, that's also a valid that you're calling more on the data engineer side unless I'm a little bit of an architect, right? So I did, that's where I moved to consulting. For me, that was kind of a perfect fit for me. I love working with the customers. Also working with the data got the enviable position to kind of help start up a community of excellence. I guess I called it over in Europe, living in Italy and really kind of building their practice there, which was really great to kind of see the different cultures and really understand a global view. I came back to the U.S. and then went more into product management, which again, this is a kind of an odd, but actually building some of the tools I was using. So, and I'm doing this now if it was actually a feature I had put in and a tool I'm actually using now to client. One I was really happy about when I was kicking myself. So it was kind of neat to actually build some of these products, data modeling tools and data metadata tools and things like that and really get that aspect from the vendor side, which is a really different aspect. For some of you in the call, you might have think I joined the dark side and then I went into product marketing and really sort of how do you market and sell those products in some ways that was really valuable. How do you spend something? How do you take something and then communicate it really well, which did help my consulting. So now I realized though, my heart isn't actually doing the stuff. I like building it, I like building, but when I was building it, maybe I was a good product manager because I could always go back to how are we gonna use this? How's the business going to actually implement it? And to me, that's my sweet spot. Looking at a company, really understanding how it takes and then building some cool stuff. I did a sit in more of a management consulting company that again on that spectrum was truly up here when we were doing business model design, very little data, but it was super valuable. How do you model a business and really understand where it goes? Which then was my aha moment of not many people are putting both of those together, business design and data design and how can we kind of create data-centered companies. So that's where I started. I am the founder of Global Data Strategy and that's what we try to do here is kind of, I don't wanna make that a selfish, but we try to link that business with the tech. What's next? Who knows, right? I might just give up and be a ski instructor, but I don't ski well enough, but who knows? I guess for those of you who are starting that kind of age old, just try things because you're never gonna know. Isn't such a bad idea, because mine was very varied, but I did see some patterns as I was looking through. I like kind of working with the business and I like the tech. I wasn't really happy in only marketing because it wasn't techy enough. I wasn't really happy in only tech because it wasn't people enough. So you might be any of those on the spectrum, but so don't hesitate to kind of jump around. And there is especially in data management partly because there isn't as much of a set rules around things. You can do things like jump from finance or marketing or music to data as long as you do get those skills. So as you search, if you're one of those who's searching, some just look for your strengths and I feel like I'm being lecturing now because that's my dad used to always say to me and I'd roll my eyes. Still do, he said it just the other day.  But think about that. Some of you may have more time.  Do you like the, do you like learning tech? Really, where do you, are you a good communicator? Do you hate or any of these gaps? So what are your strengths but then expand your knowledge because you kind of have to be a purple person of that idea of being a little bit of both. Is there tech you haven't thought of? Are you so in the relational land you don't look at graph, right? Are there technical things you can expand? I do a lot of hiring and I have to say I love a good communicator but if they don't know Azure and I'm looking for Azure, they're out, right? So you can't just, there's a lot of good, the guy who packs my groceries is a really nice person, but I wouldn't hire, right? So it's not enough to be a good communicator. You do have to have that tech. I do not want to belittle that at all, right? And expand your network, obviously, right? People are very open now, I think more than ever because people are sort of locked away and looking to connect. Flatt-Lewington is my friend, I'm there a lot. The Data Management Professional Association, that is a global group of data people like you and the people we've introduced to that often say, oh, I found my people, I didn't know it existed. Look online, there's all over the globe, there's groups that meet in person when we can and a lot of them are doing virtual things. So you're gonna tend a lot. And of course, diversity and things like this. So I do want to open up for questions because we genuinely do. But just to summarize, great opportunity. It's a tough economy, but there is still almost more so opportunities for data because people are going digital. You do need a broad range of skills. No matter what end of the spectrum, you need a bit of everything.  And if you're an only tech coder that absolutely won't speak to people, you're not gonna do well as well. But there's a spectrum in between. But just be clear though, what you want to do, what your interest is in and what you actually want to do. Have fun with it. It's a great time to be looking at this stuff. There's a couple of things before we close. We do this for a living. So if you're looking for help, let's know. And I hope this isn't too bad. Shannon, but we are hiring. So many of those jobs are of interest to you and you are living your career. Check out our webpage. Next month is on graph. And now I will open up the Q&A. So Shannon, nobody? Are you in need, Shannon? Thank you, Donna. Yep, sorry, help me. Thank you for this great presentation. And just to answer the most commonly asked questions, just a reminder, I will send a follow-up email to all registrants by end of day Monday for this presentation. I'll link to the slides and the recording. So dive in here. And Rick, you're welcome to join as well in answering these questions. You know, this question came in even before we got started. And as I believe if we were to put in order, we should see data architect for the overall data collection steps and for gathering data modeler to do the design, logical and physical and data engineer to put the design in place and perform ingestion integration. Thoughts on that? I think that's fair. I think the only different, yeah, I would think an architect could be very broad. And then sometimes where there is a distinction, you know, that platform architecture, not just the sort of database architecture, but I think that's a fair summary with kind of the nuance we added to the coin. I don't know, Rick, do you feel any differently on that? No, I agree. That's definitely a fair characterization of their different personas. Yeah. Should a data architect be realistic, pessimistic or optimistic? Should they be biased in any way and force their opinions? Oh, gosh, those are two different questions. I'll ask the first and I do have, I have my own bias on that one and I've touched on other presentations a lot of that idea of the optimist, pessimist, or I think I've got a slide over this sort of, just a totally stereotype, kind of the grumpy DBA who tends to be just, you know, always sort of looking at the problems and being very negative and of the business person and the other expect from who tends to be more of the optimist. We're going to double sales this year. If you've ever, one of my best experiences that I never want to do again is going to sales kickoffs when I was in the vendor side and it is totally a raw, raw faster. How much are we going to sell? We're going to double it. And then you've got the DBA and the other who sort of paid to find pro, well, that's never going to work. And that's often where there's a disconnect because the business is psyched about the stuff and we tend to be the ones that their grumpy talent is not going to work.  But try to put on your positive hat because I think you're going to get more, we tend to just have that stereotype of being the more negative hat. So I would say realist to optimist and given that some of us tend to be on the realist to pessimist side, given that, again, we're trying to fix stuff could probably be a benefit. And then there was a second part of that question, Sharon, that I forgot already. Was there a second part? Is she going to be biased anyway and force their opinion? I don't think you should force your opinion. Again, well, it depends. If you own that decision, you can force it. And that was sort of why I stressed that is that ultimately the business is the, if it's a business suggestion, it's the business's decision, right? And that's where I worked for one company. We sort of had it was funny and I told you so bored. So at some point, you know, or it could bone both ways. I could have a business and I think guys, you should go and sell this dataset and they never do. You can always say I told you so, but that wasn't your scope. Similarly, you could tell the infrastructure team we need to go to the cloud and they didn't. I told you so. You know, the data model here in architect, that's yours. You can own that. And for the other ones, you only have influence. And I would say sometimes all of us human nature, we tend to step on people's toes. Just be clear when it's a suggestion and when you own it, right? Rick, anything you want to add? Yeah, I actually came from a sales background as well. So I do remember, you know, the sales rah-rah meetings and they're like, so I agree. The architect needs to be realistic, not necessarily pessimistic like the grumpy DBA example, but like the sales guys, you know, having shots after sales kickoff because, you know, that's not necessarily realistic. So again, the point is for the DBA to have some grasp of reality and use that in making decisions. Yeah. Yeah, don't do shots before you set up a server. Yeah. So is it easy for a data engineer to become a data scientist and vice versa? Oh, those seem opposite to me. So I would think the engineer is the type of person who wants to get their hands, well, again, almost stereotype, get their hands dirty and kind of build stuff. Often a data scientist comes in and I would think they want to do the kind of exploration. I want to find all these cool patterns in the data and do all my, you know, the models and things like that, my analytical models. And often those people don't last because they come in and the data isn't prepared enough to do that. So that's why data architects and engineers can be really popular because they can serve out the data for the scientist to do their magic.  Is your data ready for a data scientist? That can be disappointing on both sides. I've heard a lot of data scientists go, I was not hired to be a data cleanser or a data organizer. I need to analyze the data, not lunge it around. So the fact that their hands are on is similar, but I think those are kind of separate and you don't want to mix them up because they may not be. Maybe a data engineer might want to kind of take statistics and do modeling, but I have to get there, but I don't see them similar myself. But I'm not ready for that. No, I don't think they're similar. I think data engineers just spend a whole lot more time wrangling data than I just do. But having said that, some data scientists I have worked with in the past ended up doing a whole lot of data engineering too. But I would say that's probably somewhat of a waste of the data scientist time. There's probably more effective ways to use a data scientist than doing a data engineer's job, you know what I mean? I agree. In good days of programmers controlling the show, we have seen project managers as good programmers. So when data personnel have more to say to have more say to business, then can we see more PM from DS-Soming? I wanted the last part of that question. So when data personnel have more to say to business, then can we see more PM project managers from DS-Soming? I hope so. Yeah, there is this, I don't know why it happened. I guess we all have our theories, but there tends to be several camps in the industry if there's programmers and there's data people. I never saw that distinction because I was a programmer, I just saw the data, but maybe that's why I'm in data now. But they tend to be different camps. The programmers want to code stuff and they don't where they see data as kind of a second order thing where data people see the data as a first order thing. I think data people often have a better ear to the business because data is the business, right? They understand that you're talking about my customers and my products and things like that. So you can use that to your advantage. And I wouldn't, I do see those more recently, people are starting to get, maybe because I'm self-selecting my projects that tend to be data centered, but even as a development, you can have a data model at the beginning ever every sprint. You can say, you can even do your data models and sprints or you can say at the beginning every sprint, if you're adding a data element, does it compare to the data model and that's not what's the impact, right? You can still integrate data into programming techniques. And I do think that's an area that those silos need to come down because it doesn't make any sense to program stuff if the data isn't right. That's kind of cool. Yeah, I would ask that in no SQL environment, it's a little bit easier to do it to create your data warehouse and then do your steamers on read. So in that situation, programmers actually have quite a bit of control over what the schema looks because they're assigning the schema when they read your data. I love it. Well, thank you both so much for this. That is all the time we have for today. Thanks to our attendees who are so engaged in everything we do. It's been a very hot topic. I will get some of these questions over to you, Donna. It's been great. Just a reminder, I will send a follow-up email for this webinar by end of day Monday with links to the slides and links to the recording of this session. Thanks to CouchBase for sponsoring today and making all these webinars happen. Thanks, Donna. Thanks, Rick. Thanks, everybody. Thank you. Have a good day. Bye.


Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ Ṭ  ژRE Life isagtine, sini no rjay li prestoto ڐ interest is carrying on ڈRE Life isagtine ڈRE isagtine ڈRE Noodles &eni ڈRE Noodles &eni