devopsy.kinsta.cloud

Category: DevOps Chats

  • DevOps Chat: Rosalind Radcliffe and Bimodal IT

    DevOps Chat: Rosalind Radcliffe and Bimodal IT

    I had the pleasure of sitting down with IBM distinguished engineer Rosalind Radcliffe the other day to talk about bimodal IT, systems of engagement, variable speed DevOps and IBM’s upcoming InterConnect 2016 event.  I have interviewed Rosalind many times over the last few years and it is always informative and interesting. I hope you find it to be so as well.

    Below is the SoundCloud streaming audio interview, followed by the transcript of our talk.  Enjoy!

    Alan Shimel:                Hi, Alan Shimel here with another DevOps Chats, and my guest is – for this session is a friend of mine, Rosalind Radcliffe of IBM. Rosalind, welcome.

    Rosalind Radcliffe:      Thank you. 

    Alan Shimel:                Rosalind, I think you’ve appeared on DevOps Chats before, and of course we have done webinars and videos together, and so many other things. But for members of our audience who may not be familiar with who you are; do you want to give a brief background?

    Rosalind Radcliffe:      Sure. So I’m Rosalind Radcliffe, I’m a Distinguished Engineer at IBM, and I’m responsible for our DevOps strategy for Enterprise Systems. So I am not only responsible for driving our product direction, but I really spend a lot of time with clients helping them with their DevOps transformations for their Enterprise Systems – mostly mainframe, and their systems of record.

    Alan Shimel:                Excellent. Rosalind, of course, we’re going to talk a little bit about today about this term that’s been creeping up, Bimodal IT, and then I want to spend some time talking to you about the upcoming InterConnect Conference as well. Maybe we can combine Bimodal IT and InterConnect; I don’t what we would call that, but Trimodal. Anyway, so Rosalind in talking offline before we jumped on here I think we both agreed that we weren’t big fans of the term Bimodal IT, and all that seems to have entailed now. Do you want to share with our audience why you may not be a fan?

    Rosalind Radcliffe:      Yeah. I think the term and the way it’s used isn’t implying that there is a defined slowness for the systems of record. I think it’s important instead of saying Bimodal to say more variable speed IT or something that implies that the systems may move at different speeds. I’m not going to disagree with that, but it’s not that one is inherently faster and one is inherently slower. It’s that hopefully for your system of record you’ve built that as a set of API’s or services, and so you don’t have to change the services as often as you need to change that system of engagement to entice the users to stay connected.

    So it really should be about how the systems of record and the systems of engagement can work together through loose coupling, and through proper services. I do think that is going to happen; there are going to be different speeds at different times. Sometimes, honestly, the systems of record might be moving faster than the systems of engagement, because there are changes needed – regulation changes, etc. But it’s – we need to pay attention to it from that standpoint and that’s the reason why I don’t like Bimodal IT. It’s really variable speed.

    Alan Shimel:                Yep. The other point that gets me with it is this whole idea of Bimodal IT, it almost takes that we have two tracks if you will, that move at different – or two trains on a track that move at very different speeds. But they never interact; it’s almost – it almost reminds me of civil rights, separate but equal. We have the water fountain for the mainframe guys, and a water fountain for the cloud dudes, and they both serve water so that’s okay. But the mainframe guys can’t drink from the cloud dude’s water fountain.

    It didn’t work for civil rights, and – I don’t think it works for IT either. I think a better model when we talk about systems of record, systems of engagement, and this whole world, is more – I call it the Swiss watch model. Where you have gears that turn at different speeds, but they all mesh together in a fine tuned timepiece. To me, that’s a much better model than this idea of separate tracks, if you will. What do you think about that Rosalind?

    Rosalind Radcliffe:      I actually think that’s a wonderful way of putting it. Because I think that – it would be a much better interpretation with the gears and the Swiss watch, and Swiss watch timing is always excellent with their gearing system; so that’s exactly what it is. The teams need to work together, and they need to be using the same tools, the same practices, the same processes, and each system needs to go at the speed that is required for the changes that they need to make. But they’re obviously interacting. Your systems of engagement is nothing without your systems of record. So they need to interface properly, they need to work together to provide this end-to-end solution for their end users.

    So they have to be collaborating, and I – honestly I think the organizations that have brought the teams together, that do the systems of engagement and the systems of record into one team, actually do the best. They’re the most efficient; so they may have variable ability in the speed they’re delivering on different parts. But they’re all working together, they’re all collaborating, they’re all one team; not this separation idea. I think your example is very good, it’s not separate, but equal, it’s one team.

    Alan Shimel:                I agree wholeheartedly. I’m not here blaming Gartner for pushing this whole Bimodal IT name and paradigm. But, Rosalind at last year’s InterConnect I remember having a bunch of conversations with you and Sanjeev Sharma and Carmen Diardo, and we were using the term variable speed IT. Right?

    Rosalind Radcliffe:      Yes, absolutely.

    Alan Shimel:                To talk about it – the similar thing, and, of course, I – we’ve heard other people use the term two speed IT. But I think in larger organizations, there’s actually more than two speeds; there’s a lot of different pieces that move at different speeds.

    Rosalind Radcliffe:      That’s really the right answer. I really think it’s important have that ability to move at the speed required by businesses – the business demands, and that’s why it’s necessary. I think there’s a lot of thought process about Bimodal IT, because there are still or there seem to be people out there that still think the mainframe can’t move as fast, that it can’t use DevOps practices. I think that’s actually the core of the issue. We have to break down this thought process that the systems of record – the mainframe can’t move as fast, can’t be DevOps. It really can be, and it’s a reality – I guess it’s a hot button in a sense right now. I’ve just spent the last two weeks with two different clients, and this week with one of them – the first principle they put up was that there’s nothing about the mainframe that means it shouldn’t be DevOps. That the first principle is it needs to be DevOps, it needs to take advantage of the same pipeline, the same functions, the same capability to be able to move as fast as required in a reliable, consistent way with all the advantages of automated testing and automation.

    Alan Shimel:                Absolutely. Rosalind, let’s turn a little bit to this year’s InterConnect where we will have – whether you want to call Bimodal IT, variable IT. There are out of the 200 or 300, I forget how many DevOps related tracks there, there will be some great ones, and I want to talk to you a little bit about that.

    Rosalind Radcliffe:      Yeah, I’m looking forward to the event as well, though I’m not ready for it yet. There will be a lot of discussion and a number of sessions, both customers as well as IBMers talking about the variable speed IT or the different ways that different parts of the application development need to interact, and need to work together. One of the clients I was speaking with this week will be there talking about their DevOps development, particularly about how they’re literally building brand new applications on the in COBOL CICS applications using DevOps principles. So I look forward to all the different client discussions that are held there, bringing their teams together, and I think your Swiss gear interpretation is a good way of putting it. Because that’s what they’ll be talking about, how they’ve geared the teams together to be able to work together to provide the value the company needs.

    Alan Shimel:                Absolutely. Rosalind, are you allowed – can we mention to our audience what company is that presenting? Are you allowed to say at this point or no?

    Rosalind Radcliffe: So in that case, it’s Rabobank, because they’re published as a session speaker; so they’ll be speaking. There are actually quite a few. Rabobank’s one, UBS is another; there are numerous speakers scheduled – client speakers scheduled who are going to be speaking about their efforts and their transformations.

    Alan Shimel:                Rosalind, what about you? I’m sure you’re speaking.

    Rosalind Radcliffe:      Yeah, I have quite a few sessions that I’ll be discussing DevOps overall, working with clients and their transformations, the capabilities available, as well as having more discussions on the ops side of DevOps. I think one of the things that has been an interesting challenge is the how do we really bring ops into DevOps since we really do have ops organizations. That’s going to sound really strange, but when we think about DevOps a lot of the discussion has really focused on automation and delivery, not really focused necessarily on running the systems. So I’m trying to help some of the discussions bring more of the ops side in. How do we really get the ops collaboration coming in? How do we tie the teams together from a complete end-to-end standpoint?

    Alan Shimel:                Excellent. Rosalind, it’s hard to pick among many, but what do you – besides the ones you just mentioned, give our audience – if they’re wondering should I go, should I not go, not sure; what are the two or three biggest either sessions or points of learning that you think people should know about to jump in here?

    Rosalind Radcliffe:      Honestly, I think there are too many sessions to name, but the way to think about it is there are too many sessions to name. There are lots of client sessions, we’re going to be discussing their experiences. So the value out of a conference like this, one of the key values is the ability to hear from your peers, and to network with your peers to understand how they’ve done this, how they’re getting value. That’s the best way to learn from other people who are already experienced or who are experiencing. You’re going to learn from people who are headed for you, and you’re going to be helping people who are behind you. So it’s the networking, it’s the opportunity – hear those sessions, and the opportunity to meet all of the different people who are working in this space.

    I think that’s the value of conferences like this; the chance to network and take advantage of that. Many people I’ve met in prior InterConnect’s have said it’s the collaboration, it’s the conversations, it’s the meeting of people that have given them the most value. Attending the sessions is also very important, but it’s the sessions that give them those contacts. So they learn in the session, and then they have this contact that allows them to continue to discuss. You always get fun – learn something new, you get some fun stories, you get something you’re really going to be able to take back and provide value to your organization.

    Alan Shimel:                Absolutely. Rosalind, believe it or not we’re just about out of time; we probably have gone over. As usual it’s always — when this happens whenever we talk I apologize. But, I am looking forward to seeing several of your sessions at InterConnect, as well as I should mention – this is a quick plug, I am moderating a session myself on what DevOps will look like in the next three to five years, and I have none other than Gene Kim on the panel with me, which should be a lot of fun. So if anyone listening is attending Interconnect, please come on down for that one.

    But, Rosalind, it should be quite a show, and I’m looking forward to how this whole Bimodal IT, variable speed IT, how it plays out. We’ve said it before, mainframes aren’t going anywhere, and the new way of doing things like DevOps and Agile and stuff it’s going to influence how we use our systems of engagement, but it’s not going to negate them. It’s always a pleasure to speak with you, and look forward to seeing you in Las Vegas February 21 to the 25th correct?

    Rosalind Radcliffe:      Correct. I’m looking forward to it as well, and as you mentioned the panel discussions, those are always wonderful. I’m hoping that I can make it to your session with Gene Kim if I’m not in another session myself. So I’m looking forward to it, and it’ll be a great week.

    Alan Shimel:    Absolutely. Rosalind Radcliffe, Distinguished Engineer IBM, thanks for joining us today on this edition of DevOps Chats

  • DevOps Chat: Mustafa Kapadia, IBM DevOps Transformation Workshop

    DevOps Chat: Mustafa Kapadia, IBM DevOps Transformation Workshop

    I always enjoy listening and speaking with Mustafa Kapadia of IBM. Mustafa is one of the leaders of the IBM DevOps services team. As such he gets to work with dozens of different organizations in helping them on their DevOps journey. As a result Mustafa has amassed a ton of experience and knowledge on the correct patterns towards successful transformations.  He had developed a workshop around this that I think is a really great exercise for any organization thinking about DevOps to go through.

    I recently sat down with Mustafa for a DevOps Chat. We spoke to him about the workshop and process.  Below is the soundcloud audio of our conversation. Below that is a video of a workshop demo Mustafa recently delivered at our DevOps Connect: cdSummit SoCal event in Los Angeles this month.  I think you will find them both useful.

    Also the transcript of my conversation with Mustafa is below that.  Finally, below that is an interview I did with Mustafa at the recent DOES 15 event as well. Hope you enjoy.

    [soundcloud url=”https://api.soundcloud.com/tracks/237701095″ params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=true” width=”100%” height=”150″ iframe=”true” /]

    Transcript

    Alan Shimel:                And we’re here for another DevOps Leadership Chats. Today’s guest is Mustafa Kapadia of IBM. Mustafa, welcome.

    Mustafa Kapadia:       Thank you, Alan. Good to be here.

    Alan Shimel:                Yes. So Mustafa, of course you and I know each other for some time now. But for our audience who may not be familiar, what is your role with IBM right now?

    Mustafa Kapadia:       Sure. I am the service line leader for our DevOps Consulting Practice.

    Alan Shimel:                And a great job you do of it. I’ve seen you in action.

    Mustafa Kapadia:       Thank you.

    Alan Shimel:                Happy to have you here. Mustafa, one of the biggest issues we hear from executives of enterprises especially is well, this DevOps sounds great and we can understand how startups and smaller companies do it because they are doing it on a green field or from the get-go. But how do I turn the ship here? How do I get started in DevOps? How do we lead the transformation if you will?

    Mustafa Kapadia:       Yeah, Alan, that’s a good question. In fact, that is probably the most popular question we get asked from our clients.  DevOps has so many arms and legs and it’s so hairy and it’s such a big topic, getting started is hard and the way to get started to get the biggest bang for the buck is even harder. And that’s where we start bringing in something that we call value stream mapping exercise. And that really helps our executives figure out what is my end-to- end picture looks like? What are my bottlenecks? What are my low hanging fruit? And probably one of the most important outputs of the exercise is what are my metrics? What is it that I can improve through using DevOps?

    Alan Shimel:                Yet. And Mustafa, of course I’ve seen you talk about this and you have developed a whole workshop around this value stream method.

    Mustafa Kapadia:       That’s correct.

    Alan Shimel:                And recently we were out at our DevOps Connect CD Summit event in Southern California and you had an opportunity to actually do this live, right, on a white board. No slides or anything.

    Mustafa Kapadia:       That is correct.

    Alan Shimel:                But why don’t you kind of walk our audience, if you will, and again we don’t have a lot of time but let’s walk them through a little bit about what you do in this kind of workshop.

    Mustafa Kapadia:       Yeah. Well, first of all, Alan, thank you for inviting me to the Summit. It was actually great to catch up with you… It was great to be there and present… But to answer your question, what we start off with in a value stream mapping exercise is just ask the audience or ask our clients How do you do thing folks from point A to point B. Who does it? How many people does it take to do? How do you set up a DevOps environment? What kind of tools do you use? How long does it take? What processes do you use? And depending on how much time we have with our clients, we can go very deep, in the Summit itself, we were very high level since we only had an hour and a half. And what that does is A) Even for the clients, it gives them a complete point of view about how you actually get an idea to market from the time the development team starts coding to the time that it actually reaches the end customer or as we say, moves into production? And it in many ways it is simply a conversation. It’s a facilitated conversation with a goal in mind but it is a conversation about how do you do things and where are your problem areas? And in many cases, for a client, this might be one of the first times that development and operations are actually sitting down in the same room and talking to each other. In many cases, operations is a separate environment and then the development team has to go in and do their own stuff to get the environments ready, to be ready for the developers to start using it. So value stream mapping exercises in many ways is the first time that they are collaborating on the big picture. And that’s what DevOps is all about. It’s about getting the dev and the ops teams together.

    Alan Shimel:                Yep. And Mustafa, typically when you are doing these in the field with real live enterprise customers you’re dealing with, what’s the feedback from the executives that you are working with?

    Mustafa Kapadia:       The two that come to mind is that number one, most executives are amazed at how long it actually takes them to develop code and actually bring it out to the market. It is not uncommon in a large enterprise for the entire lifecycle from the time an idea has been generated and approved to the time that it actually meets the customer or the end-user. It could be as much as 300 days. We were at a bank in which it took them almost 390 days to get some type of a release out to the client. So number one, it’s first just – they are surprised at how long it takes. Number two is, the honest dialogue that they can generate, not just with us but more importantly within their own team, is probably the most valuable key of that exercise.

    Alan Shimel:                Agreed. And Mustafa, I know some people are listening and they’re saying oh great; here’s an IBM services guy who’s going to be pushing us to buy IBM product…But the fact is or maybe it’s not the fact, it’s my understanding the fact is that that’s not the case in this exercise in these kinds of engagements that you work in, correct?

    Mustafa Kapadia:       Yeah, definitely not. In fact, a lot of I would say close to 99% of the time, maybe even 100% of the time, we rarely talk about IBM tools or any system tools for that matter. It doesn’t matter if it’s open source, or if it’s proprietary. That exercise is more about understanding the…process and the…pain points. So it has nothing to do with IBM or it sets of tools but more about clients understanding the end to end workflow.

    Alan Shimel:                Yep. And so Mustafa, let me throw something else at you. I’m going to throw the big C word out there, culture. Because that’s the other thing we hear from execs, correct? How do I change my culture? So everyone talks about this DevOps thing being a cultural sort of leadership thing. How do I do that? What do you do – do you do anything around the culture as part of this exercise?

     

    Mustafa Kapadia:       We do, we do. So cultural behavioral changes, that’s what we call it here, is a big part of this exercise. Part of it is that I’ve mentioned earlier is people sitting down and talking and sitting down at a table and talking about the entire workflow. But the larger question is a lot of the cultural change happens is actually go through the transformation journey together. So instead of just the operations team doing their fees and development thing in doing their feeds, when we start putting solutions together for our clients, we bring both these teams together and sell the solution together that both of them can support. And that is where the cultural and behavior change starts happening. Not just what they’re doing but how they are doing it, how they are communicating. A lot of the change happens by doing as opposed to just somebody coming in and say well, you need to change or organize your structure this way or you need to put a new metrics and so on and so forth. Our customers that succeed in DevOps do it primarily by actually doing some of the stuff together as opposed to doing organizational realignment.

    Alan Shimel:                Makes sense. So Mustafa, my next question to you is sort of the classic consultant’s dilemma, right, and that you come in, you identify the pain points. You identify new processes, new ways of doing things. You advise the client. You may even stay there on a short engagement timeframe to hopefully see these things starting take root. But what happens after the consultant leaves? What’s the success rate of this stuff really taking hold?

    Mustafa Kapadia:       To be honest with you, a lot of the bread-and-butter at IBM in our service lines is actually what happens after the consult engagement. What we sit down with the client and actually help them execute the roadmap that we had developed together from A) building the platform to integrating disparate capabilities into the platform, supporting that platform and even training. In fact, one of the things that we are rolling out right now with some of our clients is actually training our customers, our clients, on how to start using some of these DevOps platforms tools and so on and so forth. So our longtail…believe it or not, is actually sitting down with the customer and helping them through the entire journey as opposed to just coming down and putting things down on PowerPoint. In fact, the consultant piece is a very small part of that business. Our real business is about hand-holding them through the journey.

    Alan Shimel:                Great. Makes sense. So Mustafa, we are coming close to our time limit but I have another question or two for you. I was on a webinar this afternoon with Gene Kim and lady named Shannon Leitz from Intuit. And it was on security DevOps. But we got a couple questions from the audience in there. It’s a reoccurring theme here at devopsy.kinsta.cloud. One gentleman wanted to know this is all fine and dandy for tech firms. But do you have any examples….chemical or energy-related firms that were doing DevOps? Of course, another person wanted to know did you have any white papers on financial related firms doing DevOps? And you and I were both at the DevOps enterprise. We saw all kinds of companies from presenting there…

    Mustafa Kapadia:       Yep, definitely.

    Alan Shimel:                But your own personal experience, Mustafa, is there a particular vertical that is more suited to adopt this or less suited to adopt these kinds of ways?

    Mustafa Kapadia:       Yeah… So the general rule of thumb is that anytime you have a system of engagement application, that is the best place for us or for you guys to start DevOps. That is where you get the biggest bang for the buck. And that is where this whole idea of being agile … to market makes a difference. Now, with that being said, there’s actually three key industries taking up or adopting DevOps faster than all the other sectors that we have within IBM. First is financial services. Second is retail and third is believe it or not, actually software development companies. So it’s these fast-paced companies that are trying to get some more features and product out to their customers and clients. We see those three sectors taking up DevOps or adopting DevOps much faster than the rest of the industry. But that doesn’t mean that the other parts of the industry are not doing it. In fact, we are right now working with healthcare clients. We’re also actually working with an energy client who is trying to figure out how to bring DevOps into their mix.

    Alan Shimel:                Excellent. The next question is I’m actually working on a report that I want to put out next month on my prediction for 2016 that this is the year of the great divide where we are really going to see the gulf widen between companies who are adopting DevOps patterns and not just DevOps but the Cloud, hybrid Cloud, big data, IOT, the open enterprise if you will versus companies who are sort of digging their heels in the sand… Do you think this is the year we see….real gulf starts opening up or old-style companies skate by still?

    Mustafa Kapadia:       Yeah, I unfortunately think it’s more of the latter than the former. I think some companies, especially in traditional industries, are still going to stick to their guns, so to speak, and think DevOps is just a fad. But then the industries that I’ve just talked about, I think those is where the gulf between the doers and the not doers is going to start widening especially when you get a retailer who can now push out enhancements to their e-commerce website, we’ll definitely see them picking up the benefits of DevOps as opposed to somebody else who just chooses not to do it. I think that’s where it’s going to happen this year or I should say next year. And then if that does happen it, 2017 becomes a really interesting year because that’s when everybody starts to catch up. A lot of our customers are trying to get on the ground in 2016 so they are not in bad shape in 2017.

    Alan Shimel:                I think otherwise it could be fatal to their business. Mustafa, one last question and I usually ask all my guests on the podcast near the end and we’ll let you go. For our leaders out there who are wanting to maybe dive deeper into DevOps or just want to lead the transformation at their organization, if you had to pick one book for them to read, what book would it be?

    Mustafa Kapadia:       Oh, that is a very tough question. There is actually a book called Competing Against Time. It was published in I believe 1975 by a managing partner at Bing. …While it doesn’t talk about software development or application lifecycle, it really talks about how you can start thinking about time as the element of competition. And it’s what other companies are doing or perhaps have done in the past to actually help you actually use time to kind of gain not just an advantage but almost an inhuman advantage over companies, right? So that one comes to mind…Dell comes in mind. This idea about DevOps is not a new idea. It’s new to IT. But the idea of us drinking time has been around for quite some time. And I really like that book because it kind of, a lot of the principles that we talk about now in software development can be found in that book in examples outside of IT and in other industries.

    Alan Shimel:                Fantastic. That’s a new one to our book list and great suggestion. And it just goes to show what’s old is new and some things never go out of style, right? Anyway…

    Mustafa Kapadia:       That is correct.

    Alan Shimel:                Mustafa, we are over our time, I apologize. It’s hard to do these things in 12 minutes. I apologize. But thank you so much for appearing on this episode of DevOps Chats. And thank you so much for helping us whether it be at CD Summit or DevOps Enterprise Summit or at so many locations we run into each other. Not to mention writing press here at devopsy.kinsta.cloud.

    Mustafa Kapadia:       Thank you. And Alan, you’ve always been generous and I appreciate that. I also, if I have a few seconds to make another offer to all of your audience. Three things, actually. So this value stream mapping exercise that we’re talking about in many cases, will actually do it for free for some of our clients so you guys can reach out to me. And Alan, you have my card…

    Alan Shimel:                Yes, we’ll put it in there.

    Mustafa Kapadia:       So that’s number one. Second is, we have this IBM conference call, Interconnect, which is in Las Vegas. It’s on 2/21-2/25. It’s a great way to learn about DevOps.

    Alan Shimel:                I will be there, Mustafa.

    Mustafa Kapadia:       And last year we had 300 or so DevOps sessions. Perfect, perfect.

    Alan Shimel:                Yes.

    Mustafa Kapadia:       And the last thing, if I’m not running out of time, is if you guys can’t wait until Interconnect, I actually publish a monthly newsletter and if you can just email me, I’ll be more than happy to put that on as well.

    Alan Shimel:                What’s the email, Mustafa?

    Mustafa Kapadia:       Email is M.A.Kapadia@US.IBM.com.

    Alan Shimel:                Fantastic. Mustafa Kapadia, IBM. Thank you so much for being today’s guest on DevOps Chats.

    Mustafa Kapadia:       Okay, thank you very much, Alan. I appreciate it.

  • DevOps Chat: 7 habits of successful DevOps

    DevOps Chat: 7 habits of successful DevOps

    I recently had a chance to speak again with Sam Guckenheimer of Microsoft about his experience in leading the transition for Microsoft Visual Studio to Visual Studio online. In doing so, Sam and his team developed the 7 habits of successful DevOps.  You can listen to my interview below or read along below that. Also if you want to download the Microsoft paper on the 7 habits of successful DevOps you can do so here.
    [soundcloud url=”https://api.soundcloud.com/tracks/234949072″ params=”color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false” width=”100%” height=”166″ iframe=”true” /]

    Hi, everyone—Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Leadership Chat, and I’m joined today by Sam Guckenheimer of Microsoft. Sam, welcome.

    Interviewee:                 Hey, Alan. How are you doing?

    Interviewer:                 I’m doing well. It’s good to speak to you again. The last time we spoke was at the DevOps Enterprise Summit out in San Francisco.

    Interviewee:                 Yep, that was a lot of fun. That was a great conference.

    Interviewer:                 Yes, and you know what? I think—well, you contributed to making it great, Sam. It was a great presentation you made, talking about, kind of documenting the journey of Visual Studio from a COTS, you know, traditional kind of software model to a SaaS based program, Visual Studio Online. And, you know, I think that’s something that a lot of our listeners may be interested in, and how do they turn their current software offerings into SaaS based. And along the way, of course, you’ve come up with a, I guess you call it the Seven Successful Habits of DevOps?

    Interviewee:                 Yeah, so we think about the seven habits that we’ve applied as we’ve done our transformation. We started around 2010, we were in the, if you will, the pinnacle or the leader’s quadrants on all the analyst assessments as a provider of software for on-prem use in what was then called ALM—application life cycle management. And we said, “Hey, we need to become a great SaaS provider as well.”

    So we think of things in terms of these seven habits that we need to provide. Three of them you can think of as sort of Agile on steroids or second decade Agile. That’s team autonomy and enterprise alignment, is number one. We work in scrum teams or feature crews, think about 8 to 10 engineers and a product owner. They autonomously pull items from a common product backlog, and at the same time, they align to enterprise goals on a six month planning cycle, we call this a semester or a season, where we know, in that time frame, what are the needles we’re trying to move for the business? What are the things we’re trying to do at the epic level that count, and Sprintly we measure, how are we doing against that, and the things that each feature crew is doing are counting against that. They may move forward, they may move backward, they may decide, based on the data they’re collecting to do more or do something else. But you know, that’s in their control based on the things we’ve agreed for the six months.

    The second habit we have is a rigorous management of technical debt. We’ve known about technical debt for a long time, but when you’re running a service, you really can’t afford to let any debt creep in, and you have to stay clean all the time. So we make sure that we’re constantly monitoring both what’s happening in the production service and what’s happening in the development process. So if, for example, there is anything on the live site going wrong, we attend to it immediately. If there’s anything happening in the development process, like a feature crew is letting its bug count start to ride up, they have to stop immediately, fix the bugs, and can’t do any new work until they get them down to zero, so we stay clean on tech debt as we’re going.

    The third habit is a focus on the flow of customer value. We’ve talked about this since early days of Agile. Now, with SaaS, we can measure it. So we have great telemetry in the service, and we look at how people use our software, both quantitatively as we’re going forward; that is, we actually observe what gets used, what doesn’t get used, what the scenarios are, and we reach out to customers qualitatively, where we engage with the high usage accounts and we say, you know, “Let’s talk to them.” And we encourage our engineers to buddy up and reach out and say, you know, what’s gone well, what’s gone not so well, what would you like us to do that you don’t see? Are there things you wish for that we could be doing for you, and so on.

    So we reach out to customers, we listen to them through things like UserVoice and we observe their behavior through telemetry on a continual basis. That’s all kind of Agile on steroids.

    Interviewer:                 Mm-hmm.

    Interviewee:                 You know, those are the first three. Then you get to the stuff that’s really new with devops. The first is, of those, number four is what I’d call hypothesis driven development or a backlog that gets groomed with learning. This is what Eric Ries, in Lean Startup, calls “build, measure, learn.” So, in other words, the idea is that the backlog, instead of being the just, you know, what an omniscient product owner things is right, it’s—we recognize that it’s a set of hypotheses or beliefs. We think that these things will improve our service, but we’re gonna treat them as hypotheses and we’re gonna turn those hypotheses into experiments, and we’re gonna collect data against those experiments so that we can substantiate or diminish the hypothesis, and that data will be evidence gathered in production. That’s the fifth practice—everything is evidence that we need in order to build up or draw down against those hypotheses. We look, we use instrumentation on everything, we use telemetry on everything, and we measure it against what’s important.

    So, for example, if we think something’s gonna be a better sign of experience, we will run the new against the old in parallel, and we may, if we have multiple front doors, like in our case we have a web experience and an experience through the IDE, the integrated development environment, we’ll run those in parallel. So that would be a four cell test, you know? New and old, web and IDE, and we’ll see what the evidence shows us about how much better the new is than the old, and hopefully the new is better; it might not be. Hopefully we’re right, but sometimes we’re wrong. In any event, it’s the data that will tell us, and it’s a “bring your data” world.

    So, evidence gathered in production is our fifth habit, and that is made possible by our sixth, which is what we call a production first mindset, or what Satya, our CEO, calls a live site culture. The idea of a live site culture is that the site status is always first priority, and with site status, you have two goals. If there is a live site incident, you want to, as quickly as possible, remediate so that customers aren’t affected, and you want to drive to a root cause analysis. Practice the 5 Whys like Toyota, get to the root cause, and identify the actions that you need to take in order to prevent a recurrence of such an incident or something similar, and those root cause actions that you take, you need to complete in one or two sprints so that you’re hardening the service as you go learning from the live site incidents so that you’re always getting better.

    That’s number six, and finally, number seven is that we manage infrastructure as a flexible resource. We can do this because we use the public cloud—of course, in our case, that’s Azure. We work as a customer of Azure just like our external customers would. We take things a little earlier, but otherwise, we’re a customer when we need more resources for development or for load testing or to spin up more labs, we just do it.

    And we continue to expand the number of data centers we run, and we now run our Visual Studio Team Services in eight data centers around the world; that’s out of 24 regions that are currently active in Azure, and we fully automate the deployment, but we start each Sprintly deployment with a canary instance, which is where we work. It’s our own one of those stamps, and the one where our closest early adopter customers are so that we know from the canary if there’s anything wrong with the deployment, and if there is, we then restart at the canary before we roll out to the subsequent deployment rings. And that practice of canary-ing, going big with load testing is part of the deployment pipeline, and then using the automation to roll out in subsequent rings is something that we’ve used to harden the service and let us get to a global scale on a regular basis.

    Interviewer:                 Got it. So, Sam, these are obviously lessons learned the hard way, right, [Laughter] by doing and paying the idiot tax and doing that.

    Interviewee:                 Yes.

    Interviewer:                 For our leaders who are listening to you now, where to begin? Where to start? Obviously you can’t do all seven at once. Some of them are dependent on others. Where do they begin?

    Interviewee:                 Well, I think that the first thing is to make sure you have Agility down. I think you cannot do this if you are a command and control organization that doesn’t really let teams learn, and to recognize that you do need to measure your time to learning along with your other measurements, you also need to totally automate your release pipeline.

    So, the notion that you can have manual steps somehow between a development pushing code or checking in and the release of that is a thing of the past. You know, start with continuous integration and then quickly go to continuous deployment and put the telemetry in place so that you can see the evidence from production that gives you the feedback on everything that’s getting deployed.

                                        If you don’t have those things in place, the rest will crumble.

    Interviewer:                 Yeah, agreed.

    Interviewee:                 Sam, we unfortunately are coming up near the end of our time. I want to ask one more question of you, though, and it’s along the same vein. So, you’ve laid out the steps here for us. How did you get your team’s buy-in on this—or did you?

    Interviewer:                 Well, we certainly did. I don’t think it was very hard. I think that we all wanted to move to this world. I think that there was a broad recognition that we needed to become a first class SaaS provider. I think that there were some additional quirks in our case of being a great SaaS provider while we continue to be a great provider on-prem software, and maintaining that engineering discipline.

    The teams were all for it. I think the leadership needed to recognize that we were investing in new practices and that we needed to maintain the investment in engineering systems and engineering practices so we have a rule of thumb that about 20 percent of our investment goes toward non-customer visible engineering, things like live site work, and we don’t quarrel about that. If we need to do live site improvements, we do them.

    So I would say there was a little bit more work on management to accept the change in practices than there was on the ground with the engineering teams who were sort of chomping at the bit to get going.

    Interviewer:                 Well, there often is in devops, right? You have that “from the bottom up” and getting true top down sponsorship and cover is a problem, right? Not a problem that cannot be overcome, but an issue that we’ve explored previously in our leadership suite here.

    Interviewee:                 Yeah. Yeah, it helps that our, right now, our CEO comes from this world, Satya Nadella, so he is pushing everyone in the company to make the change and to learn the new practices. There were some folks in the middle who were not comfortable, necessary, but you know, they’ve come around.

    Interviewer:                 As they often do.

     

    Interviewer:                 Sam, anyway, we are probably over our time and I apologize, but thank you very much for sharing your Seven Habits for Successful DevOps. Continued success with your Microsoft Visual Online and the rest of your endeavors at Microsoft, and we hope to have you on again some time in the future and we can talk more about leading the transformation at companies around the globe with these new ways of doing things.

    Interviewee:                 Thanks, Alan. I’ll do one commercial, which, which is that there’s a URL, microsoft.com/devops, where you can download an e-book about our journey and a devops self-assessment if you want to read more.

    Interviewer:                 You know what, we’ll include that link in the article, too, in the transcript so people can get that. Sam Guckenheimer, Microsoft—thank you so much for being our guest today.

    Interviewee:                 Thank you very much, Alan.

    Interviewer:                 Okay, this is Alan Shimel for devopsy.kinsta.cloud. Thanks, and have a great day.

  • DevOps Chat: Sunil Rajasekar, CTO of Lithium

    DevOps Chat: Sunil Rajasekar, CTO of Lithium

    hero-sunilContinuing our DevOps Chats, Leadership Series I recently sat down with Sunil Rajasekar, CTO of Lithium.

    As Chief Technology Officer, Sunil oversees core product, development and delivery of Lithium’s enterprise platform. Sunil is a seasoned technology executive who brings more than 15 successful years of enterprise, small business and consumer software experience. Prior to joining Lithium, Sunil served as Vice President of Engineering, Operations and Program Management at Intuit Financial Services and held a variety of senior roles in the Intuit Small Business and Central Technology groups. His passion is building innovative and successful web and mobile offerings that companies and end users love. Previously, Sunil worked at Oracle, Cisco and several startups.Sunil holds a MBA from the University of Toledo.

    Sunil and I had a nice chat about what it means to lead transformation at at organizations today using the many tools and options available. Regardless of tools though, Sunil emphasized what leaders have to do to enable transformation. It was a great chat that I hope you enjoy!

    [soundcloud url=”https://api.soundcloud.com/tracks/230736526″ params=”color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false” width=”100%” height=”166″ iframe=”true” /]
    Alan Shimel:                Hi, Alan Shimel at devopsy.kinsta.cloud here for another Dev Ops Chat in the Leadership Suite. Today’s guest is Sunil Rajasekar, CTO of Lithium, Lithium Technologies who are helping people with their social customer service software and social software in general. Sunil, welcome to Dev Ops Chats.

    Sunil:                           Thank you, Alan. Happy to be here.

    Alan Shimel:                So Sunil, for those of our listeners who may not be familiar with Lithium, can you give us just sort of a quick background on what it is Lithium does?

    Sunil Rajasekar:          Sure. So we’re in the business of helping companies engage with their customers in new patterns and what they’re dealing with now, right? Where consumers have all the power, they have access to all the data that they need and companies don’t own their brand anymore. The consumers are the ones that determine the brand. So we help companies deal with this environment in this reality that they are dealing with by helping them engage with their customers at scale through social channels and also facilitate conversations between customers.

    Alan Shimel:                Sure. And Sunil, I thought this was such a great topic for our Leadership Suite because I’m sure many of our listeners are grappling with this issue right now. There’s just a new way of doing things including a new way of engaging with customers. A new way of presenting your brand in the marketplace. And so much of it is wrapped around the social media and social communications that we see today. And companies who aren’t grasping this are quickly becoming dinosaurs. People tend to think of it’s the Unicorns, the Googles, the Facebook, the Twitters who are getting this or the startups. But that’s not really who your customer base is, is it Sunil? You guys work with some large customers?

    Sunil Rajasekar:          We do, yes. So we work with a wide variety of customers. We work with companies that have been a really long time so AT&T, Telstra, Cisco, HP; these are all customers of ours and they’ve seen a lot of success _____ [inaudible]. And we do work with a lot of the new companies that have been born in the “digital age” as well. So we work with companies like FitBit. We actually do work with Google, they are huge customer of ours as well. So we actually have a variety of customers across the spectrum, those who are new who get this new reality and those who get this reality but are adapting their business to adjust to it as well.

    Alan Shimel:                Sunil, I’m sure we have some people out in our audience today who are leaders in their respective companies and they are faced with an evolve or die reality. What, as a CTO, as someone who founded companies and so forth and you are background, what would your advice be to them?

    Sunil Rajasekar:          I would say three things, Alan. So one is make sure you have a diverse network. And so and the reason I bring that up first is we were talking about this earlier as well. Things are changing so fast in the tech world right now, it’s hard to keep pace and it’s hard to know whether it’s a passing trend and what’s here to stay. And it’s hard to digest all this data and then figure out the _____ [inaudible]. And if you’re going to try to do it by yourself, I would say it’s going to be next to impossible. And if you stick to just your countered network, right, the people you work with day in and day out, you’re probably getting the same level of information and you do end up with a group think type of situation. So making sure that making the time to engage with people in other industries, similar roles who are probably trying to figure out the path forward just like yourself. I think that’s the way to do it. You want to make sure you’re plugging into these other networks, you’re sharing your learnings and learning from others as well. So this is something that I’ve made a conscious effort to do in the past couple years and it’s been invaluable so I would say that’s one.

    In the second thing is, it does boil down to good old change management as well. Yes, there are some great trends that are out there and you should probably thinking about implementing it. But at the end of the day, you’ve got to know how to take this trend or new technology or new process and make it work for your organization. And that’s good old change management, right? So you need to know about your team. You need to know about the business needs and make sure that you can tailor whatever transformation you want to drive to the needs of your company. So what does boil down to change management?

    And then the third thing I would say is just resilience. And anybody who has made it up the ranks, they probably know this already but it’s a good reminder. Anytime you’re driving a large transformation, there are going to be challenges along the way. And you need to make sure that you are resilient and your team is resilient and the rest of your executive staff has bought into the transformation you are driving and they come here to support you and there are roadblocks as well. So as those are the three things. Make sure you have a diverse network, focus on change management and make sure you don’t forget about being resilient.

    Alan Shimel:                Sure. Sunil, I have questions I’d like to follow up with you on two of those points you’ve made. First of all, in terms of a diverse network which as you said you have pursued over the last couple years, what advice can you give our listeners on what kind of group should they be looking for? Where do they find them? How do you make that a reality?

    Sunil Rajasekar:          Sure. So there’s three ways I’m going to do it and there’s a plan to do it, I would say, here as well. One is of course your personal network. There are people you’ve worked with in the past who you admire, probably have gone on to do other things and have other experiences. So making sure that you really cultivate your network and you reach out to people and check in and if you have a situation you’re dealing with, reach out and ask for advice. Or if you’re contemplating a big technology decision or a business decision, reach out to these folks who are in your network and get the advice.

    Another thing that we’ve done is we’ve set up a technology advisory board so we have course have the board for the company. We’ve got a special technology advisory board that we’ve set up as well. And this has people from companies like Google, LinkedIn, Netflix. So some very, very strong background for all these folks and we’ve use this technology advisory board extensively for some key decisions that we’ve made. So that’s been invaluable.

    And then the third thing I would say is plug into meet ups that are going on. Chances are whichever city you’re in, there are a ton of tech meet ups that are going on and if there’s not that many, start one and get people from other companies to come and share their learnings on different topics. So we have a _____ [inaudible] ops meet up that we set up and we meet pretty regularly in our office and it started off as a small thing and now we have members who participate from again, the Googles of the world, the Air B&Bs of the world and we have over 1000 members. And that’s been great as well.

    Alan Shimel:                Yeah, no, that’s fantastic. Sunil, jumping to one of the other points you made which was about change management, so something else – just my opinions, observations and advice is sometimes it’s about embracing change. Too many people look at sort of the new technologies, the new ways of communicating, the new ways of doing things as oh my goodness, I’ve got to learn something new. Or this is changing what I do and no one likes to change what they are used too. I get all that. But sometimes embracing change is what makes the difference. Right? Embracing this change, looking at it as how can I make it a positive rather than just defending my turf if you well? Way too often people are just defending their turf, it seems, instead of embracing the change and running with it. And that would be my advice as well is don’t think of these changes as yet another thing you have to do. Think of them as ways that are going to make your life easier, make you more successful, make your organization and those around you more successful. So I –

    Alan Shimel:                That’s part of it.

    Sunil Rajasekar:          That is so true, Alan. There was a time when I think leaders were looked up to for stability and making sure that things stayed stable. But I think that paradigm has changed. In this time and age, the leader is looked at primarily for their ability to predict change and guide the organization on the path that they can adapt to this change and be successful in the future as well. So as a leader, that is one of our key responsibilities, looking at what’s coming around the corner and making sure that you are guiding the organization in the right direction. So it’s changed in my opinion.

    Alan Shimel:                Absolutely. Well, Sunil, the problem with changes sometimes it moves too fast and so does the time we have for our web chats unfortunately. We are well over our 10 minute kind of target so were going to have to wrap it up. But for people who want to find out more about Lithium and kind of how you guys can help, where can they find you on the web?

    Sunil Rajasekar:          Oh, it’s easy; www.lithium.com. And from there, you can connect to a lot of good information and hopefully you know me as well; if you have follow-up questions or comments.

    Alan Shimel:                Fantastic. Sunil Rajasekar, and I may have messed that up; I apologize. Thank you for appearing on this episode of Dev Ops Chats for the Leadership Suite. And continued success with Lithium.

    Sunil Rajasekar:          Thank you very much, Alan. Thanks for having me. 

  • DevOps Chat: IBM draws on deep DevOps experience to launch Bluemix Garage Method

    DevOps Chat: IBM draws on deep DevOps experience to launch Bluemix Garage Method

    RandyNewell_IBM_HIGHRES1

    With the start of the DevOps Enterprise Summit 2015 this morning IBM has made what they are touting as a major announcement. Drawing on their wide and deep experience in DevOps across multiple segments of the company, they have announced   Garage Method. What exactly is Bluemix Garage Method? Great question. I spoke today with Randy Newell, Director, DevOps Marketing at IBM about this. Below is a streaming audio of our conversation, followed by the transcript. I expect to follow up with Randy and other IBM folks this week on both DOES and Bluemix Garage Method, so look for a follow up shortly.

    [soundcloud url=”https://api.soundcloud.com/tracks/228889575?secret_token=s-uhTmi” params=”color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false” width=”100%” height=”166″ iframe=”true” /]

    Alan Shimel:                Hi, this is Alan Shimel of devopsy.kinsta.cloud and we are kicking off our coverage of the DevOps Enterprise 2015 Summit in San Francisco. And happy to be joined by Randy Newell of IBM. Randy, welcome to DOES 2015.

    Randy Newell:             Hey, Alan. Thanks. It’s great to be here. This is exciting.

    Alan Shimel:                Yep, there’s a lot of buzz going around, Randy. A lot of companies announcing exciting news around the event. And I think I’ve heard IBM has some announcements coming out.

    Randy Newell:             We do. We are announcing today a set of practices designed to help enterprise organizations execute and scale innovation. It’s called IBM Bluemix Garage Method and it combines the best of design thinking, Lean Startup, agile development, DevOps and Cloud, and is specifically designed to help enterprise organizations accelerate all phases of the app design, development and delivery lifecycle.

    Alan Shimel:                Very exciting. So Randy, for our audience who may not be familiar, let’s start with the basics. Bluemix Garage – it sounds like a startup, what exactly is Bluemix Garage?

    Randy Newell:            So Bluemix Garage is actually a set of physical locations that IBM has opened around the world — including in San Francisco, located in the Galvanize facility, where IBM brings clients and provides a startup type of environment. It’s really designed to bring in enterprise clients and take them through a methodology, a process, by which they go from ideation right through to delivered application in an MVP-type of situation, and really learn how to accelerate innovation. And this has worked extremely well. Where the challenge has come is how do I take that success and bring it back to my enterprise? Especially since many of these organizations are building innovation centers, lofts, etc. How do I capture that culture, that startup mentality that happened back in the Garage and scale it? And that’s what’s behind the Bluemix Garage method. So we’ve specifically named it Garage to capture that startup culture that we are cultivating within the Garage environment, and put a lot of that into the methodology and the way that people interact with it.

    Alan Shimel:                Excellent, excellent. So Randy, I’ve been lucky enough to attend other few DevOps-related events recently, and I’ve seen that as a theme from IBM, this concept of how do we bring that startup energy, that startup methodology and sort of grafted onto the enterprise tree. And this announcement today kind of sounds like maybe the culmination of that.

    Randy Newell:             It is. IBM has gone through a major transformation that reaches back almost a decade – but a lot of activity over the past couple of years where we’ve rolled out DevOps transformation within IBM to thousands of developers. And then of course, we are actually delivering DevOps transformation capabilities with clients, both at Bluemix Garages as well as through various services organizations within IBM. And so what we’ve done is taken the best of from those various methodologies and integrated that into what we’ve now named Bluemix Garage Method.

    Alan Shimel:                Got it. Now Randy, I think one of the special sauces that IBM brings to an announcement like this is the breadth of services and people that IBM brings to bear on this. Can you give me an idea of how the different segments if you will or the different parts of IBM are coming together on this into one cohesive strategy and offering?

    Randy Newell:             Well, it’s what I’ve defined as the input to this process. So you have the genesis within IBM from internal organizations, the CIO office, across different parts of Cloud and Software groups; and then of course what’s come in from what we refer to as Global Business Services. So all these have played a role. And obviously best practices coming from interaction with clients and with different business partners, as well.

    The method itself consists of a digital experience. So it is a site that you visit and on that site is a practice library of work product assets, of shared learning in the form of videos and case studies and blogs. It’s an open community where clients, business partners, IBMers and third-party tool vendors will continue to progress and advance this methodology.

    And then kind of an interesting perspective are these prescriptive adoption paths for various use cases so you can engage with the method in a role context or in a particular use case context. Let’s say I’m building a cloud native mobile app, you basically have that as a track or adoption path through the methodology.

    So we are starting off — this is delivery of version 1.0. It will progress extremely rapidly so we’ll see new tracks for these prescriptive adoption paths added on a regular basis. We are pretty excited about that and it’s a really high-value add with the methodology.

    Alan Shimel:                Fantastic. Randy, for people who may be listening to this or reading it while they’re out in San Francisco this week for DOES, any IBM sessions that will be talking about this?

    Randy Newell:             Absolutely. In addition to the IBM booth where we will be demonstrating the Garage Method there are a couple of key sessions that I would suggest people attend.

    Specifically, Tuesday, tomorrow, there’s a session with Angel Diaz, Rachel Reinitz and one of our business partners, Kristal York from PointSource, will all be talking more deeply about the Method. We will also be talking about it at an event called Night at the Garage on Monday evening, tonight, starting at 7:00 PM after the networking session is completed here at DevOps Enterprise Summit. This is an invitation to all DevOps Enterprise Summit attendees to get on a trolley with us and head 7/10 of a mile down the street from the hotel to Galvanize which is where the IBM Bluemix Garage is located in San Francisco, and join us for some demo stations where they can see more on the Method but also enjoy the bar, entertainment, and dinner. So that’s an invitation; we’d love to see everyone from DevOps Enterprise Summit join us.

    So a little bit of a plug, later this morning, Dibbe Edwards is co-presenting with USAA on DevOps Innovation. Rosalind Radcliffe is presenting on Wednesday on test automation for mainframe applications. And then our Services Line leader for North America, Mustafa Kapadia, is driving a session on differences between traditional and DevOps IT.

    Alan Shimel:                Sure.

    Randy Newell:             So there’s a lot of neat sessions and we’d love to see people of course join us in the booth as well. We can show off IBM Bluemix which is our PaaS platform; IBM UrbanCode for deployment automation and DevOps Services capabilities that are integrated  into IBM Bluemix. So lots going on within the booth in addition to the methodology that we are introducing.

    Alan Shimel:                Fantastic. I’ve actually either interviewed or met many of the people you’re speaking about and they are all good presenters. So they should be good shows. Randy, what else? There’s a lot besides IBM going on at DOES. Non-IBM related, is there one particular thing that you are looking forward to?

    Randy Newell:             I think back to last year’s event and Gene Kim set such a great tone, very collaborative; we saw otherwise competitors in the marketplace sitting together and talking about DevOps strategies. That was a great tone that seems to be persisting already at the conference this year. The conference was populated with a lot of sessions about initial successes within large enterprise. People telling their DevOps journey, initial successes. And if you remember at the time, one of the business reporters had written an article questioning whether DevOps could be applied to large enterprise. And here we are a year later and that question actually seems pretty comical now. So I think the observation, and I see Gene evolving the sessions to be this way, it’s about the “how”, right? So it’s not the proof points of DevOps so much anymore that it works and it delivers value — whether that’s measured as speed, improved quality or reduced risk. But that DevOps success is directly related to business outcomes and how you scale those successes at an enterprise level. So kind of bringing it back, this is timely for the introduction of the methodology that I described earlier.

    Alan Shimel:                Absolutely. So Randy Newell, it sounds like IBM is on top of their game here at DOES. And a lot of exciting announcements and you guys are really integrated into this whole DevOps party going on here if you will, and how we continue to evolve to the next phases of DevOps adoption. Thanks very much for checking in with us today. Enjoy DOES and will check back with you maybe at the end of the show and get some thoughts.

    Randy Newell:             Okay, great. Thank you very much, Alan.

    URL:  IBM Bluemix Garage Method – www.ibm.com/devops/method

  • DevOps Chat: Carol Carpenter, CEO ElasticBox on the Real Value of DevOps

    DevOps Chat: Carol Carpenter, CEO ElasticBox on the Real Value of DevOps

    Carol-93I recently sat down with Carol Carpenter, CEO of ElasticBox.  We just released the results of the survey we partnered on with ElaticBox on the “Real Value of DevOps”.  There were some great takeaways in this survey for leaders looking to lead the transformation in DevOps.  Carol and I discussed these takeaways and other relevant topics.  Below is the streaming MP3 file, as well as the transcript of our conversation below that.

    [soundcloud url=”https://api.soundcloud.com/tracks/227014073″ params=”color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false” width=”100%” height=”166″ iframe=”true” /]

     

    Alan Shimel:                Hi. This is Alan Shimel, and this is another DevOps Chat for the Leadership Suite, at DevOps dot com. Thank you for joining in. Our guest today is Carol Carpenter, CEO of Elastic Box. Carol, welcome to DevOps Chats.

    Carol Carpenter:        Thank you Alan. It’s great to be here.

    Alan Shimel:                So Carol, well, you and I know each other, but for our audience, just quickly, just in case they’re not familiar with Elastic Box, can you give us a little background?

    Carol Carpenter:        Sure. So Elastic Box is a cloud application manager. We enable companies to deploy any application through any infrastructure, or private or public cloud, so that businesses can actually deliver code faster. We help companies, like Netflix, T&A, Cytobank and more orchestrate the deployment and management of applications.

    And many of these companies have seen their application life cycles increase by 10X, in terms of speed, and time to deploy, and time to market. And the secret sauce of in terms of speed Elastic Box is our reusability. And the way we orchestrate is through a reusable architecture of, what we call, boxes that enable IT operations, dev-ops, and even end user’s application, for supervision on demand, infrastructure in one click, and access to a sophisticated service catalog.

    Alan Shimel:                Fantastic. And Carol, we just recently announced you had sponsored a survey that we did here at DevOps dot com, with some research, on the real value of DevOps. And, of course, people can download the survey from the Elastic Box site, and read about it here on DevOps dot com.

    But I wanted to ask you, what as the reasoning behind doing some survey research?

    Carol Carpenter:        Well, you know, there’s a lot of discussion about dev-ops. We’re seeing many new titles and organizations recruiting for dev-ops, and yet when we would talk to customers and prospects, there was still ambiguity about the role itself – who’s actually doing what?

    And what is the real value of the investment – both in terms of people, time – open source or not? Where is the real value in return on those investments? And we wanted to try to understand, and delve into that area, and understand better – what’s really happening in dev-ops? Who is spending this time there? And what’s the ROI?

    Alan Shimel:                And Carol, for these DevOps Chat for the Leadership Suite, we’re really talking to CIOs, CTOs, VPs – upper management. What, if you can, as a CEO yourself, what would you say were some of the biggest or most important takeaways for leaders within the survey?

    Carol Carpenter:        Alan, great question. You know there were a few key takeaways, and I think you and I were both surprised by a few of them. I think, to start with, as a leader you look at what are we investing? How are we spending our money? And what is our return?

    The ROI analysis I think is still very early and immature around dev-ops, and we have lots of hypotheses about that. But it was surprising because there has been a lot of effort, and energy, and investment that’s gone into dev-ops tools. I mean – look at how many dev-ops vendors there are right now in the market.

    And yet, the actual impact and measurability remains largely subjective and I don’t know – over 50 to 60 percent of the respondents said, I don’t know, when asked about Hoover Trucks. That as like the big, number one insight, that surprised me.

    I think some of the other takeaways are a little bit less surprising, but nonetheless reinforcing of what’s happening in dev-ops today. So number one, when we asked about the team sizes and functions, Alan, what we saw is that, dev-ops, while over 50 percent of the respondents said – yeah, dev-ops is my primary function.

    You know another 41 percent said they had another title, and it was IT Ops. And then another 42 percent said their secondary function is around security, and that’s pretty interesting. But what it reminds us is that dev-ops is still a very nascent, growing area, and that these people are wearing lots of hats.

    And so we, as a vendor partner to dev-ops teams and others who are trying to work with them, you realize like they are spread very thin, and that dev-ops teams are being asked to do work that – what used to be traditional IT Ops, in addition to work that’s now kind of develop or deployment work, and be this communication bridge across these different groups.

    Alan Shimel:                I agree. I mean, Carol – and you and I have gone over the survey in-depth, obviously. To me, the biggest takeaway from leadership is what you hit on first, which is – we really don’t know the true ROI yet of a lot of these dev-ops practices, and tools, and patterns if you will.

    I think, gut, right – and so many executives, as you know, Carol, go with their gut, right? And if their gut tells them that automation is good, that dev-ops can help, that more releases, higher-functioning IT directly results in higher profits, and higher productivity.

    And so they’re going on their gut, and they’re going on what seems logical. But a lot of people just haven’t done the – the bean counters haven’t jumped in there yet and done the real statistical analysis, to really show us – yes. This is the ROI. Yes. This is the return where you’re going to get it, and this is how much more profitable.

    We’ve seen people sort of bite at the edges, if you will. But from a leadership point of view, especially in more risk adverse verticals, I’m surprised more people haven’t asked that. The other thing that I thought, Carol, from a leader’s perspective as really something to keep in mind was, so many – and I think it’s a fallacy.

    So many people think of, open source, as free. Yes, you don’t pay for the software, but when you look at the total cost of ownership, it’s not free. It may be cheaper than commercial software and maybe not. I’ve seen studies go both ways. But I think, from a leader’s point of view, they have to remember that just because we’re using open source “free” software doesn’t mean that it’s free throughout the total life cycle of it. Make sense?
    Carol Carpenter:        Oh yeah. I absolutely saw that in _____ as well, and I think the other point, as a leader looking at dev-ops and what kind of investments you make – I think the promise of dev-ops is to reduce the silo between development and operation cycles. That’s how the title emerged.

    And yet, one of the findings is around dev-ops tools lacking sufficient integration for the end to end delivery and ongoing management. And so I think what we’ve seen is – yes, great pockets of success in automating one portion of the pipeline.

    And we saw a large number of those comments are doing automated testing around continuous integration, and continuous delivery. But what you’re seeing is – while that’s working is – across the whole end-to-end tool chain, like there still are these little silos. And I think what we will see evolve over the next coming year, is more integration, more glue in terms of platforms, to bring them together, in these various dev-ops projects.

    Alan Shimel:                I think you’re dead on Carol. I think what we’re seeing right now is the first generation of dev-ops tools, making their way into the marketplace, and they themselves are almost siloed, right, where they don’t necessarily work with each other.

    Carol Carpenter:        That’s right. I mean what we saw was, when people were looking at their investments and their responses in the surveys – all right. There’s _____ control. There’s container platforms. There’s CICD. They’ve invested a lot in configuration management, and there’s automated tools for that, and some people have invested in it.

    And it’s still disparate, so I agree with you. I think we’re going to see continued maturation of this market.

    Alan Shimel:                Yeah. I think you’ll see a second generation of tools that maybe seek to stitch together a lot of these first-gen tools and, frankly, that’s somewhere where Elastic Box plays too, right?

    Carol Carpenter:        Absolutely. We like to think of ourselves, Elastic Box, as elastic glue. We’re the glue to bring together a lot of these dev-ops initiatives into an end-to-end integrated delivery and management platform.

    Alan Shimel:           Absolutely. Carol, so we talked that there were a lot of surprises or things that we didn’t expect in the survey. What would you say was the biggest surprise for you?

    Carol Carpenter:        Well, I think that the biggest surprise was around the lack of measurability and lack of understanding the ROI of the dev-ops investments, either in terms of people, time, resources, or money. And I’d say the second one is that when we asked about the dev-ops tools that they are using, that CICD came to the very top.

    And, on the one hand, you could say – okay. That’s not a surprise. People have been trying to automate testing for a long time. But CICD is a step beyond that, and that was surprising to me that that’s the biggest driver still. I guess, based upon the noise and what we hear every day in the market, I expected that there would have been another dev-ops initiative would have risen to the top, such as, you know [Crosstalk] –

    Alan Shimel:                Like configuration management?

    Carol Carpenter:        Management or monitoring, which obviously there’s very, very strong monitoring tools, or security and compliance, or even containerization. And maybe it’s because of the press and media and we’re so bombarded by a lot of the initiatives, that we think that that’s where the money is going, and where people are spending time and energy.

    And yet, automated deployment and testing and CICD are still at the top.

    Alan Shimel:                Absolutely, and I think – I mean, what we see here at DevOps dot com bears it out. Look, there’s money being spent across the board in dev-ops tool sets right now, but CICD certainly are some of the biggest ones. Carol, believe it or not, we’ve already gone over 12 minutes, and we try to keep these short, and we need to wrap it up.  But I wanted to ask you the same question I ask every attendee here on the DevOps Chats, and that is, for our leaders out there listening, if they had to read one book which would really help them the most, what would be your suggestion?

    Carol Carpenter:        Gosh, there are so many great books. I would recommend the Phoenix Project. Have you read that, Alan?

    Alan Shimel:                Oh, as well, yeah. That’s what got me into dev-ops. I met Gene Kim about four or five years ago when the Phoenix Project was a manuscript,

    Carol Carpenter:        It’s just game changing, right? The Phoenix Project – it gives you an orientation and a framework around how to attack process challenges, and how to attack the full delivery, you know, the whole life cycle of soft ware or any process. Really, really insightful, and you know, obviously, it’s written in a parable format, so it makes it very enjoyable and easy to read.

    Alan Shimel:                Absolutely. It’s an easy read. Well, Carol Carpenter, CEO of Elastic Box, much continued success at Elastic Box, and again, the survey that we’ve done with Elastic Box and the real value of DevOps, is available if you go to Elastic Box, and you can find it at devopsy.kinsta.cloud as well.

    I’m interested in anyone’s feedback obviously on it. Carol, we hope to have you back again in the future, and thanks so much for being today’s guest. 

    Carol Carpenter:        Thank you, Alan.

    Real Value of DevOps

  • DevOps Chat: Randy Newell, IBM InterConnect 2016

    DevOps Chat: Randy Newell, IBM InterConnect 2016

    Last week I had a chance to sit down with Randy Newell, Marketing Director for DevOps at IBM.  We talked about the buzz starting to build around InterConnect 2016 this February in Las Vegas.  The call for speakers is open until September 25th.  Randy and I spoke about last years event and what to expect this year,
    Below is the audio of our conversation and below that is the transcript if you would like to follow along.  Enjoy!

    Alan Shimel:                Hi. This is Alan Shimel and this is another DevOps chat. Our guest today is a friend of mine, Mr. Randy Newell, Worldwide Marketing at IBM. Randy, I’m pretty sure I messed up your title. Why don’t you correct me for our audience?

    Randy Newell:             Sure. I’m Marketing Director for DevOps at IBM.

    Alan Shimel:                Fantastic. Randy, we’re on today to talk because the buzz has already started building for InterConnect 2016, which is February 21st though the 25th, if I’m not mistaken, out at the MGM Grand in Mandalay Bay Hotels in Las Vegas. Is that correct?

    Randy Newell:             That’s right, Las Vegas, Nevada, USA.

    Alan Shimel:                Welcome to fabulous Las Vegas. Randy, for a few people in our audience maybe who are not familiar with InterConnect, can you give us a quick background on the conference?

    Randy Newell:             Sure. IBM InterConnect is IBM’s Premier Cloud and Mobile Conference. The first time event was actually last year. It was a mash-up of three different events that IBM has been doing previously, Impact, Pulse, and Innovate, all having different angles to them. We mashed them together and then kind of put in an overall mobile and cloud focus on it.

    We ended up having somewhere in the neighborhood of 20,000 attendees last year, and delivered an enormous amount of curriculum and content, about 2,500 sessions. It was a tremendous success. So we’re excited to be back at it and planning it now for next February.

    Alan Shimel:                Randy, near and dear to the hearts of our listeners here on devopsy.kinsta.cloud, under those 2,500 or so sessions there was a tremendous amount of dev-ops related content and curriculum at the show, wasn’t there?

    Randy Newell:             Yes, there was. I think in all the number was something like 385 dev-ops sessions, and that includes presentations, labs, workshops, et cetera. So it was one of the major streams. I think we had five total streams last year. Dev-ops was one of them. Streams is just conference vernacular for a grouping of tracks. We’re essentially doing a similar approach this year, so there will be a similar major presence for dev-ops, somewhere in the neighborhood of 300 or 400 total sessions.

    I think what’s interesting about this year is you’ll actually see dev-ops in addition to being in its own stream, its own set of tracks, will actually permeate a number of the other streams as well like hybrid cloud, mobile, Internet of things, security, et cetera. So that’s kind of neat because we’ll see it put into the context of some of these other streams.

    Alan Shimel:                And that very much is in line with where dev-ops is in the market today. It seems to be everywhere. Randy, for those who are listening, I wrote an article just the other day about “Up Your Game” when you go to these conferences. Rather than participating by listening, participate by speaking. The call for speakers is still open, correct?

    Randy Newell:             That’s right. It actually closes out on Friday, September 25th. So those who are reading your blog and taking the challenge to get themselves out and present this year, we really encourage them, if they’ve got a good story of their dev-ops journey, to really consider putting together a response to that call for speakers and getting that submitted by this Friday, by September 25th.

    Alan Shimel:                Randy, I’ve spoken to dozens if not more of people who say, “Oh, why do people want to hear about me? What do I have to say to people?” Can you give us sort of a peek into what are the kinds of stories or presentations that you guys are looking for, for InterConnect this year?

    Randy Newell:             I think that’s a great question. First of all, just maybe a minute on the way that we’ve organized dev-ops at the conference, the way that the stream looks. Dev-ops is the overall stream, and then think of it organized into a couple of interesting tracks. One really positions dev-ops overall as an enabler of transformation. So if you’re thinking about submitting and you have stories about the way dev-ops has helped transform application development delivery generally or transform for faster innovation, which is really where we’re seeing a lot of these come in now, consider that particular track.

    Then there are a series of tracks that are knitted together that dive into what we refer to as option paths or phases of the software delivery lifecycle, so focus on plan, dev, test, deploy, operate. So if you’ve got a particular story in that space, then I would encourage you to think about that context.

    Then we’ve got a track that actually addresses the unique considerations of dev-ops in large enterprise, where you’ve got multi-platform environments, so considerations relative to Z mainframe, for example, power environments, and get into neat concepts like variable speed IT, bimodal, those sorts of concepts within that context.

    Then of course the other tracks that I mentioned are streams on hybrid cloud, on mobile, security. So first I’d think of, “Hey, do I have a story that fits particularly well into this framework,” not that you have to work within that framework, but it would give you some context.

    Then I think what we saw playing particularly well last year, so conference sessions that end up getting scored particularly well are about your dev-ops journey, and think of sharing it at really one of two levels, because InterConnect is very broad and we should probably talk about that a little bit. But what’s interesting is we have management topics and we have technical topics. So I would generally think about whether you’re grouping your story into one of those two.

    The management topics and technical topics can actually play against everything that I’ve mentioned so far, but the important thing is sharing the journey. What were your successes and also your challenges? Envision yourself sitting in the seat. Am I learning something? What am I learning from this particular session? So I’m listening to the presenter. Tell me about their journey and not just, “Hey, we hit the following KPIs around speed or quality or engagement,” or what the particular metric might be for your particular execution, but what were the challenges politically, especially cultural issues. How did we get that first starter project through? What were the challenges on scaling for the next project?

    I think it’s those sorts of things that work particularly well. I would encourage people the way to get your track approved and, importantly, that in most cases will get you a free conference pass which is worth a couple thousand dollars, which is good, is to get specific about the learnings, the metrics, what you were able to accomplish with some good quantitative aspects behind it.

    But as I indicated, don’t forget some of the qualitative aspects that would say, “Hey, while this was dev-ops and was largely about increasing speed or increasing quality, what did it allow the business to do?” Because in the end we were after gaining some business agility or some increased market speed, and what did that mean. Increased market share. Were we able to launch a new business venture? Did we increase customer sat? Those sorts of things come out extremely well, especially if you’re talking some of the management tracks.

    Then if you’re looking at a technical track, really peel back and look at some of the leading edge implementations and use cases. I think that’s where we’re going to see a lot of excitement.

    Alan Shimel:                Absolutely. Randy, I always like to tell people talk about what you’re passionate about, and chances are there will be other people who are passionate about the same thing, and birds of a feather will flock together and they’ll join in your passion. There’s nothing better than a presentation where you have a room full of people that are passionate about the subject that’s being presented. It makes for the best presentation.

    So I highly, highly encourage you. If you are thinking about it, dipping your toe in, whether you’ve spoken before at conferences or not, if you’ve got something you think you want to share with the world and talk about your dream and your path and your journey, as you said, Randy, it is open till September 25th, the call for speakers.

    I believe you can get to it at www.ibm.com/cloud-computing/us/en/interconnect. But don’t worry if you didn’t write that down. We do have it up on our website at devopsy.kinsta.cloud. You can find it there under an article I wrote called “Up Your Game: Speak at a Conference” or something to that effect.

    Randy Newell:             You can also just use your favorite search engine to just search on IBM InterConnect 2016 call for speakers.

    Alan Shimel:                That sounds too easy.

    Randy Newell:             It might take you right there.

    Alan Shimel:                Yeah. That’s another way. Randy, all work and no play makes us dull boys and girls. The other great thing about InterConnect is it’s such a great networking event. I don’t mean switches and routers. I mean human networking. Talk a little bit about some of the social activities maybe from last year and what we might look to see this year.

    Randy Newell:             I think one thing to note and obviously anybody that’s paying attention to devopsy.kinsta.cloud knows that there are an awful lot of conferences that are going on in the industry. I think what’s neat about InterConnect and what’s maybe a little bit different than some of the other conferences is the breadth of the conference itself.

    As I indicated earlier, we intentionally blended a number of prior events into this, and then obviously have extended the curriculum to be largely around mobile and cloud. Surprise, surprise, it’s about the enterprise. That’s where IBM plays. So it’s a very rich enterprise environment.

    But what really hit home last year, we used to have a prior event called Innovate, which was a dev conference. We had another conference called Pulse, which was kind of an operations conference. We had another conference that was Impact, which was largely about middleware integration concepts, et cetera. All of those, every one of them had 4,000, 10,000, 12,000, and now this is combined and we’ll do well over 20,000 at this event this year.

    When you put all those together and you have a topic, especially like dev-ops, and we might have addressed in prior years and it might lean towards a dev topic. It might lean towards an ops topic, depending on which of these events. When you put this attendance base together, it really is exciting because you’ve got major enterprise customers that are sending in some cases dozens if not over 100 attendees from a given organization, and they’re from different parts of the organization, yet you’re hearing the same major conference topics. You’re able to segment your path, your personal roadmap through the event to get what you want out of it, but you’re able to basically go share experiences as well.

    So if you want to go onto the show floor, going back to your question about what’s going on socially, the mix of sessions and labs and workshops and going out onto the show floor, whether it’s demos and touch and feel and let’s build an app together and those sorts of things, especially when you do it with your colleagues who might represent your dev-ops team. That’s kind of cool.

    Alan Shimel:                I agree, Randy.

    Randy Newell:             We do some neat stuff, too, and I know you were there last year and I appreciate your collaboration around the event. IBM knows how to throw a party as well. Last year we had Aerosmith there and we took over the MGM coliseum. Obviously it was sold out. I think it was well over 12,000 or 13,000 people. And it rocked.

    We end up kind of blending what turns out to be very long days with lots of excitement and lots of technology and lots of learning and sharing and networking, but there’s an awful lot of play time, and Vegas is certainly a great place to do that. There’s certainly an awful lot of distractions and opportunities for –

    Alan Shimel:                For those who want to partake. Randy, I will just mention as a participant last year, as an attendee, as an observer, what I really loved about the InterConnect experience was it is a really big show, and sometimes though one can get lost in a really big show. What I liked about InterConnect was the keynotes were by the kinds of luminaries you would expect to see at a show of this magnitude. These were real headliners, not just keynotes, headliners.

    But because of the breadth and width of this show, almost 400 dev-ops tracks, if there was a particular aspect that you wanted to explore and take a deeper dive into – so many shows have dev-ops and three-quarters of the things are: what does dev-ops mean to me? What is dev-ops? Why should you care? At a show like InterConnect you could slice minute slices into stuff that you’re really important on. How can I facilitate better continuous delivery and better feedback loops in a banking scenario, in a financial institution scenario? How is a Fortune 100 bank delivering mobile applications based upon mainframe technology?

    Those are the kinds of deeper dives that you’re not going to get at a show that doesn’t have that depth, doesn’t have that breadth. So I highly recommend it for that reason.

    Randy Newell:             I don’t think we’re unique in this, but I think what we’re getting better at with the InterConnect Conference and IBM conferences in general is tagging the content. So if you go on to your personal agenda builder as you’re readying for the conference, you can build yourself a personal track based on: am I looking for management tracks on this topic? Am I looking for technical tracks? When I’m thinking about how advanced the tracks are, am I signing myself up for novice stuff? Am I going for double black diamond? Those sorts of things.

    So I think there’s ability in all of that breadth to actually really find a personal track through it. I think we uncovered some gems last year based on ratings, based on attendance, and of course our updating that based on what we’ve been hearing over the last year, since the last conference, is we’ve evolved in the dev-ops space from a lot of clients trying to understand what dev-ops is, and we still answer that question and will answer the question this year with sessions that are designed for that, but we’ve seen customers evolve not just from doing pilot dev-ops projects or drilling down in a particular adoption path area like deployment automation or agile planning or something like that, but to actually now start to build full integration across the lifecycle so that they’re actually achieving real continuous delivery. That’s really cool.

    For the clients that haven’t gotten to that point, there becomes a question that says: how do I get started? One of the things that we delivered last year and I think you’re aware of is we ran some workshops. The workshops were designed to do a dev-ops assessment. Where are you on your readiness for dev-ops?

    These were kind of cool environments where you’d bring in either a single client and you’d actually get 10 or 12 people in the room all from that client, or you might run it in a multi-client environment and just a common topic. But the point was you do an assessment right there live as a workshop, and these things are run by pretty heavy-duty folks from IBM. These are distinguished engineers. They might be IBM fellows. They might be global services partners or directors who bill out for a fair amount of money. You’re talking about live, basically included in the price of your conference fee, consulting on how ready are you for going towards dev-ops and getting to a point of, “We understand where we’re broken and where the right starting point is.”

    We’re going to keep building on that for this year. So we’ll continue to see those types of workshops, like I just discussed, but we’ll actually progress it and blending it with some of the stuff that we’re doing now in our Bluemix Garages, for example. I don’t know if you’ve heard about this, but we’ve opened up a whole host of Bluemix Garages and these utilize a neat approach. It’s a startup methodology that they use.

    What we’re finding is that enterprise customers are coming into that garage environment, and they’re understanding how you can very rapidly use this kind of startup culture as well as a kind of rapid methodology that’s there, to go from ideation to MVP in a matter of a couple of weeks. If you’re talking about line of business, being able to see that kind of responsiveness, that’s exciting, and that becomes kind of the way that you can go back to the enterprise and scale that sort of startup culture within the enterprise environment. We’re trying to harness that.

    So being able to put that kind of environment into InterConnect to say, “Let’s go from your assessment,” if that’s where your readiness is, to understand where you are, for those who have progressed and want to understand some of the design thinking and aspects that go into this very rapid movement from ideation to MVP, so that you can start to show this to your business stakeholders. That’s a neat thing that we’ll be experimenting this year as well within the context of InterConnect.

    There are a few things that have enabled that. Last year we were working off of a beta version of Bluemix, which is IBM’s platform as a service. Bluemix together with SoftLayer have become a really pivotal part of the way that we can deliver dev-ops in a hybrid cloud environment. Bluemix has since gone GA last summer and is now actually the fastest growing platform as a service in the industry right now, and that’s the tip of the arrow for doing rapid dev-ops environments. So you have this immediate standup environment that’s available on the Bluemix platform, and then you have this integrated experience for your dev-ops team within that environment, and able to go right from build to test to automated deployment instantaneously, literally a one-click environment within that context.

    So that’s something that we’re going to leverage in the InterConnect environment, to be able to show that speed with which you can get to that initial end.

    Alan Shimel:                Fantastic. Randy, we’re way over time here, so I’m going to have to wrap it up. You know what? We’ll be doing more chats as we get closer to InterConnect certainly.

    Just a quick reminder again, if you listened to nothing else today, if you want to speak at InterConnect September 25th is the deadline. Don’t miss it. There are a lot of openings, a lot of slots. So I encourage everyone to share their journey and apply.

    Randy Newell, thank you very much for giving us a little InterConnect 2016 insight today. We look forward to having you again as a guest on our show.

    This is Alan Shimel for devopsy.kinsta.cloud. Till next time, thank you very much.

    Randy Newell:             Thanks, Alan.

  • DevOps Chat: Varun Singh, CTO of ScaleArc

    DevOps Chat: Varun Singh, CTO of ScaleArc

    singhI recently had a chance to sit down with Varun Singh, CTO and founder of ScaleArc. ScaleArc was recently named a Gartner Cool Vendor and is the leading provider of database load balancing software.

    Varun and I spoke about why IT leaders need to ensure that their databases are performing optimally.  On top of that Singh has had a colorful career in India as a pioneer in the Internet.  You can listen to our conversation and follow along with the transcript. Enjoy!

    [soundcloud url=”https://api.soundcloud.com/tracks/224505149″ params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=true” width=”100%” height=”450″ iframe=”true” /]

    Alan Shimel:                Hi everyone, this is Alan Shimel, editor in chief of devopsy.kinsta.cloud. Very happy to be joined today by our guest, Mr. Varun Singh, founder and CTO of ScaleArc. Varun, welcome to our webcast.

    Varun Singh:               Thank you, Alan. Thank you for having me today, it’s going to be fun.

    Alan Shimel:                I think so. So Varun, we were talking a little bit before we went live, or recorded, as the case may be, and you were giving me a little bit of your background. You’ve had quite an interesting career working on OS/2 Warp and BBS’s in India, running the first BBS based on Linux in India and hosting a TV show there as well.

    Varun Singh:               Yep, yep. I’ve really sort of aimed for diversity, if you want to put it that way, in my career. I’ve tried anything and everything. Been a writer. Been a journalist, sort of reviews and everything else. Started a website called TechTree.com, which is now like the number one tech website in India at this point in time, and a whole bunch of other stuff. Joined CNBC sort of at the peak of their build up and joined them primarily as a tech editor, but they wanted me to be the CTO, so I did that sometime. Built a whole lot of websites with them, and when we did that, essentially learned the value of how to scale databases. And from there came the idea of ScaleArc.

    Alan Shimel:                Excellent. So Varun, excellent lead in for our audience who may not be familiar with ScaleArc, can you give us a quick background?

    Varun Singh:               Sure. ScaleArc is database load balancing software. We essentially ship you a virtual machine, and that virtual machine includes the database load balancing software that let you scale, provide a zero downtime environment, and essentially make your transactional apps completely zero downtime. This is the kind of tech that pretty much Google, Facebook, everybody else have had within their networks, because they’ve built it for themselves. What we’re doing is building it for the rest of the world.

    Alan Shimel:                So as some others have been wont to say, the CoreOS people, you’re bringing sort of Google-like experience to the masses.

    Varun Singh:               Yes, at the database layer, yes. So CoreOS is doing it essentially, the OS layer, and there’s a whole lot of stuff that’s going on in the container world, which is all very, very exciting and we’re participating in that in someway as well. But essentially what we do is we sit at the transaction box. So applications and websites, they connect to us with an abstraction layer, and once they connect to us, we then go ahead and establish connections to multiple database servers in the background and make sure that no matter what happens, that application gets its transactions through.

    Alan Shimel:                Excellent. And Varun, ScaleArc is sort of a six-year overnight sensation, right? You guys have been around for some time since 2009?

    Varun Singh:               Yep, it took us about 2.5 to 3 years to sort of build the tech itself, because it’s pretty complicated to build what we’ve built, because we’ve built essentially the world’s first transparent database engine. If you look at the four patents that we filed in 2010, they’re all about transparency and how we’ve basically made this possible for any and every app. So all an app has to do is just transfer its connection over to us and immediately they get access to an entire cluster, they get access to zero downtime, they get access to deep SQL  analytics, and all of that is available to them as part of that one single package that we provide.

    Alan Shimel:                Excellent. So Varun, our talk today is really aimed at C-level, VP manager level people. Why should – without getting too far into the weeds on the technology or feature set, why should executives care about what ScaleArc is doing and what problem are you solving that executives care about?

    Varun Singh:               Sure. So at this point in time I’m sure a lot of executives are looking at how to migrate to the cloud. The moment you go to the cloud you’re essentially running into smaller machines, you’re running into unpredictable arrangements windows, and you also have to worry about how to aggregate capacity across multiple machines to be able to make your performance numbers.

    A lot of applications that are running on very large servers on prem don’t have a way, don’t have a path into the cloud right now. So ScaleArc is basically the thing left that’s the last step in being able to migrate to the cloud as far as large mission critical database intensive apps go. So that’s the first thing that we do.

    We’re making it a lot easier for your application developers to develop these apps and not have to worry about the HA piece, not have to worry about the failover piece and all those things. And that makes your developer’s life so much easier. We provide you a lot of APIs and all those APIs let you automate pretty much all of these functions. You could go ahead and do a rolling upgrade. You could do a rolling patch. All of that can be automated, and you can do all of that using our S API’s that are provided by us.

    Alan Shimel:                Excellent. So Varun, when you guys typically – well first of all, is it mostly larger enterprises that are looking for this kind of thing or is it across the board?

    Varun Singh:               It is across the board, but we’re specifically at this point in time targeting larger enterprises. So some of our largest customers are like Dell.com. So every single transaction on Dell.com works with us and we’ve been with them through the last two Black Fridays and just preparing now for a third Black Friday with them. We work with NASDAQ, so NASDAQ pretty much all price feeds at this point in time come through our system. We work with Answers at Microsoft.com, so all user queries that are going through Answers to Microsoft.com come through us. And that’s one of our large deployments that is across the board, four regions, multiple datacenters, active active. So pretty complex applications and pretty complex deployments.

    Alan Shimel:                Excellent. And Varun, when you engage customers of this size, where is the engagement coming from? Is it executive led or are there sort of technical champions that are bringing ScaleArc technology to the exec team?

    Varun Singh:               Sometimes it is executive led, sometimes it’s architecture led. Sometimes it’s even DBA or application developer led. It’s across the board. We’ve seen all kinds, but the most consistent one we’ve seen is the architecture, and that’s a pretty good fit I think with your show as well.

    Alan Shimel:                Yeah, yeah, I believe so.  So Varun, as I think we were speaking earlier, we live in interesting times. It’s sort of a boundary layer as we move into a world dominated by movements like DevOps and automation and continuous delivery integration, continuous integration, continuous everything. How has that played into your life and ScaleArc?

    Varun Singh:               It’s helping us massively. That’s pretty much exactly what people want. They want that application infrastructure to be continuously available. So from that perspective, the fact that databases are the last thing remaining in that stack which are hard to manage, we’re sort of flying at this point in time.

    Alan Shimel:                Exactly. So the database is one of the last pieces of the stack to kind of get the message about doing more faster and getting sort of a DevOps approach to things, or agile.

    Varun Singh:               Yep, and essentially what customers are right now aiming at is to be able to get to a point where they really understand their database stack and have full control over their database stack. And we’re kind of becoming that one control panel that they look at every day and essentially find out exactly what’s happening, whether it’s new users that are logging in to their database stack or new queries that are being executed that have never been executed before. And what we’re providing them is that entire stack as well as the ability to do zero downtime maintenance, being able to mark a server offline in the middle of the day, put a patch on it, upgrade it, and bring it back online. And you have never been able to do it in the past because you would have always had a ton of application errors, and what we’re doing essentially is eliminating all of those application errors and providing a transactional engine that works with pretty much any application engine and allows that application engine to become a zero downtime app.

    Alan Shimel:                Excellent. Varun, for executives listening in on here, what do you see as the next frontier or the next thing that CTOs, CIOs, VP, managers should be looking for in terms of database management, database performance, database load and so forth?

    Varun Singh:               I think at this point in time, they have to look at figuring out a way to expand out, scale out and get to what we call shared nothing. Shared nothing is essentially a way to store database information on servers in a way that you don’t have to worry about interdependency issues. So each server is its own individual isolated zone and even if you have five servers, you can have four of them go down and the fifth one will still be alive. So that’s the architecture that I think everybody is headed to right now. That’s the architecture that MySQL sort of made famous, and now at this point of time pretty much all databases are headed to that architecture. And databases are getting more and more sophisticated. But apps really haven’t been able to use that because the issue right now is that quite a lot of these apps are written to older versions of SQL databases. So what we do is provide all the new features that are coming in from the new databases to the apps without a single change on the app.

    Alan Shimel:                Excellent. Varun, we’re almost out of time here, believe it or not. We try to keep these chats relatively short. But a question I always ask people ending up is, for people listening in, whether they be managers, C-levels or people who want to be managers or C-levels. If you had to pick one book to read that would help them further their career and understand what’s happening and where they need to be, what would that book be?

    Varun Singh:               I could give you two or three right now, but if you really want one as far as an entrepreneur is concerned, I think The Hard Thing About Hard Things is really still the flavor of the month. It’s going pretty well still, I’ve sort of re-read it twice and it gives new meaning sometimes if you re-read it because you’re sort of analyzing a situation from a completely different perspective, and it’s a pretty interesting book to read.

    Alan Shimel:                So The Hard Thing About Hard Things.

    Varun Singh:               Yes, that’s by one of the partners from Jason Horowitz – Ben Horowitz.

    Alan Shimel:                Ben Horowitz, sure, I know the book well. Varun, and of course if people want to find out more about ScaleArc, is it ScaleArc.com?

    Varun Singh:               ScaleArc.com, and we’ve got a whole bunch of videos, we’ve got some webinars, we’ve got a lot of other stuff available as well as customer case studies as well.

    Alan Shimel:                Excellent. Varun Singh – founder/CTO of ScaleArc – thank you very much for appearing today on DEVOPS Chats and continued success with ScaleArc.

    Varun Singh:               Thank you. Thanks for having me.

  • DevOps Chat: Tyler Jewell, CEO, Codenvy why leaders need DevOps

    DevOps Chat: Tyler Jewell, CEO, Codenvy why leaders need DevOps

    tyler jewellI had a chance to sit down with Tyler Jewell, CEO of Codenvy.  Tyler is an experienced tech exec and VC participant.  I met Tyler recently at the CloudBees CD Summit and Jenkins User Conference in Santa Clara. Tyler’s present company is Codenvy.  I spoke to Tyler about why and how leadership should engage DevOps.  Tyler says leaders need DevOps. You can listen below or read along. Enjoy!

    [soundcloud url=”https://api.soundcloud.com/tracks/224505270?secret_token=s-gFEIj” params=”color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false” width=”100%” height=”166″ iframe=”true” /]

    Alan Shimel:                Hi, Alan Shimel, devopsy.kinsta.cloud here for another Devops web chat on the Leadership Suite. Our guest today is Tyler Jewell who’s CEO of Codenvy. Tyler, welcome to Devops chat.

    Tyler Jewell:                Thanks for having me.

    Alan Shimel:                Tyler, I guess we should start off with those of our listeners who may not be familiar with yourself or Codenvy, why don’t you give us a quick background?

    Tyler Jewell:                I have been working at Enterprise Software for 25 years. I started off as a software engineer and then held a number of positions in product management at companies like BEA and Quest Software. The past six years I have been a venture capitalist, a partner at Toba Capital, investing in midware, Devops, and developer related technologies and while there at Toba Capital I founded and run Codenvy, which is now three years old.

    Alan Shimel:                Great. So another overnight success, huh?

    Tyler Jewell:                Business is good and there’s a lot more to be had.

    Alan Shimel:                So Tyler, for those of our listeners who may not be familiar with Codenvy, what are you guys doing over there?

    Tyler Jewell:                We are in the business of providing continuous development solutions, which is a part of Devops and continuous delivery. We do that by delivering on demand develop or work spaces that are easy to replicate, are constraint free, and collaborative.

    Alan Shimel:                Great. So Tyler, our audience for these chats are really managers, executors who are managing software – well, every companies a software company today, right? But these are people who are managing software departments and managing software delivery. Why should they care about what problems Codenvy is solving?

    Tyler Jewell:                Well, I think that there’s an interesting statistic that says 88 percent of organizations are now pursuing a Devops strategy and that’s just a phenomenal statistic in my mind considering that the term Devops did not appear before 2010. So in five years we have had essentially market saturation, and so why is that? And that’s the case because ultimately organizations that can release more frequently are able to drive customer happiness and this ceiling, this philosophy, has so many truths to it that software organizations are assessing their ability to deliver continuously at all stages of the pipeline.

    Where Codenvy fits into this is that we are providing continuous concepts to the pre-commit or the pre-merge phase of the pipeline, which is where the developers spends his time, and frankly where the developer spends a lot of their time configuring it and not coding.

    Alan Shimel:                Tyler, what about sort of system architects, system planners? Are they part of the Codenvy value chain as well, sort of even before the code, the proverbial papers taken into pen to paper, when we’re planning new apps and new software?

    Tyler Jewell:                Well, I think that historically the code has been the domain exclusively of the developer and there’s really no reason for that and that the code can become the domain of all audiences that are part of the software team, including the architect, but also the QA engineer, the product manager, the project manager as well. And essentially if you’ve been someone who has wanted to bill code or to run or debunk the code you needed to be a developer and set up a developer work space.

    That was a very technical skill set that you needed to have. In this day and age with the advent of containers and a lot of the automation that has been built into our technologies there is no reason that you need to be technical to recreate a developer environment. You can do that with URLs. You can do it online without installing software. And when you do you can allow users, your QA engineers, and product managers to get a feedback on to the code along with the engineers having these environments without overhead.

    Alan Shimel:                Got it. And Tyler, so we have this – to many people and especially to a lot of managers, execs, Devops is sort of developer led, but we’re also seeing this movement of IT ops, right? And as IT ops folks between to code more and infrastructure code starts happening more do you think we’ll see a migration from sort of Devops to IT ops being dominate here with this?

    Tyler Jewell:                Well, I think what we’re looking at is it’s a feedback driven initiative here. So whether it’s a developer or a development organization or an operations organization that is the driving initiative, the common goal here is to find ways to get feedback earlier into the life cycle. So whether that is an operation’s engineer or a developer it’s really about the people who value that feedback the most and can benefit from it.

    And feedback exists at every stage of the pipeline among all the different departments that are there and they all benefit from having that feedback as well. So I think they’re all gonna become drivers in their own way and they’re – any barriers that exist between them are gonna increasingly come down including perhaps their titles and job responsibilities as well.

    Alan Shimel:                Sure. Tyler, one of the functions of executives, especially IT executives, is we service somewhat of a translator between our very technical teams that we work with such as developers, such as IT ops or QA and even security. Between that group and then translate that into business speak for our peers who are perhaps CFOs or CEOs or nontechnical executives in the team. When we talk about the kinds of problems that Codenvy tackles, how can executives translate that into business speak that they’re CFO and CEO understands?

    Tyler Jewell:                Well, I think that if you are an organization that depends upon software either to be differentiated with your products out in the market place or to just be more efficient, the leap that CIOs need to make with their peers is that software teams that are high functioning are those that are able to release the most frequently here.

    So having a benchmark of release frequency, comparing that to your own ability, and then assessing your technological people in cultural capabilities along those lines is a simple way that you can start to communicate the benefit of having a very efficient software development organization that is embracing these technologies and philosophies. If that kind of assessment and narrative does not work then I think you have to take it back to perhaps manufacturing fundamentals, the theory of constraints here, which goes that if you want to produce a high volume, high quality parts, physical parts, you have to focus in on the portion of the work flow that is the slowest and most _____. And by resolving that and making that the most efficient then the entire manufacturing process becomes more efficient and software is the same philosophy. It’s just done with bits as opposed to screws and bolts.

    Alan Shimel:                Got it. Tyler, let me ask you to step back from your role as CEO of Codenvy for a second and put on your hat as someone as you said has 25 years’ experience in IT who’s served on the venture side of the house. What do you see as the biggest innovations or trends that executives should be watching around this whole new way of doing software and apps?

    Tyler Jewell:                Well, I think that they’re – as an investor at the very basic investment thesis in that the demand for software is increasing at a faster pace than the supply of engineers exist to produce it here. And so the only way to revolve this demand supply curve or this inequality that exists is that there’s gonna have to be tremendous innovations that show up that allow us to create software 10 or potentially even 100 times faster than we have in the past. And businesses and technologies that play to those trends are going to have outsized returns versus vendors who are not playing to those trends.

    So I think that’s the way I think about it and that’s abstract level. At a very concrete level the things that are playing to that, containers are absolutely fantastic. They provide low overhead. They also provide the programmatic definition of infrastructure which is something that we’ve never had before. So their rising adoption and popularity are a reflection of that. At the same time we’ve started to see new evolution of programming languages.

    Programming languages that are special purpose or domain specific are particularly geared towards Cloud development and those are making developers a ton more productive. And at the same time I also think that we’re continuing to see the rapid mobilization of knowledge workers around the world. We still have not seen a high penetration of that and there’s a lot more penetration to come. So those trends are inevitable trends that are playing into this Devops’ philosophy.

    Alan Shimel:                Got it. Last question, Tyler, and it’s the same one we ask everyone who appears on our show. For your executors out there, if they should read one book that will really help them with trampling with all of these kinds of issues and further their careers, what would you recommend?

    Tyler Jewell:                I’m a huge fan of Stephen O’Grady’s book that he wrote. It’s a two hour read. The title of that book – and this is my older age slipping my mind here – it is Developers are the New Kingmakers.

    Alan Shimel:                I know the book.

    Tyler Jewell:                It’s a fantastic read and I think that the book provides a very non-emotional explanation for why developers and development teams behave the way they do.

    Alan Shimel:                Yep. Excellent. Hey, Tyler, Tyler Jewell, CEO of Codenvy, thanks for being this week’s guest on Devops chats and much continued success with Codenvy and we hope to have you on again soon.

    Tyler Jewell:                I look forward to coming back. Thank you so much for having me today.

  • DevOps Chat: Gary Gruver, Leading the Transformation

    DevOps Chat: Gary Gruver, Leading the Transformation

    I recently had a chance to sit down with Gary Gruver, well known DevOps leader and author. Gary’s new book, Leading the Transformation, Applying DevOps and Agile Principles at Scale is a great how to for managers looking to lead the transformation at their respective teams.  Gary put on a very informative webinar which you can listen and watch that goes into much greater depth than this short conversation.

    I have posted both the audio file to listen to and a transcript of our conversation below.  Enjoy!

    [soundcloud url=”https://api.soundcloud.com/tracks/224098337″ params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=true” width=”100%” height=”450″ iframe=”true” /]

    Here is the transcript of the conversation with Gary Gruver. You can follow along with the audio file or just read if you like:

    Alan Shimel:         Hi. This is Alan Shimel, Editor in Chief of DevOps dot com, and welcome to another DevOps chat in our leadership suite. Today’s guest is DevOps thought leader, and well-known author, Gary Gruver, who has just published his book, Leading the Transformation, Applying Agile and DevOps’ Principles at Scale.

    Gary, welcome to DevOps Chats.

     

    Gary Gruver:                Hi Alan. Good to be here.

     

    Alan Shimel:                Thank you. Gary, first of all, let me just commend you. The new book is great. I think I mentioned to you offline, I read it on the way out to California, and back. I went back and actually highlighted a bunch of stuff, which I don’t often do with books anymore, but it was that good and that important to me.

    So great job on the book. For those of our readers who may not be familiar with both yourself and the book – why don’t you give us just a quick background and synopsis of Gary and the book?

     

    Gary Gruver:                Well I’ve been in high tech for a long period of time and the last, probably eight years, leading large scale transformations of software development projects in different organizations, first at HP as the Director of the Imbedded Firmware Organization, over about – we started with 800 developers.

    And I wrote my first book because the results and benefits that we saw with that were so dramatic, and I learned so much from the organization and the transformation that I just felt that I had to share it with everybody else, do that’s a practical approach to large-scale actual development. It’s kind of a case study at HP.

    And that kind of gives you a feel, a short, quick, easy to read, not very technical book for executives that just – here’s what a transformation looks and feels like. I’ve gotten more actively involved in the Agile and the DevOps community and learned a lot by going to a large retailer, and was head of QA Release and Operations at that retailer, and led a large transformation towards continuous delivery there.

    And what I found through the process is, it’s easy for engineers to go to different conferences and understand how to develop differently, but if the executives don’t engage in leading the transformation, they’re going to come back, and the organization is going to throw a wet blanket on it. So what I tried to do with the second book, which Leading the Transformation is, is write down and capture in a book that was short enough – 100 pages – so that executives would read it, but had everything I wished I knew before I started on my transformation. So look, there’s going to be uniqueness and differences with different organizations.

    But the more they can avoid the bumps on the heads and the learnings that I’ve already gotten to on my own, and moved forward, and kind of moved the process and the technology forward, I think the more effective they’re going to be. So I created a lot of passion around trying to get some great business benefits.

    And I really wanted to share with others and try to figure out how I could help others to be more successful too.
    Alan Shimel:                Absolutely. So, Gary, one of the interesting things I got out of your book was – you know, many executives, they hear of the benefits of Agile and DevOps, and where do they sign up, right? Sign me up for that. I’d love to see those kinds of exponential improvements in all of these metrics.

    But one of the things you say is – executives who are just looking to do sort of Agile in and of itself aren’t going to see that sort of success, correct? It’s not just doing Agile, if you will. As a matter of fact, if you say that you do just Agile, you’re probably not going to be very successful. Do you want to expand on that?

     

    Gary Gruver:                Yeah. I would say it’s too large of a transformation and too large of a turmoil. If your current development processes are meeting all the needs of your business, you really shouldn’t go through this much effort and turmoil in your organization and cultural change.

    But I think what most organizations are seeing is – they’ve got larger, and software has become more and more important to how they compete in the marketplace, that their current software development processes just aren’t able to react and respond to where they need to add value as a business.

    And so, start with what is not being delivered to your business from your software development processes and your business objectives. You know at HP, it had been two decades that firmware had been the bottleneck for the business, and so we really started by saying – we want to be able to add a new product anytime we want without firmware being the bottleneck, and we wanted to free up capacity for innovation.

    And it was with those business objectives that we were able to prioritize the things we went after, and I think if you start with your business objectives and fundamentally looked at the rest of your toolbox, whether it’s to add to laying DevOps, sort of combined automated – just any of those things are just tools in your toolbox that are there to solve a problem.

    And then you go on a journey of continuous improving. That’s where you get the business results. It’s not going after one of those principles and hoping that you’ll get business results. It’s driving for business results and using the tools as appropriate.

     

    Alan Shimel:                Got it. And Gary, you use the term a lot, continuous improvement. In a world where continuous is the new black, and we hear about continuous delivery, and continuous integration, and continuous testing, and continuous security – briefly, what is continuous improvement?

     

    Gary Gruver:                Well it’s really wanting to go out and learn what’s between you and your organization delivering software better and more effectively. And then it’s constantly just chipping away at those barriers and learning and getting better involved. You’re not going to know everything.

    You know, at HP, we got two to three X improvements in productivity, but we didn’t go off on a three year plan to make that work. We took it month by month, and assessed some objectives, and tried to get better. And you’re going to learn so much as you really start getting out there in trying to figure it out that, what you’re going to find is, if you create a three year plan, or even if your could, it’s going to inhibit you from getting better because you’re going to learn something new that was getting in the way.

    And so, don’t try to lock in too much. Software developed and improved effectively can be very flexible and responsive. Learn and adjust, and learn and response, and just take on the biggest barriers to your productivity one at a time. And when you improve that, you’re going to learn what’s next and continue to improve that.

    But it’s getting the executives to come together once a month to review what they said they were going to get done, what got done, and what didn’t get done, and what you’ve learned in the process, to set the objectives for the next month. You know, at HP, we went off trying to get 10X better, and we did it a month at a time.

    And when we looked back three years later, we had gotten, you know – my co-author would say, 10X better in terms of frequency, and builds, and those things, but business results – easily 2 to 3X better, but it wasn’t by executing a four year plan, it was by getting up after continuous improvement, and learning and adjusting along the way.

     

    Alan Shimel:                Sure. You know Gary, in the book, one of the things I got out of it is, you sort of refer to CD, continuous delivery, as a lot of the tools and maybe processes that we follow along this Agile and DevOps journey, if you will, or process. But DevOps specifically is largely cultural in the book anyway. Is that correct?

     

    Gary Gruver:                Yeah. It depends on whether you’re talking to Gene or Jez. Jez will focus more on the technologies, and Gene will rely on the culture. I can’t really separate the two. You can’t get the cultural changes without the tools, and you can’t implement the tools and get the benefits without the cultural changes.

    I like the definition where you just lump them together and say – it’s the cultural and technological changes that enable us to release code on a more frequent basis, in a more stable way, and get feedback from our customers on an ongoing process. And so that’s the definition that kind of resonates with me, and I have a hard time getting between the two.

    But you know, in a large organization where you’ve got tightly coupled code that requires people to develop, qualify, and deploy in unison, the technologies of continuous delivery, whether you deploy everyday or not, is the forcing function that ensures all your code is going together and stays aligned.

    And so the first order of effect in a large organization is to help it come together to deliver code, or deliver value to their customers, on an ongoing basis. And the second order of effect is how the individual teams work, continuous delivery, and some of those principles are the forcing function that allows working code to provide that alignment across a larger organization, and not develop code that either won’t work together or won’t work in a production like environment.

     

    Alan Shimel:                So Gary, another sort of debate – and I don’t know if it’s a Gene and Jez debate, but it’s certainly within the community – is, do you do DevOps from top down, bottom up? Do you do it from both and meet in the middle? You have a very unique perspective in having led several transformations now and, obviously, you come at it from a top up perspective. What should leaders, listening to you here today, what should they take out of that?

     

    Gary Gruver:                I think if they’re going to be successful, the leaders need to lead it because you can’t have some groups decide to do it, or some groups decide not or do it in a different way, if their code has to come together and be delivered as a unit. But, at the same time, it’s not management.

    It’s more lead it. Set the direction. Set the priorities, and engage with the organization to learn what’s working and what’s not working. And so, you know, the continuous improvement, executive-led continuous improvement process I describe in my book really shows how the executives engage in the organization to lead that because you need all the learnings in everything that’s getting in the way from the bottom.

    And you need kind of the set of priorities from the top, so it’s that constant interaction between the leaders and the organization that gets all the best ideas and all the learnings out on the table, that gets you to prioritize the right things and go after the right improvements.

     

    Alan Shimel:                Yeah. Gary, the last chapter in the book is entitled, Getting Started, and it kind of represents, okay – after you’ve learned what you can from this book, here’s how you can get started in your organization. Of course, people should read it for themselves and learn from it, but what can you take out of that last chapter to give people a jump start on that?

     

    Gary Gruver:                You know, you really need to start where the most pain is. And one of the things that DevOps causes you to do is do things more frequently. And what you’ll find is your organization has been brute forcing its way through the same issues for years. And as you start to increase the frequency, you’ll have to start fixing that.

    And it’s hard to tell. For different organizations, it’s different places, which is why I put that piece at the back end because it depends on what you already have in place. If you’ve got a web micro services architecture that enables teams to work independently, it may be as easy as a cultural shift, and putting an operations person on that team, and letting him own things end to end.

    If you’ve got a more tightly couples system, you’ve got to think about how do you coordinate the work across them? And the first step may be, can you do continuous integration of as much of the enterprise system as you can, with a few simple tests? And make sure you’re automated correctly. So it’s that step of learning and evolving. And then as you try to do it and increase your frequency, you’re going to find different pain points.

    And that’s why I’d say it’s the continuous improvement stuff. And you know I do work shops with different executive teams to really try to bring out, and try to understand their development processes to the point that we can figure out where to start the continuous improvement process.

    We hold a work shop with their technical and manager leaders and everybody in the organization, and try to really nail – what’s that first month’s objectives? And then we do ongoing mentoring calls for the first six months to make sure they’re off on the right path.

    But you know, as opposed to spending forever trying to figure out where to start, if you can think about starting your continuous improvement process, even if you pick the wrong things first, you’re only going to go down that path for a month before you have a chance to learn, and adjust, and go after the things that are really in the way between you and your organization being productive.

     

    Alan Shimel:                Great. Hey, Gary, we’re about out of time.

     

    Gary Gruver:                Okay.

     

    Alan Shimel:                Thank you very much for appearing on today’s DevOps chat and, again folks, the book is, Leading the Transformation, Applying Agile and DevOps’ Principles at Scale. And for any executive or manager out there who is contemplating or perhaps is already engaged in leading a transformation around Agile and DevOps around software development, I highly, highly recommend it.

    You can get the book on Amazon. It is from IT Revolution Press, and just Google it. I think we also have a two chapter download, which we’ll put a link to up on the webinar page for this. Gary Gruver, thank you very much. This is Alan Shimel, of DevOps dot com. Have a great day.