recording in progress. Hello and welcome. My name is Shannon Kemp. I'm the Chief Digital Officer for Data Diversity. We want to thank you for joining the latest in the monthly webinar series, Data Architecture Strategies with Donna Burbank. Today, Donna will discuss improving data literacy around data architecture. Just a couple of points to get us started. Due to a 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 panel. Or if you'd like to tweet, we encourage you highlights our questions via Twitter using hashtag DA strategies. And if you'd like to chat with us or with each other, we certainly encourage you to do so. And just to note, the chat defaults to send to just the panelists, but you may absolutely change that to network with everyone. And to open the chat and the Q&A panels, you will find those icons in the bottom middle of your screen to enable those features. And as always, we will send a follow-up email within two business days containing links to the slides and recording of this session and any additional information requested throughout the webinar. Now, let me introduce to you our speaker for the series, Donna Burbank. Donna is a recognized industry expert in information management with over 20 years of experience helping organizations enrich their business opportunities through data and information. She currently is the managing director of Global Data Strategy Limited, where she assists organizations around the globe in driving value from their data. She has worked with dozens of Fortune 500 companies worldwide in Americas, Europe, Asia, and Africa, and speaks regularly at industry conferences. In fact, she'll be at our data governance and information quality conference here coming up in June. And with that, I will give the floor to Donna to get today's webinar started. Hello and welcome. Hello, Shannon. Always a pleasure to join you at these webinars. And thank you everyone on the call. Always nice to see some familiar names, which lead to familiar faces in the before times when we actually saw each other. But as Shannon said, hopefully some of you will be at DGIQ next month. And if this is your first time on this series or with Data Diversity, welcome and know that this is a series. So if any of the previous webinars look interesting to you, as Shannon mentioned, not only do you get the recording if you register for this webinar, but all of the previous recordings are out on the Data Vercity website, which is a great repository for all things data. And if any of the future webinars are of interest to you, please join us again. Often folks, again, seem to join us month after month with this is great. And next month's topic on BI and data analytics in the architecture behind that actually ties in some ways nicely to what we'll be talking about today, which is data literacy around data architecture. So let's without further ado, jump into that. What is data literacy? What will be what will we be covering today? So, you know, hearing more and more about data literacy, a lot of companies are including data literacy as part of their change management organizational change management campaigns, part of their data governance, part of their just data analytics. And I think a lot of that idea of, you know, the citizen data scientists or self service BI is really showing that need, you know, just in general, as more companies want to be data driven, we need to understand what data is. And so that's been a lot of the focus of how do we get the business up to speed on data. But I would also argue at the same time, technical roles need a strong data foundation, which we assume, but maybe should not. So I'll talk about that as well. So I'll jump into kind of my version of data literacy, which has an architecture focus. I guess, if you've joined me before, I tend to have my little data rants that I sometimes hold back and sometimes don't. No promises today. But I guess one of my mini rants is when there is talk of data literacy, it tends to be on the focus of analytics in BI and to people know how to read reports and create their own reports and things like that, which is super important and super, you know, a part of data literacy that is an aspect. But I think some of the core fundamentals of data quality, data architecture, data management, the good old Damon DM, people are familiar with that are equally important and really will help the reporting as well. So you can kill two birds with one stone. So the need for data literacy. So I've kind of pointed to this survey and a few other webinars as well. And again, this is also available on the Data Diversity site and Shannon's team usually sends this out as a link on the follow up. But some interesting stats that I think fit nicely, some data driven aspect of this that fits nicely with our topic today. So if you look at the survey results from last year, which is 2021, about 40%, so almost half of organizations, when they list of some of the issues they're facing, like collaborating between business IT as a major impediment to being sort of data driven, which to me ties into data literacy. What I find even more interesting and heartening because I'm a fan of data architecture is that over half of the respondents said that part of this collaboration was improved using a defined data architecture that might not jump to mind when folks say we need to be a data driven organization and have better analytics and how do we get business more involved in data is to jump to data architecture. But hopefully by the end of this webinar, you'll see that some of the tried and true tools that we use in data architecture are really nice way to communicate between business and IT and really set that foundation for data literacy. The other aspect, and I've talked about this in my webinars before of this kind of merging between business roles and technical roles, the business is becoming more technical, the tech folks continue to need to understand the business and not only in data, but especially in data, most companies have a skill shortage. It's hard to find really great people in data that have that fundamentals. I will hold back on one of my rants that I don't think they are teaching. There are exceptions. There's plenty of organizations that do have kind of information management degrees and focus on the data. I think though often that focuses on the data science and some of the data management fundamentals kind of move away with data science or application programming, which I'll talk about later, that should be all about data. It was when I learned it. I think that sort of exacerbates a little bit that skill shortage and things like folks like the diversity can fill some of that gap with their training. The DAMA group, there are plenty of ways to get those skills, which are becoming hotter and hotter. If you are looking for a career boost, that's a great way to do it. Data is very hot. On that note, 32%, which seemed low to me until you look at the fact that 36% already have self-service BI in place, but most organizations I work with are implementing self-service BI for several reasons. Firstly, it's generally because the business wants it. As I said, business gets the data. Business is data. The data is driven by the business. Now that the tools and technologies have come so far, it is a lot easier for business people to create their own dashboards, which is a great thing. It's also a risky thing without data literacy. Do we know what those reports mean when we do a join between two datasets? Is it accurate? What do we mean by accurate all of that? I think a lot of that is driven by demand and interest, which is great. A little bit from the skill shortage, too. I can't find folks to do it. I couldn't find someone to do a patio, so I did one myself. It's maybe not as good as a patio for a professional, but we got the patio done. A little bit of that as well. I found those to be some interesting stats. Again, if you're interested in more data stats, that survey is available for free on both the diversity side as well as the global data strategy. Hopefully, some nodding heads on the need for why. Of course, we're data people, so we like to define the what. What do we mean by the term data literacy? I've generally been a fan of Gartner's definitions. I tend to agree with them, and I'm stealing their definition again with attribution. Their deficit of data literacy is the ability to read, write, and communicate data in context. Love that. To me, data in context is metadata and all of the background and data architecture behind data, including, and they go beyond, which I like, it isn't just how do you read a report or how do you generate a report. An understanding of the data sources, the constructs, the analytical methods, the techniques applied, and the ability to describe the use case, applications, and value. Great. I think that's a really solid definition as all of that. We do not have time in the hour in this session to go into all of those. Where we'll be light in this webinar is things like the analytical methods. Would love to do a webinar just on that, but I chose on this to focus a little more on the architecture because I think so many people do focus on the analytical side of data literacy, which is great. I just think that's only a piece of the puzzle. So by design, I'm not including that in this webinar, and we'll focus on some of those others. And still, just a subset of so much about data. We can't cover it all, but we'll do a sampling. My version of that is really if everybody in the organization really should and does have some touch point with data, both business and IT, that if we routinely ask the question, what about the data? We're building an application, what about the data? What data should we use? How do we design the data? We're launching a marketing campaign. What about the data? We're launching a new product. We're building a dashboard, of course, et cetera, et cetera. I'll give some examples of that. But I think, having, to me, that's being data-centric, realizing that almost everything we're doing, we're doing business process, re-engineering, that's all about the data. So I think the more people tend to have a data lens, and again, a ramp I'm not going to do is that I think a lot of folks have an application development lens or even a reporting lens, which should be data, but often it's about the visualizations and kind of that front end. And only the really cool kids like us really think about that back end. What's the data model behind it? What's the data source behind that? But I found business people do get that. So to ask the question, when I'm looking at this report, where did it come from? How is it calculated? Is that a trusted data set, et cetera, et cetera, et cetera? So kind of asking, we'll have our friendly owl pop back in a few other times in this presentation. Hopefully he doesn't creep you out. I think it's kind of cool, but those eyes are, yeah. Okay. So what is data literacy? Again, so I just, to hone in on that point, often the focus of data literacy is on analytics and kind of that data driven decision making, which is super important, but that's often the front end. I also want to focus on operational data. Most applications we use are data-driven when we order something on Amazon, that's data-driven. When we hire an Uber, that's data-driven. And I've ruined most of my friends and family that when they have a customer support problem or bank error, I told them it was a data error and their data model was probably wrong. I think of that almost everything when I have a problem with an order or with a problem with my bank or even Uber being late, I often think, what about the data? So I think that's a health, it's not always the reason, but often it is. And I think having more people kind of think of that as data being the driver of some of these is only helpful. Master data to me is the underpinning of a lot of operational data and reporting data. We have a whole webinar on that earlier in the year. So again, I'm touching on a lot of things lightly, but we do have a problem ordering from Amazon or our favorite retailer and the product code is wrong. It's probably master data, right? Or they ship it to the wrong person. That's customer master data. And how do we solve that in the organization? Who owns that? Who maintains it? What's the data model for that? That's being data-driven. That's data literacy. I think the fact that people realize that it's a data problem, not necessarily a problem with the app or a problem even with the business process, maybe it is, but then it all relates to the data. Application development, again, critical portion of software development. I don't know why that is. I mean, I grew up in software development myself. To me, it was obvious that designing the data and the data sets are kind of that reusable component that stays behind beneath the applications. It seems like a lot of app devs don't seem to think with the data focus or they'll code things in the data that could be in a database or et cetera. I think having a data-driven application development lifecycle will also be super valuable so that there aren't separate camps where there's the data team and the app dev team. It should all be one team. It's all one business, right? And more, I mean, these are just a subset. I'm sure you can think of examples yourself and please feel free to do that in the chat as well. Anything that affects data or things we might even suspect or have a data, you should ask that question. What about the data? Remember, our little friendly owl? That's kind of maybe a fun way to think about it. So to go through some examples of that, having started with it's not all about the analytics. I will start with the analytics because that's or the reporting. That is accurately a big part of that. And of course, when you look at a report, I hope you're thinking, what about the data? Where did we come from? But I'm just assuming and recognizing some of the names on this call. Typically, there tends to be a high percentage of folks who are in data management of some sort, data management, metadata, reporting analytics. So I think a lot of us get that. But I think when we talk data literacy, part of that's having that when we talk data driven culture, I know that's a buzzword that maybe is overused. But are we even using dashboards and not to pick on sales? But often it is, we could come in and tell sales, we could tell you how to better target your customers and sell more widgets. They say, thanks, kiddo, but I've been doing this for 10 years. I think I know my customers. You can't tell me anything. I don't know. It could be right. We can learn from them. But can we get folks curious to see, can we understand revenue trends by year? Can we eat that maybe the basics to understand what's our total revenue by product? Are we thinking in a data driven way, if we look at that pie chart on the left, so many things. I could spend an entire webinar. Don't worry, I won't. An entire webinar on this one chart with all the questions we could ask in terms of data literacy. One might be, is a pie chart the best way to show this data? Maybe it is in this case. Maybe it isn't. That might be a good data driven data literacy, that data visualization. It could be data literacy of when we have widget one and widget two and super widget pack. What's in a widget pack? How do we define a widget pack? Are we double counting our widget ones and widget twos in our widget pack? And is that even an accurate bar chart? We don't know. It could be things when we say some of total revenue by region. What do we mean by region? We have EMEA, we have North America, South America. Is Mexico in Latin America? Is that South America? Is North America? How do we even mean, and then I see region NA up top, is NA North America? Is that not applied? NA not applicable? Again, should we have some metadata and data standards? There's so many, so many things here. Are the dollars there US dollars? Are they Australian dollars? A lot of info here that could be understood. But even the fact, are we using these dashboards? And generally, once a company becomes data driven, the problem is we have too many. But there are still organizations where people resist needing a dashboard like this or even having these dashboards in a meeting or back to kind of the Gartner definition when you're in a meeting asking where did that data come from? Are we using the trusted source? Is this your total revenue by year that looks really good? Does that match the company's revenue by year? Or are you kind of tweaking the numbers? Who doesn't want their own spreadsheet to kind of make the story sound good, right? But even better, this is sort of your basic table stakes here. And I'm not discounting it to get the basics of total revenue by year by product by region. We're still working with some of them in our consultancy, some of the biggest companies on the planet who still have trouble getting those numbers accurate, because it's hard even to get something as simple as total revenue by region, by product consistent across the globe, across the large organization. So not discounting that. But again, that should be the basics. And then how can we, again, be data driven and integrate advanced analytics into the predictive next best offer? Can the sales rep get AI driven or machine learning driven suggestions into their inbox of the best customers to target based on historical patterns and things like that? Is sales starting to ask that? Which again, I'm often on the back end side of this techie side, but work with a lot of business folks. And that's both a good and a bad, right? That the business is starting to read the articles and start to ask for things like, can we do this? Can we do predictive? And too often, unfortunately, we have to give them the bad news. Well, the data quality isn't good enough, love to be there too. But not always. Often there's stuff we could be doing that the business comes up with of, you know, I have this great idea for a new analytics use case to be more predictive, to be more data driven. That's what you want. And that to me, that's a data driven culture. You know, the flip side of the cousin of that or whatever, the way you get that data right is that data governance. How do we define total revenue? What countries are included in South America or Latin America? You know, data quality, that should be a question that anyone who's data literate should look at this and say, can I trust the numbers? Where did this data come from? What are those data sources? You know, is that master data? Is it someone's spreadsheet, et cetera? And then behind that is the data architecture. So what do we know? I look at a more like this, you know, is there a dimensional data model behind that? Is there a cube in Power BI? Is it, you know, from a warehouse? Is it from somebody's spreadsheets collaged together in Tableau? That is pretty important when you're looking at that. So knowing what the data architecture behind that is a super important part of data literacy. And we'll go into that, doesn't mean that the business needs to necessarily be designing data databases or data warehouses, but they should know what those are and that the question should be asked in terms of where does the data come from? So doesn't mean that everybody needs to know every piece of the puzzle in data literacy or data architecture literacy, but I think people should be aware that those puzzle pieces exist. Makes sense. At least asking those right questions. And it's both sides. I don't want to just focus on the business who needs to learn what we do, you know, we being the architects on the call. It's also data architecture needing to know what the business does. And a good data architect would be asking those questions proactively. What do we mean by revenue, total revenue? How do you calculate that? What's that metric? You know, is North America, is the approved abbreviation for North America NA? And which one do we show in the dashboard? You know, those kind of very basics, which isn't the exciting part of the dashboard, but makes the dashboard usable, right? So anyway, that's kind of your standard, you know, data driven literacy from the reporting side. I don't want to forget, though, that operational or kind of your application data. And again, I love to come home and rant about your data issues that I've encountered. And often it is on something like an order form. And do we even have an order form? Or is there some other data driven way to support that customer journey or patient journey or student or citizen or, you know, so many companies are really looking to be data driven. And is this the best way to order? Or could we assume from historical buying patterns that they always buy more light bulbs in May? And we can proactively put an order and suggest that they do that, right? Could we make an order form obsolete by being more data driven? You know, there's so many things we can think of being that data driven. To me, that's data literacy, people understanding what's possible, you know, realistic, and then coming up with more data driven ideas. But there's also that basic, you know, is how do we get the data in a form right? And gosh, we've been doing this for dozens of years. And I still, the one I love to share in the perpetrator will remain nameless, but I was registering for a data quality webinar. That's important part of the story. And when I put in my contact information for the state code, it was a US webinar. It was a free text field. I know that's not funny, probably to anybody, but not anyone outside of the data world. But a list of states, a list of the 50 states in the US should absolutely be a dropdown list. Where if I'm from Colorado, it's CO and there's no other choices. Because what's one of your classic quality issues? You know, is it CO? Is it Colorado? Did I mistype it and say CX, which is an invalid value? All of that. It's not the sexiest part of data management. But that has to be right. Because if I'm trying to say what are total sales by the states in the US, if I say CX instead of CO, they're not going to get my sales. Again, not exciting. But we all have to realize that that's a key part of data literacy. And then who owns that? Who owns the, you know, the, the, the dropdowns that are shown. But again, hopefully we get that kind of table stakes stuff right. Now that we have a dropdown, if you look at the list of products, we've looked at one, widget two, widget two, spelled wrong. Is that a new product with two G's that's called the widget? Or did someone spell that wrong? And you know, how do we know what product can get the right price? Again, I don't want to belittle that because, you know, a large part of my business is helping companies get that right. And it's, it is complicated to get the basics right. But once you do get the basics, right, the up sign is so valuable. Can we do predictive analytics, you know, customers who bought widget one also bought thingy X. Now you might like the X as well. So, you know, there's so many pieces that you could be much more exciting than just a standard form. But part of the form, who owns the customer onboarding? Does a customer fill this in? Does the sales rep fill this in for them? If so, do they know all the information? Et cetera, et cetera. That's a big part of data governance and getting data, getting data right. And to me, that's data literacy. Where do we source the product master data? Or is that widget information right? Is the person building this form who might be an application developer even know that there's a product master that they could pull from for that drop down? Now that's a, again, part of literature, just that communication. The other part of data literacy, I think is data governance, data privacy. Do you want to be included in our mailing list? You know, do we know the regulations from our country and other countries who we're working with? And are we going to every application developer, every database developer, anyone building reports or anything with customer should be very aware of that. That's not just a business thing. The IT needs to understand that as well. And again, if we're paying attention, there's huge companies in the news practically daily who have kind of had breaches like this. And it did not think of how we should be using the customer data that we have. But what about the data? How should we be using that? So, you know, the other thing is data architecture. What's the data model behind this application?  Is that my shipping address? Is that my billing address? Something as simple as a customer can have more than one address. Again, these sound really boring, but we're working with three companies right now. One of their biggest issues is, you know, getting that proper address. Is it shipping? Is it billing? Is it for the right contact? And getting that right at the get go. This could not be right because I know in my house I have a different shipping and billing address. So, by design, we're building in poor data quality into the form. So, to me, that's data literacy. Did anyone think through that as we're building that form of how that's going to affect basically customer master data? And is that in the DNA of the business that whenever customer master data is being entered, reviewed, et cetera. We have that in place. So, hopefully those are two helpful examples from both your standard analytics is also kind of your more operational form-based information. So, moving on. I do want to stress that, and I have that data literacy is both on the business side and the IT side. And I think it's a little different for both. And I would posit that data architecture can really improve and be a good tool for that communication. If you remember those analytics in the beginning, the metrics, over 50% of companies using data architecture found that it really helped with collaboration. So, you know, for the business, what are some, and this isn't everything of course, areas of data literacy? And how do we define a measure? What's a proper way to define a good business rule or calculation rule around total sales or, you know, total profit margin? And often folks kind of have that. Do we know how to, you know, but do we know how to do that across across areas? Yeah, keep a part of governance. How do we get the right business around data quality? If we're looking at data quality, how do we quantify that this data is right and what does good look like and what is fit for purpose and what is fit for purpose the same for all types of data? That might sound technical, but that's something that should be in the DNA of the business. You know, this is my customer data.  These are the valid values, et cetera, et cetera. Governance, privacy, accountability. Again, you don't want to be the ones in the news. And then that should be top of mind for any business person. You know, data sharing agreements. If we have data, you know, data monetization comes up a lot. What are we allowed to share? But even to sharing across industries, are we going to have open data? Are we going to publish that? Do we have partners we want to share data with? And there's several sides. There's the legal aspect of what we want to share, the privacy aspect, and also just the data format. What are we going to do? Do we have a common data model? Are we going to create a consortium to create a data model? A lot around that is happening more and more.  There's so many that I could list. Again, that's both a blessing and a curse when the business comes to IT and says, you know, I read an article on, you know, self-driving cars. Can we do that for here? You know, it was a bad example. But I think knowing what's out there, but also knowing what's realistic for the data at hand within the organization helps the conversation both ways. Because the business, maybe IT will push back on me, but the business often and should have better ideas on how to optimize the business with data because they're doing the business, right? They may not know how to implement it, but giving them the right tools to be able to think correctly about what the art of the possible can definitely help. Basic BI skills for self-service. Again, blessing and a curse, but A, when it's a good idea to create your own report, when is a better idea to use one that's out there. But if we are creating our own reports, you know, how to do that and what are some of those basic reporting skills to do that, et cetera, et cetera, et cetera. But those are some of the common ones or maybe not so common ones that aren't typically mentioned with data literacy. On the IT side, you know, I sound old here, but the good old relational algebra, good old data modeling, you know, SQL, those are so fundamental. They're not old fashioned, they're fundamental. So I think understanding how to do it, internet or join and things like that should be a basic part of anyone doing, you know, reporting, anyone doing application development really need to understand some of those, you know, basic statistics, basic data science, you know, again, role dependent. If you're not doing any of that, you don't necessarily need to know. But I think having just as a citizen of basic knowledge of statistics and how information is used in the news and things is not a bad idea. I think in my university, there was a statistics for citizens course at the time. I sort of laughed at that, that that was sort of an easy fluff course. But older I get, I think that was probably wise that everybody has statistics for citizens. Even as something as core as a database, and again, there's so many technologies out there, but what is a database? Actually, I had an argument with a colleague the other day about it was JSON database, probably get some comments on that one. You know, but you know, not everything is a relational database, right? But do we know those basics and when do you use each one? Or even the fact that you should use a database and not necessarily embed certain things in code? Again, kind of bridging that gap of application development and database development, they shouldn't be separate things, they should be related. How do we generate APIs, data sharing, how that relates to existing and future databases, as well as that basic data privacy regulation, anyone doing active should at least know what PCI related to your industry, HIPAA, FERPA, etc, etc. And then how can data architecture bridge that gap? Some of these are architecture, some of these are maybe just more data management, but you know data tools that can help. Business glossary is a huge one. How do we define some of these measures? Yes, that ties into data dictionary and data catalog, etc. But just as an example, business-centric data models will continue to be a fan of these. It's a data model, not at the physical level, but at that business level and get some of that core business logic in a way that data folks can really create some of these rules that help with data quality, help with understanding it, etc, etc. The good old bus matrix for business intelligence, again, don't see these used as much as I would like to. I know, again, the business often likes them. I had sort of stopped using myself in full disclosure. Six years ago, I was a big insurance company, we were doing a huge data integration across some mergers and acquisitions. It was odd enough that I remembered it. One of the senior executives walks in, he knew it was the data workshop, and he said, bus matrix, bus matrix, that's all I want to see. It's the easiest tool for normal people like me to understand. There's no budgetary bus matrix. I'm not being in this meeting. It was very odd that he was that passionate about a bus matrix. So I think it's stuck in my head. But I think I agree with him after all these years. It's a really nice way to kind of get to the core of, you know, whatever we're reporting on, what's our measures and how are we slicing and dicing that with some of the core conformed dimensions? And that doesn't make sense to you. We'll show one later. Again, handy old-fashioned tool. Another handy old-fashioned tool, something like crud matrix. If you think back to the Gartner definition of kind of knowing how data is sourced, how it's integrated, crud matrix, terrible name for a super helpful tool, shows where data is created, read, updated, and deleted. When you're talking about data usage and where data problems might occur, great way to show that. I would say, you know, when we talk about things like user stories, if you're using agile or customer journey maps or et cetera, et cetera, is there a data-centric view of that? You know, as a user, I would like a consistent view of regions so I can do reporting across regions. You know, is that something in your user stories? Or, you know, as a user, I want to have a predictive way to suggest products when I buy one, et cetera. Data quality dashboards. We talked a lot about dashboards in terms of analytics for the business, but are there dashboards for data? And is that part of the companies? To me, that's a pinnacle. Data is a business asset. We're tracking the other assets, products, customers, employees, right? So I think that does show some data literacy when you have dashboards on data itself. So hopefully that's some examples. Of course, it's not everything, you know, data literacy could be a whole series here at the University, so just giving some ideas in this webinar. So again, when we look at the different roles that may be involved in data literacy, I want to talk a little bit about that. So often companies really take on data literacy more and more and more as data becomes, you know, top order companies becoming data driven. Often there's kind of a gamification aspect of that little, you know, I don't say little, but badges or certifications are making it kind of fun. You know, if I take some, you know, basic how to read a report and how to, you know, calculate, you know, metrics and things, maybe I'm a data citizen. If I understand data quality, you know, there's a certain catalog of kind of your average person in the organization understands how data affects their job. Maybe that's the data citizen. You know, maybe when I become an expert, I can do self-service BI or maybe I want to create, you know, there's certain levels and kind of a lot of companies have a lot of fun with this and they're really successful because people see it as a fun part of their job.  You know, maybe with a certain level of skills, you can get access to a cube and start creating and slicing, dicing your own reports. That does take a lot of some certain amount of skill and some training of how to do that, but who gets access to the backend databases. I want to now create a mark from that and that's probably a different set of skills. So it can be fun. It can be a great way to build kind of excitement in a data-driven culture and have courses and videos and badges and things like that, but there's also a bit of governance around that. You know, you can't touch the database until you have the right skills, right? So a little bit of both. I also want to stress, to me, I don't know, I don't know if folks agree or disagree, put it in the chat. Data governance really is a form of data literacy.  So again, maybe some of these data literacy is focused more in the reporting aspect, but your data governance really is those roles that help get the data right and consistent going forward. But also across tech roles, we should have kind of these data-centric data literacy areas. So, you know, I don't think I have to explain too much that if you're a data architect or a data modeler, a data engineer, BI report developer, et cetera, data scientist, et cetera, et cetera, you should know about data, so that's kind of self-evident. But I feel very strongly there are application development roles should have strong data foundation basics, whether you're a data versus Chrome master, et cetera, really understand kind of those data. The basics of data management, relational database theory, you know, what's the difference between a graph database and a, you know, relational database and when to use which, and when to use a database and when not to, would be really helpful. But of course, there's other related roles that have an impact on data privacy and security infrastructure, et cetera, you know, are more kind of, you know, foundational that they'll have a piece of that.  There's some really good certifications out there. And again, all of these are just a subset, but something to look into. And I'm seeing that more and more. I have clients that, you know, they won't look for someone that doesn't have CDMP and that was not true even five years ago. Right. So I think that's a positive thing for data literacy overall. So kind of talk a little bit about the need for who needs to look at data things and data architecture and how that might help. I thought it might be helpful to show some of the tools of the trade. Again, just a subset. Again, this could be a whole week workshop on some of these tools or several webinars. And there are several webinars on each of these in some cases. So again, just some thoughts that hopefully give you some ideas that maybe you hadn't had in your toolkit, so to speak, before the webinar. So good old bus matrix is that that guy in the insurance agency was so passionate about it. I'll start with that one. But we use these a lot. So and because a big part of data literacy is reporting and analytics, just a simple bus matrix.  And then you have all of the things you want to report on kind of down the left. And all the other things you want to conform report by I want to I want to know bookings by customer by product by vendor by channel by location by etc. etc. Those how you slice this ties in with so many other things.  These may be your master and reference data right customer. It's probably your master data vendor product location may be master or reference data, etc. etc. So this is a really helpful way to kind of look at that as a good starting point to a lot of other areas. Data model if you've heard me speak before you knew this was coming. But data models are really helpful both at the technical level as well as the business level. I'm going to talk a little more about business level because I think we got data literacy is a lot of a big part of that is that communication between business and it. But as I mentioned, I think as I mentioned, I think another big part of data models is literacy of app dev that there should be a data model with each application and with each database. So the other thing I like about data models is that they're graphical and I say I'm a visual person, but I think everybody is you know, if you go back and the caveman days they had pictures of things that were interesting to them right the animals they ate and things like that. We just I think as people see a picture of something to help it click. And as I mentioned, there's several layers of data models and I think part of data literacy is knowing when to use which. So if we're talking to the business, it really should be at that conceptual data model level or the logical data model level or even up at the enterprise which might be just high level subject areas or domains or however you want to use that term a lot of different words for that. But these are really you're trying to get the business concepts and the business terms, which is very, very different from the physical data model. And one of the reasons this is a pyramid is up at the top when we're talking conceptual, I don't care how complicated your business is, it should fit on a page and it's maybe 12 entities or so it should really and it's simple. And that means you did a lot of work to make it simple that I can look at that and say, you know, I can look at it and see customer and product and location or patient and diagnosis and and really know what your business is and how it works on some core aspects of that just from looking at that one model. So it should be simple. I've broken that rule myself depending on on the audience. Sometimes your conceptual becomes a little more logical as folks want to get to that level of detail. But both of those, you know, logical is going to get a little more of your attributes and your business rules in the more detail. But there's more entities, there's going to be just more volume. And when you get to the physical, maybe there's thousands or hundreds of tables, because you need them for a certain reason, that's probably not something I would show to the business, or you should not in your subject areas, maybe that's six, maybe that's a really simple model. So again, it gets more complicated as you get to the physical. The other thing, and I will argue to the deaf on this one, I often hear is all business people won't understand a data model. Oh, not true. It may be how you're showing that data model. I've had a really good experience of also misstep, you really need to know your audience. So we all, any data modeler is one of those geeks and I use geek lovingly. Let me show you my data model and I want to show you all the detail and some people care, many people do not. So how do you just get that right level of detail that makes sense to the business? But I have and do and all the time get very positive feedback on data models because it's a way to quickly show business rules. I think you need five, 10 minutes tops to explain how to read a data model. So don't use words like cardinality. That's the most basic concept is how many things. So what do we do when we're kids? We hold up fingers. If you're using kind of IE notation at the bottom, customer, a department contains more than one employee or zero one or more. I'm using my fingers. You can't say one kind of looks like a one, zero kind of looks like a zero and the little things that look like fingers saying more than one is funny enough, more than one. And so you can explain that boxes are the nouns and lines are the verbs and generally within five to 10 minutes people get it from the business. They might say, what was that notation again? Or what's this? But they pretty much get it because of their data. And then very quickly they can say, wait, a department could never have zero employees in it. That doesn't make any sense. And wait, an employee can be more than in more than one department here. So that thingy on the left is wrong. They might not know what thingy is called or whatever, but they can very quickly tell you that employee can be in more than one department, which is a really, really important business role and part of data literacy. So when we're talking about that, and that just happened to me, which is probably why my voice is getting all raised because I can relate to them again when I have these problems, their data problems. I was a consultant and I had to, I was also doing product development at one of my previous jobs and had to go into business trip. And on the expense form, it was what department are you in? But part of my business trip was to go to one department, which was engineering and software development. And the other part of the trip was for consulting and the sales, I mean, the travel system wouldn't let me do it because in their business role, their data model said an employee can be in one department, but the business role was the employee can be in more than one department. So I could not correctly submit my expense form. I did, I got my expenses paid, but when they're trying to say how much did we spend on travel by department, their dashboard is wrong, right? So you may not have looked at this thing at the bottom that said department people and thought of, hmm, my travel and expense system is going to be wrong or my reporting by department spend is going to be wrong. But it was all came down to a data model. So the more you can get it simple and get those business roles out of business people, the better. And you can do it fairly quickly with really, actually, I'm visiting family in Boston this week. And I asked my elderly parents, I did, I took them two minutes, maybe they're smart. I said, if I explain this to you, you get what that means. You're like, yeah, department can contain more than one employee. Like, thank you, got it, because I'm doing a webinar today. So generally across the board, people do understand that. So just keep it simple. So having said that, avoid the death by data modeling. And I've been in these, I've seen these, I've seen the remnants of these, and maybe in the day in the 90s or whatever folks got away with this, but I don't know how, where you go into the war room, they'd call it in and there'd be a kind of enterprise logical model across all four walls with thousands of entities. And they would bring the business in and say, you know, I know you're super busy trying to core close end of quarter sales, but could we just sit in the room for a few days and, you know, just start with a, with a data type for account code, you know, sorry, even I would want to die after that. So can you get that information, maybe in a smaller session just saying, Hey, can we just do a workshop for an hour, half hour? And can you tell me, you know, is there a department code in your departments or whatever? And just keep it small, keep it simple, and keep it really targeted on outcome. And that's when I get, you know, I've had business people push me out of the way to start whiteboarding and want to draw the models themselves. We've had, you know, healthy arguments, we've had, you know, folks, folks go into data architecture after these, because they really, you know, really see how these can be helpful. So I generally say I've done right. People, people get it. Another thing, and I'll probably get some comments or either hate mail or love mail after this, but I'm going to go say it. Avoid technical database terms that we had two projects recently where we had some arguments on this one. Use at a business level, which is your conceptual or even logical, I would say, but definitely at the conceptual, I'll stick there. Use the business language. It's a customer. So what don't do, and I had a, we were in a workshop and DBA argued with me, it's not a customer, it's DBO7 on the Syrup Cust. Now it's a customer, we're having a business workshop, but she couldn't get past that fact that the table she looked at was called DBO7 on the Syrup Cust or whatever it was, and she would have lost everybody. I'm not sure why she couldn't see that that was representing a customer, but she couldn't make that jump. The one I see a lot, and maybe you could argue with me there if the business kind of understands and likes that idea of dimensions and facts, something like DIMCust. Really, can you just call it customer? I mean, I don't know. To me, I would prefer to just say, you know, at the semantic layer, the business layer, just call it customer. Or, and I'll probably, because people are going to jump out of the screen and hit me. I am not a fan. I'm saying it. I'm not a fan of the party model or even entity model for several reasons. I think, again, you can overly, it may be true. I've had party-like models, but you should get there by saying, well, we have customers and we have vendors and we have employees and we have, I don't know, subcontractors. They all seem like a similar thing, are they? Because sometimes they're not. I mean, you could over type things. I guess what is just so generic, you could just say, you know, human being, and yes, there's human beings, but there's employees and there's customer contacts and there's patients and they're all just very, very different things. You know, it's over, you can overdo it and just say everything the thing and things have thing types and thing attributes and you might be right, but that would be an extreme. So, yes, there's benefits at the physical layer, even logical layer of kind of genericizing some things, but I think definitely the business level to suss out whether that's correct or to suss out business process issues when we're thinking of master data, right? These, a lot of these parties become master data. So what is a party? What is a legal entity? Is it a partner? Is it a, you know, is it a, I don't know, I can't think of my words today. Subsidiary, you know, is it us? We're a legal entity. So really think that through. Again, it may turn in that at the physical level, but I've seen more mistakes with jumping to the party model because it's easy to model and hey, we've got a table where everything can fit in, then going a little more detailed and really saying, is there a different process? So yes, they're both legal entities, but is there a business, different business process to onboard customers versus vendors versus suppliers? Is there a difference between a supplier and a vendor? I mean, that's the type of thing you really need to suss out. Not boring people, like at the bottom with too many questions, but I think you'll lose people if you start using technical terms. Yeah. So anyway, we can debate that at the DJQ conference if you come. But anyway, I think that's part of data literacy on the IT side of understanding the terms of the business, and then you will have the business be more data literate by being able to tell you what the attributes of customer are or the attributes of a supplier. They're going to get that right away. There's often a master data team in the business that they're the master data team. They have never seen the database, but they can tell you right away what the master data fields are for customer or for supplier and they might want that in a word document. Yeah, they probably don't want to see a data model. I at least want to employ on the call is probably nodding her head because I did show a data model. No, I won't. Can I just see it in a word document? And they were right. And we did. Same information just showed in a format that they understand. So again, think of that because it's all the same information. Just are we showing it in the right way? I'm a big fan of using a data model that describes your business. And if a regular data model doesn't work, I often use pictures. And that can be silly or it can really get to the crux of a matter. We have a customer and there's a person there. They might say, well, that's silly. We sell the corporations as B2B and you're doing B2C. That right there could have a huge error. We have a product in a box. So like, no, we're an insurance company. Our product is an insurance product. So take off the box and put a piece of paper there, et cetera, et cetera. So had a lot of success with really, if nothing else, it starts to get people to understand what you're talking about. I mentioned this when I was talking about the party model rant of linking business process to your data. You might think is that data literacy? I think so. How is data used across all business processes? Who owns it? Who's responsible for it? How is it stored? Is it stored consistently? Gosh, I would say almost to a company that we work with, everybody's having this trouble because the first order thing is to get the business process right or to sell more widgets. But do you ask the question, what about the data when you're setting that up? And if you ask that question and maybe just pause for a bit, a couple success stories we won't have enough time for in this, unfortunately. But we had one, we worked with a non-profit and surprised the heck out of the vendor of when they were starting their new software application. They asked to see the data model and the vendor said, we're not buying it until we see the data model. When you know that it can either be customized to match our master data or it's close enough that we can work with it because we have a really strong master data process. And the vendor did, they said the data model ended up working. But you can't always have that flexibility. But is that question asked? How, when we buy an application or create a process or do whatever, what about the data? Our little out-of-there friend. And then for things that already exist, what's that crud matrix? What data is touched when we receive an order or fill an order or send an invoice? Really kind of understanding that is a huge part of data literacy. Again, as often overlooked more, we kind of focus on the analytics. But this is the stuff that PG analytics and really needs to be right. And on that note of it being right, again, this is a whole webinar we're having later in the year. So I won't go into this. But we don't want to over-nerd out on this. But understanding that data quality isn't just, is it right? What does that mean? If it's not right, why isn't that right? It's not complete. You don't have enough data. It's not consistent. It's right. I mean, there's nothing wrong with the state code being CO for Colorado and also being the word Colorado. But it's wrong if it's different in every application. So pick one, right? It's CO. We're going to use the two-letter field. And then that's right. Or is it, you know, it's correct. We have Nike and we have Nike Inc and we have just Nike Inc without a comma. I guess all those could be right, but there's now duplicates, right? So again, knowing the difference of this and what to solve for, it could be right, but we get it too late. We only get our data monthly and by that time it's too late. So it's out of date. It was right at the time, but it's not right now. So this and understanding and being very intentional about how we use words can really help and be a huge part of data literacy for both the business and IT. When I'm fixing something, what am I fixing? Am I fixing the business process to get it more timely? Am I fixing the business process to get it more unique and then not have duplicates? Is it an IT thing or we could have a dropdown for consistency? Again, a lot of value can be had by understanding this as part of your data literacy. Just a little course on that. What are the dimensions of data quality and how does that affect your job for both business and IT? You're really helpful. So a lot of problems in this world, world peace through data quality. Okay, and on that note and again, plenty of webinars and diversity about data governance and the aspects of it, but I would argue that data governance is a key foundation to data literacy. It builds that data culture, the communication around it. How do we get the right people in the right place? How do we get those right data management measures, the processes, and getting the right tools in place to really manage this? So again, Canada should be a whole section on data literacy about what data governance is, but I think that really helps kind of create that framework to keep data literacy going. So I do want to have time for questions. So in summary, data literacy should be an increasing concern because data is an increasing concern. We need to know about it. It's both a business and IT thing. It goes beyond analytics and is really a part of everything that touches data. And architecture provides some really helpful tools to communicate and hopefully fix some of these problems. If this was of interest and you want to hear more about analytics and data and BI, because I didn't go deep on that today, we'll have a session next month just on that. Other blatant plunk, we at Data Global, Data Strategy, my employer does this for a living. If you need any help on data literacy or data architecture, come find us. And with that, I will open it up to questions and pass it over to Shannon. Thank you for another fantastic presentation. As always, love the chat that's been going on throughout as well. Thanks to all of our attendees. If you have questions for Donna, feel free to submit them in the Q&A portion. And just a reminder, I will send a follow-up email by end of day Tuesday. Monday is a U.S. holiday, y'all. So by end of day Tuesday with links to the slides and links to the recording. So diving in here, Donna, is it possible to have a successful data literacy program without support from the executive tier? If not, how do we get C-suite's attention on this issue? We have a data literacy program without the buying of the C-suite. I think so. I mean, I think it's certainly better to have executive support. And that's often where these data literacy programs start. We're going to be data driven. And then we start with that and have a whole organization change program. But I think it's also, I've seen it really successful from grassroots. It could be lunch and learns. It could be even for your own staff having some data courses. Can you make those into little videos and just make them available to other people? We had one BI analytics, well, back in the day when people actually were in the office and they had kind of a booth at lunch of, you know, you want reports, you want to understand your reports, come to us and ask questions. Yeah, I think there's a lot of ways you can be grassroots. And you're kind of helped, even if your management doesn't understand it, the industry, the world sort of does. So maybe something as simple as that, some little videos out on your company sites and just have them available to people. And then you can go to management and say, you know, we put out a data quality video or a self-service BI video and it was viewed by a thousand people in the company. Could we now get some funding for more? So I don't think you have to, I think it's great to have executive buying, but you certainly don't have to wait to get anything done without it. I hope that helps. Perfect. Indeed. So is it true that data architect positions are coming up more now in the job market due to the rise in data governance programs? Yeah, I think that's fair. I think anything with data in front of it is a really good thing to have in your resume. I think data governance, the rise in data governance, people are really getting data architecture. Yeah, I've seen some folks come out of retirement that the demand was so high that people are really looking for, and I would say pure data architect. I mean, I think for a while, we were sort of the hidden heroes. We would be a data something else and we were doing data architecture, but I have several customers with open job descriptions they can't fill for the role of data architect. And I am seeing more roles that are literally just called data architect, which is maybe that's the sexiest job of the next century or next decade. So yes, I am seeing that. And where do you see the break over for incubating data wizards that understand the data model and can use it without fail versus something kind of dummy proof, like a drag and drop reporting model that end users cannot get wrong. A struggle with end users becoming literate and catcher in the ride versus literate in the little engine that could. A lot to unpack in that one. I mean, I think a good data model can help folks that aren't aware or a good cube. Think of it that way, your data model kind of, you say your dimensional data model turns into a good semantic layer cube can help people drag and drop without error. That's a lot of part of that hard work to make it easy for folks. I do think there's that might have misunderstood the little engine that could analogy, but maybe I'm going to put in my own take here, we're working with several companies where people just get so and it's not out of malice. It truly, I've talked to these folks, they're so excited about data and they come and say, look, we built this thing. Look what we built. But they really sort of, it's a good start, but it's not going to scale. And again, it's me trying to build the patio in my backyard and the real professor would kind of laugh at, which is fine because it's my own backyard, but if it was an enterprise, probably wouldn't be so fun. So how to channel that positive energy in the right way. So either putting the guardrails in place, here's the cube, it's published, it's validated. I know a lot of data catalogs now have kind of little, this is validated and trusted data, which goes a long way. Or if people are that eager, get them into the great, this was really, really good. We'll get you now into the BI course so you can do even better. Don't curb their enthusiasm, but you put guardrails in place. Make it easy to do the right thing by having trusted data sets and then providing education to turn that passion into knowledge so they can do it right next time. Hopefully that helped. Indeed. And perfect timing brings us right to the top of the hour. Donna, thank you so much as always. And thanks to our attendees for being so engaged in everything we do. Just love it as always. Again, a reminder, I will send a follow-up email by end of day Tuesday, because Monday is a U.S. holiday, with links to the slides, links to the recording as well. Thanks everybody. Hope you all have a great day. Thanks everyone. Thanks.


are Friday late afternoon March the 20th 2015 this might be the last snowfall here in northern New Jersey for 2015 for the winter of 2015 because spring is very close actually spring is wow it should be tomorrow or the next day it usually the seasons change on the 21st of the 22nd Bernal Equinox who knows anything could happen in spring March and April March is supposed to go in like a lion and out like a lamb but I don't see any lamb yet I don't see no rack of lamb I don't see any lamb chops I'm making myself hungry now I don't see any kind of lamb in the month of starch March this is James P. Madonna of Megalife 21 the hardest-hitting internet talk radio station on the planet I have seen on the web Megalike 21 progressive talk internet progressive talk radio I've seen on the web but anyway it's probably all glared out I don't know why it does that you know I mean it's it's without a doubt overcast it's not sunny so I have no idea why sometimes these daytime snowstorm videos come out all snow blind blinded it blinded it blinded but it's coming down in big flakes I mean it's coming down moderately heavy but it's it's really not sticking because it's coming down wet and that's to be expected because that's how spring is a lot of rain especially when you're close to April April showers oh no no lamb no no going out like a lamb no lamb chops no breast of lamb no lamb with mint jelly big pine trees all probably snow blinded it snow-blown blind blind blinded it that whatever the fuck you call it it's what I call my my Bart Simpson headed evergreen bush because of the spiky top when the snow pushes the top down the branches old man went there old geezer went there has not said goodbye yet very brutal cold winter of 2015 we had climate change I won't say global warming because then you have all these right-wing fools tell you how could it be global warming if we had such a bad cold winter well the earth is fucked up the axis has moved and what you have is the extremes of temperatures in the different seasons including more severe and more frequent storms of all kinds St. Patrick's Day blue by I must say that the only place that had all you can eat corned beef and cabbage was the local Lodi buffet every all the cheap basses in the New York metropolitan area in northern New Jersey you all suck you're all cheap and stingy and greedy scumbags I used to go to pub 46 over on route 46 East and Clifton, New Jersey for free all day and all night delicious succulent tender corned beef brisket and cabbage by the bar and they did away with that every single business in my area had no and I repeat no all you can eat corned beef and cabbage so I had to go to the Asian owned buffet and the the quality sucked there was it wasn't the best brisket it was a little tough and it was a lot more cabbage than corned beef they treat there were stingy they were trying to stretch the corned beef the rat bastards hey maybe it was corn brat meat who the hell knows over there but anyway that's my review on St. Patrick's Day of 2015 and I'm very disappointed we'll see it next holiday is happy pagan Easter pagan Easter this has been a mega live 21 production


Okay. Very good. Thanks, folks, very much for stopping by. So my name's Phil Robb, and I'm going to talk about Open Daylight. Open Daylight's been around for just about a year now. We launched 13 months ago on April 8th of 2013. Again, my name's Phil Robb, and I work for the Linux Foundation, and I spend all of my day job actually just facilitating the community around Open Daylight. So I want to talk a little bit about what Open Daylight is, give some current statistics on where the project is, talk about the first release that we had, the current release called Hydrogen. Also talk about what's coming in new as far as getting everybody up to date on what the project is about to go launch into for development activities. Some more focus areas on our second release, which is called Helium, and then just end with where you can find out more about the project. So what is Open Daylight? Open Daylight is really about a community for building an open source SDN platform. We wanted to really look at this in three different prongs, one being code, good code to use, as well as acceptance, get broad industry participation. As we saw SDN beginning to form as a concept and a technology, there were a lot of disparate different methods of doing it, and so much of this is just core platform that needs to be done for everybody to build solutions on. So we wanted to build an open source project to get there and then have a true open source community similar to OpenStack as far as anybody who has an innovative idea and has the time and energy and effort and passion to come bring a project and come bring their effort, then they were very welcome. And so that's what we really formed. Specifically, we're building an SDN platform, and it's important that we talk about the evolvability of that platform. There are lots of different meanings and terms for software-defined networking these days. We don't really know today what it's going to look like in five years and two years. We're very much in a greenfield area here as we try to build these networks where you have a separation of the data plane and the control plane, and you now have all of this information available to that control plane where it can see the full breadth of the network, what it all looks like, as well as managing both the overlay and the underlay of virtual environments. So we want to create these abstractions for the northbound, for applications that are using Open Daylight. And in our context for Open Daylight, OpenStack is an application. It sits north of us. It's going to call upon an SDN controller, such as Open Daylight, to manipulate both virtual and physical network underneath. So when Open Daylight talks about applications, OpenStack is one of the most important ones that we have. We want to be able to actually intermediate what those requests are from those northbound applications and then be able to manage those down into a southbound set of devices, be them virtual or physical, within the network. So have a common abstraction for the northbound applications above the controller and then a common method or a way of actually manipulating different kinds of devices southbound of us. This also includes applications to manage things. The folks from Open Daylight gave a talk earlier today talking about having an application that can implement flavors of OpenStack. And that's something that we're going to be working on throughout this year and probably in the next year. I'll talk a little bit more about that later. Just a summary from our first year. Again, for a project that's been around for only 13 months, 1.17 million lines of code is an awful lot.  We started with about 30 contributors in April of last year and we've got about 181 active contributors now. Very surprising to me and so it is of note, we actually won Best of Interop a month ago. We're the first open-source project to ever win Best of Interop. And so I'm not quite sure how that works, to be honest. Open source is about the technology. It's not about a product. And very much Best of Interop I had always thought was more about polished products that go into users' hands. But I mean, if you look at it from an impact to the industry standpoint, I think that's really why we won. Again, I would not advocate that everybody go off and take this code and go put it in your production environment and want to rely on it on a day-to-day basis. Again, we're a young project. We've got a ways to go. But it was quite fulfilling to actually be, again, the winner of Interop as a very significant technology for the networking industry. We won a variety of other awards. We've doubled in size. For those that missed the announcement earlier, HP actually moved their membership today from Silver to Platinum because it's now going to be a key piece of their future work as well. Again, we had our first release, which is code named Hydrogen on February 3rd. We have our second release Helium planned for September 29th. There are three products right now that I know of that are based on Open Daylight, as well as many that are actually on the drawing boards for 2014 and 2015. So for Hydrogen, this is the standard diagram, and if you want to stop by the booth, we can send you off with one of these. But the important thing here is that you've got the applications that are writing on top, a common set of northbound RESTful APIs. This technology is Java-based, and we also use OSGI for creating bundles for the project. So you can either interface with it straight through Java if you're running on the same machine, or you can go through the RESTful APIs if you're off-box. A set of networking service functions, as well as room for additional services, all sitting on top of a service abstraction layer. And it's that service abstraction layer that allows for a common set of northbound APIs to talk to a disparate set of southbound protocols depending on the devices that you're talking to. Those southbound protocols, OBSDB, Metconf, and so forth are also part of the project. And then that dotted line is really where we end our scope. So things that are underneath that dotted line, like actual physical devices or virtual devices like OBS are outside of the scope of our project. So this is what Hydrogen looks like, and those are the commons that are part of it. We're just now, so today is actually in the lifecycle management for Helium for our second release. Really, okay. All right, that's fine. All right, I guess I'll do this now. So today is actually the day that new projects are supposed to be identifying themselves as wanting to be part of the Helium release. So we've been going as a project, we've been going through a series of creation reviews for different project proposals. I wanted to talk about the projects that have come thus far. So these are all projects that have been introduced since Hydrogen actually went out the door. So these are new projects that will be part of future versions of Open Daylight, but we're not actually part of Hydrogen. First one being Deluxe. This is a project for a much better augmented user experience and user interface for Open Daylight based on AngularJS, or AngularJS, rather. The group policy plug-in is for identifying policies for different type of end nodes, and that is going to match up with the group-based policy that's inside of OpenStack. So the naming and its purpose are very closely aligned and intertwined with the needs of OpenStack as well. Open Daylight Toolkit was a project that was brought forward to basically leverage Maven archetypes to make it much, much easier for developers to create applications and begin to test new applications sitting on top of Open Daylight. So if you've got an idea for an application, looking at the Toolkit project may very well help you jumpstart what that application looks like, so I would suggest you go there. Documentation in general, again, is a new project. It typically is one of the last things to get off the ground right behind a lot of code. So having a project that both works specifically on creating good solid documentation as well as integrating tools to have documentation generated as part of the build process is really the idea behind this project. Dynamic resource reservations, so being able to set out flows and identify resources and paths based on different criteria is what the Dynamic Resource Reservation Project is about. Negotiable data path models is really an implication of TTPs. If you're familiar with the Open Networking Foundation work that's being done in the forwarding abstractions working group, one of the things they've been doing is trying to figure out how best to manage the variability of functionality that can exist in switches, particularly with OpenFlow 1.3, and so this is a way of managing that and trying to trim down the combinatorics of what you could do with the extensions and the options for OpenFlow 1.3 and instead have this as a protocol and so that's another project that's been introduced. Packet Cable PCMM is another project that's been a proposal that's been brought forward and has been accepted into incubation. Specifically this came from the folks at Cable Labs. They want to be able to manage CMTS type of cable modem devices as just another network element in their environment so they added a southbound protocol so that they could manage it from the controller. The ODL ROOT parent is an internal project that's really geared towards improving how the different projects inside of Open Daylight manage their own objects and the dependencies across the different projects. As we've grown and we've had these new projects come forward, being able to manage the dependencies and continually roll forward in a continuous build environment is what we're going through is growing pains and so this is a project brought forth by members of that community to make it so that it's much easier as we're continuing to do this. The OpFlex protocol that's been submitted to IETF for a standard for implementing and managing application policies down to networking element devices has been proposed and is introduced. The ODL SDNI project is about using, it's about creating an east-west protocol set for doing controller federation. They want to base this off of BGP as a base protocol to start with but as we look at both doing clustering using Infinispan, using other technologies as well or federation where BGP is a natural first choice to begin east-west protocols, the ODL SDNI project is geared towards doing that. A southbound plugin for the OpenContrail platform so actually integrating and allowing manipulation of OpenContrail through Open Daylight has been brought forward by the folks at Juniper. This last page are actually projects that have been proposed but they have not yet gone through their creation review. We have one final creation review set that will be occurring this Thursday and I felt remiss if I weren't going to at least include a brief description on what these look like again because they're quite reasonably going to be part of the Helium release as well and accept it on Thursday but these are not yet approved. One is around authorization, authentication and accountability for both machines and users on the net and that's the AAA service. The L2 switch is really somewhat of a refactoring taking the core functionality for L2 functions and actually turning it into its own project separate from the controller and making it a little more abstracted so that it can be basically augmented and leveraged more than just the way it is now embedded inside the controller. Service function chaining will be the first to actually build an effort to put service function chaining features and API sets inside of Open Daylight and then secure network bootstrapping infrastructure as it describes basically leveraging certificates on hardware and understanding a set of boot priorities and secure boot devices that can be brought up inside of that controller environment with key networking elements as well secure from boot. So those are the items that are there. Key themes for us are really around stability, scalability and performance, improved ease of use for new users as well as developers and you can see that with like the documentation as well as the toolkit projects that we have. Again improved processes for both continuous build as well as release and getting more work done with real users. We've started a whole series of proof of concepts as well as the user group. Ways to get started and you can take a look at these slides after the presentation's over. The Wiki and the mailing lists are really the best ways to get involved. There's a YouTube channel that has a lot of great intro videos if you want to learn more about Open Daylight and then of course we're on Twitter as well as Facebook and again come to the opendaylight.org site. With that, thank you very much for your attention.