 Alright folks, for the next session, we are going to have a talk on metadata strategy for beautiful NADs. I will play the recording and feel free to ask questions or leave your questions in the chat drop and Anna will be able to respond to them after the session. Okay, let me know if you can see my screen. My name is Anna McHugh and I am a content librarian and curator at Red Hat, which is one of the world's first open source software companies. Today I'm going to talk about content management systems, both for external web users and also internal libraries that you may have at your organization. My role as a librarian and curator at Red Hat is to ensure that our content is relevant, up to date, labeled with meaningful labels and also is housed in software systems where it can be found and where you can emphasize the most important information. I came to Red Hat about five years ago and I am not a formerly trained librarian, although I have always been a huge information nerd. I love hanging out in the stacks of libraries, finding that choice bit of information that's hidden all the way to the back and all the way in the basement. However, as soon as I got to Red Hat, I realized that that kind of inclination was simply not going to serve me. I am responsible for the library on redhat.com and so that's a collection of documents that is valuable to a wide variety of external users. So we have two documentation that is for developers or system administrators. We have documents that are good for people who are just trying to learn about what open source is and how it functions in the world. When I came over, I realized that it was very important for us to build robust and easily access metadata systems and also to use that metadata to ensure that search experiences are easy for users. And I'm going to tell you how all of that went down. And I think that it's really important, however, to note that, you know, in this day and age, it can seem that, you know, our vast amount of information is always an asset. There's definitely also an inclination to hang on to every last white paper, every last case study that you authored. However, I think it's very important to razor in on the important information and to establish context throughout the entirety of one's collection to make sure that you're connecting users, not just with the totality of information, but saying, here, this thing on the top, this is the most relevant, the most trustworthy, because given the rapid amount of, you know, content that we create, and how rapidly also the subject matter of that content tends to evolve is very, very important to be able to do that. Additionally, I think that it's really important in terms of our move toward an all remote workforce. And Red Hat has always been anywhere between 30 and 40% remote, at least in the time that I've been there. And so when, you know, COVID came and we started to work remotely, we already had some really good practices in place. That being said, one of the things that my team took a look at almost immediately in terms of our new, you know, supporting mission is the GitLab remote manifesto. This is sort of an adjunct to the agile manifesto, which essentially establishes a set of principles and ideas where teams that are interdisciplinary or multidisciplinary teams can build products together in a rapid and iterative fashion. Now, this is a very, you know, dynamic way to work, but you also need to have excellent communication between team members. And so, you know, very frequently, a lot of the practices that develop around agile involve a lot of meetings, a lot of regular communication of what is in your way, what kinds of changes the business has given you that changes the software changes the project that you're creating. Now, in order to extend that GitLab has, you know, brought forth a couple of really interesting sort of principles that can help agile teams also adapt to an all remote environment. And before anything else, inclusion and transparency are paramount. And I think that, you know, the work that I do is really important in establishing that because transparency and inclusion really begins with everyone having a certain understanding of where information can be found and what a source of authority is. Additionally, good documentation is very important, you know, you don't have the opportunity to necessarily job shadow somebody if you're in a remote environment. So good documentation, not necessarily comprehensive documentation, but the documentation that will help people get through their jobs every single day is super duper important. And so I think that, you know, this is an area where we can really flourish not only in terms of creating documentation but ensuring that the documentation that is the most important, again, rises to the top. Finally, asynchronous communication. I think this is going to be one of the ongoing challenges that teams grapple with and cope with, kind of regardless of their circumstances. You know, you have teams that are global people working at all hours of day or night as the earth turns, we have people with a variety of differing needs as far as their working styles. And it's very important to foster that flexibility, especially because you know at the core of this manifesto and agile is valuing the humanity and valuing the collaboration that comes out of people who feel like their value feel like they are empowered to create change when it's necessary. So I think that the work that I do is really critical in fostering all of these things. And as a result, of course I take it very seriously. Now I am not suggesting that everybody who is a trained librarian should, you know, drop their books immediately and run off and become a sysadmin because that would both be impractical, and probably not very good for the overall quality of the sysadmins that are available for hire. Now instead, I think it's really important for us to focus on what we're good at which is creating good labels, but also becoming very familiar with our tools. So, you know, one of the things that I think is really instrumental in my job is I serve as a sort of midway point between the business stakeholders. So these are the people who are building the website people who are building technology products that you know that we're trying to bring to market. And the developers and the it operations folks who run our infrastructure who run our websites, who build our content management systems and other systems of record. You can frequently hear from people in the business who have, you know, concrete concerns and considerations, but they don't understand and shouldn't have to understand how the software works to explain what kinds of features they want or what problems they're experiencing. On the other side of the house, the developers don't necessarily know what the business priorities are or, you know, have necessarily the skills to tease that out. Now project managers can help, but also, again, somebody who understands the business context of the content, but also the systems in which it's housed and how those things can be built and modified is a really valuable thing. So, you know, very frequently when I'm talking with people, I think that there's a lot of real interest in and a lot of very promising developments in the level of sophistication that we have search algorithms and, you know, creating personalized experiences, a wide array of really interesting tools to connect people with the knowledge that they need. However, there is a, I think, significant role, at least at this point for human decision making and the ability of humans to discern the, you know, what is trustworthy what is expert and what is authoritative, far better than machines at this point. I think that the recapture project is a really good example of how, you know, computers and software systems, and also, you know, the human intellect can work together to, you know, basically harvest and create more rich texture information. So, recapture essentially is just digital scans of, you know, books that haven't been digitized, and then they're presented in a sort of distorted fashion and users use them to authenticate and to get into websites demonstrate they're not bots. Now this information is fed back into this massive digitization project, which really feeds, you know, the growth of overall knowledge and, and serves a very important need. So good illustration of one of the things that human beings are very good at that machines aren't necessarily so good at and that is looking at things and interpreting images, especially, you know, distorted images, or for that matter, you know, distorted, or symbolic or metaphorical image. So the human mind is really good at understanding that kind of information and you know you can bake that into the algorithms and the different tools that you use to essentially again, build that context build that understanding that you have a value and what people are trying to learn but also what you're trying to say, because you know, no collection of documents is actually fully objective, you are saying something especially if you're talking about a website for a company. So some people will, you know, occasionally poo poo the role of human beings in the organization of such collections of information. And my counterpoint point to that would be that even Google understands, you know, the value that human beings bring to these sorts of complimentary activities, building knowledge environments that take into account some of the more qualitative factors of the content itself. So, you know, one of the things that I find to be fascinating about Google's work is that they have quality radar guidelines. So basically it's 168 page document that is for human beings. And they sit down and they read a website and they compare it against a rubric of different measures of what quality is and how, you know, again to assess and evaluate how a website behaves and performs and how basically it should rank and search. And there are three main factors that are very important that are also very difficult for machines to discern. And I think these are also really the three critical things that determine whether or not information that we encounter in digital environments is valuable expertise, authoritativeness and trustworthiness. So essentially the entire set of activities that a quality radar goes through is to identify the level to which a page represents those things. This becomes increasingly important when you're talking about websites that potentially have a lot of implications of using that information. So medical websites, financial services, etc. So all of the, you know, human feedback is fed into the Google algorithm, so that there is sort of a continual building of a set of understandings of where those fault lines are in terms of what makes something of an authoritative, what makes a voice expertise and more than anything else, what is trustworthy because that's the most important thing that we're trying to parse on the internet or really anywhere. So stepping back from all that crazy stuff I'm going to tell you the story about how my job came to be and how I came to, you know, spend the last five years at Red Hat going from a chaotic document library in a very, very disorganized content system hosted in Drupal to what I would like to think is a more robust, more flexible system that people also have access to data that is meaningful both on the outside and internal users. So this is a quick timeline. We aren't actually dancing bears at Red Hat, although we do occasionally have a reputation as party animals. We were tired in 2014-2015. We were just moving on to Drupal from an earlier content management system. So the new redhat.com had a library that I essentially on my first day inherited. And I said, my goodness, this is rather large and my boss, you know, said, well, yes, you know, part of your work is going to be sorting out, you know, what's good content and what we need to get rid of. And I said, well, that should be relatively easy. We just pick a date and we archive things that are older than that date, more or less. And she said, aha, this is the difficulty when we migrated our content into Drupal. It put the same time and date stamp on all of these things. This is a perfect example of the unintended consequences of building cool new stuff. But as a result of that, it also became very clear that our first order of business was going to be going through the content and auditing it, making sure not just that we're getting rid of the things that are no longer relevant. But more importantly, that we were developing a strategic system for managing and labeling that content and future content so that we'd be able to create a system that had a little bit of coherency to it. So, you know, 2014, 2015 was kind of getting my legs under me and, you know, working on some of this auditing 2016. Additionally, we spent a lot of time not just auditing content but also starting to work on our content management system itself. And so developing a far more sophisticated taxonomy, working to, you know, develop onsite search mechanisms and also incorporate some of our organic strategy. 2017 and 2018 were characterized by getting additional access to data outside of the content management system and marrying it up. So, you know, the best example of this is that we were able to create content segments using our inventory and so say for instance we could gather a list of assets or a list of white papers about Linux, which is one of the primary things that red hat is in the business of. And we could marry that up with the data analytics that are used to measure the performance of content. This is really helpful to us because we're able to understand what's working, what's not. And also have an understanding of what users are trying to get to so that we make sure that information is what we focus on in terms of making sure it's up to date. And then in, you know, 2018 and 2019, we started to also branch out into some sort of home group technical solution so we could take these different sources of data and bring them together. We also started to do it, you know, started to do hacks and work around so that we could use our taxonomy to do some personalization and other interesting activities. And additionally, in 2019-2020, we built and launched a digital asset management system as a software as a service. So we were moving off of a far more traditional sort of file management platform onto something that's available in the web browser. And we built the entire search experience around that and around the, you know, specific collection that we're trying to present to people. So I'm just going to give you a quick rundown of the main things that we had to get done before we could make any progress on the cool things like, you know, tying our performance data together with our content metadata. First of all, we had to audit that content and also look at the metadata, not only, you know, what labels were on things and ensuring that, you know, we cleaned up that, you know, all of those records, but also making sure that the taxonomy itself was in good shape. Now, if you're not familiar with the term taxonomy, I'm just going to back out really quick and explain it. More or less taxonomy is just classified information. Dad jokes aside, essentially it is just a, you know, organizational system where you have a hierarchy of information. So you have a parent level, you know, a parent level category and child terms underneath it. So in the case of Red Hat, we have topics is one of our parent level categories. We have Linux, we have cloud computing, we have DevOps and security. So you're basically able to say, okay, this is a dimension of the content. This is a, you know, a label that I want. And here's a controlled list of selections that people have. Now, sometimes people feel, you know, users can say, well, I'd love to be able to use keywords because I can be descriptive and, you know, it'll be easier for people to find the content if it's a very specific bit of information. I find a controlled list of taxonomies that are also developed sort of strategically alongside the business and the collection to be far more effective. So you have to, you know, audit your content, audit your metadata. You also have to ensure that that data continues to be accessible and also has high integrity. So, you know, if you have to pass the torch to a different person who is going to become responsible for publishing content, impressing upon them the importance of good labeling and tagging is critical. So when I first started at Red Hat, we had, again, this idea that it's going to be relatively easy to get me up to speed and we're going to, you know, be able to sort of smoothly transition to this new platform where we were hosting our content, so Drupal specifically. And it became very clear that we just had a lot of different problems. Everything from, you know, the records without the time and date stamps on them to, you know, information that was simply out of date and needed to be looked at by people who are technical, you know, owners of the content people who are experts on Red Hat products and open source technology. So over the course of the first year and change that I was working at Red Hat, we eliminated nearly 2500 PDFs that were either out of date, no longer relevant. Basically what you would call content rot, which is the C information that is redundant outdated, and even worse than everything else trivial. So that was the focus. And, you know, on an ongoing basis as a practice we quarterly will audit content. And so our method for doing this essentially is we say anything that's older than a certain amount. So in our case 18 months needs to be audited. If it does not meet certain performance benchmarks. So we need to ensure that the content is, you know, actually of interest to people to again get rid of the trivial things and emphasize the things that are more important to our users. But also to just give us a gut check of like 18 months later is the still relevant in the technology industry very frequently we have to retire things far before 18 months. So we have a window of time basically, you know, three years to 18 months of age we look at the performance of the content itself. Anything that's older than three years, someone has to scream and yell and holler to not have us archive it. And certainly we will have people who are owners who are really good at communicating like no this technology is actually stable enough, or this is a product that some of our users have that we need to keep around. That said, auditing and auditing on an ongoing basis is really, really important to us. I will attempt to use my slides in the correct direction. So not just auditing content, you know, obviously that was one of the first things that I really dug my teeth into. But, you know, in the building and then the maintenance of the Drupal system and then subsequently our internal digital asset manager. We realized that access to data in a very simple CSV format was probably the most valuable feature that our developers delivered for us. We would have all of the wonderful flexibility in, you know, how large your mosaic display is or how people scroll or how they build a collection for themselves. There are lots of wonderful things that can be done with software, but at the end of the day, in order to actually create a system that people can use and to be sure that the information that's stored in it is relevant. You need to be able to pull records out that is inclusive of the metadata that you have. In Drupal, we don't have a very sophisticated list of the metadata that we, you know, include one of the primary use cases that we have is we basically build an inventory. It's a Google Sheet. It's super simple. You know, it has the name and, you know, the type of content that the item is also its publication date, and then all of the taxonomies are usable as filters. They're filtered by topics and by products and by product lines and a variety of other parent terms. Additionally, we took our analytics data out of Adobe analytics and also out of our contact database. So, you know, records of sales and married our inventory of content and our metadata from our CMS up with the, you know, web performance and ultimately the business earnings of each individual piece of content. It's really valuable to us because it gives us a chance to say, okay, it's not just a matter of raw popularity. It is also this, you know, contextual understanding of how our content performs. So for instance, occasionally we'll find something that is a really highly detailed document. And some people say, for instance, in marketing would say there's maybe not so much value to this. However, if we look at it and we say, well, there's only five people who downloaded, however, those five people ended up buying $500,000 worth of Linux, it's probably important to ensure that that document stays up to date and that we continue making documents like it. It's important to be able to get access to, you know, your the data that's within your content management system and again CSV format is really important. I also highly stress that you want to make sure that the values that are separated, you know, comma separated are great, but occasionally, you know, you can end up with a system where all of your terms are in one list and it becomes very ugly. So, you know, looking at what kind of filtering you're going to want to be able to do and what your other use cases are is really important in that case. When you're building these search experiences, you know, be it for in my case red hat calm or, you know, this digital asset manager. One of the few things that I really deeply and fundamentally believe is that a flat taxonomy is very, very important. When I first came on board. I had an internal library and it was basically set up like a traditional sort of file tree, and it got very, very complex and confusing really rapidly, especially because you had things broken up sometimes organizationally but sometimes by different products. It was almost impossible to use and it was very elaborate. Now it was very logical as far as its hierarchies were concerned, but those hierarchies didn't really make sense together, and they're simply way too deep. And most of the time when you talk to people about taxonomy or you talk with them about metadata, you know, their eyes start to glaze over taxonomy to them is reminiscent of, you know, their dorky high school biology teacher. And they think of it also as a deep multi layered thing, you know, a taxonomy as you start at kingdom and phylum and down to genus and species and in between there there's all kinds of stuff that it's almost impossible to memorize. Now the reality is that a flat taxonomy is oftentimes really intuitive and easy for people to use on the subject of taxonomies I think it's important also that, you know, whatever system you're building, being able to modify that taxonomy is very important. So being able to change the parent categories, but most importantly, being able to change the labels on all the records within your system is critical. So for instance, a couple of months ago I had to remove a product from red hat calm, you know, and all of the records associated with it. We have a feature that's a bulk tagger so basically I'm able to go in, delete the term, and the tag essentially falls off all of the records that are associated with that term. So it's a one and done it takes me two seconds, I clear the cash, it, you know, is removed from our content delivery network, and it's a done deal. So if you have another tool however that if you want to get rid of a taxonomy term, you first have to remove that from, you know that specific term from all of the, you know documents and records that have that term. So you can understand where we're getting into a little bit of a problem here. So it's very important to have a flexible flat lightweight taxonomy in my opinion. I'm going to give you a bit of an example, you know why this might be the case, because this is my talk and you can't stop me and I can't even see you. I'm going to talk to you about my big hobby and that is my ecology, which is the study of molds spores and fungus. I really enjoy hunting for wild mushrooms and messing around with culinary stuff it's just a great hobby. But one of my favorite parts about it is it's a very taxonomy heavy discipline as well. There's already millions of, you know, different species of fungi probably around 1.5 million so and who's counting. And so, you know, there's a very, very rich taxonomy associated with the study. That said, most people, you know, when they're looking for a mushroom or thinking about mushrooms is a really basic template and they have a very specific need. It's a good parallel to, you know, the sort of digital library experience I'm trying to provide to people, even though as the back end user and an administrator, I want to be able to look at all of the seven different names something has had. The front end user wants something very simple. So let's talk about the, the shiitake mushroom probably one of the most popular culinary mushrooms in the world. And because it's so popular it's been studied for a long time. And as a result of that is it actually had seven different classifications seven different linear names. Now if you're super into mushrooms like I am that's great and you can you know dig through taxonomies and the history, you know the changelog, all you want to figure out why people named it that and why they moved it to a different genus etc and so on. So for most people, what they're doing in relation to shiitake mushrooms is walking into a store looking for the produce section looking for the mushrooms, and then looking for the bin that is labeled shiitake. So I'd like to, you know, propose that information environments digital information environments, especially for, you know, web users who can be pretty much anybody in the world. It's very simple, they should be straightforward. And, you know, as much as you may be an expert and have, you know, really relish developing these complex, but very nuanced ways of getting information, you're usually not actually doing your audience of service. So as a result of auditing our content, also getting access and ensuring that the data in our systems had integrity, and then, you know, working to sort of understand the overall value that our audience finds in the content we're able to do some optimization work. So it read had about two thirds of our revenue comes originally from contacts that we make in organic search. Now, because a lot of the materials that we create are sort of old fashioned, you know, we have a lot of PDFs. We've been making an effort to publish these kinds of documents and HTML. Now, when we do that the traffic for those particular pieces tends to be anywhere between 10 and 15 times the amount that a traditional PDF would get, especially for organic traffic and this allows us also to sort of grow our information ecosystem for specialized topics that come from sort of our technical teams. So in looking at this information of, you know, our metadata we're able to identify okay, what are the things that people are interested in, what are the things that maybe we don't have quite enough on and then we use that to migrate that content and make sure that it is created and published in HTML first. We also have a content analysis program so we're able to, you know, work with different campaigns. We have an editorial board and we have a couple of different, you know, sort of programs that are designed to, you know, project and to articulate red hats position, especially on a particularly interesting, you know, element of open source software. So we're able to, you know, perform analyses. My team has done somewhere in the neighborhood of 35 of them and we split them up by all kinds of things. So, you know, if you are the owner of a particular product we can give you an analysis of your content. If you are working within of our one of our vertical teams so you know say for instance you work with telecommunications. You can talk to you about the performance of your telecommunications content that is published in French, and you're interested in organic traffic instead of conversion traffic and people buying things. So this level of nuance and detail is really helpful. And, and it allows us to, you know, understand and analyze our content really starts to also wrap our heads around, what are we known for, and are we saying the things that we want to say. And going back to, you know, Google's principles around expertise, authority and trustworthiness, seeing the kind of content that people access will give you a sense of whether or not you are in fact delivering the kind of message that you want. And if not, then you can refocus. Another thing that we have done this really helped, I think the entire business sort of understand metadata and participate in the development of, you know, our content software is our metadata governance committee. So we meet on a monthly basis. It's an open meeting. Anyone can attend and we often do have people from the business or, you know, software developers who are working on our, you know, business applications who attend. And we just basically talk about new terms that we want to add to our taxonomy or terms we need to remove or disambiguation we need to do. So, you know, it's an open forum on a monthly basis where people can bring to the table their need for new metadata or even just a need to be able to find content a little more easily that maybe we should design a label for. So we do that on a monthly basis is very open very collaborative and it's very much the red hat way. It also is an opportunity for us to form relationships with people and to basically demystify the idea of metadata and being sort of a business stakeholder and building, you know, like web applications or search applications, content management systems, etc. And then a couple of days after our, you know, our open collaborative fiesta, the librarians and owners of the different tools get together. We, you know, update the tools that are relevant. We keep a change log and we also maintain a data dictionary, and we do that every single month so every time we change something we have a really clear record of what we did and why we did it. So I also want to talk about, you know, I think the character of the work that I do and the things that I find to be inspiring. You know, I think the very first thing that I discovered is I was not going to be, you know, again, just an organizer of content, but that I was going to be really closely involved with the development of these systems that weren't working very well to ensure that people could find what they want. I'm going to drink some lemonade. All right, that does the trick. So, you know, when I embarked on this journey and I realized, again, that I was going to have some agency to work with the developers work with the business to improve our systems. I realized almost immediately that I had to take on a technologist's mindset I had to, and, you know, fortunately I do have a great deal of enthusiasm for trying new things. And also I simply love a good search experience and so you know this wasn't rocket surgery for me, but what was new was an understanding that in order to get good at my job I had to be really good at bug hunting. And there are a couple of reasons for this. You know, I think that first of all it is the best way to become familiar with the systems that you're using. You know, and I've seen people walk in the door, you know, with a lot of experience and a lot of knowledge, and they come into contact with, you know, a custom content management system, and it's just like, you know, it's like touching a live wire. So I think it's really interesting to delve into a tool as it's been developed for a specific group of users at the same time as you're looking at the content itself and sort of being a librarian about it. But it's really important to also be that bug hunter. So also you can start to understand where the limitations of the system. What do we need to document really well. And also it's a chance to say, hey, you know, this is a thing that's busted. How bad is it. And oftentimes the developers will be like yeah it is busted and it's really difficult to fix. Is it really that big of a headache for your users and oftentimes you can find a way to jigger the system so that that need is met without having to create these, you know, elaborate technical solutions that can be very simply dealt with in another way. I love the fact that in my job, if something is broken or someone can't find something. It is always my turn. So if they can't find something because of a server time out. It's my turn. If someone can't find something because it's labeled wrong. It's my turn. If you know content hasn't been audited appropriately so old content is rising to the top because it's been popular forever and the thing that's new and shiny is is you know sitting in the bottom of the drawer. It's my turn to figure out how to fix that problem. And that may sound daunting but it's actually wonderful and it gives you an opportunity to build really rich rich relationships. You know there's nothing more satisfying to me than talking to a user who's having a problem but can articulate what the issue is, because they don't spend time in the software and being able to walk over to the technical team and saying okay this is the issue that they have. It involves these different components these are, you know I've tested it five ways from Sunday so I've verified that it is actually broken. This is something we need to fix. And if so how I think it's also really helpful when you're, you know, building these road maps and trying to develop additional features, because there's oftentimes a temptation to, you know, adopt. And this is from the business side in my experience pretty elaborate search experiences and you know they're like we're going to have this very very specific set of filters that people are going to use and will have, you know, comprehensive documentation and a user guide. And I love to bring people back to the reality of the paradox of the active user. People are going to jump into your software right away and start using it. And one of the first things that almost everybody is going to start doing almost immediately no matter what the software is, is try to find things. Now of course in an information environment that's really all you are doing is uniting people with the knowledge that they need. But I think it's really fun to put yourself in the position of a user and say okay, I am going to behave the way that I ought to, in a digital space which is if I cannot get the information that I need that kind of denigrates the quality of the experience and that makes me want to find another source of information. In addition to the inconvenience of not being able to navigate the system, clearly. So I think that, you know, articulating this is oftentimes very helpful for business use, you know, your business stakeholders to hear. I think one of the most valuable sources of information and input that you could have when you're trying to build information systems and environments is the projects and the problems and the pains of your passionate amateurs. We're talking about the people who will hack together a solution to a crummy problem that they have in the content management system, because they need to get their work done and they're always looking for new and exciting ways to get around, you know, the hurdles that they encounter. I think that also it gives you a sense of where people are willing to put their efforts. That gives you an additional sense of what is very valuable to them and what you need to be able to provide in terms of the user experience. In my team, that person is Brian. When Brian first came to us, he was really excited to bring together the analytics information and the information from our content management system to build these inventories and provide people with greater access to our content greater insight into what was working. But he wanted to take it further. He wanted to make it easy for people to submit requests for content to be published and to, you know, label their content appropriately and have it, you know, go into our project management system and then subsequently into publishing in a smooth and automated fashion. So he built a Google form that we can basically use to take in that information and put it into the software where we basically manage, you know, all of our tasks. He also used, you know, similarly, that data to send automated notifications to people who own content after three and after six months of that content being published, because it's super important to be able to say okay what's working what isn't. And ultimately, he wasn't able to do that with the tools that we had available so he wrote a couple of Python scripts we used, you know, really simple components like Google forms and runs the whole thing off of a Raspberry Pi on his desk. And what I would propose to you is you want to find the people who are running the Raspberry Pi, unplug it, tip it over and shake it and you will find some really good future features. Because again the people who are willing to work hard and come up with creative solutions to certain problems are also the people who understand what the biggest problems are. And this is really important because you're going to be, you know, more than likely involved with a project where you have to build software that has been purchased by someone who doesn't necessarily know how software is designed. At this point in time 40% of the software and technology business, you know, technology buying power resides with the business units in different organizations. Now, that has its value because of course those are the organizations that know exactly what the need is and what their associates are struggling with. However, a lot of times, you know, there are software systems and software as a service in particular is kind of becoming ubiquitous for these, you know, knowledge management systems of all kinds. They need to be built in a way that was that is very thoughtful and very straightforward but also with a full understanding of what's going on under the hood. So if you, you know, sort of look at the totality of features that are available occasionally people who are purchasing software as a service will focus on, you know, the user interface or some of the different tools and configurations. But ultimately, you want to make sure that you can build a collection that has relationships that ties things together that basically each individual piece of content that you have functions as a star in a larger constellation. That superimposes additional meaning that basically helps tell your story and helps articulate to your users what you need to convey to them. So this is an example from our digital asset management system that we built in 2019 and have been, you know, adopted business wide at this point. And one of the biggest challenges that we had was establishing relationships between different pieces of content that were related. It was people would be looking for a white paper but they also wanted a digital banner ad or they wanted, you know, email template copy something similar. So we built the system to, you know, reflect those relationships and to build a very simple publishing mechanisms into the system. So it's easy to build those relationships and essentially again, curate the content in a way that's meaningful and a way that's flexible and can be reconfigured if necessary. All of that said, one of the great things about software as a service is that you can do all kinds of really interesting things with it. You know, you don't have to worry about hosting it. The vendor takes care of a lot of things people just go into their browsers and use the tool and that's all they need. A lot of these different solutions do employ, you know, machine learning, some AI sometimes natural language processing in order to sort of execute some of the search and recommendation engines. I will say that those are really cool features. I would not make a single decision based upon them. However, I think it's important to bear in mind that those things are relevant in the future. But more often than not when I'm looking at a knowledge management system or a CMS, what I'm looking at is something that is difficult to get the information out of it's difficult to change the labeling system and organizational structure. And ultimately, the teams are just not ready to use the amount of information that comes out of machine learning and AI algorithms. So I think it's important to, you know, consider that but I also think it's important to when you're working with people say we need to focus on the foundational basics. How do we ensure that, you know, when a new version of our software releases that everyone finds the most recent version of documentation and not something that was published two years ago. So in conclusion, I want to talk to you very briefly about the four things that I consider to be the deliverables of my job and how I get the information that I need to, you know, execute on those deliverables. So first, I have user interfaces for my, you know, content management software. I also have to deliver governance and flexibility. So essentially, building search experiences that have the tools, and also the informational flexibility to to accommodate new forms of knowledge into my collection. So, you know, talking with users and understanding the jobs that they have to get done is absolutely critical. Also talking with people about taxonomy and metadata is important. And it's something that, you know, again, maybe intimidating to people at first but usually when you explain it as a good labeling system, you will get people interested in it because people love to go from the vague to the specific, especially if it means that the things they put effort into writing or creating get used. Now, when you start to get more advanced and things are, you know, more sophisticated, working on application integration, bringing data from different applications together, and also managing and analyzing organization data becomes instrumental. So a lot of that work comes in understanding how different software systems connect. And so, you know, in our case, we're building a virtual data infrastructure that sort of collects all the information that's coming out of our systems and also makes it easily accessible. So little API connections can be built. You have loosely coupled applications throughout our environment. And then ultimately at the base layer, you can pull all of our enterprise data out and, you know, slice it, dice it, analyze it using some very sophisticated techniques. But again, that data access and integrity making sure that things are, you know, tidy and prioritize for truth is, I think, one of the primary things that I bring to the table and that my team works to achieve. Now this is, Truth Happens is one of the watch words at Red Hat, our CEO Paul Cormier, you know, is really fond of saying that we simply don't understand what the truth is going to be in the future. We only understand the truth that is now, but it is constantly happening. It's constantly evolving. This is why we participate in open source. We like things to go rapidly. We love innovation. We love learning where we're wrong and improving. And I think what, of course, one of my favorite quotes about the understanding of change and how truth and how, you know, authority and expertise can shift over time is the statement that Bill Gates made in the 80s about how 640K is about as much computing power as anyone could ever possibly want. We all know, especially Bill Gates knows that that is not the case. I appreciate your time very much at the very end of the day. I think that my job is rewarding, because I have an opportunity to work with software, work with people who work with software, and work on search experiences with an eye toward ensuring that, you know, we're communicating, not just in a comprehensive way, but in a meaningful, trustworthy way. I appreciate your time. I welcome you to reach out to me on LinkedIn if you have any questions. And I hope you have a magnificent day. Wow, that was a really well delivered talk. Thanks, Anna. Folks, if you have any questions, I think we just have about four minutes or so. To take questions. So if you do have questions, feel free to drop them in the chat. And Anna will be able to respond. And I, there's any questions and you'd like to, you'd like to come on video. You can just request to share your AV and then you can, you can talk with the participants. But if we don't have enough time, I guess we can move over to the breakout room. I will put a link as soon as I find it in the chat. And we can head over there to continue with this discussion.