 Okay. Well, we're in for round two, at least for me. So, hi again. Fred Karris here from Ericsson and my colleague Ronnie and I are going to go through, I think, a topic that I hope will be of interest. It is a very interesting thing to me about what a system I call Agile SI. And we'll talk about that here in a second. So, once again, Fred Karris and I'm a principal consultant with Ericsson. I've worked on a number of large, very large enterprise private cloud developments and then the deployment and into the field. It's interesting, we call them deployments, but if you really think about them and you're going to see, they're really large system integration programs. So, and then with me is Ronnie Haddad. Ronnie is a cloud solutions architect also with Ericsson and he and I actually worked over the past year on a very large cloud sort of deployment system integration project. So, the situation is that enterprise private clouds are accelerating in scale, thank you, in scale and complexity. As you just saw, those that were in the prior discussion from Earl, you can see right now that it's accelerating in scale and complexity. The challenge, though, is while we're adopting agile methods in our development and DevOps for releasing cloud updates and so forth, we see, frankly, the enterprise is very siloed at the especially large enterprise and they move at very different speeds. So, we're going to examine some case study scenarios. That's what Ronnie is going to be an expert at and then talk about some solutions that we see from some models as well as technology for making other parts of sort of this equation of bringing the cloud together happen more agilely. And then finally, we'll talk about some new technology innovations that are on the horizon that will help us speed us along as well in the future here. Okay, so first of all, I'd mentioned about the enterprise private cloud accelerating here in scale and complexity. So, here's an interesting factoid. If you look at the size of the enterprise private cloud in 2015, it's going to be in 2020. So, at this point, four years from now, 10 times the size, this is measured in dollars spend worldwide, we're going to see a tenfold increase in sort of the magnitude of the enterprise private cloud deployments. And the second fact is that more enterprises are now shifting, not surprisingly, much more complex application systems, tenant systems over to these clouds. So, this is not like the AWS, Amazon, Azure, things where maybe they're much smaller, you know, dozens of VMs or less small medium business. These are large hundreds, even thousands of virtual machine type of systems. So, you know, the question is why the big increase, frankly, if you think about it, enterprises are adopting this because of security issues with their applications. There's some very complex integration between applications that are occurring that they wouldn't be able to instantiate well in a public cloud. And frankly, at the end of the day, it's about end to end control, right? Okay, so, with all this happening and OpenStack is a big contributor, the good news is Agile is here, as we heard in the keynote address this morning, and I think most people here know, there are twice yearly version releases of OpenStack, each one of them with more features and functionality and all that. And our experience is the tech dev kind of organizations, development organizations in large enterprises are adopting these to these release cycles, being able to architect whatever that enterprise strategy is and architecture is for these clouds. However, so they're basically getting in line with an agile type development, and that's a good thing. So, very, very fast. And like I said, we're all happy about it. However, what about the other enterprise organizations that play into this equation? So, we're going to explore that right now. So, first of all, I thought this would be an interesting thing for you. I think most of you may be aware of this beer guy, right, the world's most interesting guy. Well, this is the perspective from enterprise IT's most interesting man. I love it. I don't always do agile, but when I do, I do it like waterfall. And it is so true, and there's good reason, by the way, they do it as waterfall. We'll explore those, but I thought that was kind of funny and had a lot of truth to it. So, once again, those that were here for the last presentation saw this diagram, but I just want to quickly touch on it again. And it's what really comprises an enterprise cloud. So, we've got this marvelous OpenStack software that's getting continually upgraded by the community, new releases, and so forth. But in the grand scheme of things, that is just one-third of the production cloud, there's two other equally important components. The first is the infrastructure. Of course, that comes from the data center infrastructure through your typical IT organization that supplies the bare metal platforms and other software functions, the infrastructure that the cloud rides on. And then second, there is the cloud tenants, so the actual applications. And it's really only the intersection of all three of those that make up the production cloud. So, we have to consider how agile are they? And then finally, they all rest upon the typical, I'll say, enterprise. We've always done it this way, things. And so, there's actually a fourth element as well that is really necessary for this cloud to be actually a functioning entity. So, quick review. As I mentioned, the cloud software development and enterprises we're working with is actually becoming quite agile, right? Some of them are different degrees, but frankly, they're getting close. They're getting themselves attuned to this six-month release cycle and being able to do quick bug fixes and things like that. And get that new technology out to the tenants, the applications that are actually the ones that are consuming them and the real business reason for these clouds to be in business in the first place. So, that's happening, frankly, pretty good and it's going fairly fast. Now, we've got our traditional IT, our experience in the large enterprises we're dealing with and we're working with is they are still on a very rigid waterfall-type development, classic SI, requirements, design, integration, verification type of thing. And so, it's sort of big iron and there's good reasons for that. The truth is, frankly, there's big capital investment reasons that they choose. You know what? We've got to standardize on this type of server, this type of storage and those things. It has to do with system-wide compatibility at the infrastructure space. It has to do with vendor relationships and dollars, those type of things. And then finally, the other attribute of our colleagues in Enterprise IT is they are the ones ultimately that are responsible for keeping this whole system up and running from the bare metal up. And production, a system availability is absolutely paramount. So, just culturally, and we heard this morning about culture and the need to change that as we get to a more totally agile cloud system. But their culture is very processed and has a very regimented don't mess with the underlying infrastructure. So, that's typically a very long cycle that they go through in terms of speed. Now, there's the tenant applications and, of course, they're very business-focused. So, sort of from a speed perspective, I put that you see the little speedometer at sort of sometimes they're fast, sometimes they're slow. It's really fast when you're talking about time to market, delivering their end service to their customer, whoever that may happen to be. So, it's all about how they basically consume new services to focus on their product, their service to the customer. However, we found them to actually be quite, I'll say, less fast and maybe even slow in terms of business stability. Once they're in operation, it's don't mess with it, don't rock my boat. I want to keep stable. I'm providing a service as many nines as possible, please. So, sometimes they're fast, sometimes they're slow. And then finally, there is the enterprise systems that I mentioned, the procedure and no good presentation mentioning the enterprise would be good without a Dilbert cartoon. And so, you have Dilbert there actually saying, hey, he needs to go out and see if he can basically get some sort of ballpark prices to the vendor. But frankly, before he does it, he needs to have some sort of a approval, CCB approval of the process. Well, I can't get approved unless I have a CCB but I can't do the CCB unless I have the information. And it's kind of funny, but it really talks about the fact that most organizations are very siloed. They've stratified because that's what's made this big enterprise successful. And so they have old ways of working. They've been successful on that. And you could just imagine the type of things that you deal with that weaved out with are capital appropriation cycles. Three months would be fast. Try 12 months, that's probably closer. Hey, you know what? You want something changed in a data center to meet your next release of your cloud? I need to charge a number before I can even do it. It's part of the cost accounting system, right? I see some heads nodding out there, so you see what I'm saying. You know what? Who's actually paying for this cloud infrastructure up front? It's a new model, right? It's a more utility computing model and who's paying for this capacity up front that'll be used for future expansion. And then ultimately, hey, you know who's in charge of this cloud anyway? There's a lot of different organizations involved. So those are all things, so that kind of moves slow too. So now that you've been sort of seeing all of this, you can see that we actually have an SI dilemma. Got this wonderful new technology, OpenStack software coming in twice a year, new features, new upgrades, and all that type of stuff. But then we've got other elements that frankly aren't nearly as fast. And so what I'd like to do now is turn it over to my colleague, Ronnie. And like I said, he and I worked for the last year on a very, very large enterprise deployment of an OpenStack cloud system. And we were at the forefront of receiving all the wonderful code releases and pushing it out into multiple, multiple data centers. And we ran into all the problems headlong. When we started this project out, I'll never forget one of the executives that this company told us, hey, we just are upgrading software. We're just throwing software out there. Well, we found out really quickly. No, this is about all these other elements as two. So he'll go through some of these scenarios and then tell you how we overcame those issues in the near term and what some strategic approaches are to correcting these things and making the whole system more agile in the long term. So, Ronnie. All right. Thank you, Fred. Good afternoon, everyone. Welcome to Austin. In fact, I went to grad school here in Austin. Really happy to be back here. This is a great city. So anyway, let's go back to our dilemmas. As Fred mentioned, there's different pieces of the puzzle in order to build that cloud. And so there are challenges along the way. And I'm going to talk about some of these challenges. And then, like Fred mentioned as well, we're going to talk about the short term versus long term strategies. And hopefully, towards the end, dive into some detail about the strategy in order to make this a success. So my first example here is a challenge in trying to implement agile for SI. And so have you ever tried to implement designate or DNS as a service, which is a simple open stack feature, right? So you'll have to think about things like naming convention. What are my naming conventions? Should all my VMs have DNS records or aliases? And so how do I optimize my DNS based on the tenant VM latency? Or are all my DNSs reachable? Do I have any firewalls in the way? And all these questions. And the key point here is really there's a lot of teams involved. So you've got your networking, your security, your IT teams, your architecture that needs to determine naming conventions and the like. And so you've got all these teams involved. You've got multiple decisions and approaches you can take. And so from a really simple software feature push, you could end up with chaos. So that's one example here. Another example and the challenges in trying to implement agile for SI is around infrastructure. So you all know the cloud has to live on some type of infrastructure, right? So your infrastructure has to be architected. The requirements need to be defined. And also there's some certification that has to happen. So how do you actually do that in agile fashion, right? So it's really tough. And you'll have to make the decisions like, well, do I really care about what kind of brands, what kind of servers, what kind of hardware I'm trying to run over here? Do I really care about within a single type of, let's say server, what is my rate configuration? How many hard drives do I have? What kind of storage do I have on those? My BIOS or firmware versions, et cetera, do they have to be the homogeneous versus heterogeneous decision? What do I really care about? What are the specifics that I want to make similar versus the ones that I'm not really relevant to the end goal? So and how do you make this agile? That's real challenge. Another example of the challenges in trying to go the agile route is the business owners and the tenants that are coming into the cloud. So some of them, within an enterprise cloud, these tenants or businesses might be internal or external. So some of them might have some requirements or mandates or needs and they wouldn't get on the cloud unless those needs are achieved. So for example, one of the tenants could say, hey, I don't want this storage technology. You better get me another storage technology here, otherwise I'm not going to get on board. Another one would be, I don't really want to use this cloud for my production unless you have this specific software feature. So these kind of decisions will impact the enterprise strategy as a whole and so revenue will be affected and also productivity will be affected and decreased. So tenants or those businesses need to be educated about cloud usage and some of them might have unrealistic expectations as well and one thing they ask for is high fidelity like was mentioned earlier. They want really environments where they can test that their applications work well within that ecosystem that the enterprise is introducing. So another challenge in general in trying to go the agile route in an enterprise is the dilemma that's called the alignment autonomy dilemma. So you've got different teams within the enterprise. So there's two things that need to happen to go the agile route. There's autonomy and there's alignment. So the enterprise has to be aligned. There's also some autonomy that actually improves productivity that would like to implement. So for example, you're trying to implement an open stack feature that requires different teams like the networking, the security, the architecture. So these teams need to collaborate and somehow if you do too much alignment, nothing gets done, right? This is the typical dilemma of scaling agile. So finding the sweet spot is a real challenge and so here's one example from the book, The Art of Action that actually tells you what the sweet spot could look like. So you've got autonomy over here and alignment and if you're in a high alignment and low autonomy where nothing gets done, people talk about what and why and how do we do things a little too much. And so the other way is where you've got a lot of autonomy and so everybody's doing their thing and then you end up with an end product that doesn't work altogether. So everybody's working on their own. They're trying to be autonomous. They're trying to be agile and then you look at the end product and it doesn't work. So how do you find that sweet spot? You really have to, you know, across the organization agree on the what and the why and then somehow quickly align on the how and let the teams figure out how to get there, you know, to succeed at the end goal. So we've actually came up with this model that we think is a good implementation of agile across the enterprise and at the center of it is this, you know, cloud integration as crumb that's composed of different teams from, well, different people from different organization and it's a multi-disciplinary team that, you know, we've talked about and I'll let Fred talk a little bit about this. Yeah, thank you, Ronnie. So, you know what, first of all, I want to say, you know, part of getting this whole enterprise agile is of course bringing in these disparate elements that we had mentioned of being the enterprise, the tenant applications, the IT infrastructure group as an example and how do you basically bring them in so there's not the stove pipes and walls? So what we've concluded and what we're recommending is something we call a cloud integration scrum. So you can kind of view that cloud integration scrum as a kind of a scrum of scrums, but I want to be very clear, this is not a PMO, a bunch of managers, these are at the very least, they're like technical PMs that can come in and be responsible, okay, to basically make sure that all of these elements that need to technically come together can come together and that when we do our deployments, we actually don't end up with, frankly, a big sort of integrated mess. And once again, it's really about having a kind of working and IDing the technical integration points. And so we would conclude the mission of this group, the vision would really be to deliver a flawless integration. And if anybody in the room has been participating in a very large new cloud architecture rollout, I can guarantee you know what I'm talking about, you're gonna find out every point that you missed. And so, and you will miss some, these are very, very complex systems and so forth. However, the role here of this cloud integration scrum would be to try to mitigate that. At the end of the day, we really want the entire organization to transform from sort of very agile, maybe in the software development area, but way less than agile, maybe in the enterprise or the IT infrastructure. We really want them all to become more agile. I don't know that they'll ever become, as agile as the software development, just because some of the physical realities are different, but that's why you'll see IT ops, network engineering so far. They're shown as light blue there that we think by having at least participation up front in a cloud integration scrum, and then those people having the authority to go back into their organizations and start speeding up the process there will definitely improve the agility of the overall system. So that's sort of a recommendation of a model. I can tell you a funny story and a very large cloud development and deployment project that Ronnie and I were both part of over the last year. We didn't have a cloud integration scrum and the PMO, and I'm not trying to bash PMO, I still think it has its place, but the overall program management tried to take that role and what happened when we got near and into the actual deployment, rather than having an eight or 10 person cloud integration scrum, we ended up having daily two, three hour meetings with 40, 50, 60 people from all the disparate elements of the organization. So it can be a very, very big problem if you don't get ahead of the power curve. So with the context of this model, like to turn it back to Ronnie and he'll go through a couple of examples of how we can use this model to attack a couple of different areas relative to the overall deployment of a cloud system. Right, thanks. So we talked about challenges, real case study challenges. We talked about the model and now we're gonna explore a little bit more details into how that model fits into deployments, into production supported areas. So in the area of deployment, you've got your typical SI challenge, which is the big bank style deployment. And in order to mitigate this using Agile, we can use continuous systems integration. Another challenge would be the tenants deadline, right? So these businesses have a lot of deadlines and scope requirements. So one way to mitigate this is to have a prioritized backlog and deliver the highest values first. Another challenge is geographically dispersed vendors and they're operating under different contracts and that's a typical thing in SI. So how do you deal with that? So you actually structure your contracts in order to align all your vendors, whether it's storage, networking, or whatever vendors under contracts that have common integration goals, right? In a common integration environment so that the end product actually works. And finally, from a deployment's perspective, you've got internal conflicts between different organizations within the enterprise. So really you have to nurture the enterprise with this Agile culture in order to improve on the delivery and the productivity. So in the model, we've got production support and upgrades and that's a typical, I guess, aspect that you have to deal with. And the model here is kind of traditional, kind of not. So you've got your NUC Network Operations Center, which is the first line. And this is for a production support case and that first line goes to DevOps organization and that DevOps organization is responsible for fixing that problem that was reported by the first line. And so if the DevOps organization cannot fix that problem, you go to a third line support where you actually have more technical teams, depending on what the issue at hand is, that request gets diverted to someone in the third line. From a production upgrades perspective, you need to upgrade your cloud. And so the way it works is that DevOps organization will actually be responsible for this upgrade. And at the center of this upgrade is the continuous integration practice that will actually help you be more productive and achieve the upgrade faster. And if things go wrong, you can always refer to the third line. So I wanna mention, so we talked about the model, we talked about the areas of deployment support. I wanna mention another framework out there and a few specific strategies, a little bit more detailed over here. So this is one model that's kinda similar. It's a model that's out there called the Safe Framework. It's about scaling agile within the enterprise. And it offers a detailed approach about how to scale agile across the enterprise. So you see there's programs at the bottom here and there's a middle section that's missing, which is the value streams and there's a portfolio. So portfolio is made of different value streams. A value stream is made of different programs. And you've got your release train engineer and product management architecture kinda working together. There's a lot of teams working in different scrum teams. There's also the business owners, et cetera. And this framework has its own features like for example, pipe planning, which is a common practice. And pipe planning happens every four to five, let's say sprints. And what happens is it's got a very standardized agenda. So all the teams that are involved meet, right? Across the enterprise. And they have a two day agenda that's very defined and it clearly outlines the enterprise business vision and also the architecture vision and also some other content there. So this is one example. Other approaches to increase agility across the enterprise. For example, in the development teams, something called peer programming. You've got these two little kids they're doing something called peer repair programming where one person types the code and the other person is actually reviewing each line of code as it is typed. So this is in the development area specifically, one of the strategies. The other thing is in the infrastructure, right? So your infrastructure, you wanna make sure if you're deploying a private cloud in OpenStack that you do proper capacity planning. So this is key. You don't wanna be landlocked in a data center where you're trying to scale out your cloud and then you end up with no available physical space. So this is definitely key to your cloud deployment. And here I just wanna finish this by talking about the hyperscaler HDS-8000. On my last point here, you wanna make sure your infrastructure scales really well. And so this hardware what it provides, it's a disaggregated hardware approach where you're not contained to boxes, right? So what you can do is add more memory, add more CPU, add more storage. So it's on demand, memory storage and CPU. And you can expand this as you go really. So the traditional architecture is revamped really here. There's no need to separate the different servers and tours and complicate your infrastructure. So you can really simplify it and scale it out nicely. And the other thing about this is it's got a full optical backplane. So 100 plus gigabit per second speeds that actually helps with futuristic bandwidth demand that we've got. And it's definitely, it's got a lot of positive impact on energy and power utilization and energy utilization in general. So you wanna bring those down as much as possible. So with this, I'm just gonna... Sure, well thank you Frani. So basically the call here is to let's get agile across once again, the entire ecosystem. This is gonna be so important if enterprise private clouds with OpenStack are gonna succeed in really fulfilling the promise not only of a virtualized cloud environment but also at the speed that this expanding community is driving this marvelous technology. You know, years ago, I worked in sort of high tech space, satellite programs, launching rockets, very complex technology. And I can guarantee you that the OpenStack software of today is every bit as complex as a Saturn V rocket. I mean, it's really amazing stuff and we're pushing more and more and more of that out into the field. But if, so the community's really gotta get kind of on board with this rapid sort of increase to take these private clouds into production at the type of monstrous scale that we're talking about. And if we want to let our tenants who are actually the ones ultimately paying for these clouds experience the benefits of all the new technology innovation, the entire enterprise is gonna have to get itself much more agile than it is. And so our call to action for the community is it's more than just the code. The code is core and it's very, very important but having methods as we described that are being pushed I think and helped develop by the OpenStack community is going to benefit our overall deployment and scale up of OpenStack out there in the industry. So that's our appeal to the community and I think it's going to all serve us well in the days and the years to come to really scale up the overall OpenStack cloud. So with that, Ronnie and I will take any questions that the audience may have. I'm curious if you have any recommendations on method or process as far as transitioning an IT operations team that is typically working in a highly interrupt driven environment to make them more agile. Okay, well, so I mean it's a tough question for sure but essentially the culture is starting with the development teams and it expands into other teams. So I think part of it is actually trying to figure out what the best structure of your IT operations is. The other part is once one part of the train gets moving in a certain way, it kind of affects the other pieces as well. So once you have this release cycle, so eventually it's going to be contagious. So the organizations are going to try to figure out how do I actually make myself agile as well. So specifically it really depends on what the scope of this IT operations is. How do they work? What are the things that we can improve? And really how that, I guess trend moves from just the dev teams into the other organization. So I would add on that I think sort of in true agile type fashion that I would also say it's part of the team's responsibility to start, they know their business best but what we found is, you know what, there's really kind of two types of problems right there is there's issues that maybe with other parts of the system that an IT support group can go ahead and start troubleshooting problems or whatever but there's also issues that need to go right back into the development teams. And so I think what we found is there actually needs to be two streams. One going back into the actual development scrums itself so get them out of the tier level three, level four support back to the people that can fix them. But overall I would actually ask that the groups involved start looking at their business in a new way how they can actually optimize themselves into this model. And it's difficult. It's a cultural change just like was explained this morning and frankly as big of a challenge is bringing OpenStack to the point that it is today has been I think literally overcoming this cultural challenge is as big or bigger of a problem or a challenge let's put it that way today but I've seen signs that we can get there. So one of the specific examples we mentioned right so there's the cloud integration scrums got people from typical IT operations so they're gonna be there in these sprint cycles and they're gonna be making those decisions in an agile environment. The other example is the DevOps organization that we mentioned. So you've got some people from typical operations together with the dev teams working in a similar fashion. So this actually opens their eyes on what is what these agile methods look like because they're part of it, they're actually doing it. So and like I said, so I'll transfer over to the rest of the organizations and soon enough you'll get your organization moving in a much productive way. Are there any other questions? A few slides ago you mentioned something that you do every four to five sprints. I forget what you called it but you said it was a two-day meeting. Right. I was wondering if you could just elaborate on that. Yeah, this is one of the frameworks that's out there, it's called the SAFE framework. This is called pipe planning. So it's a two-day meeting with a very standardized agenda and the goal is really alignment. So we talked about alignment and autonomy first. The goal is really to align the enterprise. You've got value streams, you've got programs and so different teams, because agile works in small teams. So different teams need to be aligned. So this is one way to get them all on the same page and you have a two-day with telepresence usually and if people cannot be co-located, they can use whatever other means to do that and they can align the enterprise on the business vision from also an architecture perspective. So the business vision, the architecture, why we're doing this, what exactly we're doing for the next two months and then people in different teams understand the roles and how they can actually together build the full picture and complete the puzzle. Any other questions? I just wanted to say that was a great presentation. You guys have obviously lived through a lot of this stuff as we've seen. If you had to narrow it down and this kind of is a continuation of an earlier question, is there one thing going into an organization that you think is maybe the main driver you'd want to emphasize? I know you've talked about the safe and the, I forgot what it was that the... The vibrations from? Yeah, yeah. Anything going into an organization where you have these siloed mentalities and all that, if you were starting one brand new, what would be like the key takeaway you might want to deliver on where you would start this for that? Sure, so I would kind of go back to our cloud integration scrum model. I think the number one thing is to don't just do an agile development for your software and expect that the rest of the organization and contributors to that cloud are just going to naturally go across. When Ronnie and I were working through a major deployment, frankly, of a new highly sophisticated open-stack cloud system over the last year, there were other elements of the organization that didn't even know what was going on. It was all new to them. So I would propose in my thought that probably a key I would suggest is get a cloud integration scrum together, identify every single organization that technically has to contribute, technically or procedurally has to contribute to this cloud actually coming together, software, hardware infrastructure, site infrastructure and your tenant applications and bring key representatives back in it. So that would be one thing. And then the second is to then, through the governance and PMO, empower that organization or that group to work in an agile way within the development process. But when they go back to their home organizations and say, okay, we're gonna need to restructure things this way within our infrastructure, empower them to help bring the whole organization into a more agile way. But I think it really comes down to getting that right group of people together. I think it's a great question. Yeah, one of it is definitely the group of people together and the competence. But I also think that if you're trying to start from scratch, if you bring people together with, first of all, you don't want large teams if you're doing agile, right? So you want small teams with specific goals and the specific value they're delivering. I think that's key. So if you actually figure out what your value is, the one that you're trying to deliver and size your teams accordingly and give them their missions respectively. And this is how you actually transfer the culture into an agile culture. And that would help us achieve the goal, hopefully. Great, any other questions? You guys have been a wonderful audience. It's been a long day. A full day. Thank you very much.