 All right, welcome, everybody. Welcome to our session, Meet the OpenStack Personas. We have an Easter path set up with a lovely bit.ly link, bit.ly slash OpenStack Personas hosting. So we have a link to the presentation included. Also feel free to add in any comments or questions in the Easter path. And while you're doing that, let's get started. Welcome. And welcome to our session. So the session is about the personas around OpenStack. We're talking about the roles model companies around the cloud ecosystem for OpenStack. And the goal of this talk is really to help those that community understand who our users are and to add clarity when we're having conversations about these users around OpenStack. First, oh, let's see. How should I? Oh, yeah, there it is. There's a slap. Yeah, so the presenters. So we have Buster and Pete over there from Intel. We have Jeff, Shamal over there, and myself Stan from IBM. I will also highlight that Pete represents the UX project for OpenStack. He's a project PTL for the UX project. And Shamal represents the OpenStack product working group. And we would also like to dedicate this presentation to Jim West, Jim in the middle of this photo, in the center of this photo, typing out his laptop. At the time was a senior architect at HP. And he definitely helped us in building that understanding towards operator as a subject matter expert. Unfortunately, a couple of weeks after he participated in the Austin persona workshop last year, he passed away. So we wouldn't be able to get this far with the persona without his help. So we would like to dedicate this presentation to him. So yeah, to get started, I would like to talk a little bit about who are personas. A lot of you might have worked with persona before, just so that we are on the same page. Personas are a representation of your key users. It's usually based on either qualitative or quantitative accommodation of both based on this research. And as an example on the right, say dog, that's our persona for the domain operator. You can say it's usually depicted as a specific person, but in no way is a representation of a real person. It's by no means a real person. So by using the personas, it really helps the team to understand and to build on this agreement of who the users are and to help them focus, really focus in building, designing for a specific type of user. And you might wonder, so OK, I'm a developer. I don't really build graphical user interfaces. I work on backhand or I'm an operator. I don't really care about persona as well. Personas are relevant to you if, say, you're a developer for developers in the audience. The persona is really relevant to you regarding to any type of interface, like be it graphical user face, be it CLI, be it the APIs. And on a high level, persona helps you to validate the assumption that you have on what the user would do with your product. And it really helps you to determine what features, what you need to build, and what you don't need to build for your product. And at a detail level, persona helps you to determine, say, the specific roles of your product, specific user roles. Helps you determine the arrow messages. Helps you to determine, say, the terminology. So even the default values of your product. And for the decision makers in the audience, the persona research as well as other research really helps you to understand the Cloud adoption strategy. We'll cover the cost or the benefits in doping to Cloud. You also help you to understand how well your company fit into this Cloud ecosystem by comparing your company with other model companies that we have from our research. Before we jump into specific research findings, I would like to highlight that it's really based on solid user research efforts. So we had a set of three workshops. We had a persona validation survey. And during the three workshops, we had a set of around a dozen different user-visual activities to help us in building these findings. So what was it? So we did a round of 20 user interviews and analyzed the data during the first workshop at React Space, we did a cost-shorting activity with three subject matter experts at the second workshop at IBM Design Studio in Austin. So now I would like to hand them my go over to Jeff, who's going to talk about the findings. Okay, so I am going to talk about the artifacts that we've created to help the OpenStack community provide more clarity about who users are, how do they differ, and what are the ecosystems where they work. And so we have not just personas, but we have a concept of model companies and we'll get to that in a few minutes. So this is one of the first things that we created, which was it came out of the second meeting in Austin. And so this is kind of a set of roles that map to a moderately or larger sized cloud environment. And it starts in the middle with what you'd call central IT or in a managed scenario, that would be the managed host. And then moving outward you're getting closer and closer to what you might call end users, but hopefully we'll convince you not to call anybody end users by the end. So the red is showing the personas or the roles where we focused on creating personas. And the gray are ones that we acknowledge are important, but we haven't delved into them yet. So we've all, okay. Okay, so in the middle we have data center ops. And then moving outward we have automation engineers, the service admin, so that would be the owners of different projects in OpenStack. CloudOps, infrastructure architect. So that's kind of the core. And then as you move outward you have domain ops, the developers, what's that? Sure. It's the top one. Okay, the project owner and then developers. Okay, and so, what's that? Yeah, so we included, we uploaded the presentation and we have a link in the user path. So you can definitely like, our reach through like after the presentation. Yeah. So I think a lot of these may be a little hard to see if that one was. So this is showing the different stages of cloud adoption and we map the roles onto them. And so what you can see is that there are some that are present throughout many of the stages and those are probably OpenStack Summit attendees. And then there's a group of them here, which are, you might call the end users, but these are the people who have not much investment in OpenStack. They're developers, they use OpenStack because that's what they have available. And if you're not providing them something that's easy to use and that's solid, then they're gonna go to AWS or someplace else. So they really need things that are focused on getting started and shortening their learning curve to get moving on OpenStack. The other ones, they're gonna delve into all the details and learn everything there is to know about it. And they are important and we want things to be easy for them, but they have a lot more tolerance for pain, that's a good way to put it. Okay, so this is the OpenStack personas. So these are based on the roles that we showed on the previous slides and I guess I can read through them too. So the two at the bottom are who you might call the central IT people or people who would work for a service provider. So there's Arnie, the infrastructure architect and Carlos, the cloud ops. So again, those are hopefully representing a lot of the attendees that are here. And then starting up at the top, there's developers and developers work together so they need somebody to manage the projects. So there's a team lead or a lead developer pay. And so she's really gonna be concerned with she's gonna be a developer too, but in terms of OpenStack, she's gonna be managing the users, possibly managing some policies, things like that. And then there's Doug, so Doug is a domain ops. And so you may have that kind of role in an enterprise setting, but you'll definitely have it in a managed provider setting. So that's the person who makes sure their provider is meeting their SLAs, that things are working, that it's running fast enough and so on. And also doing troubleshooting on the customer end. So with each of the personas, we have a description. And of course they have names and job titles too. But we have a description and then we have what does a good day look like in a bad day? And we'll make those available externally and if they're not readable now then please check them out later. Oh, good. Okay. Doug is on the, so the easiest way to imagine is to think about it as a hosted relationship where somebody's providing the infrastructure and Doug works for the customer. So Doug makes sure that the customer is getting what they expect out of the infrastructure provider. He's a part of the customer, but he makes sure the infrastructure's there. So in a large enterprise it would be probably a bit more informal role if they're using domains, but in a service provider type of environment he will definitely be there. Someone has to make sure that the provider's providing. Does that make sense? Yes, he would work on the customer's side. Actually the next slide will show that better. So that's kind of getting at one of the key messages is that roles that IT is complicated and that there's a lot of different types of business relationships. And so you really need to understand the different types of ecosystems. And so what we've provided here, and I don't think this is a complete list, I think maybe telecom is one that we're missing and there's probably other ones too, but the idea is to sort of have these personas of companies. So the idea of personas is pretty standard in the industry, but this idea is fairly cutting-edge. At least I haven't seen a lot of people presenting things like this. So on the left we have a research university. So they have a pretty informal setting. They even installed OpenStack. There's not many rules. They send an email when they need to, when they think they're gonna use a lot of capacity. It's not terribly structured the way things work. They're assuming everybody's gonna be a good partner. On the far right is an enterprise, and so enterprise is gonna have much more formal processes. They're gonna be very concerned about security. They're gonna be very concerned about compliance with various kinds of regulations. They're gonna have much more formal roles in the ecosystem, and then in the middle we have a service provider relationship. And so the service provider relationship is actually backwards in the title, but the MOI would be the customer, and Nuage is the provider, and so they would be providing a service to their customer. Many of the, so they're gonna be very concerned about security and keeping their customers from seeing each other's data, but many of the other things are gonna kind of inherit from their customers. So they comply with HIPAA or something like that. It would depend on who their market is. But then within each of these, they may have different sets of roles, which we haven't created personas for all those. We've kind of just picked one which we think is capturing most of the complexity that you might see in all the other ones too. So we really base the personas on a service provider customer type relationship. As you move to the other ones, you may see some of the roles disappear. So you may see Doug, the domain ops guy, not be a formal role in CNBB. In the research context, he won't be there at all. He'll be probably an administrator and lots of users. So then this is showing an example of drilling down into the model company. So these are still the works in progress, but the idea is to show what's important for these different kinds of companies. So Nuage is a service provider. They're very concerned with security. They don't want their clients to see each other's data. They don't even want most of their clients to know the other ones are there. Most of the time, they need high reliability. If they're not there, then their clients are gonna go somewhere else. Compliance is gonna kind of be inherited from what their customers need. And then I see a lot of other places that you could fill in here that would be characteristics for these different kinds of customers. So now that we have that, I am going to hand it over to Shamile, who maybe we should have warned. I was listening. Okay, so I work in the product working group within the OBSAC community. And so just an overview of who we are is we're a group of product managers in particular, but technologists, operators, et cetera, that are either building open-stack-powered products or consuming open-stack at scale. And so our goal is to identify user stories in the community from operator feedback, from market feedback like Telco Enterprise and other verticals, and document them so that way we can all collaborate on the priority of them and resources to get them from concept to reality, more or less. And so naturally, as a part of what we do, the user story is a critical artifact that we generate. And in a user story, basically, you have the problem definition, you have what the opportunity or justification is like, why is this problem a problem? And then you have user stories of as a role, I would like to do some capability so that I can achieve some benefit. And so as we document those, when we started the product working group in our user stories, the work being done by the UX team around personas in the community wasn't there yet, so we kind of just randomly chose roles to build. And the result of that was very generic roles. So everything became as a company, as a cloud service provider, or as an open-stack user, or as a app developer, there was not enough context to be able to say, why is this role interested in this capability and the benefits? And so one of the things that we're doing now is we're actually going back into our user stories, and this is actually a real example of the capacity management user story that we have, which was before as an open-stack user, and we're gonna go in and replace that with the domain operator, because the domain operator is really interested in being able to manage the resources this provider is giving him or her. And so we're gonna go back in, and I think with the addition of the personas into the user story, it makes the user story kind of be more compelling, and the context becomes much clearer in that regard. Another way that we're actually using them, and this is actually happening right now, there's other members in the product working group who are presenting a cross-project themes update. And so in the product working group, we also like to define as we're capturing requirements and we're also getting roadmap information for projects of themes. So basically, if a team is working on a capabilities like Cells V2 and NOBA, is that for resiliency benefits, manageability, scalability, interoperability, or modularity? And so Cells, by the way, is for scalability, but as we're doing that, we're now also starting to look at, okay, how can we help prioritize themes and identify themes through roles? And a good example of that is one of the slides that they're showing right now is they have the different personas, and one of the new themes that we're thinking about now is security. And the reason we're thinking about it, because security was a theme that regardless of the persona, it had impact or had some interest to that persona. So we kind of looked at themes and said, okay, out of the themes that we can discuss, which themes would have the broadest impact in the sense of personas? So that was another way we were able to leverage the personas to help make a decision within the community. And so as we move forward, we're collaborating heavily with the UX team and we're gonna start definitely integrating more and more personas into our work going forward. So it's been very helpful to have it. So just to close really quickly, we wanna talk a little bit about the user experience vision for the personas. And one of the things that we really wanted to do in the community is to build a common language or vernacular. You know, I want you to take a look at this quote right here, it really boils down to being, to having OpenStack act more like a single initiative versus a collection of projects. And this came from the user survey a couple of months ago and it was a very, very common theme. People, particularly the operators were pushing back on us because they felt that there's so much isolation between the projects and lack of coordination that it was becoming confusing for them. And it was small things like the idea that, you know, do you call it a tenant? Do you call it a project? Well, what's that? Is that you? Okay, could you stand up for me? I need everybody to turn around. Okay, good, good. So what we're trying to do really cross projects the drive consistency and how we talk about our customers within the community. And that goes from the OpenStack Foundation who we're working with, the user, excuse me, the user committee product working group, of course, and the OpenStack UX and specifically the individual projects as well. And, you know, we're doing that. In fact, we're doing that right now. We're having a meeting in a couple of weeks with the foundation to talk a little bit about their roles because as you know in the survey, you self-identify by role. And having that consistency, one of the things it does for us is the qualitative data or quantitative data as well that we generate from the user survey can be, if you will, more easily consumed by the community if we agree on roles. Otherwise it gets really hard to coordinate. So call to action. So a couple of things. I think the first one is particularly important, which is we really need you to start using or integrating these personas into your discussions as projects, right? So what we're trying to do is push the community away from talking about generic users because it's so incredibly vague that a borders on meaninglessness and start talking about, you know, start talking about Doug, start talking about Arnie and what Arnie's looking for and what Doug's looking for. And I think in particular, start talking about Arnie in context of the type of company that he works for. Is it a large enterprise? Is he a service provider? Is it a nonprofit? And that way we'll get a little more specificity and a little bit more focus on our features. The other thing too is we want you to participate. So there's a couple of ways you can do that. One is we are documenting the personas. We're working closely with the documentation project. As you know, then that's gonna go up for review and people can leave feedback. And it would be awesome to have people go in there and leave feedback and talk a little bit about whether they agree or disagree and how they'd like to change it. That would be awesome. I think the other thing too is this is gonna be a work in progress. And I would imagine that we're probably going to have, I wanna say meetings probably twice a year with various people to talk about the personas. How do we wanna update them? How do we wanna make them more useful? And so it'd be great to get participation in that as well. The other thing that I do wanna mention too is important to me is also discussions around the presentation of the personas. There's a lot of ways that you can sort of socialize personas. And what I wanna make sure is that we tailor that socialization or presentation of the personas to the community so it's consumable. So contributors. One of the things that we did wanna emphasize is this wasn't a couple of people in a room deciding that we wanted to have personas in the community. This is actually a collection of 15, 20 people that participated in it. It was cross companies. So we had IBM, Rackspace, HPE, Intel that were involved among other companies. In addition, we had subject matter experts. We had designers. We had operators. We had product managers as well that were all involved in this process. So it's very, very collaborative. So, have any questions? Wow, you're quiet. Anything at all? I'm calling out names. There we go. It always goes, I'm gonna let you go. Make sure you go to the microphone too. And I'm gonna have you guys come up here with me just to make sure that we can all answer questions. There's a URL there too. And you're also more than welcome to reach out to me if you wanna meet me afterwards on the PTL for the OpenSack UX project. So I'll definitely coordinate with you. We had somebody over there. Okay, thank you. As a product manager, I'm very close to personas and thanks for the great job. And I would love to contribute towards the community putting together personas. Question I have is about buyer persona. Did you guys consider it at all so far in the context of OpenStack? Is there a new buyer persona evolving? Sorry. So yeah, one of the things I think that Jeff sort of emphasizes is that when we showed the role ecosystem with the levels of distraction, remember the ellipse. So we chose to focus on four or five and it was just sort of us sitting down trying to identify what we thought was the most important. You know, we may have been wrong, but that's what we wanted to focus on because we had so much time. Now, I think it sounds like a great persona and my recommendation is to reach out to me, Jeff or somebody else and talk a little bit about that. And the next time we have a work session, we'll bring it up. Sure. Yeah, it's a good idea though, it's a great idea. And I think too that they are very related to the different kinds of ecosystems and so they really would probably be, It'd be interesting. It would be something we would add to that. And same things with other kinds of decision makers. And also, I would add the persons that we have, one of the activities we did in the last workshop that I attended was we actually mapped tasks to different persons that we built. And so buyer wasn't a persona that we identified, but the element of decision making or influencing was some of the tasks that were associated with some of the persons. So I think when you look at the documentation that's being built, you'll probably find that there might be elements of what would be a buyer persona spread across the persons from a task perspective. Yeah, I would like to highlight on like second on that. So if you look at like the cloud adoption stages, like the first stage is decide. That's like the buying decision that happens there. The other thing I wanted to add as well, is it's sort of an interesting, it's interesting that you brought it up because now you have me really thinking about it. And that's a pretty compelling persona because it does change significantly across the company type. So it's a great suggestion. So Adam Young with Red Hat and I'm a Keystone core and I want to say that this is absolutely fantastic. This is really getting to the heart of some of the questions I've been asking. I've been working on dynamic policy and on roles as the Keystone as the role-based access control implementation, which I think is gonna be the first consumer of the wisdom that you guys are gathering here. This is exactly the kind of information that we need to feed in. I'd like to point out some of the other efforts that are going on that are gonna be really complimentary. I think are really gonna be able to take what you're doing here and make it practical. One which is, and I'll be talking on this tomorrow on the advances in roles and role-based access control in Keystone, specifically the domain specific roles which are supposed to be a tool for a domain admin to give their own names. So once you have personas there, you can say this is the set of personas that apply to my domain or my deployment here. But the way that you're framing the discussion and the thing that I really like, especially that last thing I just heard about tasks, is I've often thought of this as access and obviously that's not the entirety of what roles are used for, but you identify a person, what they need to be able to do as their top level assigned, call it their role assignment or their job assignment, a middle tier which is the workflows and those are going to be reused across multiple personas, across multiple jobs and then at the finest grade level what APIs are actually able to call and to be able to take what you're using there, you're defining there and drive through a diagram and analysis for a given deployment or multiple deployments. You're giving us a really good language I think to talk about this stuff and so we'll try to consume this and use this as the way to drive what we're doing with dynamic policy and with access control. So I just wanna say thank you and I'll tie in with you guys afterwards. Yeah, that's actually a couple of things actually that I wanted to address. I think one is we are having, we were planning actually to have a meeting with some of the people that are doing the common policy roles in a couple of weeks and so it's gonna be a meeting with you folks, the foundation's gonna be part of that so they can adjust their survey and it's gonna be us as well. So I'm excited to do that. The other thing that's pretty interesting goes towards tasks is about nine months ago the foundation actually sent out a survey and it identified like a huge list of tasks and had people select them based on their specific role and it would be really interesting to do a cluster analysis on that to see how those roles sort of grouped because I think that's some serious quantitative data that we could use for sure. So you had a question or did anybody else wanna follow up? Okay, next question. So I was wondering whether you have differentiated between the size of the customer in the sense that whether the customer is a customer like Sun or Yahoo or PayPal, eBay or the customer is a enterprise customer with a capacity of maybe five to 10 racks or something like that. Have you differentiated because depending upon the size of the customer we may not have all the people that you have highlighted. Yeah, so I think, so the idea really is that those formal roles emerge more as companies get bigger and you're totally right and it's sort of an art of balancing having too many different choices and being able to capture the right level of variability between all those different roles. So we definitely think about it and we have to restrain ourselves from creating a lot more of the different kinds of model companies and ecosystems. I think we need some work to figure out what works but we're definitely conscious of that. I'd like to add on like so from not the person's perspective from the enterprise working group perspective we also work on publishing materials that can help people that are new to OpenStack learn what the capabilities are how to move from evaluation to deployment. But one of the questions we had in that exactly was is company size a factor? But we didn't include it because we got into an internal debate about when you say company size is it the number of employees? Is it the scale of the cloud? Is it the percentage of revenue being allocated to R&D and cloud budget? Like what is defining size? The budget or the people or the scale? So the other question I would like to get answerable I don't even know that you can answer yet is are there roles in the organizations that need to be able to do jobs that they can't do because of the structure of OpenStack? That Joe, he's that middle tier that domain operator that you have there. There's things that he's not able to do because in order to do what he has to have admin and the IT and the people who manage the physical resources are not comfortable assigning him that or they have to give him that and in doing so they're identifying that they are violating compliance or they're making something much more powerful available to somebody who only needs a limited thing. Are there places as we go through where the access control obviously I think in terms of that but the abstractions that we have across the board and it may be on the network level or whatever don't support the set of roles or the set of personas that we're identifying that people want to be able to have and that they can't because of gaps in what we're doing. I think we need more research in that area. I would bet Doug would probably be the place where that would be the biggest problem though. Because he's sort of a role that might be new to a lot of the OpenStack community. Have you guys had something like that? It's like an observer, is that right? Somebody who can look, the cap, or a... That's been a big request and being required. Right, yep. So I agree, I think Doug would be the one that probably would hit that. An example of that that I've heard in the past ops summit was there was an operator who needed to be able to audit the size of all the center volumes that they had across all tenants. And they could do it per tenant, but then basically he had to basically run the same command over and over again and aggregate himself because the way the policies were set up he couldn't traverse and get the full. That's actually a policy, at least he could do it. Yeah. It's painful if you do it. Exactly. It's not even able to do it. Yeah, exactly. That's the first thing I wanted to get into. Exactly, so I don't know any specific examples like that, but this was, yeah, exactly. This was painful, but doable, if you will. This is not so much a question as an observation. My name is Derek Kadzo, I also work at Red Hat as a content strategist for the documentation group for OpenStack and a few other products. I have done this kind of work before and dearly departed Nortel for their documentation. And back then when we were still delivering book structures to customers, this sort of stuff was very relevant and especially when you relate it to tasks as opposed to personas, structuring them according to tasks that people would find was useful because as you say, somebody who does maintenance in one company may not be the same person who does it in another company. But to your question about is the size of the company relevant for documentation, we found that it was quite a bit and this may still have a bearing in this environment as well. For large companies like Bell South, who was a customer for us, the expertise of the people doing the sort of low level work and using the documentation was much lower than in a smaller company. So in the documentation, we had to include much more detail in the task procedures for them than we would have had in a smaller company, even down to the point where at the end of a command we had to put and press enter. That's how detailed they wanted it. So for a larger company, that may be one factor that is relevant. And you did use organization size like some number of employees. In that as a way to judge small, large? Yes, and it's also a question that we're looking at today to see whether the larger companies are starting to get involved with right now will drive further detail required in the documentational procedures. Awesome, I'll keep an eye on that. Yeah. Thank you. So anybody else? We good? Yeah, I think we're good. So I appreciate your time. It's awesome having you here.