Tag: ibm

  • 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.

  • Lean for DevOps: Measuring the meaningful

    Lean for DevOps: Measuring the meaningful

    At a recent Lean project report out to stakeholders, a piece of analysis was presented which showed the quantity of metrics being captured, in various areas, at different organizational levels. IBM’s Watson had been used to generate the chart, and it told an interesting story. But that story needed some translating.

    metrics eg
    ‘Look at all those metrics under ‘Managers”, said one Director, with enthusiasm. ‘Seems like they’re looking at a lot of different performance measures for their people’.
    ‘Yes,’ said the Lean Coach, ‘but is that a good thing in itself?’
    Another Director chimed in, ‘Well, when I look at how few metrics are being captured on timeliness I wonder how anyone knows how they’re doing.’

    As an IBMer, and Six Sigma Blackbelt, I’m pre-disposed towards data. Information can be power. But with too much being reported, it can be hard to see the wood from the trees. Performance metrics are intended to allow teams and leaders to improve their performance. For many of those people, reading charts and interpreting data may not be a core skill and it certainly isn’t how the organization wants them to spend their time. So those teams generating masses of performance metrics may not be doing themselves, or their leadership, a service.

    The key is to identify the critical few metrics. Ideally leading indicators of performance issues, rather than lagging ones. Leaving aside areas like SLA adherence and budget management to those responsible for governing them, these are the handful of metrics I would suggest a DevOps team needs to watch on a daily basis:

    • Number of bug fixes for top 20 systems
    • Number of critical issues, average time to close and longest time to close – looking just at the average may mask longer running issues
    • WIP: number of projects in each phase of the SDLC
    • Customer feedback for top 5 systems – preferably actual user feedback; failing that whatever you can infer from app usage. Top 5 systems may change over time as you launch new functionality or as usage changes according to the business calendar.
    • Percentage of projects who deliver 100% of their agreed scope
    • Core application availability – actual availability to users, not SLA adherence

    What do you think? What do you measure?

  • SAFe and DevOps – a recipe for a delivery smoothie!

    SAFe and DevOps – a recipe for a delivery smoothie!

    DevOps brings you the deep pink color of fresh strawberries and SAFe the rich, creamy texture of blueberry yoghurt!

    ‘Agile’ delivery is not always smooth. If not managed well, it can be a nightmare, as those of us who have seen rogue agile processes run amok know. That’s where the Scaled Agile Framework (SAFe) comes in. It blends with DevOps to bring agile delivery to the enterprise.

    A quick word about SAFe: Those familiar with SAFe would know that it divides the work of building a system into small time-boxed units. Each unit must typically be deliverable in around two weeks.

    For instance, if you run a factory then receiving and issuing material is likely to be part of what you want to automate. You may want to provide users with features, such as the ability to create issue vouchers online, modify vouchers, cancel vouchers, or search for a particular item while creating a voucher. Some of these features may be small enough to be delivered in two weeks. Others may need to be split up further into sub-features, and so on. Let’s suppose the item search feature is tiny enough to be implemented in a couple of weeks and can therefore be considered a unit (or ‘iteration’ in SAFe parlance). The system would be the sum of several similar units, each capable of being implemented in a couple of weeks. Typically, one would assign the units to various teams, and schedule them based on their inter-dependencies and various staff, infrastructure, and other resource constraints. This composite set of small units is called a ‘program’ in SAFe. More about SAFe in a later article.

    The DevOps culture: The SAFe methodology requires that each unit be made usable within the two week interval. That is, the unit must be developed and deployed to a production-like environment. The ‘agile team’ creating the unit must therefore have an ‘end-to-end’ perspective of the unit and not be constrained by artificial boundaries of development, testing, or operations. The members should have the skills, and be willing to work in each other’s domains, collaborate actively, communicate frequently, and provide feedback quickly and clearly.

    This active collaboration between developers, testers, and operations is what DevOps is about. An organization that has a DevOps culture will therefore find it easier to implement SAFe.

    Developing on cadence: A factor which makes project managers reluctant to use agile methodologies in large enterprise scale projects is the number of multiple units (and teams) operating in parallel. SAFe attempts to simplify the process of synchronization between teams by aligning the two-week windows so that they all start and end together. By ‘developing on cadence’, as this practice is termed in SAFe, the different agile teams can align common activities like planning, review and system demos. This makes it easier for the program to identify inter-team dependencies and assess how unit-level feedback and change requests can affect other units or teams. The cadence mitigates the complexity of synchronizing work across scores of teams.

    SAFe DevOps tools: While work synchronization helps, there are certain activities that still need tools. With often several hundred code changes being checked in every day, enterprise scale projects need sophisticated configuration management and deployment tools capable of tracking and maintaining the multiple versions of code, intelligently scheduling and triggering builds and automated tests, communicating feedback about test status, configuring and creating environments, creating installers, and deploying the builds to the appropriate environments. Tools like Docker make the deployment process quicker and more flexible. IBM® Rational® solution for Collaborative Lifecycle Management (CLM) provides a suite of tools capable of working across the spectrum of tasks and managing the complex delivery process end-to-end.

    Agility over the last mile: Because of the need to deliver usable code at short intervals, testers and operations personnel need to be as nimble as developers.   While developers may have achieved success in using Agile methodologies and have efficiently been churning out byte sized chunks of code at short intervals for a while, it is only more recently that operations teams have begun to accept agility as an achievable goal. DevOps, assisted by various collaborative and automation tools like CLM and Docker, has played a significant role in changing mind sets and transforming capabilities over the last mile.

    It is this end-to-end blend of the DevOps culture with SAFe, along with the various tools that are part of the DevOps ecosystem that will propel enterprise level software delivery towards the goal of smooth, continuous delivery.

    About the Author / Vidhya V Kumar

    Vidhya V Kumar

    Vidhya is an advisory software engineer at IBM.  An evangelist and practitioner of agile methodologies, continuous delivery, and documentation, she has around ten years of experience in the IT industry.  She is a subject matter expert in DevOps, Application Lifecycle Management, and Search methodologies.

  • 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 Enterprise Summit 2015 kicks off

    DevOps Enterprise Summit 2015 kicks off

    Are you going to San Francisco? If you are you don’t have to wear a flower in your hair. But if you are into DevOps or want to be and are in San Francisco this week you should be at the DevOps Enterprise Summit 2015 (DOES 2015). The conference produced and hosted by Gene Kim’s IT Revolution and Electric Cloud, features a 3 day schedule chocked full of success stories of enterprises who have adopted DevOps.

    Additionally many leading DevOps companies are sponsoring, exhibiting and otherwise participating.  Several are making or touting recent announcements. Electric Cloud themselves have just made a big announcement, releasing ElectricFlow Release which according to the company “helps organizations speed application releases by streamlining and automating software deliveries into highly organized and well-choreographed release pipelines. For software teams adopting DevOps and Continuous Delivery, it replaces checklists and spreadsheets with a single, unified view across both traditional and Continuous Delivery style application releases to increase reliability, transparency and predictability while lowering risk.”

    Screen Shot 2015-10-18 at 10.48.59 PM

    More on this in another post coming this week.

    IBM is making a major announcement as well with the BlueMix Garage Method. I had a chance to speak to Randy Newell about this new release and you can listen and read the transcript of that conversation here. IBM is a major sponsor of DOES and have several sessions and events planned including a DevOps Garage event at the Galvanize building Monday night.

    devopsy.kinsta.cloud will be providing extensive coverage of DOES 2015.  Ericka Chickowski and I will be live blogging from the conference all three days in addition to filing stories to keep our readers up to date.  Additionally we are setting up a video booth in the foyer by the Grand Hall. We are video interviewing every speaker at the conference, as well as select other guests.  Look for those videos to be available soon.

    So if you are at DOES stop by our video set and say hello. If you can’t make it, devopsy.kinsta.cloud will do all we can to keep you up to date on all of the goings on at DOES 2015.

  • Coming to DevOps Enterprise Summit 2015? Must attend IBM sessions and Night at the Garage event!

    Coming to DevOps Enterprise Summit 2015? Must attend IBM sessions and Night at the Garage event!

    DevOps Enterprise Summit 2015 is next week. Though only in it’s second year, it is a conference that any technical professional can get excited about, and is an event that IBM is proud to sponsor. Three days of discussion span topics from product integration, to agile and lean concepts, and how to start implementing DevOps and continuous delivery at enterprise scale.

    We are bringing the full force of IBM DevOps to #DOES15 this year, with subject matter experts speaking in two keynotes and two sessions, and bringing even more knowledge to booth #8 to show IBM DevOps solutions in action. If you are going to be at DevOps Enterprise Summit this year, make sure you check out:

    • DevOps and Innovation at USAA and IBM from Dibbe Edwards, Vice President Development, DevOps for Hybrid, IBM and Michael Bueche, Assistant Vice President IT Operational Excellence, USAA on Monday morning from 11am-12pm in the Grand Ballroom. Dibbe and Michael will discuss how DevOps initiatives combined with automation and culture changes are driving quicker user feedback and overall software delivery.
    • Act like a Start-Up, Scale for the Enterprise from Rachel Reinitz, IBM Distinguished Engineer and CTO, IBM Bluemix Garage, Dr. Angel Diaz, VP of Cloud Technology & Architecture, IBM, and Kristal York, Executive Mobile Strategist, PointSource on Tuesday afternoon from 2:15-3:15pm in Bayview A. Rachel, Angel and Kristal will discuss why and how IBM is implementing DevOps and how IBM’s global network of Bluemix Garages is providing the knowledge and experience that enables our clients to transform into digital businesses and deliver disruptive innovation.
    • Test Automation For Mainframe Applications from Rosalind Radcliffe, IBM Distinguished Engineer & Chief Architect for DevOps and CLM on Wednesday morning from 9-10am in the Grand Ballroom. Rosalind will be talking about how to apply shift left testing to mainframe applications, including integration testing and virtual services to improve early testing.
    • Organization Design Panel Discussion with Mustafa Kapadia, IBM DevOps Service Line Leader, as the facilitator join Jason Cox, Director, Systems Engineering at The Walt Disney Company, Jeff Einhorn, Senior Group Engineering Manager at Target, Jeff Raffo, Director – Personalization Technology at Nordstrom and Jim Penny, Solutions Director at IBM on Tuesday afternoon at 2:15 pm in the Exhibit Hall. The group will discuss about Organization Redesign and how some of the largest enterprises have been able to achieve this transformation. You may also get a box set of our For Dummies books or a limited edition IBM DevOps t-shirt with your visit!

     

    Picture1

     

    Finally, if you are looking for an immersive DevOps experience that includes complimentary beer, wine, local cuisine, and live entertainment, join us for a Night at the Garage! IBM is providing transportation on Monday night, October 19, from the Hyatt Regency SF to the Galvanize building that hosts the IBM Bluemix Garage, where you can network with other DevOps enthusiasts and witness the art of the possible firsthand at 5 interactive workstations. Register now to attend, space is limited! We look forward to meeting you there.

    About the Author/Saleem Padani

    SaleemPadaniSaleem Padani has 20-plus years of technology and business experience in product and application development, enterprise architecture, service delivery and solution marketing. Currently, he is responsible for overall go-to-market strategy and execution for IBM DevOps and Enterprise modernization capabilities for IBM. Follow him on twitter at @spadani1

     

  • DevOps Connect: cdSummit at Austin Innotech

    DevOps Connect: cdSummit at Austin Innotech

    Last week I was down in Austin, Texas for the DevOps Connect: cdSummit @Innotech show. With almost 1900 people registered for Innotech, we had a solid 150 folks specifically for cdSummit.  I think it fair to say that the attendees got their money’s worth!

    The morning started off with a great presentation by Jez Humble.  If you are talking CD, who better than the guy who literally wrote the book to kick things off.  Jez never disappoints and he didn’t last week.  His presentation is below.

    After Jez, Andy Pemberton of CloudBees presented.  Andy has a great delivery and I have seen him present before. It was a great engaging presentation and it is below for you to view.

    Following Andy we were very lucky to have David Lindquist, IBM Fellow, VP of Development, Mobile and Cloud DevOps. David gave us some great insight into IBM’s own journey of using DevOps to make an enterprise work at startup speed. Again his slides are below.

    We then broke for a great, relaxing lunch break and to give our attendees a chance to explore Innotech. There was a demo theater on the show floor featuring Jenkins, BlueMix, New Relic and AppDynamics demos. Innotech also featured a “Women in Tech” show and CIO roundtable with some great content.

    After lunch we broke into two rooms in a dueling track format. We have enclosed those below. My favorites were from the great, welcoming and amazing Austin DevOps community. Ernest Mueller previewed the talk he is giving at DOES next week.  James Wickett, one of my heroes from the Rugged DevOps movement did a great job on his session and Boyd Hemphill brought the house down closing out with his HomeOps presentation which I found witty and incredible.

    All of the speakers were really good and the feedback from the attendees echoed this.  Many thanks to our sponsors, CloudBees and IBM as presenting sponsors, AppDynamics and New Relic as gold sponsors. Most of all thanks to all of the people who came out and spent a great day with us! We are holding the next cdSummit on December 3rd in Los Angeles and if you are interested in speaking, attending or sponsoring, contact me at editor@devops.com.  We will announce more details shortly.

     

     

  • How Fast Is Fast Enough?

    How Fast Is Fast Enough?

    One of the primary goal of DevOps is the ability of an organization to bring an idea to market faster. But how fast is fast enough? Do they need to improve time to market by 10%, 20%, 50%..90%? Do all applications need to ultimately be released within hours? In order to compete do we all have to be the Etsy or the Netflix’s of the world?

    Unfortunately there is no simple answer. Optimal application delivery speed (aka time to market) varies drastically across industries, markets, organizations, and even within an organization’s own application portfolio. Remember “two speed IT”.

    In other words there is no “one fit for all” when it comes to speed. Yet defining your optimal speed – goal – is critical to your DevOps success. Without it, its almost impossible to provide a vision, measure progress, and fundamentally change the way you delivery software. For example, IT is very good at measuring costs. In fact they measure costs from every way to Sunday. As a result, cost takeout becomes the fundamental value metric for service delivery – “how low can you go to delivery the same service”. Similarly, if speed and agility is the goal then we must start with measuring our current velocity and then setting (realistic) goals for the future state.

    The Definition of Speed

    Before we go about trying to determine an applications optimal speed it is important that we first agree on the definition of speed. We like to think that speed is a fairly simple concept, but its amazing how mis understood it is.

    Many organizations new to DevOps simply equate speed to release cycles. They believe that if they increase the number of cycles then they are improving their time to market. Unfortunately it does not work that way. Improvement in release frequency is a natural outcome of going faster (as we will see in the example below) but not the driver of speed.

    True cycle time is measured from end to end – when the idea enters the development funnel to the time it is released to the end user. In other words it’s the Work In Progress (WIP) time for that particular piece of code and any improvement in speed is the reduction of this WIP time.

    For example, a healthcare client recently shared with us that it takes them just 20 days to develop a medium size enhancement. For them, their cycle time was 20 days per enhancement. But on further inspection we found that it takes 20 days to determine requirements, 10 days for setting up environments (while using cloud), another 15 days for testing, 10 days for moving code from one environment to another, and a whopping 15 days for approvals. When we added all that up, we discovered that their true time to market (speed) for that enhancement was just over 90 days.

    Once we were able to define speed in tsurehis context, it opened up an entire new world of dialogue within the organization. Now instead of optimizing 20 days, they have another 70 days of activities to pick on. Even if they were to shave just a mere 1/3 of the 70 days (cue automation with some simple processes engineering) they would be able to improve their time to market to 65 days. And as an added bonus, the team instead of just delivering 4 enhancements per year (90 days x 4) they can now deliver 5 enhancements (65 days x 5) much faster.

    By defining speed in such broad terms, it not only gives IT teams a glimpse at the big picture but also visibility into areas of wastes, opportunities for true end to end improvement, and a platform for collaboration.

    Now that we have our definition right, lets get on to answering the million dollar question,

    How fast should I be (what is my optimal speed)?

    The simple answer is fast enough to delight the customer and beat the competition. But to determine at what point you are able to achieve this goal is a bit more complicated.

    Most organizations try to answer this question by looking inward. They perform a detailed value stream mapping exercise, determine cycle time for each activity, identify bottlenecks, and then triangulate how fast they can go if they eliminate some of the key bottleneck.

    Unfortunately, speed is not a function of how fast can you go (IT view) but a function of potential benefits (business / market view). More precisely, your optimal speed is directly depended on the additional benefits the business will enjoy (additional revenue, higher customer acquisition, better customer retention etc.) as a result of greater velocity.

    To help understand this relationship between benefit and speed better, ask yourself the following three questions,

    1. If we were to reduce our cycle time (from idea to production) by 10%, 20%, 30%, 40% etc., what is the incremental benefit to the business
    2. Can we quantify this benefit?
    3. How sensitive is this benefit to speed? Are they inversely proportionate, is there a benefit / speed plateau?

    By doing so, there is a good chance that most applications will fall within one of the three scenarios.

    1. Benefit and Speed Are Directly Proportional

    For some businesses, speed is king. The faster you can deliver a product the greater the incremental benefit. Consumer facing apps (Facebook, Linked In etc.) focused on revenue generation / customer acquisition work well in this scenario. For these applications, there is essentially no speed limit. The rule of thumb is step on the gas and get out of my way.

     Figure A How Fast Is Fast Enough

    Optimal Speed: No speed limit, step on the gas

     

    1. Benefit Improves But Only To A Certain Point

    Most SaaS applications (SFDC, Workday etc.) fall within this category. At a certain point the incremental benefit diminishes as speed increases. In other words, users like the regular updates and upgrades but to a certain point. Change too much too fast and you end up delivering little additional value. In this case, there is an optimal speed and any investment in speed after that is a waste of money.

    Figure B How Fast Is Fast EnoughOptimal Speed: Limit your speed to the point where benefits plateau

    1. Benefit and Speed Are Adversely / Not Related

    This is the opposite of A, where speed has an adverse / no impact on benefit. Here users prize stability and status quo over anything else. Changes are welcomed but need to be few and far between. Many on-prem legacy applications fall into this category. Imagine if your ERP provider published a new update (mini upgrade) every day. It would wreak havoc to the organization. If this happened to your general ledger system, you would never be able to close your books. If you find yourself in this category it is best to go pick a different application.

    Figure C How Fast Is Fast EnoughOptimal Speed: None, stability is prized over changes

     

     

    Two Caveats

    The graphs are a great representation of the various options but there are two caveats that every organization should be aware of, cost and competition.

    Cost: The speed limit makes little sense if the cost of getting to that speed is greater than the incremental benefit potential. After all, like any other IT project ROI is key in deciding if DevOps is worth investing in.

    Competition: Ultimately…competition holds the trump card. No matter what your charts say and / or your cost model shows, if the competition is going faster…you have no choice but to match that speed or better yet, beat that speed. Which is why we urge many of our clients to invest into DevOps early, set the benchmark, and build a competitive advantage.

    Happy speeding!!

    About the Author/Mustafa Kapadia

    Mustafa-KapadiaMustafa Kapadia is Service Line Leader for IBM’s DevOps practice, a business advisory practice focused on helping large enterprises transform their software & application delivery. Through DevOps, organizations can get software to market faster, with better quality, less defects, reduced risk and shortened lead times.

    Prior to joining IBM, Mustafa was a management consultant with Deloitte’s Strategy & Operations practice. He lives in San Francisco Bay Area, is an avid blogger (when time permitting), a speaker, and and advisor to start ups.

    You can follow Mustafa on LinkedIn: https://www.linkedin.com/in/kapadiamustafa and Twitter: https://twitter.com/mkapadiatweets

  • Lean for DevOps: Is it OK to move the banana?

    Lean for DevOps: Is it OK to move the banana?

    There is an urban legend about a Lean deployment which, in the process of applying the 5S to a workshop, drew lines on the desk to indicate where each worker should keep their banana.

    Katie 2 5 S deskKatie 3 5S desk 2

    5S, for the uninitiated, is a set of principles by which Lean practitioners organize a workspace – which might apply to a virtual, shared workspace, or Sharepoint repository just as well as a back office space or factory floor.

    • Sort – identify and get rid of unnecessary items
    • Set in order – organize what’s left so that everything has a logical place – including deciding on the optimum spot for banana placement
    • Shine – tidy up and clean your new workspace
    • Standardize – document and put boundaries around your newly organized workspace so that it’s obvious where everything should go – including drawing a line around that banana
    • Sustain – establish systems, tasks and behaviors to ensure your work place remains neat, organized and free from clutter

    Katie 1These are great principles to apply to any shared workspace – and standardization will speed your adoption of DevOps principles. Standardizing the way we organize information allows for fungibility, so a Quality Manager can switch teams at short notice and quickly pick up the way their new team works, and access the information they need. Standardizing storage in a way is the principle behind Docker, and other modular code concepts. Standardization can reduce errors: if user requirements are captured in a consistent way it is easier to see at a glance if any essentially information is missing before we start work. And standardization ensures consistency, for example, applying a pre-determined decision tree and criteria to enhancement requests will allow prioritization decisions to be made quickly and equitably.

    But you can have too much of a good thing, Creative activities and problem solving tasks are often intuitive or require people to take a variety of approaches until they find one that fits. A checklist just may not help here. Furthermore, one of the aims of DevOps is to increase flexibility and speed to market. So if your standard start to get in the way of that, you’ve lost your way.

    As a Lean Coach I have struggled with the amount of churn I see in requirements during the development lifecycle: at first glance it reads like rework. But it is, in fact, a healthy feature of an iterative, responsive process. Many IT departments have sought to manage churn by trying to standardize it out – setting deadlines for new intakes, and arduous change control procedures. As soon as you layer governance on top of a process, you create a need for a shortcut, and an expedited route.

    I recently ran a Lean workshop for an IT team during which we identified that 30% of change requests were going through an ’emergency’ process.  Clearly the standard process wasn’t working.

    DevOps requires standardization on an ‘as needed’ basis. This includes a standard way to handle rapid change, and variation. That standard approach must be light touch governance: make the right way the easiest way. And I’ll stick my neck out and say that standardizing where a worker keeps their snack is a step too far.

  • 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.