 Thanks for joining, and this is, by the way, my name is Ludinio Santos. I am a designer with IBM, my colleague Carl Svonsson, an offering manager also at IBM. Today the topic is administration of Cloud Foundry in the enterprise. And as something important that emerges when adoption of a technology like Cloud Foundry scales up to the enterprise's administration. How does an enterprise manages all the resources and activities around that technology? Things like users and their onboarding, their access control to capacity, the infrastructure capacity to things like version updates, serviceability, support. All those things are the kinds of things that we'd like to talk about today. And actually, I say that's not quite exact because I said we are going to talk about. And the reality is that we would like to do this session a little different. Usually you have a presentation where people like us present to the audience. We would like this to be more of a participatory design thinking session, sort of a workshop. For the purpose of understanding the users involved in the administration of the Cloud Foundry in their enterprise. So the idea here is that US community will help to define those needs, the administration needs of the enterprise and sort of collaboratively will come up with an approach and defining the needs of those administration needs for the community. And as a designer, something that is important for us is to understand users. That's the foundation of everything. So we would like to start defining and outlining those administration needs by better understanding those involved in the administration. And sort of the exercise today is that we hope your engagement is about defining users and user tasks. And the framework is something that we call enterprise design thinking, which is about empowering teams to deliver better user experiences. And this is the framework where we at IBM and other companies, people approach the design of solutions starting by understanding the users. And in fact, talking about design thinking, we thought that it would be good to give you a quick, very quick overview of what design thinking is. And Carl is going to give us an overview of that. Thank you, Carl. Yeah. So as Lucidio mentioned, design thinking is basically a concept where you don't only take into consideration what you think your user is looking for or what you think the market needs, but actually taking time to drill down to users, getting their feedback. Definitely not a new process, but definitely something that bears careful crystallization to make sure it's handled at a consistent pace, rate and pace throughout an organization. Lucidio, for example, is one of our key designers who goes through design thinking at great depth as we're going through projects, like the one we just released recently. It's a combination of what is the business case? What are you actually looking for? What are you trying to market? Technology, of course, is important, but really it comes down to the user experience. Who's going to be using the product? What do they expect and why do they want it? Drilling down. And we're going to be going over that concept in brief during this session. It actually brings back real and measured improvements for projects. Increasing team efficiency, return on investment, and much faster time in the markets. IBM has done some significant measurements over time, projects that do and don't use design thinking. And it really does improve the experience quite a bit and the overall outcomes of the project. So we'll go through that and then at the end we'll have some references. One of the things that IBM likes to do is talk about the design thinking concept. So there's a vast amount of material you can download for free and actually use it internally. If that's what you guys want to maybe do, kind of see what the experience is like. Thank you, Carl. And in fact, there are, as part of the design thinking framework, there are a number of methodologies that are used to understand users, anything from user journeys, empathy maps, scenarios, scenario flows, and so on. Today we're trying to compress, given our time constraints, we're trying to compress all this in a simple exercise in which we are going to ask you to define or tell us about who has any Cloud Foundry Administration responsibilities in your organization. And by that we simply mean defining the roles who is involved in administration, the tasks, what do they do, the goals, what are the business goals behind those tasks, behind those roles, why are people administering those Cloud Foundry resources and activities, and finally obstacles. What are the obstacles that users and enterprise encounter when performing those tasks? So the exercise is simply going to be about laying out the roles, and what we have here is just the subset of the roles, the obvious ones, the administrator, the lead developer, the developer, but then maybe other roles that perhaps you can tell us about. And the idea is simply to write down a short description of the task, along with the goal, what is the ultimate goal that users are trying to achieve when performing this task, and what are the obstacles that they encounter today when performing those tasks. We have a fairly obvious example, fairly straightforward, where we are saying, well, onboarding users to organizations and spaces is an administrative task. The goal is to ensure that developers have access to the right resources and only the right resources. So there is an implicit goal of access control here that we don't want to lose sight of when designing a solution around this task. And finally, what are the obstacles that you guys or perhaps the people who administer Cloud Foundry in your organization have? Maybe at the level of, well, I don't have access, easily access to the IDs to the names of those folks. So it's hard to identify or I may have to onboard one user at a time where I would like to do it in a more efficient manner, perhaps. This is just an example. And we're hoping that perhaps you can help define other tasks, perhaps other roles. And so if we go back to that previous chart, what we have over there right with Simon is working on his ThinkPad, is sort of a whiteboard where we hope that we can write down these kinds of activities. So perhaps wondering if any of you have any ideas or would volunteer to speak up and tell us about some of these tasks, perhaps some of the roles that are missing there that maybe we could write down. Anybody? Anybody, whether it is an administrative task that you perform or somebody who you know perform these kinds of administrative tasks? Again, we're not talking only in the domain of user administration, perhaps security, yes, you have. Actually, would you mind standing up and tell us your name or where you come from? My name is Zenon Hannick. I'm from a company called Armacuni, a cloud native consultancy. In an ideal environment, when we go into clients, we like to build a continuous delivery pipeline for Cloud Foundry. So it's delivering Cloud Foundry through a pipeline. So would you consider that defining the pipeline or managing it? I suppose the original thing would be to define the pipeline. And ultimately, this may seem obvious, but what is the ultimate goal for the company to do that? Automated deployment of Cloud Foundry and kind of zero downtime and deploying any pipelines kind of automatically without any kind of manual intervention. Automation and minimization of downtime. And what are the obstacles, if any, that your company experiences when performing these tasks? The major one is probably conceptual, people not believing that it can actually work and that's the way to do infrastructure. People often feel that it should involve manual steps and they need someone there to press a button before a change is made because they don't have faith in it working automatically. But then also, particularly, we work in some highly regulated environments. There can be issues around governance, security testing and things like that. So the fact that there is a cultural obstacle, of course, people don't quite believe so they don't take the step to actually do it because in the end, they don't really believe that it's going to work. And you also mentioned some perhaps regulatory issues that prevent them from doing them easily. Now, who would be performing this task? Or any of these folks or perhaps other folks? We have plenty of room here to gray down additional roles. It depends how it's set up, but we're trying to get the idea across of a kind of product team, a platform product team. So rather than it being an administrator having a team who's responsible for developing the platform as it were. How would you perhaps label that team? I mean, you could call it a platform engineer, you could call it a kind of... Platform engineering team, yes. Lots of people like to say DevOps, but I wouldn't necessarily call it that myself. Very good, very good, excellent. You can call it DevOps. Excellent. Thank you very much. Anybody else perhaps has any thoughts? Any other thoughts? Pipeline, think about maybe monitoring, managing availability, managing capacity, making sure that people, yes. Your name? Yes, Jim Brown. Yeah, a particularly important area for us is the management of access to user data and the regulatory environment and what kind of opt-ins users have given. And so matching that to access across the company into different pipelines for that data. So that's a major task area in the administration. It's not quite DevOps. It sort of rolls over into business information type systems and because you're managing opt-in, et cetera, and then there's legal and regulatory restrictions. So that's quite a complex task area that needs to work seamlessly. So complexity because of the nature of the various data sources involved? Yeah, and it's constantly changing. For example, you may opt-in today, tomorrow you may have opted out as an individual and therefore your data should be exempt from a particular pipeline or activity. So you may have opted out for targeted advertising and therefore you should not be, your data has to actually not be submitted versus someone else's maybe. So it's a very fast moving environment including user preference, end user consumer preferences. So it's quite a complex environment and there is no really good solution for today in terms of automation. Who does perform that task today? It's done basically by making sure that you only collect the data where you have all the permissions. So it's not as nuanced as it should be and so there's an inherent inefficiency. So that is an element of policy, the final policy. Right, you'd be better off if you could be more nuanced. If you could basically say, you know, okay, of all my users, take the intersection of the ones who have opted in for this, this, use their data this way, others use this way. So there's no clear solution for that. Yeah, and who does, if any, today, who is involved in creating those policies? Oh, it's the product teams at our customers. So it's not, it goes back to the product team and the business information teams at our customers. That varies from OEM to OEM. Yes, thank you very much. By the way, anybody's welcome to come up here and get one of these sticky notes and create your own. But in the meantime, anybody has any other thoughts about administration? I'm wondering who does capacity planning, for example, in terms of ensuring that the infrastructure has the right amount of power, memory, CPU. Do you guys encounter this kind of situation? Anybody? No? Understanding demand and then mapping that to supply of system resources. Yeah. So that's a major undertaking. And how do you do it today? Well, demand is generally part of business case. So there's business case that starts at the product level that says, you know, I need this facility. I will therefore generate this much activity. That activity needs to be mapped back into a demand planning cycle and then you put the resources in place. Then you have to fine-tune it. So there's two stages. There's this growth stage, which is part of the business case. And then there's a fine-tuning stage, which is part of what's happening on Tuesday versus Thursday. So that comes out of the monitoring. So it's a combination between the business planning group and then the DevOps groups. And is somebody on a regular basis monitoring the ups and downs? Well, it should be. Is it more than one group or more than one people? Or is somebody in charge? Typically, it's one group in the IT and enterprise services group, is what I see mostly. Again, we don't do it ourselves. We work with customers. So it varies from customer to customer. Very good. But yeah, normally somebody has responsibility for that. Let me show you perhaps. We have come up with a bit of a model that lays out how we envision these kinds of administrative tasks to roll out. And so what we have is disciplines like user management, application management, service management, monitoring, change management, capacity planning, incident management. Because this is something that when you have a platform at the enterprise level, the understanding is that there are going to be support issues, serviceability, and there are going to be cases where people have to create incidents and manage and follow through to them. And so we have the cloud architect, the dev lead, the developer and the administrator as the key administration roles. And so there is going to be some overlap, but you are going to have a concentration of user management tasks around the development lead and the developer, obviously around organizations and spaces with a heavier load on the development lead or a scrum lead, a manager, with an architect having an initial role, particularly around onboarding their own administrators, the initial onboarding to the key people into the platform. So once the platform is created, somebody like the architect, the cloud architect, is going to set up some demo evaluation environments, give access to an administrator and perhaps one or two lead roles, and then they are going to take over some of that user administration. Then obviously the application management is going to rely on the actual developers who are going to do most of those application management tasks. I think there is also an element of DevOps, which in a way, and I think that brings back what you mentioned earlier, that it's not necessarily just an individual, but it's going to be a DevOps team, an engineering team, who is going to do a lot of these tasks and strive for automation. We mentioned service management, change management. A lot of these are going to fall on the side of the administrator, who is going to perform a lot of these tasks on a day-to-day basis, ensuring that there are a certain baseline of infrastructure capacity available, monitoring the use, monitoring how those resources are being used by the various teams, by the various business units, that there is an element here of charge back within the organization, and following that sort of flow that you mentioned earlier about the business case and planning. I think that that seems quite an important administration aspect. That is obviously to the monitoring, monitoring availability, health and performance. This is more of an operations task, where people need to make sure that the platform is up and running. Again, we're talking about an enterprise level. The belief is that there has to be a set of individuals or teams who are going to make sure that that platform is available, monitoring the status, and following through when there is a problem with that platform, contacting vendors and performing whatever tasks are necessary to bring that, communicating the status, the availability, or not availability to the consumer population. Performance is something that could also fall under that category of monitoring the availability of the system. I was curious what do you think of that sort of model? Is there anything missing perhaps? Does that make sense? Does anybody know or is aware of any of these tasks being performed at your organizations, at your teams? Or a situation where you wish that you had a tool or a process in place to better administer these things? Any thoughts? How about application management? Scaling, load balancing? Do anybody perform these kinds of tasks on a regular basis? One thing that we wanted to mention is that we have a Twitter handle. If you want to continue the conversation, if you have further thoughts, that you're always welcome to, if you have other individuals that would like to join this conversation. Organize something that we'd like to take a long-term approach to defining this administration task and needs. So we can always continue the conversation there online. Yeah, go ahead. Are you looking to do a sort of a single approach where there's sort of, how strict are the roles and how do they map into the RBAC mechanism? I would assume that this eventually ends into the situation of who has access to which APIs as well as which dashboards and what can they do with those things, eventually. Once we have an understanding of what are the administration roles and tasks, the idea is to make sure that we provide the right tools to the right people. Although, as you said, the idea is not to have a closed system because in many cases there may be an overlap. And sometimes if you have a dashboard that monitors, for example, resource usage, resource usage is something that administrator may be interested in, obviously, but also an application developer. So if you are developing an application, you may be interested in having a view into how the various memory and CPU resources are using a particular cell within the Cloud Foundry so that you can evaluate your balance and your load balancing needs and make sure that your application is running right. So there are situations where the same dashboard may apply to more than one role, even though there may be certain tasks that are within that particular dashboard. You, as a developer, may be interested in one thing, rather than the administrator who is interested in more infrastructure, sort of, making sure the supply is meeting the demand as opposed to an application developer focusing on his particular application. Would you have a mapping or some sort of list of what open source projects or open source subsystems that relate to Cloud Foundry are within the scope of this work, or does it relate to the IBM distribution of Cloud Foundry and the sort of ecosystem IBM has with Devoli and all those other infrastructure tools? Also, in terms of mapping projects, ongoing projects to an administration sort of model? Well, yes, I guess, if administration is the only aspect. I mean, if we are talking about sort of a DevOps approach, I would assume that, and you had developers there, and if you go to DevSecOps, then you have the continuous compliance and blah, blah, blah, thingy, so I would assume that you will be suddenly bombarded with a few other roles as well as well beyond admins. Yeah, we were seeing more of a conceptual level, simply understanding what are the administration needs for the enterprise specifically. So that's something that everybody would be aware of and so that anybody either establishing a best practices system in the organization or a vendor would be able to provide better tools and solutions towards that model, making sure that all the administration needs are covered by any solution, whether it's IBM or another vendor or whether it's an open source initiative. Okay, thank you. I think this... Yeah, probably that's just a reiteration what I understood just to clarify my understanding. I understood you are here offering a set of best practices, roles, descriptions around the Cloud Foundry ecosystem. That's not so much specific about how we, IBM, are providing a service, right? Yes, it's not about IBM, it's about having a common understanding of what are the administration needs, Cloud Foundry administration needs in the enterprise. I'm a developer of Cloud Foundry and IBM of the platform itself, so I perform a number of that tasks. I also have my own Cloud Foundry applications running on Cloud Foundry, so I might also perform some of those roles. And so, yes, for me it makes sense, the roles that you list and the tasks that are required, and it's probably a good thing to give somebody a good overview who's diving into that Cloud Foundry ecosystem. Yeah, but what do you think? Is this a complete picture? We have aspects that are missing perhaps in that administration landscape. And I think with any of the Cloud Foundry windows out there you can map this model and then choose different implementations and tooling around that. Yes. Yeah, exactly. But again, before we take this, we want to make sure that we have the right model and that meets the realities of the enterprise, as defined by the community itself. So is this an initiative then beyond IBM? Is there somebody else? I wouldn't call it just an initiative. It was simply sort of something that we wanted to understand better. Okay. We wanted to understand the roles and the tasks involved in the administration. Not so much an unofficial initiative, although it could lead somewhere, to something like that if needed. Yeah. I'm just wondering with respect to the community. I've been, I'm not, I'm foreign a bit to the Cloud Foundry community, but I'm just wondering beyond the technical projects that they have or working groups, whether or not this sort of thing would be best served as a sort of a working group or a project with... Possibly. So you're thinking of maybe a project or not necessarily a technical project, but more of a working group. Conceptually, I mean, you could have guidelines, documentation projects, and you could have those sort of that relate to more of the documentation or testing or then on the other hand of operations and those sort of things. So I would assume that you could create projects around those. At least in other open source communities, those have been available. Does something like that exist in another sort of domain that you know of? Well, my understanding was that in Kubernetes you have these special interest groups and I think the operations beyond just the class administration is also about the best practices and the best practices in few of those six. But the six are so... There are so many Kubernetes six that I'm unfortunately not quite sure what each of them are doing, but my understanding was that they would go beyond just the technology development projects. Yes, good, understood. Thank you very much. Any other thoughts? Any other final thoughts from anybody? Questions, yes. All right. Let me close the session. Thank you very much. I think as I mentioned, oh, by the way, you have that link if you want to know more about enterprises I'm thinking and definitely that is your welcome to continue the conversation in Twitter. Thank you.