From the CUBE studios in Palo Alto in Boston, connecting with thought leaders all around the world, this is a CUBE conversation. Hello everyone, welcome to this special CUBE virtual coverage of AWS Summit 2020 online. This is the AWS Summit that has now moved from a physical event to a digital event, a virtual event, it's all online. Of course, the CUBE normally at the summits are virtual as well. We have an all day program of CUBE coverage here from our Palo Alto studios with our quarantine crew, great team who's been sheltering in place for the past two and a half months, as well as our team in Boston with Dave Vellante and Stu Miniman. The CUBE is virtual because we have to be and we are going to be continuing doing more coverage. We're going to continue to do that with all the other big events in the enterprise and emerging tech business. Stu and Dave are going to join me. Hey John, good to see you, thank you. Stu, we're going to do a segment later on more of a breakdown of some of the news and the highlights. We've got Matt Garmin coming on who's the new vice president of sales and marketing. He ran EC2, he now reports to Andy Jassy. He's running the field. We've got Sanjay Poonan, the chief operating officer at VMware coming on as well. And then we've got a customer and then we've got a slew of great guests, Swami, Dave Brown who now runs EC2, the GM of analytics. Stu, are you going to do a segment with Corey Quinn, which should be fun? And Dave, of course, you're going to do a breaking analysis to end the day. And we've got a lot of other great content on the CUBE.net, check it out. Guys, let's just jump into it. AWS is really feeling all the pressure as all the Cloud guys are. Everyone's working at home, the Cloud is on the front stage of the world in terms of delivering capacity, compute, everything else. And now they've got to run a digital event. So pretty crazy times. What do you guys think, Dave? What's your thoughts? Stu. So, John, you want me to, yeah, let me jump in there. So really impressive watching Werner Vogels. First of all, last year I saw him up on stage at the New York City Summit. Of course, we'd seen him on stage at Reinvent Mankind, but well produced, really looks good. Challenging to have that keynote feel when you're sitting at home, but they did a nice job of editing. They put them up on a big white space here. But what Werner talked about is the scale of Cloud. This is what they've been building for. You never know when you're going to have a Cyber Monday. And I just need to be able to scale. He talked about examples like Netflix, more than doubling, how many minutes they're doing, and walking through all the ways that Amazon is stepping up. Something we've been looking at, close days been digging into the analysis here. Public Cloud is being put under the spotlight right now. Can they react? And Amazon, to their credit, is doing a real good job of not been hearing any challenges. They're not leaving their customers behind. They're having lots of people coming and wanting more. I've been looking at people, yeah. I want to dig into that a little bit later in terms of uptime and high availability. The table stakes right now in this new virtualized world of living and working at home, competing with life, is what services stay up the most? Which ones are failing? The staffing level's there. Are they dealing with the remote workforce? All these things are going to impact the Cloud. But ultimately, what we're talking about now is who's really leading this? Dave, you and I have been riffing on this around who really has the market share lead and what the numbers are. Clearly, Amazon is winning. The numbers all point that way. Some people even have Microsoft ahead of Amazon. I don't know how they get there. But bottom line, Microsoft is catching up. But what is the real lead? What's the market share numbers look like? What are you finding in the research that we're doing? Well, as you know, John, we've been tracking this for a while now and all three companies, the big three, Amazon, Google and Microsoft, just reported. And we actually have some data on this, guys, if you could maybe share that with our audience. But we saw this last quarter. The reason why, John, that people, some maybe people have Microsoft ahead is because they bundle a lot of the stuff into their intelligent cloud. And it includes GitHub, Azure Stack, hybrid, private. It includes services, and oh yeah, by the way, Azure. But nonetheless, they give us some clues as to what Azure looked like. So this is our estimate of infrastructure as a service and platform as a service. Both Google and Microsoft sort of hide the ball a little bit on the pure play. Amazon very cleanly provides that guidance. And so you could see here, I guess the key points are, like you said, Azure and GCP are growing faster than Amazon, Amazon is much bigger. I would say though, if you go back to 2018, Amazon was well over 2X, Azure, 2019, it was just kind of around 2X. You're seeing that now with the trailing 12 months. And this last quarter, dip into a little bit below. So you are seeing Azure close that gap. But as I say, the numbers are fuzzy. So you have to do your best to squint through them. I read 10 Ks till my eyes bleed. So you don't have to. Stu, what are you hearing in terms of uptime?  You see Google doing much more vertical focus. They're obviously going after retail. That's an easy one. Microsoft with Office 365 doing well on the enterprise. The numbers are there. What's your thoughts on the reliability and uptime? Yeah, so John, first of all, Amazon not hearing any reports of issues there. As you noted, where Microsoft and Google going after Amazon, where they can. So retail is an obvious one. The ecosystem, how well can they partner with companies? Because the fear of many companies is, if I partner with Amazon, are they going to come after my business? So when I looked at the online events, John, I got a sneak peek last night for the Asia Pacific region. I kind of logged in as if I was from Australia or New Zealand. They have regional partner things set up. So once again, Amazon, huge global presence, doing a really good job there. And as Dave showed in the numbers, while Azure and Google have much higher growth rates, if you just look at raw numbers, Amazon's just adding another Google Cloud like every quarter to their revenues. So it is still Amazon in the clear lead out in front. You know, I think it's important to point out that the clouds have different capabilities. You know, Microsoft put out a blog just very recently saying that it was going to prioritize some of the essential businesses, you know, some of the healthcare workers and several others that were quote unquote essential.  So they're clearly having some scaling issues and they're somewhat using the COVID-19 pandemic as a bit of a heat shield there. Oh, by the way, they're prioritizing teams as well for the work from home. So it's caveat empty there, as I said in my breaking analysis. I mean, you know, unless you're one of those sort of priority customers and maybe even if you are, you might want to sort of be careful as to what you're actually running in Azure. At the same time, you know, clearly Microsoft's doing well. It's got a lot of spending momentum for its platform. And so that's undeniable. A lot of workloads are kind of good enough. Yeah. And I think just to put a quick plug if you're watching this segment now, Dave will do a breaking analysis at three o'clock on our stream here. Of course, it'll be on demand on theCUBE.net as well as YouTube. Guys, I want to get your thoughts on some of the hot spots here. Usually around this time, Amazon comes out and shows a lot of GA, general availability, a lot of stuff they announced that reinvent. So Kendra is going general availability as well as some other services. But one of the things that was interesting to me, I want to get your thoughts on it because I held the processor in my hand. Jassy tweeted about yesterday, the new ARM EC2-M6G which is their Graviton 2 processor. It's like super small. This has really been the competitive edge for Amazon's performance. The stuff that they're doing now is they're lowering the cost and increasing the performance. That's their Amazon law. That's what they do. So you got the processor, you got analytics. You start to see these GA's. Can you squint through some of the announcements and try to get a feel for where this is going? Obviously it's machine learning. If I'm an enterprise, I got to make some tough calls right now because I got to double down on the projects that are working that are going to get me through the pandemic and then a growth trajectory. And I got to get rid of the people and the projects or redeploy them quickly. This is going to impact positioning and ultimately revenues. I mean, I think if you look at the edge specifically and you think about ARM, I think what Amazon's got right is they're not just throwing traditional, you know, data center boxes over the fence to the edge and saying, okay, here you go, data center in a box. What they're doing is they're sort of rethinking it and realizing that you're going to have real-time workloads running at the edge, processing very, they have to be very efficient and very inexpensive. So that's where ARM fits. And I think, you know, you're going to have to be able to do the processing at the edge, much of the data, if not most of the data is going to stay at the edge. And it's not a traditional processing architecture. New architectures are going to emerge. David Flurry calls these things matrix workloads. He's written a lot about it. And it's just a whole new way of thinking about computing architectures. And really the edge is going to be driving that. Stu, I want to get your opinion on something. And David, you can weigh into that. That'd be great. You know, I was watching a little bit of the Down Under APAC stuff yesterday, Stu, as well. And I saw Ben Kaps, one of our friends, CUBE alumni and co-host helps us out. He lives in New Zealand. He brought a couple of interesting things I want to get your thoughts on. This is more of a community angle. Andy Jassy's been with Amazon for 23 years. Ben mentioned the cloud a rod. He's still going back, you know, thinking about cloud was 2008 around that timeframe. There was only a small cast of characters talking about what was going on. And finally he mentioned the point about Jassy's keynote, a fireside chat he mentioned. One-way door decisions versus two-way door decisions. The former cannot be undone, hence need to be thought over. So you start to see Jassy 23 years of experience. You get the cloud a rod, the kind of ecosystem influencers that are out there that we all know. We've been covering this for that long of a time. And then you got this notion of the two-way door. You're starting to connect the dots here on what's going on. You start to see a maturation of AWS. But not only that, the community. The truth is out there. And it's interesting to see how this plays out in terms of how they talk about the information as we're all on virtual online. Who are the experts? Who are the YouTubers trying to get a flash in the pan? What's the real story? The data, the misinformation that's flying around. There's a ton of that going on. We're going to see more of it with virtual. But you got the experience in the table with Amazon and the community, your thoughts. Yeah, so John, absolutely it's about, you need to have optionality. We know that things change really fast. 2020, key example of having to react to things that I weren't prepared for. Dave was just talking about edge computing. What I need to succeed in edge is very different from how I was attacking cloud before. So is Amazon a walled garden? Everything goes in, hotel California, that it was attacked for years? Or are they going to be flexible? You see Google and Microsoft really trying to attack Amazon here. Many of us that are proponents of open source have attacked Amazon for years. They've hired some really good people, of course, Adrian Cockruff a couple of years ago. Peter Ulander more recently, they've even hired some people from Red Hat and the Linux Foundation. So getting involved in open source and they've been leading some of the efforts when you talk about edge. But emerging technologies like serverless and edge computing, is it the Amazon way or everything else? Or will they play in an open ecosystem? Will they allow things to be more flexible?  In 2020, will Amazon soften on their multi-cloud stance? Especially if you start throwing in where edge fits in this environment. They can't be a one way ladder to everything to the public cloud. We know it needs to be a diverse environment. And therefore, that community and ecosystem wants to play with Amazon, but also wants a mature and competitive marketplace. We've all seen what happens when there's a monopoly or duopoly out there. It's not good for innovation. It's not good for the customer's long-term. Dave, the reality of the marketplace is changing. Customers are going to be virtualized in their world, literally, physically and digitally. How the work's going to get done is to mention open source when it's probably see a revolution of new applications. Cambrian explosion of new kinds of capabilities, new demands, new expectations. There's going to be favored here for the people who have the steep learning curve who have those, has that trajectory. And as Amazon says, you know, there's no compression algorithm for experience. This is a real kind of nuanced point, but it's going to expose for the next year, who's got the juice in the marketplace? Your thoughts? Well, Warner Vogels today talked about, he said there's a shift, a fundamental shift going on. And he sort of referring to COVID-19 is not just about the technology, but it's about how we access applications, how we build applications. And Amazon is clearly making some bets and betting on data, we know that. And they're also betting on video because they know that's where a lot of the data come from. And when you talk about who's got the experience, I mean, clearly Amazon is seeing a huge, you know, demand for video services. And we're seeing a giant disruption in content distribution networks. And Amazon, I think, is at the heart of that. So I mean, it's, you know, it was interesting to see him doubling down on that, talking about the whole workflow.  You know, I've heard the term reinvent many times in the past couple of months, especially during the COVID crisis. And it wasn't in context to the Amazon show. There's a real reinvention going on in the marketplace in enterprises and small, medium-sized enterprises. To every business, they have to rethink and reinvent what they're doing to get a growth trajectory. And traditionally, if you look at these crisis 2008, companies that came out on the upswing became real master, master class examples of growth. And a lot of people who weren't prepared, flat-lined or dropped off. So we are in this point, even theCUBE, we're digital, we're virtual, we're rethinking it. We're open to new ideas. There's going to be an experimentation phase at the same time, how do you leverage what's out there? This is going to be an opportunity for the cloud guys. What do you, how do you guys react to all that? Well, the last downturn was good for cloud. And Stu, we've talked about how this one certainly is shaping up to be a tailwind as well for cloud. Cloud is doing better than others. I think Gartner put out a stat today. They've seen like a 5x increase and increase around cloud, not surprising. Companies that previously wouldn't even think about cloud now really have no choice. Guys, we've got to cut it there. We've got a clock here. We've got all day with theCUBE, CUBE Virtual, AWS Summit Online. Check out, they got a big portal, it's complicated. A lot of education going on there. It's the classic Amazon Summit. We've got great interviews. Guys, we've got a great interview coming up next with Matt Garmin, who's the new senior vice president or vice president of sales and more. He runs all the field, public sector, both of those areas under massive growth opportunities. So we're going to hear from him. Thanks for coming on guys. Really appreciate it. Good to see all of you as well in Boston. And thanks for the insight. So we'll be right back with more CUBE coverage after this short break. And Matt Garmin, up next.


So, hello everyone, welcome to our next talk in security dev room. Next speaker is Mojish and he's talking about plain text secrets in configuration files. Let's welcome him. Thank you. Hi everybody. I'm here to present my work on protecting plain text secrets. This work is being driven in the OpenStack project and it's mostly written in Python, what we have so far. Basically in our applications or services we handle input, output and we have many ways to interact with our applications. Basically standard input, standard output networking as well. We also have standard error and then we get other forms of interaction like arguments and for Python we have R parser. In this short code we can see I can import R parser, I create mark parser and then I declare what will I expect as arguments and then I can later use them. I can call and it automatically will generate me a helper for my program and I can call my program passing the arguments in the command line and it will behave accordingly. It will also handle types for example and that's mostly for arguments. Next one we have environment variables. So Python we use OS environment and then you can import OS and then see your environment variables but also we can have some private information there that we want to keep it secret. Another thing configuration files. So usually when we deploy your building service application we have the code and then the code base it usually doesn't change and then we have the configuration which usually changes from deployment to deployment and we want to keep them in a separate place. Usually we use configuration files for database connection for example. In Python we use config parser which consumes any files and you can see you have a session and then like a key value on each session and then you can access them with the code if I import config parser, create my parser and then start parsing the file. I can see the sections, I can get the values of each key and so on. Then we also have signals to interact with. Then we have this bunch of signals I'm not going to go through all of them and finally our application has like an exit code where we can see if it worked or if it didn't and then try to find out what happened. Then in OpenStack it's basically some people call it a cloud operating system. It handles bare metal nodes, virtual machines, containers and then on top of it you can deploy basically anything. It stays in the layer of infrastructure as a service and OpenStack is broke, is separate in lots of projects. This project is Oslo which is OpenStack common libraries and Oslo config is the package we use to handle configuration in OpenStack. It's not, you don't really to be doing OpenStack stuff to use Oslo config, most of the OpenStack libraries, they are, you can use them in any piece of software, you don't really need OpenStack for it. So Oslo config supports configuration files but also arguments, environment variables all in one and this bit more which are the source drivers that I've been working in the past two years. These source drivers it's what allows Oslo config to absorb configuration, to read configuration from different sources. So mainly in this talk we are going to use Oslo config to access secrets behind Vault which is a secret manager. But we have open specifications that you can find links for it in both of the posters I attached to the presentation site and then from the specification you can create your own drivers and then use Oslo config to draw the values from whatever source you want. So Castillon is another library under the Oslo project and it's a secret manager interface. So it can both talk to Barbican which is the OpenStack secret manager but it also talks to HashiCorp Vault and then in the future it can be enabled to talk to other secret managers. And basically your application is talking to Vault and then it has all the secrets stored and then you authenticate to Vault, you provide a key ID and then it finally gives you the key. And then it's all encrypted. Oslo config it has basic types where you can do type verification, string, Boolean, integers, float, list, digs and it also has some special types for validation like URI, host name, IP address, host address and port. And this is a simple, an example of an application using Oslo config. So here I'm importing from Oslo config and you can see my options, for example name, default world, the greeting, default hello, the times, default one and in my code I create my configuration object, I register my options and I call my object and then at this moment it will load all my configuration values. I can register command line options with the register CLI options. I can register a single option with a group and the name and here if you use a plural you'll have more than one option, this is a list and then this is a single option. Okay and when I run it gets you the helper from the information you put on it option. You can also change, it will automatically try to build the name of the arguments but you can also override that. And then when I call my program it's drawing basically the configuration from the default values but now I can pass using the argument and it changes behavior. I can have a configuration file and then tell my program to use the configuration file and then it will load the data from the configuration file and it happens if you put like multiple sources of information you will have the configuration file first and then environment variables and then argument and then different sources. It's in the documentation of the OSO project you can check how the fallbacks happen and the order it acts. So if I call, oh quite fast, if I call my program now you're just using arguments and configuration files and then on this example this is environment variable. The environment variables it's also a source drive that derived from the first implementation we did in 2017. So basically you put environment variable with OS underline as a prefix open stack and then the group name greeting and then underline underline and then you can put your option name. So if I have greeting times as an environment variable like that it will draw the configuration from the environment. So here I have a basic application, flask application I made to run in my welcome machine so it has a host and a port that it will listen to and then I have some database connection. And then I will try to connect to this database and when I run my application it should connect to the database and then tells me if it was successful to connect or not. These values they can be put to default so I can make my configuration file smaller and then just change them if I need. Of course you're not going to put username and password as default on your software so we are going to, I'm calling my application like this, passing the configuration file it's still able to work.  And then these examples they go from like most insecure to more secure. The next one we have, so this is now using the Castlin driver to talk to the secret manager. So how it works, I have an option called config source in the default group and then it defines this section called secrets. You can have more, as you can have a list type in Oslo config you can have multiple configuration sources, config sources and then it will try to fetch configuration values from them based on the order you declare them. So I could have like secrets one, secrets two, secrets three and then when my application runs it will poke them index that sequence until it gets the value. On the session you have to define the driver so this driver is Castlin and then you can create your own drivers. The config file for Castlin itself and a mapping file. On the config file for Castlin which is here I have key manager, the back end vault on the example that I will be showing and you can also have Barbican on open stack. And then there's a session that should be a session here but I will be passing those values on the environment variable. And then the mapping file it tells me for the group DB username and password they have these IDs. So when I poke the Castlin driver it will use this mapping file for when I ask it like give me the username of the group DB it will then use this ID and then talk to vault and retrieve the secret which is under this ID. So here I call my application again passing my configuration file and I pass my vault token on the environment and then my application is able to talk to vault, get the credentials for the database and then run. I think this is the last slide, yes. Then here is the demo that I presented at EuroPython last year. I have Docker Compose which I will run one Flask app in the first one. The second one is a vault server and the third one is a database. So I will start Docker, should have done that before but it was killing my memory. So we have, and I'm not connected to the Internet, yep, oh it's here. It doesn't work until I connect to my phone and then oh I have Internet and then I can, so I can connect to the database. And then I'm saying here the username and password I used and basically all the values are coming from the configuration file. Then I have the other examples. On this one, on the plain text example I have only my application configuration file and this run script will call my application passing the configuration file. When I run it, it is using with this configuration and I have here another node running in a different port, the same application. So going up another level, this is plain text example. So now I have a secrets static. So I have my application configuration file. I have a casted on file and the mapping for the secret and when I run it, it will crash because vault is not running yet, it's sealed, it's here. So I started my container, my vault container, it is locked so I have to unseal and then now I have my token which I can check it's unsealed. I have my secrets there and then now it will not crash. So when I try to access, it connects to the database but I still have the same secrets there. So if you have multiple nodes, the ideal is that you have different credentials for each node because if you have 100 nodes running with the same secrets, if one gets compromised, all of them are compromised. So I have a third example. So even though the secrets are encrypted and stored in vault, if you have multiple nodes, that's a problem. So on this one, just see, I also have this example code, a simple orchestrator that will talk to vault, get me a temporary token for my node and then generate temporary credentials for my application and then we'll create the configuration files. So when I run this, it talks to vault, creates the credentials for me and then here I can see that I can connect to the database and I have a different username and a different password and if I run this again and again, it will always create different credentials for me. If I go to vault and check my access, lease, database, credentials, so this is that token and as this is an example, it's one minute valid token. You should have more running on production but for this example, I put it just one minute so we could check 13 seconds, it's still working and now probably, okay, the token expired so it's no longer listed here and when I try to connect again to the database, it will fail. So that's it. Thank you. Give it one more pause for the speaker.


Live from Washington D.C., it's theCUBE. Covering Boomi World 19, brought to you by Boomi. Hey, welcome back to theCUBE. Lisa Martin with John Furrier covering day one of Dell Boomi World 2019. We're in D.C. this year. We're not in Vegas, pretty cool. Big news with FedRAMP and Boomi. John and I are very pleased to welcome Slalom guests, a couple of them. Slalom is with a partner and a customer. Please welcome Michelle Yee, practice area lead and founder, Slalom Innovation for Good. Michelle, great to have you. Thank you so much. Excited to be here. And we have Shane Fisher, solution principle, business applications and integration. Shane, welcome. Thank you. Thank you. Appreciate being here. So the Boomi World, yesterday I know, kicked off for partners with partner summit. Today kicking off for customers and everybody else with a lot of energy, a lot of excitement. But one of the things that Boomi talks about that Slalom is involved in both is their 9,000 plus customers, which obviously you guys have a big hand in and 580 partners of which you guys are winning a number of partner awards over the last few years. Shane, we're going to start with you and then we're going to get to the innovation for Good, Michelle, with you. Tell us about some, you guys have some really outstanding use cases of where you're helping organizations implement Boomi. Tell us a little bit about the business overall and then we'll go into some of those use cases. Absolutely. So we are part of a group within Slalom that really kind of focuses on business process automation, integration and things like that. And so we've had just the unique privilege of being able to help a number of life sciences customers in particular. Couple that I'm super excited about are SiteLife and Juno Therapeutics. Both obviously with great missions. Juno Therapeutics, their mission and objective is to cure all kinds of lymphomas. And obviously that's a great mission that just really makes you excited to go to work every day to be able to support that. So talk to us about, so I believe it's an immunotherapy company. Yes. Talk to us about what was their IT environment like? Because on the one hand they're processing all this data, patient data, wanting to probably get patients into clinical trials to evaluate new potential therapeutics. Talk to us about their IT environment. I imagine disparate systems, things not connected. Give us that before picture and why Slalom went in with Boomi. Absolutely. So as you can imagine with any sort of startup, even in the life sciences space, you start fairly immature. You don't have a lot of systems. There's a lot of manual processes. A lot of paperwork based processes. Tracking patients manually or using bespoke to SQL databases and things like that. It's that necessary sort of bootstrapping that a lot of very early companies do, but then you reach a certain level where it's like, okay, we've got to grow up a little bit. And so what kind of what started our journey, what you know is that they selected Salesforce as kind of that center to sort of collect patient data and be sort of that first touch point. We first kind of interact with the patient and are able to kind of track them through their life cycle and you give them the best service possible. And obviously once you have Salesforce embedded into your infrastructure, now I need to integrate that, right? And so that was kind of where Slalom became involved and went through a product selection. Boomi came out, the clear winner, you know, not surprisingly. And yeah, and we stood that up for them, and started sort of connecting Salesforce to some of their other systems and automated. What were some of the reasons why Boomi was the winner? Was there certain categories you had focused on? Was it something specific around what they had? What was the use case that made them stand out? So I think speed of delivery and just ease of use are kind of the two main things that really stood out. Particularly in the Salesforce realm, I mean, Boomi just integrates so naturally and so easily with Salesforce. I mean, it's as easy as it could be, right? And so that was just a natural use case. And then just the speed of delivery, you know, being able to crank through these integrations. We heard a gentleman during the keynote talk about, man, integrations used to take like four months to deliver and you think about it now, it's like that, it's silly, but it's true. That's the world we came from. And so to have a platform that just makes it so much easier, so much snappier, particularly in a space where it's so important, like what the end goal is, is to get that patient care and get them the best medicine and stuff like that. Yeah, and it's such a story that everybody on Earth has been touched by. So Michelle, talk to us about Juno Therapeutics as a great example of what you're doing with the program Tech for Good, Innovation for Good, but also give us a little bit of your interesting backstory on you had a personal connection to this. Tell us about that. Yeah, absolutely. So the Psalm Innovation for Good team is only about three months old, so it's a pretty new capability. And what it really stems from is we're an extremely purpose-driven company. I think that's also one reason why we partner so well with Bumi is because we share a lot of that passion together and we're trying to make the world a better place. So one thing that we try to do is say, hey, major or not-for-profit, whoever you are, we understand that you have the same challenges all of our other commercial clients do. So Juno Therapeutics as a great example of I have information everywhere, how do I get this under control and get value out of that? And that's why this partnership makes so much sense. And so we bring to the not-for-profits our expertise in technology, but then also our connections and partners like Bumi to the table to say, all right, what could we be doing to accelerate this person's mission or this organization's mission and do that using our strengths? And so another client of ours, for example, is American Cancer Society and very well tied to Juno Therapeutics because actually immunotherapy is a huge opportunity for newer treatments that are less invasive and damaging than chemotherapy. And so my own personal story is, of course, I have a history of breast cancer in my own family.  So helping clients like this through our technology is exactly what we should be doing. You know, one of the things that's interesting is there's a renaissance of tech for good startups. And we started reporting on this a couple of years ago when we were in DC with Amazon. We saw that with cloud computing and the lifecycle changes of delivery and integration that you can get off the ground with very little capital and you could also rent.  So there's a real renaissance and entrepreneurial thinking in this area, which is now kind of spawning social investing, social impact, but actually businesses are getting to profitability. So this kind of speaks to the boomy ethos. I want to get your opinion on this.  Is that true? Do you believe that? What do you see? What's your thoughts on this wave of tech for good? I won't say philanthropy because people are building real apps and there's real value being created. Your thoughts? So I can kick us off. Yeah, I think exactly as Shane was saying, our ability, so if we can reduce time for integration, let's say to two months, three months, I don't know, for something simple as a POC even, the speed at which we're changing the landscape is incredible. And as an example, so we did some work with breast cancer images and using AI machine learning in the cloud. And so we were actually able to reduce the time it takes to do that analysis from three years into a couple of hours in the span of three months. Wow. So when I think about, okay, it's not like this massive, okay, first we're going to do this three-year integration plan, then when we're done with the three-year integration plan, now we can unlock AI and machine learning. It makes so much sense. And who's paying for that, right? Exactly, oh yeah, all the money that the not-for-profits have, right? So when I look at that, it makes complete sense that we should be capitalizing on this and transform that whole industry. Shane, Renaissance, your thoughts, what's your opinion? Absolutely, so I was just talking to a gentleman last night from a retail company who, again, very similar story, has launched his own private foundation and is using technology to do it. Making an impact. Absolutely. There's so many companies out there that are doing this. It's what they call it, responsible capitalism, something like that. And yeah, I think the technology is sort of enabling more of that sort of behavior. If you think of it from a classic pace-layering standpoint, right? It's the, where do you want to spend your investment dollars?  And I think making the infrastructure and making these applications so much easier to work with is just unlocking all the rest of the potential for just having an impactful... Impact, impact is a commercial impact for profit. People do that, that's what businesses do. The workloads or workloads, the impact is impact depending upon what you're trying to do. This is the innovation that we're seeing. Yeah, absolutely. And one of the things too that Chris McNabb talked about this morning, even more critical when we're talking about immunotherapy, American Cancer Society and organizations like that is shortening that time to value. John and I were talking about that in our open. And when we're talking about literally life and death situations, any element within an organization, the technology sector where you can save even a couple of clicks for a workflow, there's a snowball effect there because as anybody knows, your family knows, we've all been touched by cancer, there isn't time, you're racing it against a clock. So that time to value in an example like this really speaks volumes about those outcomes that John was talking about. And I mean, I'd love to get your thought, Shane, on I feel like as the tools are evolving and becoming even easier and easier to use, we can democratize those insights faster and enable more and more types of people to leverage these technologies. So I don't know if you're seeing the same. Yeah, no, absolutely. And that sort of that time to value I was thinking about the Sightlife use case as you were kind of talking about that, right? And this is literally where Sightlife's mission is about matching eye donors to people that need them, right?  And so if you can reduce that, which is what Sightlife did, reduce that life cycle from like a 24 hour cycle down to hours, it's impactful. I mean, that just has huge impact. And you're also helping, Sightlife has a goal, I was looking at my notes here, of ending corneal blindness by 2040. So any element that they can possibly shorten in that entire organization is essential for them to achieve that goal. And I also was reading that the success rate of corneal transplants is very high, yet the majority of those folks that need it are in areas that are low income, not as accessible. How can Slalom help Sightlife be able to achieve that goal of ending corneal blindness in that time? Like how is Boombi going to be a facilitator of that shortened time to value? Yeah, I mean, from my standpoint, Michelle, feel free to jump in as well. But it's about kind of exactly what you said, right? Finding those opportunities to reduce time. And the other thing, particularly in life sciences, is quality is a big, big deal. And making sure you're matching the right patient to the blood types, matching blood to blood in the Juno use case, we call that the vein to vein process where they actually take the patient's blood, ship it to a manufacturing site, use their own blood and their own immune system, basically, to manufacture a drug and then re-inject that into the patient. Imagine if you mess that up somehow.  So- Let me help give them that view, because we talk about John and I, at every CUBE event that the CUBE covers, which is a lot, data is always one of the number one topics of conversation. And we think, well, it's the new blood, it's the new oil, it is. If an organization actually has access and visibility to it, and if the applications like Salesforce, ERP, blood bank applications, for example, have the ability to leverage a single source of that data that's governed that they can trust, how does Bumi facilitate that vein to vein process, for example? I'm just wondering if, is there, from a master data hub perspective, is that one of the elements in there that's able to help those on the other end be sure that the data that they're matching is indeed correct? Yeah, yeah, no, that's a great question. So right now, we haven't explored MDH yet at Juno, but I think that's one of those things that may be coming at some point in the future. We call it a chain of identity, right? Is ensuring that the blood that you took from the patient is the same blood that comes back, essentially, like tracking that through the entire lifecycle. And right now, we're using the Bumi platform, we're using Bumi integration to accomplish that. We log sort of patient identifying information all the way through the chain, but we also redact it when we log because obviously there's GDPR, there's all these other regulations around that. So there's a, again, in life sciences, there's a very interesting balance you have to walk. There's regulations you have to follow and things like that. I'd love to get one last question in for the people watching that are maybe changing careers or doing something entrepreneurial in social impact. Your advice to them, because people can see value, they see how path to get there, funding requirements are lower, a lot more people saying, hey, I'm not just doing good, I'm actually can make this as a living, a lifestyle choice or whatever reason, business reason. What's your guys' advice to folks thinking about making the change, best practices, lessons learned, scar tissue, anything you could share? Ooh, ooh, ooh. They're definitely scar tissue, like a four month, oh. Four months, four years, the four months, the four hours. In the basement, you know. Hard core, how do you get this up and running quick? What's the best practice? Yeah, I'll let Michelle start on this one. Oh boy, okay. No, I do have some advice, you know. I don't think it's necessarily an easy path to do this. However, I think it's much more feasible now to do it, especially with the speed of technology.  And I think at Slalom anyway, and with many of these other companies, we have found operating models that support both. And I think if you maintain your passion, but also your business mind and the technology sense and combine those, I think that's the way to go. Shane, technical thoughts, standing up stuff's cloud, booming. Yeah, I mean, it's a very wide and deep world out there. But the thing that's so awesome, you know, I tell, you know, my directs this all the time. The opportunity to teach yourself things is like at no other time, you know, in our world, all the information is there.  So I'd say, you know, follow your passions and, you know, be a fearless learner because the opportunities are there. Great insight. I like that, be a fearless learner. Well, Shane, Michelle, thank you so much for sharing what you guys are doing at Slalom. And we look forward to hearing continued successes. Absolutely, thanks for having us. I appreciate your time. Thank you. For Shane and Michelle and John Furrier, I'm Lisa Martin. You're watching theCUBE from Boomi World 2019. Thanks for watching.


Okay, so how many people work for product companies like Microsoft or Phillips or IBM or whatever. How many people work for service providers like Tata Infosys, get stuff like that. How many people here are coaches or Mentors or you know working on your own have coaches that are on work on your own. Okay. How many people are other? How many people try to raise in your hand? Oh? Not many. Okay. Oh Thank you. Okay. So nice What I want to talk about today is the dispensable enterprise. What does this actually look like in practice? So what's the story that I'm about to tell? Well, one of the things that I've noticed over the years and I'm a tad guilty of this myself is that Agile software teams are really good at building awesome racecar engines. We're good at tweaking agile We're good at tweaking agile software development. We've got a lot of great ideas We can you know, you know keeping the engine analogy going we can you know get better and get better fuel mileage We can become more performant. We can speed things up.  I guess that's a that's a very good thing actually, but unfortunately We take these awesome racecar engines that we're building these awesome agile software development teams and We put them in organizational tractors We put them in these legacy organizations with legacy systems and legacy mindsets and legacy management legacy government governance and We've got these you know awesome racecar engines in these tractors and that's a big surprise when we don't win the race I have no idea why you know, I don't think I don't think a tractor has ever won formula one I don't think everyone's even been entered But anyways certainly if one has been entered at some point in history. I don't think it won Because what we really need are? racecars We need these it department racecars that can support our enterprises that can support our organizations But that's just not enough either. We also need a team to run the race car So I'm not a race car driver So yes, I could yeah, I could I could go and buy a race car I presume I could somehow enter it in a race and it would probably I would probably lose because well first of all I'm not a very good not a very good race car driver I have to presume but also I don't have a good supporting team. So we need an organization So we need a great IT race car But we also we also have to have that in an organization that can take advantage that can use and work with the race car In order to win the race So we need to look at the big picture. So this is what I'm what I'm gonna talk about today So I want to address three three important questions. So first of all, what does it mean to scale? At least in it within enterprises and then I'm gonna look at scaling from two points of view How do we scale tactically? So how do we help agile software development or solution delivery teams? I would like to say scale to meet the needs of the situation they find themselves in and Also, how do we scale strategically? So how do we scale agile across the IT department? Because once again, if you know, we have these great race car if we have these great racing car engines These great software development teams, but the rest of the IT department is a tractor Then it doesn't really matter what we're doing. Yes, we'll have a tractor with a really cool engine So what, you know, I'm sure the farmers of the world are go out drinking and they brag about the great engines They have their tractors, but if that doesn't really make news headlines Because we want to win the race because these days if you're not winning the race or if you're least not competitive Then you're pretty much you're destined to go out of business So anyways, what does it mean to scale agile? So first of all like I said, I like to distinguish between two two types of scaling first of all tactical How do we scale agile teams and then strategic? How do we scale like to IT departments? So scaling is it more isn't just about team size Okay, now obviously, you know team size is interesting so we can scale agile all the way from teams of two people To teams of several hundreds of people. I've worked with teams of many hundreds of people Delivering mission critical software into the market like single programs of six seven hundred people Delivering mission critical software into the marketplace. There's not many teams out there like that But they do in fact exist the vast majority of teams are actually 10 people or us Well, let's actually see so many people here right now are working on a team a software development team of 10 people or less Many people are working Maybe a third half. How many people are working on a software development team between 10 and 20 people? 20 to 50 50 or more Okay, pretty big. Not so bad. It's a little bit of a little above average Only about 2% of all software development teams are 50 or more people, but be that as I mean apparently You're above average That's the way I'll spend that one Okay, so Another thing we have to have to be concerned about more scaling is geographic distribution One of the great myths in the agile world is that agile teams are co-located now. This is obviously a very good thing I'm a firm believer in co-location, but the minority of agile teams are co-located The as soon as you have people working in cubes or working in their own offices That's a form of geographic distribution Let alone if they're working in different buildings on the same campus or different buildings in the same city Or different buildings across the planet and the more and more geography distributed you are the greater the risk goes up and you know Cost goes up and bad things start to happen to you so a point that I want to make right about now is that teams in different situations will work in different ways So a team of five people will work differently than a team of 20 than a team of 50 than team 500 a Team that's co-located in a single room will work differently than a team that's in cubes Then we'll work differently than a team that's spread across multiple buildings different teams in different situations will do different things Then we have organizational distribution It's pretty straightforward when everybody on your team works for a single division of a single company Little harder when you have multiple divisions involved politics start to rear their ugly heads It becomes a little more difficult to prioritize stuff like that a little harder yet If you're involved in a consortium of companies that are trying to build some sort of a shared environment Little harder yet if you're off-shoring or if you're outsourcing some of the work So you've got one or more external companies that you're working with to get the job done There's some sort of business contract in place So once again different teams in different situations will work in different ways Then we have regulatory compliance Some team roughly a third of agile teams work in regulatory compliant situations. That's just the reality It's not and it's not it's not a paradigm thing at all If you're working in the health care industry chances are you're have to conform to health care regulations I've done as I've worked with agile teams in very highly regulated environments and those teams those highly regulated teams Work in a different way than the teams that don't face any regulation at all Then we have domain complexity some teams get to work You know build you know address very simple problems So for example, you know not to not to Denigrate the conference, but you know that the conference app. That's a reasonably simple problem to solve right fairly straightforward building an air traffic control system Several orders of magnitude more complex than the the conference out. I Have to think that the air traffic control system team will work in a slightly more sophisticated manner Then the applicate then the conference app development team. It's got a full range on that one And then finally we have technical complexity It's pretty easy to work in an environment where you're working with brand-new technologies You're building a silo system that doesn't have to interact with anything else and it's green fields You're building it from scratch. I've never been involved in something that trivial It's a little more difficult when you've got to work with older technologies We got to support multiple platforms when you have to work with legacy systems when you have to work with legacy data sources When you have to fix legacy systems because you're you know for some strange reason You want to pay down technical that when you have to pay down technical that in your database also a little more sophisticated So we have a wide range of technical complexity that we're dealing with as well And we're gonna work in different ways when we do that so different teams face different scaling factors Okay, and you could all and you could also very easily argue that we're missing some sort of a people or a cultural or skills based scaling factors. Well, that's Yes, I agree. Maybe so but anyways, this is this is challenging enough. So any given team will be somewhere on these scales Your team will be have a different set will face a different situation than your team even though you work for the same company and Maybe developing reasonably similar things but different teams in different situations. It is what it is So one process size does not fit all you need to be flexible Choice is good. Well, I'll hammer on that a few times today. So an interesting question is is this real is You know, are we actually seeing this in practice?  Because usually what the gurus talk about and what's really happening can be very different sometimes. So in this case It does in fact seem that we the agile teams are in fact facing these complexity factors Sometimes we have agile teams. So for example an interesting thing when we ran this survey This is not something I expected one of the interesting things that happens when you're whenever you run me We do research like this You find you find things you don't expect one of the things that was very interesting Was that agile teams are more likely to be taking on hard problems than non agile teams So the organizations that are doing agile and particularly more interesting ones that are doing both Traditional or you know non agile and agile are finding that agile is much better at dealing with complexity than not so agile ways of working So they've learned to you know Oh, I got a hard problem better give that to my agile team because they're more effective at dealing with that hard problems This is not a good message for the traditional folks What I also found was interesting which I also didn't expect was agile teams on average tend to be a little more bigger than Not so agile teams The good news is we're less likely to be geography distributed now Some of that might be we're still sort of figuring out how to do Geographic distribution that some organizations have have clearly figured out how to do agile in a geography distributed manner But for the most part because we're we work a little bit smarter in the agile world We tend to avoid Geographic distribution when we can we try to you know get people as close as possible So that's a that's a good thing. So anyways, we are in fact seeing People applying agile at scale and it is in fact working. I don't have all the stats with me here today But just take my word for it There's ample evidence that agile does in fact work at scale So if you still happen to be an organization where people tell you oh, you know agile is good for the simple trivial things But you know the real men they do traditional. Well, no, that's not true anymore Agile works at scale now having said that just because other people have figured out how to scale agile and make it work Doesn't mean that you will figure out how to make it work. So, you know, there's no guarantees in life on this one The other issue just to briefly I'm talking about before we get into details a little bit later on is We also need to think about how do we scale? How do we build this racing car this it racing car? So how do we scale agile to the it level and so this is a very high level flow diagram? We'll go into a little more detail in a bit But the idea is how do we how do we streamline the flow throughout the entire it effort? Because all it takes you know Once again, it gets back to the racing engine if we've got some agile delivery teams or lean delivery teams And they're doing a great job But then suddenly they have to work with the data management crowd in order to get a change to the database and it takes six weeks To you know to add a column into a table it takes six weeks to do five minutes where the work Well, that's a bit of a problem and I work in organizations where that's the case It takes six weeks to do reasonably straightforward things because of their onerous processes and all that all that sort of stuff So if we don't streamline everything And we don't find ways for these people to work together effectively Then it doesn't really matter all these cool things that the that the agile teams are doing because we're still gonna get you We're still gonna get Brought down by the one or two teams that are working in the old way The other interesting thing about this is Something that we call this called the bimodal problem. So Gartner talks about organizations being bimodal So you've got mode one teams that they call predictable, which I find insulting But anyways, they're the traditional slow teams then you've got the mode to the agile lean teams that are working fast and In a more disciplined quality focus matter that gets stuff out the door quicker And the idea is that the observation is that somewhere around 80 to 90 percent of organizations Have both mode one and mode two going on Because either they haven't fully transitioned to agile yet, which I think is the case in the vast majority of them Or it makes sense. It does in fact make sense to have some mode one teams and some mode two teams I argue that it's really multimodal. We'll talk about that in a few minutes, but you know be that as it may There's at least you know two or more modes of working in the vast majority of enterprises out there And we need to respect that so if you're an enterprise architect and You are supposed to support development teams, which is you know the fundamental job of enterprise architect At least one of the fundamental tasks. They have to do They have to be able to work with the the traditional teams in a traditional manner and the agile teams in an agile manner And the lean teams in a lean manner and so on Okay, so their jobs become more difficult if you locally optimize on enterprise architecture You've got one way to do enterprise architecture, then you're not going to work well with at least one one of those modes of teams okay, so that I think is an important thing the other thing is this is also this diagram and like I said, there's more to it than this but This diagram is think of this from the point of view of the CIO. So let's let's raise our view up Let's get away from the selfish, you know, whatever our selfish points of you are unless of course your CIO And then this is your selfish point of view but let's look at it the point of view of a CIO and As a CIO if you're responsible for having an effective IT organization to support the rest of your company You got to make all this stuff work The challenge is that there's different bodies of knowledge for all of these things So that you know the development folks the delivery or you know software development folks They've got several bodies of knowledge. We've got the agile cannon. We've got the end you know this the software, you know the software engineering box and Two reasonably different things and see Matt and all good sort of stuff the data folks have got Dama the Management the portfolio management folks. They've got the PMI and the Prince to stuff the enterprise architects They got togaph and modaf and dodaff and zhokman and Five other things that I can't you know whip off the top of my head the operations folks have ITIL and they're all great bodies of knowledge They're all wonderful. They all got some great ideas. They've all got some not so great ideas as well It is what it is They contradict each other. They don't fit together very well. They overlap All of them are the center of the universe like this conference is all but how we agile software people are the center of the universe We're the most important people on the planet and if we were to go to an ITIL conference Well the ITIL people very obviously the most important people on the planet and so on and so on and so on So it's a complete dog's breakfast and worse yet So if you're the CIO you've got to listen to all these people go blah blah blah I till the greatest things in sliced bread and we're the center of the universe blah blah blah Agiles the greatest things in sliced bread where the center of the universe blah blah blah enterprise architecture center the universe All that sort of stuff, right? What do you do? What do you do? So keep that in mind So anyways, how do we scale agile tactically? So an important observation I'm a firm believer in empiricism and as well as in constant improvement so One of the beautiful things about empiricism is that there's a lot of you can see a lot of great things happening out there You can also see a lot of not so great things happening out there So I'm a firm believer in asking questions around the lines of what you know, so any given practice or strategy I'm always asking the question What in what situation does this work? What are the advantages? You know, why would I want to follow this practice if at all? What are the disadvantage with the side effects that I might not you know What are the negative side effects that I might not like about this practice in what situation? Does this practice make sense and in what situation or situations? Does this practice not make sense? I'm a firm believer. There's no such thing as best practices. That's a marketing term Okay, whenever somebody talks about best practices, they're taking you for a they're taking you for a ride Okay, every given practice every green strategy works well in some situations. It is the kiss of death and others So you have to be really smart and you gotta be obvi- you gotta really got to reserve and ask You know ask questions and try to figure out does this practice work well for me So you need choice Because you got to choose the right practices the right strategies the right team structures the right cultural aspects for you And you should always be striving to improve One of the great things what agile is that it made it clear that you know We should be we should be reflecting on a regular basis. We should be actively striving as individuals and as teams to get better That's all good stuff. So anyways The dispensable framework came out of empiricism It was based on the observations of my of myself and my team going around organizations around the world Seeing how they were applying agile in practice seeing how they're applying agile in these not so perfect situations and many of you when you're sticky up your hands very clearly you're not working in such perfect situations and Chances are pretty good. You're not empowered to change those situations drastically at least not quickly You got to learn to live with it and do the best you can the situation you find yourself in and then improve your way out of it I hope or improve your way into a better situation So there's a bunch of you know great great characteristics of that exactly what you expect from agile stuff It's very people-oriented learning oriented We try to get rid of the some things we that you might not expect We try to get rid of all the prescription out there by being gold-driven or capability driven We'll walk through some of the implications that in a few minutes On the Software development side of things I'm a firm believer in looking at the full delivery life cycle from beginning to end and Better yet if you're a stable team, then it's just well from the beginning of that stable team until you know infinity and beyond To quote a good cartoon character. I'm a firm believer in being solution focused not just software focused I think the one of the things the agile manifesto did was cause some significant damage out there in developer land by being too Overly focused on software development. We don't build just we don't just build software. That's a that's a misnomer our software runs on hardware We often have to improve the hardware that we're working on and even deploying to the cloud That's a hardware upgrade in my mind or a downgrade depending on your point of view We often have to change the business structure I know that you know the business processes are on the usage of these solutions We often change the organizational structure of the people that are using these systems We often have supporting documentation. So we have this full solution that we're working on Not just software. So we need to up our game, right? So, you know in the 90s we are the industry was on the right path maturing in that respect We sort of you know one of that we sort of down backslided When we started for overly focused on software. So anyways room for improvement and we're enterprise aware I'll talk about what that is this based on the observation that my team is only one of many teams and That we need to work with these other teams effectively And those and those obviously those other teams need to work with my team effectively as well And we need to do what's right for the company not just what's convenient for my team We need to look at the bigger picture a little more robust Stads of hybrid so one of the one of the great things about agile is that there's hundreds if not thousands of practices out there The problem is that there's hundreds if not thousands of practices out there How do you how do you find out about them? How do you know which ones to apply? How do you know to what extent to apply these practices? Or to even to apply them at all? How do you choose intelligently? So that's an interesting thing. I want you to think about for a few minutes So anyways, like I said, it's pretty easy to observe that my team or your team is one of many teams in your company Unless you're a very small one-team company So how do we how do we make this work? so In this financial we baked in this philosophy of enterprise awareness and what it what it is is We observe, you know, if you observe the history of software engineering that the traditional folks are all about individual awareness I want to be the best tester I could be I want to be the best programmer or the best architect I can be I'm gonna do my work and then gonna throw it over the wall to the next person And then they're gonna do their work and throw it over the wall the next person and so on more like a Tayloristic You know very finely grained way of working and that's theoretically interesting But it's a phenomenally inefficient way to of organizing a team So the agile folks came along and they observed. Hey, you know people people teams of people build software We really need to be team focused We need to you know make have these whole teams We need to get out of their way, you know Given the resources they need this time and money and whatever it takes and then get out of their way Let them you know support them as much as we can of course, but let them do their own thing That was definitely a step in the right direction But we really need these teams to be enterprise aware. I don't need I desperately if I'm a bank of America or if I'm you know some large insurance company or Ford Motor Company or Microsoft or any any these you know reasonably Reasonable-sized organizations. I don't need you going off and creating yet another customer database. I just don't Okay, if there's an existing customer database out there, please we use it. Please follow common conventions Please pay down technical that when you run into it Obviously, we'll have to fund it and find ways to find all this or stuff So we need to we need to be a little more mature. Please follow a common technical roadmap Please follow some sort of common business roadmap make make sure that whatever you're building reflects the overall needs of the Organization and what are whatever our overall direction is? So we don't want teams just going off willy-nilly Doing whatever they want. We need the fleet of teams needs to be sailing in pretty much the same direction for us to be effective as an organization So we can up our game there and this is important. This is a culture building thing So earlier James was talking about the need to you know to improve quality and pay down Technical that well part of that is you got to bake it into your culture So for example if you go home tonight and say you're the only one at home and you walk into the kitchen You want to make yourself dinner?   Yeah, you clean it up, right?  That's strange.  Nobody's listening. Okay, so what do you do? You're an adult you clean the orange juice up right as to what you do Well, if you go back to work tomorrow and you open up a code file And there's a mess in the code right poor quality. Whatever the poor quality issue is What do you do?  Most people Don't clean up the coat. They haven't you know, so you've somehow you as an adult You've baked into this idea that oh we need to clean up juice when we see it But as a IT professional as an IT adult we still you know across the industry We still haven't figured out Oh, we need to pay down technical debt when we run into it and we have all these excuses for why it's not our fault But it is what it is. So anyways, we need to start baking dispensable. We want to start baking some of these I some of these Cultural imperatives right in to right into our organization So following common conventions working to common guidelines working to a common vision working together Paying down technical debt not such a bad idea Another important observation. This is a snowflake. I realize I'm in Bangalore You never actually snows here, but in Toronto or I'm from you know, it snows, you know 365 days a year.  That's not true at all But anyways snows in the winter so snowflakes are unique People are unique if I look around this room It's a room full of unique people And even if there was a is there a set of twins in the room Every so often that no, there's no twins Okay, even if there was a set of twins or triplets if you if you know anybody who are identical twins The one of the big things that they do in life is they go out of the way to prove to you how they're not identical Unless of course they're on TV and there's all shenanigans But even twins are desperate to show you that their identity that they're unique So every person every team and every organization is unique This this is a critical observation. We we're in different situations. So we're gonna work in different ways Even two teams are in basically the same situation We'll still work in unique ways because they're different people with different skills and different preferences And they're gonna work in different ways This can be phenomenally frustrating in a large enterprise where there's people running around with this vision of oh, we're gonna have a repeatable process repeatable processes Have nothing to do with efficiency. They have everything to do with bureaucracy and justifying bureaucracy And they're a good marketing scheme for you know for those of you working it at the service providers You can still sort of get away with you using CMI as a marketing scheme Although those days seem to be numbered, but anyways, we'll have to see how that plays out So what's some of the implications here? Well, if everybody's unique and every team is unique Then one once one process size one life cycles does not fit all so when I go into organizations And I do this around the world constantly It's pretty easy for me to observe that hey There's some teams doing some sort of a scrum-ish type of a thing It's almost always scrum butt or scrum and or you know, whatever you know Whatever marketing terminology is being thrown around today, but there's some sort of of a scrum-ish type of a team of teams going on Sometimes there's some sort of lean-ish con-bonnish things going on Sometimes we see some sort of continuous You know some of the smarter teams or the more effective teams are doing some sort of a continuous delivery type of a thing And every so often we'll see some sort of lean startup You know lean product startup type teams because they're they're taking it They're doing a new product and I see this even in in insurance companies and in banks and in retail companies when they're you know Very clearly not startup companies and yet they're still they've still got teams following a lean startup process Or or some sort of a lean startup type of a thing or you know, they should certainly be doing that So anyway, so because it's easy to observe that different teams work in different ways in this one agile We support multiple life cycles and this can be a mind-blowing thing. So if you're an IT governance person Well now you're oh and You could also have mode one teams going on some traditional teams as well, which we don't cover But you know, we accept the fact that they exist. So if you're an IT governance person, oh My god, all these teams are working different ways They're not they're not creating the same artifacts at the same point in time in the same way following the same templates and oh, no My boom my head explodes right so if I'm if I'm one of these teams like the data management team or the IT governance team or the enterprise architecture folks or whoever they are and I've got to support multiple delivery teams and these teams are working in different ways Then I need to be flexible enough to support multiple teams working different ways And worse yet, even if they were all agile teams So let's let's say we're in the fantasy nirvana land and if we've got all agile teams They're all still working different ways Anyways, and even though I could wave my magic wand. So let's let's just beat this repeal process idea to death Say I could wave my magic wand and all these teams out there You're all following the exact same process right now. You're I because I'm Harry Potter and I'm magical and I can do this Doesn't matter because in a month or two because all these teams are agile They should be improving the process as they go. They should be holding retrospectives or some sort of a reflection activity They should be learning. They should be getting better. So a couple months from now There'll be noticeable deviations in these teams because you'll be learning Six months 12 months from now. There'll be significant deviations in the teams Because you're different people in different situations with different preferences different ways of working and this is what you're naturally gonna do This is the reality in enterprises might not be what you want to hear might not be comfortable But this is the reality. This is observable reality. So let's make this work Let's deal with reality So keep that in mind So let's go through some examples, so There's different ways and this is clearly not all of the ways that we can manage changing requirements But here's a few we can use some sort of a scrum product backlog type of a thing We could extend it a bit with some unified process Concepts and have different types of things on the on the stack and all this sort of stuff But it's the same basic idea. We have a stack of requirements. We work down the stack We could take some sort of a lean approach You know have some sort of a work item pool or a requirements pool We're gonna call that we're pulling things in one at a time. We got different ways We can prioritize the work all good sort of stuff We could do the evil formal change management approach Now all of these strategies have advantages. They have disadvantages They can all be used in agile lean situations I have worked in a situation where formal change management in an agile team where it actually made sense Now that that those situations are few and far between There are several orders of magnitude of people out there that think that formal change management is a good idea when it in their situation when it really isn't but We have to respect the fact that in some situations It does in fact make sense to do formal change management and what this situation was I was working with the team and we were building the software for pacemakers And when you're doing life critical FDA anal and retina of regulatory stuff like that If you don't want to go to jail, you do formal change management Now we also combined it with our product backlog To you know streamline things but for some things we did a formal change management That is the reality on the ground for some companies and we need to respect that if that's not your reality Then please don't do that So anyway, so in this financial we're all about choice So earlier James was telling us how we you know how these Discipline these agile scaling frameworks are all about being safe or being comfortable or acceptable or whatever it is and that's important Because if it's not acceptable It won't be accepted by most enterprises. That's the reality on the ground as well But if you want to be agile We also need to be bold or bold I sort of like the bald one because you know because all the incredibly sexy men out there are in fact bald But anyways, if I would show you ladies, please pay attention. Don't let anybody tell you different Yes, some some men do in fact have full heads of hair my five-year-old daughter also has a full head of hair I just figure that one out for yourselves. You can correlate What are you know taking any implication that you want about the what's going on there? So the point so what okay, so nice back on track. Okay, so choice is good So when we want to address changing stick cooler needs when we recognize that different teams are in different situations And have different skill sets and different priorities and different preferences and all good sort of stuff We need to give people choices. So one of the things that James was talking about is we you know to be truly agile We need to be we need to be bold or we need to be bald Those two things are not mutually exclusive being acceptable and being bold or bald Are not particularly acceptability involve this are not mutually exclusive trust me on this so anyways what we can do is We can give people choices. So the way you read this chart is we've got this goal So throughout construction we want to address changing stick cooler needs somehow because the requirements are going to change and they're going to involve And all this sort of stuff when we do that There's several issues that we need to consider first how we're going to manage our work items So for example, what which one of these techniques or others are we going to follow rock or combinations? They're up how do I prioritize work is it by business value is it by dependency is it by Priority is it you know or by many other techniques when are we going to accept change? So if we're following if we have iterations, do we accept change? Do we accept changing requirements in the middle of the iteration or like you know like most teams do or do we push it off to a future? iteration like we used to do like like scrum used to prescribe up until I think the 2012 scrum guide How do we interact with staples of these so one of the problems that James was talking about which I fully agreed with is product owners are certainly not a perfect solution a hell of a lot better than what we used to do was a step in the right direct Significantly better in writing documents and throwing them back and forth to each other But certainly not ideal so for example When we look at this when we look at this was stickler interact with the team We have this list of choices and it's not all choices So one of the choices is for the team to work indirectly via proxies a product owner being a proxy a business analyst Be a proxy a product manager perhaps being a product a proxy I should say so we're not directly working the developers themselves don't directly work the stakeholders a better way of working Which takes a little more discipline a little more skill is that active stakeholder participation to be side by side? You know what XP used to call on-site customer what we called agile stickler participation in agile modeling the basic idea Was that you work side by side with your stakeholders? So that's that's what that's what on-site customers all about we up the game a bit in agile modeling I said hey, I got a live body there. So instead of just asking them questions and having conversations, which is a great idea Put them to work The business people can actually do some development if you let them they can be active involved in modeling sessions They can draw things on whiteboards. They can fill out a index cards and post it notes or whatever your tool of choice is They can write code these business stakeholders who apparently have no techy skills whatsoever five minutes later They'll be whipping out Microsoft Excel and white writing some you know Uber cool macro That might not be getting tested properly, but details But they can in fact be involved in development if you allow them and it's highly desirable too And it's hard to do and a lot of organizations struggle with this But as James was saying but it's clearly an option So the acceptable strategies which might allow agile to get in the door are this you know throw documentation around Which is a really bad idea Maybe we can up the game a bit get them in you know good business analysts or good Procterors, but eventually we can evolve into active stakeholder participation like Diana Larson talks about like we were talking about agile modeling 15 years ago Now the way you read this chart is That so we've got these goals this this process goal We've got these these issues of these these factors that we need to need to consider and then for each of these factors We've got options now. We're not saying we've identified all possible options. That's not possible but we are saying there's a pretty darn good range and it's enough to wake you up to let you know you've got choices now in behind all this Every single one of these practices or strategies has advantages and disadvantages. So we want to help you make intelligent process decisions so today You might only have the skills or the cultural ability to work with product owners or business analysts That's the best you can do right now today fair enough Better ways of working. So let's bolder ways of working that We can make make you aware of so that way, you know, you've got off. There's an opportunity for improvement here So eventually it may be in a in a retrospective when you start to realize hey, we need to get better at understanding requirements It might tweak that. Oh, hey, let's go looking. Oh, hey working side-by-side with the stakeholders. That's such a bad idea Let's try it out put him to work even better. I can speed things up got more more hands That's such a bad idea Work to another example So we can explore scope in initial ways at the beginning of a pro of a team You know be at the beginning of a software effort if it's a product team or a project team We have to we have to do some initial scoping effort Gotta figure out which direction we're going in and we can do you know user stories on index cards or in some fancy tool We could do whiteboard sketches. This is a UI flow model or a UI Sketch type of a thing and there's different types of obviously many many different types of sketches you could do You could have one of those evil You know evil detail big requirement up front documents There are in fact a few situations very very very few situations where that makes sense But it's a valid technique Usually around keeping me out of jail type of a thing or we could go very high level have goals I've done multi-million dollar efforts where the requirements document was a list of five goals five bullet points Not even a pair not even a sentence Okay, definitely not a paragraph and it was a multi-million dollar effort funded based on five bullet points now That was you know a really a proven team with a good with a proven track record So they didn't really need you know detailed requirements But the point is is you got choices and all of those strategies are applicable in some situations and not others To do what's right for you So the way we capture this in a goal diagrams like this so we're exploring the initial scope Well, what level of detail do we need to go to and the point? I want to make here is that you are implicitly making these decisions On a regular basis you are implicitly making process related decisions So when you're when you're approaching requirements when you're doing requirements However, it is you do it on your teams at some point in time you implicitly thought how much detail do we need to go into? What what types of models do we have to create how are we gonna do user stories in epics? Are we gonna do personas are we gonna do? You know UI prototypes we do data models or class models sequence. You know, what whatever it is that makes sense for you You had to make those decisions. You had to figure how we're gonna go about modeling Are we gonna have formal modeling sessions do jabs from the 1970s? Are we gonna have agile in formal agile modeling sessions all good all good strategies? How are we gonna approach non-functional quality of service requirements? Because those thing you know the non-functionals they will drive a lot of your testing effort They'll drive a lot of your architecture decisions as well. They'll drive you know drive some of your well functional Requirement gathering so we got it. Yeah, we want to start thinking about those reason be early in the effort We got different ways we can fund teams. This will be a bit mind-blowing for the people working for service providers but The way we read this chart so one of our options is to do it once again This is not all the options out there. We could do cost plus So a low time of materials with the occasional delivery bonus in the extreme this is just pure delivery bonus and we and you get paid paid based on value a slightly slightly more risky Way to work is a time of materials So you just get paid a time material rate a slightly riskier way of funding an effort is Stagegate funding so we go we go to the well We you know we go to the financial people every couple months and please fund me for the next quarter jump through whatever their hoops are the riskiest way To fund an IT effort is fixed price the worst possible way unethical way For IT people to do if you want I'm not gonna go into details on that one But please feel free to Google Ambler estimating unethical or Ambler fixed price unethical Will get you to a very interesting article on this subject. So the interesting thing about this slide So we've got choices. Those are these choices are all valid in some situations for agile teams. They all have advantages and disadvantages Do you know when to choose each one? The strategies towards the top or the least risky but also require the most governance on the point on the point of view of the of the business Fixed price pretty much gambling but requires the least you know just fire and forget and hope for the best Everything so anyways, we've got choices. So we capture that is in the secure funding goal So I can go through all all the goals, but just want to give you choice. I want to make you aware of these things so in summary at least to summarize this Goldman approach for delivery we talked about 22 different goals and What and these are all based on observations and not every team does these things So not every team chooses to do risk management for example probably not a badge and probably not a good choice But that's okay. I'm one of the things that James was talking about is how do you do how do you how do you bake in? You know, how do you do or wouldn't it be nice for agile teams to pay down technical debt? Yeah, wouldn't it be nice? So not only do we bake it into the culture at least try to bake into the culture We also bake into the product into the process because there are ways that we can improve quality as we go Hopefully avoid adding avoid creating technical debt to begin with that's another story But if we do run into technical debt, it would really be nice to be paid down and there's a bunch of techniques to do that So anyways when we're scaling tactically, there's a lot of great ideas out there in the agile community that we can leverage But that's just a start and there are some challenges. You know Jane other speakers Have been talking about this at this conference that we need to go beyond scrum We need to go beyond some of these other techniques, but they do form a pretty good a pretty good start This one agile puts it all together. It tries to answer questions. How does this stuff fit together from beginning to end? How do we make choices? How do we you know? How do we live with you know, how do we how do we accept whatever we have to do right now? But how can we inch our way up into better ways of working in the future? Okay, how do we become more bold and Then finally and the idea is that if you don't know how to do agile in reason we're straightforward situations as a Team you're probably going to struggle at scale So if I don't know how to do agile on a small team chances are pretty good I'm going to struggle if it's a large team if I can't do agile when I'm when I'm co-located I'm probably not going to be able to figure out how to do it when I'm geography distributor on the planet You got to learn how to walk before you try to run Okay, and I think a lot of organizations right now are really sort of struggling with this They get good at scrum and then boom they skip a step and they try to go up And they try to start doing you know agile at scale when they can't even do it At they can't do agile at small scale yet at least not reasonably consistently and yet somehow in fantasy land They think they can do agile at large scale Good luck with that now one of the good things one of the things we've observed over the years is that Most of the scaling effort tends to fall down or most of the process tailoring effort made by teams Tends to fall on four of the 22 process goals So how do you approach initial requirements? How do you approach initial architecture? How do you coordinate your activities between within your team and between other teams and then how do you approach testing? That's the blue thing is there and I appreciate you probably can't read any of those these slides are online if you want them So that's scaling tactically now. How do we talk about scaling? How do we go about scaling agile strategically? Well, it's the same sort of issue we have choices and hopefully want to work in flexible matters James was talking about feral architects Roving around your company. I'm not so sure about the word feral. I've seen some feral dogs Out on the street. I'm not sure so sure it will not pet them But I certainly wouldn't have any problems going going into somebody's house and petting their domestic dog That's you know part of the family and working together effectively, right? So anyways, so but this feral architect concept is baked writing as well We can't see on this diagram. He's taking my word for it We're firm believers that the architecture owners on development team on the delivery teams should be actively working With the enterprise architect that might even be one of the enterprise architects depending on the on the way You choose to organize your team and that pattern applies for more than just architecture, of course So anyways, let's talk about so in this in dispensable We've been recently in the last year or so we've been extending it to address this it issue this racing car issue So we've been adding what we call process blades to give people choices because the thing once again if your data group is Offdoing, you know traditional data stuff.  It's gonna hose you up The entire organization needs to be working together We need to have all these teams collaborating together in an effective manner learning as we go and these IT departments are what's called Complex adaptive systems. So if we're truly agile or reasonably agile, we should be learning. We should be improving as we go So my team will be changing the way that we work based on our learnings Your team will change the way that it works based on your learning if we interact together The changes that I make might have potentially changes to your team and vice versa So we're constantly changing and we're caught and we're constantly learning together and evolving together And we still need to keep this overall flow Going as well and hopefully speeding up right and getting better Okay, so this is something that we got and we can't possibly do this if all of us are working from different playbooks If we're all working from different bodies of knowledge that contradict each other and have Greatly different philosophies, you know an agile person if you go off and read the dama You know the dama data management guide or book or Bach or whatever it's called You will you will probably vomit in your mouth when you read that stuff, but it's the religion in the data world And we have to work with them Right, so we need and we need to respect that So how do you do it? So anyways when it comes to program management? We've got choices There's many different many different techniques and once again I'm not saying that we've got we've identified all possible techniques and all possible combinations but we give you a pretty darn good list and it should certainly get you out of the out of the prescriptive mindset and Let you know that you've got options some of which are significantly better than off than others sometimes From a workflow point of view this is a this is a what I call one of our selfish workflow diagrams We're from the program management point of view so from that activity. How are they interacting with these other activities? What types of flows do we see between them? How do we optimize all these flows? So once again because we're complex adaptive systems who are whatever the people are that are addressing these other activities They will have an effect on program management and vice versa and we have different ways to get some information back and forth Across these activities and ways to collaborate interact with each other We've got you know various patterns for how do you organize larger teams this case? This is one way to organize a program team. Oh And an interesting point we like to say we have explicit architects There's a there's an architecture owner in each of these sub teams and they're part of the overall architecture team for the program Because you've got this court means architecture technical coordination to do yeah We at the enterprise architecture level we've got choices and we can leverage ideas from togaf and modaf and all good sort of stuff And once again, we've got flow So I'll leave you. I'll leave the scaling discussion At least this trick to teach it scaling discussion with there's a little more to scaling agile than a fancy poster Okay, and yeah, we have a fancy poster to well, maybe not so fancy, but semi fancy poster and There's more to scaling agile than just that I think we need to need to be a little more aware of that We need skilled people working together who want who want to work together want to be successful as an organization We want to make this you know, we want to win the race as an organization because the organization is paying our salaries And if they don't we don't win the race no pay can't pay my mortgage. That's such a good thing So what's the story I told? So we've gotten very good at building racing car engines An agile delivery and lean delivery very clearly important, you know, don't get me wrong. This is a good thing. We've done We've moved the ball forward very very good thing But that's a start. Well, we really need our net is an agile or a lean IT department We need a racing car not just a racing car engine But a racing car by itself isn't any good either Right, it's gonna sit in the driveway to look cool. That's okay But it's gonna sit in the drive and get nothing done We really need a racing car with a team that can run it take advantage of it and actually win the race Win the business take over the market, you know, whatever it is that your organization is striving to do Okay, so we need to look at the bigger picture and we're gonna be working at all three levels to improve at once It's not just a you know a change or a quick cut over type of thing. This is a multi-year Well, it's an infinite effort. We should always be improving. We should always be trying to get better So we've got options. So in this financial our goal is We want to help make these options clear to you Well, I let you know you've got choices that choice is good and Help you make intelligent choices in a streamlined incredibly lightweight manner because software development is complex IT is complex one of the one of the common things that we get from people is wow, this is really complex I might my brain is gonna melt well, I Would I invite you to take a look at this and then ask the question always asks is what would you take out? and the answer is well Nothing and you miss this this and this okay, so you want to make it more complex. Okay, fine You know, yeah, I can see that but you know, we're trying to keep it as simple as possible We are in a complex environment It is what it is. This is why we get paid what we get paid if I if I teeth software development was simple We wouldn't get paid what we get paid We just wouldn't right we wouldn't have as much fun either I think but anyways be that as a man So, so thank you very much, and I guess we got a couple minutes for questions No, we're out of time. Okay My work here is done. Okay. So anyways, thank you much. I am available out in the hall All you got to do is come up to me and talk to me. I'm also available by via email to so don't be shy If you got questions and you can't find me in the hall, then please drop me an email. Thank you very much