devopsy.kinsta.cloud

Category: DevOps at IBM

  • Kicking Off InterConnect 2016

    Kicking Off InterConnect 2016

    Our InterConnect 2016 coverage kicks off with online events

    Once again this year devopsy.kinsta.cloud will be providing extensive coverage of InterConnect. InterConnect 2016, features hundreds of sessions and tracks around DevOps. We think InterConnect offers more DevOps related tracks than any conference in the world.

    We are kicking off our InterConnect 2016 coverage with some great online events leading up to conference which takes place on February 21-25 at Mandalay Bay and MGM Grand in Las Vegas. You don’t have to go to Vegas though to participate and attend these events though.  Mark your calendar for these:

    • Twitter Crowd Chat, DevOps: Outthink Delivery January 22nd, 1 pm EST. Join me and some of the clients, partners and IBM experts for this free-form, lively twitter conversation on how to deliver innovation and start-up performance at enterprise scale.
    • Google Hangout #1: What Will DevOps Look Like in 3 to 5 Years, January 27th, 1 pm EST. This is a preview of a panel I am moderating at InterConnect featuring Gene Kim, Dan Berg and Raghunath Raman.
    • DevOps Chat: DevOps for multi-speed IT and DevOps & Open Technologies IT, January 21th and February 8th. My interview with IBM Distinguished Engineer, Rosalind Radcliffe and Dan Berg. This will be a recorded podcast that unfortunately will not offer audience participation live. However, if you have any questions that you would like me to ask Rosalind or Dan, please leave them in the comments on this article.
    • Google Hangout #2: DevOps for multi-speed IT, February 3rd, 4 pm EST. Join Sanjeev Sharma (IBM ), Carmen DeArdo (Nationwide), Brad Schick (Skytap) and myself as we discuss Bi-Modal IT and DevOps. Link will be available shortly.
    • Google Hangout #3: Innovate Like a Startup, Scale for the Enterprise, February 10th, 1 pm EST. Join Gene Kim, IBM VPs Angel Diaz and David Lindquist and another special guest (still confirming) with me moderating for our last pre-InterConnect event. Link to be provided.

    We will also feature more related content leading up to InterConnect in a dedicated section of the site, DevOps@InterConnect.

    At the conference itself we will be on scene with live coverage, video interviews, blogging and tweeting, so stay tuned.

    In the meantime please join us for these great upcoming events.

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

  • ‘Tis the season to up your speaking game

    ‘Tis the season to up your speaking game

    Well it’s football season in the US, that means Fall is here.  It also means that we are coming up to conference season. No matter what segment of the IT market you live in, there are probably a slew of conferences both local and national/international vying for your attention and attendance. For the overwhelming majority of attendees, going to a conference means watching and listening to others speak on topics of interest.  Maybe this is the year you should really up your game by speaking!

    This was driven home for me last week when I was speaking with the IBM DevOps team.  We were discussing how plans for IBM’s InterConnect 2016 conference were coming along. The call for speakers for this major event is open until September 25th. The IBM team was very pleased that the DevOps stream is tracking among the leading topics for submissions for InterConnect 2016.

    That is really quite a feat when you consider the scope and scale of the event. InterConnect 2016 is IBM’s Premier Cloud and Mobile event, February 21-25 in Las Vegas, and is expected to draw over 20,000 attendees, delivering 2,500 sessions, workshops and labs in 10 major topic areas – including DevOps – and infinite networking opportunities. But it also speaks to both the popularity of DevOps in general and IBM’s focus on it in particular.  In fact, the DevOps stream covers key DevOps adoption paths: Plan, Develop, Test, Release and Deploy, and Operate.  There is a track specifically focused on transforming application delivery with DevOps, and another track called DevOps for Enterprise Systems that will focus on topics related to continuous delivery for two-speed IT including z Systems and Power Systems. There are other streams such as App Platform, Hybrid Cloud, Mobile and Security where DevOps topics will appear. Each track is packed with quality client success stories, technical deep dives, labs, meet-the-expert panels, interactive workshops and more.  What’s nice is the sessions are tagged for interest for management and techies and for skill-level.  There is a ton of content.

    To find out more join me and 14 great DevOps leaders on the crowd chat DevOps: Code, Culture & Community on September 22, 2015 @ 1pm eastern time (60 minutes). You can visit https://www.crowdchat.net/ibminterconnect2016 to add to your calendar or follow along on Twitter #ibminterconnect2016.

    So what does this mean to you?  It means that there are still some great slots available to share your DevOps skills, lessons and experience with the world.  Having spoken at numerous events over the years, I can tell you that participating as a speaker in an event brings a completely new level of learning and understanding.  It is also a great way to meet your peers, other speakers and attendees and expand your own network.

    What should you talk about?  That is probably the biggest obstacle for many people submitting to speak. Randy Newell, Director, DevOps Marketing at IBM, commented to me,”highly-rated sessions are typically DevOps journeys told by peers – shared candidly, complete with the successes and the challenges around technology and culture. Transparency and passion, told from the front lines, go a long way.” I feel that you should speak about what you find interesting. If you find it interesting, chances are others will find it interesting as well.  Also, when you are speaking about something interesting to you, your passion for the topic will shine through and others will feed from and join in your passion.

    In a large show like this, the good news is that with all of the session slots available they have the ability to afford people to explore specific aspects of a subject that might not be available at a smaller event.

    If IBM’s InterConnect is not the event that you choose to share your thoughts and ideas with the world, that is OK too.  Pick another event and submit to speak there.

    Of course speaking at conferences like InterConnect is a great career move, raising your stature and visibility among your peers.  But beyond your own personal benefit, it really benefits the whole community. The best way for us to learn is to share our experiences and stimulate the discussion.

    I realize that some of you reading this may still be hesitant to take the plunge and submit to speak.  If that is your final decision, of course that is OK, too.  You can still be an active participant in sessions by asking questions, joining the conversation. Don’t be a passive conference attendee.  You get out of these conferences what you put into them.

    As for me, I have two or three different speaking topics that I am submitting this week. Some are panels where I will be with key DevOps thought leaders and influencers who are also my colleagues to discuss key trends defining the future of DevOps. Panels are a great way to get your feet wet with speaking at events, btw.

    So what are you going to do?  Share your lessons learned, explore new frontiers, advance the state-of-the-art.  Call for papers for IBM InterConnect 2016 is ending on September 25th. Don’t miss the opportunity to up your game by speaking at the biggest DevOps event of the year! Submit to speak at IBM InterConnect 2016 today. http://www.ibm.com/cloud-computing/us/en/interconnect/

  • The Art of DevOps

    The Art of DevOps

    This is the third in a series of posts on DevOps. The first written by my colleague Lee Reid was titled The Simple Math of DevOps. The second The Calculus of DevOps was written by IBM client, and my friend Carmen DeArdo of Nationwide. Lee introduced mathematically improving delivery throughput by leveraging DevOps to improve Trust. And Carmen used Calculus to imply that the business value of IT can be improved by adopting DevOps to increase the frequency of releases. In my post I would like to visit the art of DevOps , or the art of adopting DevOps by picking up right where Carmen left off – by looking at the culture side of adopting DevOps.

    Lee and Carmen have already alluded to some basic premises behind DevOps as an approach – reducing batch sizeand improving collaboration. These result in reducing complexity, increasing throughput, and improving trust. Let’s talk about how to get there.

    As I have worked with customers adopting DevOps, across company sizes, across industries and countries, there are four common threads that make DevOps adoption successful, leveraging all three aspects of DevOps adoption – culture, process and automation. These are:

    1. Reduce batch size: The most effective way to manage risk and quality, while increasing speed is to reduce the batch size in each iteration or ‘sprint’. This is a mind shift to release smaller, more frequent new versions. Where it is not possible to release new versions that frequently to customers, release small batches to a pre-production area. The deliverable in pre-production is tested and made customer-ready, and then released to the customer at formal release dates. As Lee and Carmen have both discussed, reducing batch size is a pre-requisite to improving both trust and business value.
    2. Shift-left Operational engagement: Get operations engaged right from the beginning of a project/initiative. This has been a core principle of DevOps. Do not leave Ops in a silo that one throws code over the wall to, but have them engaged in the development process, right from requirement inception stage. This allows Ops to have visibility into what is coming from Dev; allowing them to deliver the right production-like environments, as and when needed to Dev and Test teams. It also allows Ops to shift operational concerns left, left into the minds of developers, making them more Ops conscious and engaged in what happens after they hand-off to Ops.
    3. Continuous funding: This is a significant change in an organizations funding model to enable continuous availability and engagement of SMEs and business functions, previously not engaged on a continuous basis – like security, legal, marketing, etc. Carmen in his post mentioned several examples of ‘waiting for…’ work, someone else to do something and environments. Another ‘waiting for’ in enterprises is for funding. Funding is typically provided in a waterfall manner, with specific hard dates (Months, quarters, fiscal year) and gates, not suitable for a Continuous Delivery model. Funding too should be continuous.
    4. Create a ‘Product Management’ team: This team includes a Designer, Development lead, operations lead and an Architect at the minimum (4-in-box). They own the ‘product’ through its entire lifecycle, and beyond transient projects. They are responsible for long-term thinking, design thinking, evolutionary architectural thinking, and overall ownership of the product, from concept to end-of-life.
    5. Setting up a DevOps Center of Excellence (CoE): This center of excellence is not an administrative organization or a ‘tools/enablement group’, but a place where DevOps adoptees come to learn from each other and share expertise and lessons learnt. As organizations adopt and scale DevOps adoption, this CoE also becomes a source of DevOps coaches, helping teams and programs adopt DevOps, and own the organizations DevOps framework – their own flavor of DevOps.

    Adopting DevOps is an art. It is not as simple as hiring a consultant who can show how to improve processes; it is not just buying and adopting tools to automate manual tasks; and it is not going through ‘fall-back-into-the-arms-of-the-person-behind-you’ exercises to build trust. It is a combination of all three – process improvement, organizational and cultural change, and automation with tools to replace manual processes. Adopting these in any enterprise, outside of startups, requires overcoming organizational inertia. By changing culture not by edict, but by showing the need and value of change. By building trust, not through meetings, but with improved communication and transparency. By improving business value, not by measuring mandated KPIs, but by improving organizational agility and throughput. Overcoming organizational inertia, by delivering towards a common goal for the business, irrespective of where in the organization one is, and what role one has. By developing a culture where everyone takes responsibility of delivering value to the business.

    Watch the webcast series hosted by devopsy.kinsta.cloud in partnership with IBM or download a copy of DevOps for Dummies book for more information.

    About the Author/ Sanjeev Sharma

    SanjeevSanjeev Sharma, CTO and Distinguished Engineer – DevOps Technical Sales and Adoption, IBM Cloud Unit, is a 20-year veteran of the software industry with expertise in DevOps, Mobile Development and UX, Lean and Agile Transformation, Application Lifecycle Management and Software Supply Chains. He is a DevOps Thought Leader at IBM and speaks regularly at conferences. He has written several papers and is the author of the DevOps for Dummies book.

     

    Contact Sanjeev on linkedintwitter

  • The Calculus of DevOps

    The Calculus of DevOps

    This is the second in a series of blogs, partnering with Lee Reid, who wrote the first installment “The Simple Math of DevOps” and Sanjeev Sharma both of who are outstanding DevOps Thought Leaders from IBM.

    I am picking up on Lee’s mathematical DevOps model to apply a calculus perspective, a “calculus of DevOps” if you will, (OK, not quite core Big Bang Theory Calculus but rather approaching it from the aspects of engineering queuing theory).

    One of the cultural challenges that DevOps poses is, that some aspects of it run counter to engineering principles that many of us learned with respect to capacity and response time.   When I worked at Bell Labs, we would apply queuing theory to determine how to best package information to be sent across the network. A basic premise revolved around a tradeoff between throughput and response time. On one hand, the more messages that were packed into the packet, the more the payload would improve capacity because the overhead of processing the packet of information would be spread across the messages.   However, waiting to accumulate enough call processing information meant that the packets would be transmitted less frequently, increasing the response time.

    A simple example of this would be making trips to the grocery store. If one wanted to spend the least amount of resources (time, gas, car wear, etc.) on shopping, then one would make less frequent trips and then buy a larger amount of food. So if the Smith family made one trip a month and spent 2 hours, then their average time per week spent on shopping would be 30 minutes.   If the Jones family went every week and spent an hour, then they would be spending twice the time and four times the gas on grocery shopping. However if the Smith family run out of an item (say cereal), they would have to wait, on average 2 weeks before this was replenished. The Jones family average on any item that they ran out of would be 3.5 days in comparison.

    So when the 2014 DevOps report was published[1] which states that areas that deploy more frequently get customer feedback more quickly, that is to be expected. But what’s not expected is that these organizations also have higher productivity.   So exactly what is happening here that seems to be in a basic conflict to the principles of throughput and response time?

    Keeping up with the JONESES

    If we think of a pre- DevOps state for a medium to large enterprise, it may be typical for applications to only be released (deployed into production) a few times a year to provide business functionality. (I assume there are more frequent releases for “unplanned work” like defects and other changes or operational work). For the sake of this discussion, let’s call this the Smith Application. So from a business perspective, the business wants to pack as much work into the Smith releases as possible given they only have a few cracks a year at getting new business functionality into production.

    SMITH APPLICATION CHARACTERISTICS:

    • Deliver Business Value 3 times a year (every 4 months)
    • Cost is C1
    • Business Value (BV) delivered is V1
    • Average time from concept (e.g. Story) being ready to be pulled from the backlog to the time it is delivered to the customer is 2 months plus any additional wait times (e.g. prioritization)
    • BV delivered per year is 3*V1
    • Cost per year is 3*C1

    Now let’s transport over to the Jones Planet where the application is released into production with new business capabilities at the end of every 2 week iteration.   In this case the business is more concerned with providing a constant demand flow into IT than they are with debating over whether a given feature/story is going to be included in this particular release.   Instead there is a constant prioritization (or continuous planning) process that ensures the highest value work is being fed into the IT pipeline.

    JONES APPLICATION CHARACTERISTICS:

    • Deliver Business Value 26 times a year (every 2 weeks)
    • Cost is C2
    • BV delivered is V2
    • Average time from concept (e.g. Story) being ready to be pulled from the backlog to the time it is delivered to the customer is 1 week plus any additional wait times
    • BV delivered per year is 26*V2
    • Cost per year is 26*C2

    Based on the previous engineering analysis, we would expect the following:

    1. SMITH annual cost (3C1) < JONES Annual Cost (26C2)
    2. SMITH annual BV (3V1) > JONES annual BV (26V2)

    So the tradeoff (we would believe) JONES is making by delivering more frequently is that they are spending more money and are delivering less business value on an annual basis.

    However the data from the previously referenced DevOps report is just the opposite. In fact the findings are that enterprises that deploy smaller units of work more frequently have much higher quality and much higher productivity (Capacity). So what’s going on here?

    A NEW PARADIGM

    If you go up to any IT team (even an agile one) and ask them why they don’t deploy business value more frequently, they will generally refer to the following types of wait states of waste that they encounter:

    • Waiting for work (lack of consistent flow)
    • Waiting for somebody else to do something (dependencies from other teams)
    • Waiting for environments (contention)

    One major root cause of this is the dependencies that arise from large enterprises packing a lot of work into infrequent releases. From a planning perspective, the process is elongated due to prioritization discussions because being on the wrong side of the line can mean delay amounting to months, in delivering a product to a customer.   Ask a business portfolio leader what their highest priority is for IT and I am guessing they can tell you in a matter of seconds. However, most large organizations can spend several months a year planning their annual portfolio of work for IT. Some organizations spend more than 50% of their new project build time prior to a single story entering an agile development team’s backlog!

    From a development perspective, packing a lot of work into releases means many more dependencies that have to be managed across initiatives and impacted applications. From a testing perspective, downstream environments (ST, UAT) have to manage much more information in terms of application versions and especially test data that complicate and slow down the process. The complexity of test data increase is proportional to the number of pairwise relationships that exist within the datasets required for testing.   As such, the testing complexity will increase non-linearly (perhaps proportional to the square of the dependent systems) and from a release and change perspective; there is a lot of coordination necessary given how much is being changed at one time.

    All of this work to manage all of the dependencies found in medium to large enterprises completely eliminates any potential savings one might get from batching work into a single delivery. In addition, the possibility of having to pull some work out of a release (due to quality or business readiness or some other reason) sometimes leads to complicated source code management (feature branches in some cases) that further complicate the process of merging frequently into the trunk. These types of practices also serve to drive up technical debt. So looking at the problem from this angle shows why results we are seeing make perfect sense.

    Productivity is inversely proportional to the number of dependencies in a release

    As Lee related to in the initial blog, a lot of an organization’s success depends on trust. And one factor of trust is clarity which speaks to understanding the changes that each release is bringing to the IT and customer environments. So a factor that is working against trust is the notion of delivering more things less frequently and better controlling change somehow, is a good notion.

    Trust is inversely proportional to the number of dependencies in a release

    There is another hidden component of waste associated with “big bang” initiatives. Go back to our grocery example for a moment. Chances are that the Smith monthly excursion results in buying some stuff they end up not using. Perishable items are not spread out very well when they aren’t purchased more frequently. Likewise in IT planning, we tend to put a bunch of stuff in our IT Delivery basket that we don’t know for sure that we will need and we end up with a lot of wasted effort for features that are hardly used or not needed at all. Some enterprise estimates are that 50-65% of what they put into large releases does not actually result in true value to the business. Doing more frequent releases allows a constant discovery process to better guide the usage of IT resources on what is truly of value.

    Waste is proportional to the size of a release.  

    In other words:

    Yield (Value per IT investment) is proportional to the frequency of releases.

    REVISTING THE MATH OF DELIVERY TIME

    So if we revisit Lee’s model

    Lee Reid Blog equationand apply the “Calculus of Release” as we stated above, there are increased costs associated with having larger and less frequent releases in medium/large enterprises.

    • Planning cost TPLAN
    • Development complexity TDESIGN + TDEVELOP + TBUILD
    • Testing Complexity TTEST
    • Release and Change Management Complexity TRELEASE + TDEPLOY + TEVALUATE

    TRUST % – Even if everything was proportional between the JONES and SMITH models, the component of trust that impacts clarity, consistency and collaboration, is much lower for large (SMITH) releases.  Given that TRUST has a multiplicative impact, this alone can account for the results found in the studies.

    CULTURAL CHALLENGE

    While clearly one needs to be sensitive to the changes being introduced into the business, having the ability for the business stakeholders to pull capability when they want it and having it available more frequently is not only good for customers but also has extreme benefits from an IT perspective in terms of increased productivity and reduction of technical debt. The challenge is to convince leaders in both the business and IT areas on the merits of doing more continuous planning and frequent deliveries.   Unicorns may have led the way in this type of thinking but it is actually the horses that will benefit most from this type of culture shift because it is the horses[2] that have the most to gain in mitigating the dependency factor which can undermine quality, productivity and cycle times.

    Read more about the topic in the next blog of this series The Art of DevOps by Sanjeev Sharma.

    [1] “2014 State of DevOps Reports”, Puppet Labs, IT Revolution, https://puppetlabs.com/sites/default/files/2014-state-of-devops-report.pdf

    [2] “The Phoenix Project”, Gene Kim, Kevin Behr, George Spafford, http://www.amazon.com/The-Phoenix-Project-Helping-Business/dp/0988262592

     

    About the Author

    CarmenCarmen DeArdo is the Director of Application Development Tools and Technologies at Nationwide Insurance. Carmen is responsible for driving continuous delivery utilizing DevOps, Lean and Agile techniques across Mobile, Distributed and Mainframe and other technologies. This includes recommendations and implementation of technologies used across the development life cycle (e.g. IBM Rational tool suite, open source technologies).

  • “Show Me The Money!” – Delivering DevOps Value

    “Show Me The Money!” – Delivering DevOps Value

    HM Heath Solutions delivers new business applications in the healthcare industry to 35 million customers.  In order to embark on their DevOps journey to improve software delivery, Valerie Scott, their Manager of Shared Services Division, had to show senior management an ROI on a successful project, before they would invest fully. On June 2, Val Scott along with Rick Slade of IBM joined Alan Shimel of devopsy.kinsta.cloud in a webcast to discuss this interesting client case study.  During their discussion, they illustrated in vivid detail how HM Health Solutions showed success in DevOps to their senior executives, for them to buy in and sponsor the project.

    Val and Rick’s webinar parallels many similar discussions I’ve had with senior executives.  To net it out, the bottom line is, as it was so clearly and unequivocally articulated in this amusing clip from the movie Jerry Maguire: “Show Me The Money!”

    cuba gooding jr show me the money jerry maguire tom cruise show me the money jerry maguire
    When I meet with senior LOB, Finance or IT executives — they shout a similar refrain:

    “All I want to do is buy a business outcome.  I want to invest in an IT project, and have it pay back.  Unfortunately for many application development (or other types of enterprise IT) projects, that pay back is illusory, and ROI difficult to measure.”

    — Jane or John Executive, representing nearly every IT executive or CFO I have ever met

    Unfortunately, many struggle to quantify, monetize and demonstrate the financial return on investing in IT projects.  Yet as described in this blog, it is the primary responsibility and outcome of management; leading the economic performance of their department or unit.  Show me the money!  Fortunately, many clients experience positive returns, both operationally and economically.  Ten (with links to more) client case studies with returns are highlighted in this blog, and summarized on this page.

    As you undoubtedly have experienced yourself, senior executives respond to clear business value and benefits articulated as financial returns, as ROI.  But how do you do that for DevOps, a set of technical practices and associated culture change?  As Val and Rick described during their informative webcast, comparing productivity, time-to-market, speed of delivery, and quality, both before and after a DevOps pilot, are crucial.  These operational metrics will be improved by adopting DevOps.  However, to win the hearts and minds of senior executives, you have to monetize the results, in other words – show them the money!  Technical techniques and practices such as those Val and Rick described to Alan, shifting left, test driven development, and automating application build, deployment, and test are absolutely necessary, but they are insufficient to win the argument with senior executives.  The gains they produce are necessary, and impressive.  The operational results have been stellar thus far at HM Health Solutions, per Val:

    • a 67% reduction in resource demands on the release team & process,
    • a 75% reduction in relative hours to repair defects per environment,
    • an 82% reduction in application deployment time.

    Yet as impressive as these operational results are, they are insufficient.  As Val described, arguments about business value, technical value, or improvements to developer or operations staff productivity, alone did not persuade the management.  The magic word is an economic and financial one: “investment”.  Making a strategic investment to improve delivery speed and quality of business applications was the key to winning the hearts and minds of the senior executives.

    In addition to the technical practices described above, Alan asked Val to describe the tools HM Health Solutions adopted.  A continuous delivery solution with application release automation software from IBM UrbanCode was implemented, including application build, deploy, and release.

    As a way of summarizing the webcast for the audience, Alan asked Rick and Val for their two key takeaways; the two most important messages and things to remember.  Rick’s:

    1. Knowing which metrics are critical to your organization.  There are many benefits to adopting DevOps, and many potential hard numbers that are straightforward to capture and measure.  Deciding which metrics have the most impact and are most persuasive to your stakeholders is critical to making the case to invest in DevOps.
    2. Implementing tools and automation: automated testing, and linking that to build and deployment processes and automation.

    Val’s:  Rick’s two takeaways of course!   And one more…

    1. DevOps is new in the industry, and is not yet well understood or common practice in enterprise IT or among its leaders.  Understand your audience, and become good at explaining it in straightforward and clear business and financial terms to senior executives.  Especially persuasive are other client proof points, and the results of pilots in your own enterprise IT environment.  Make sure pilot results show that the solution works and delivers timely business value, and that the related facts and metrics clearly quantify the results.

    Read this blog to know more and Check out other customer proof points/ case studies

    This was a very informative, fast paced, and information rich webcast.  I hope that you find the replay useful in continuing your DevOps adoption journey.

    If you’d like to explore more about management responsibilities and know-how for establishing an ROI for DevOps and app release & deployment automation, see this ROI web page, and read this ROI blog for additional resources on method, approach, making the case, and calculating the ROI.  And please don’t hesitate to reach out to me on twitter: @paspung.

    I look forward to hearing your success stories in making the ROI case to senior executives, and delivering DevOps value to your organization!

    peter signature, small

    Peter Spung, DevOps Deploy and UrbanCode Integration Executuve, IBM Cloud, @paspung

  • Bimodal IT and Remodeling Traditional IT for Greater Agility

    Bimodal IT and Remodeling Traditional IT for Greater Agility

    Bimodal IT is a Gartner concept created to help CIO’s understand that IT organizations need to support both traditional and agile modes of IT solution delivery and operation in order to make wise choices about infrastructure, process, people, and tools.  Much attention has been given and rightfully so to the disruptive and innovative “Mode 2” teams building on the practices established by web-scale giants like Amazon, and Google.  However, in enterprises there still exists a sprawling majority of “Mode 1”, traditional, industrialized applications run by teams that must focus on risk aversion, security and compliance.  While these will likely not match the innovative velocity of agile IT teams and applications, traditional IT teams are still under pressure to get faster, more agile, innovative, productive and cost-efficient.  Yet, the Mode 2 playbook can’t be applied wholesale to Mode 1 transformation work because it often assumes a greenfield situation—kind of like a new home construction.  By contrast, Mode 1 modernization is more like renovating an existing home that must proceed in steps that address the present realities of applications, legacy infrastructure, business mandates, organizational interactions, and technical skills.

    Understanding Bimodal IT

    The Bimodal IT concepts is meant to distinguish between applications and teams that are traditional in their focus, and those that are agile.  In her blog post on Bimodal IT, Gartner analyst Lydia Leong explains Bimodal IT thusly:

    “Traditional IT is focused on “doing IT right”, with a strong emphasis on efficiency and safety, approval-based governance and price-for-performance. Agile IT is focused on “doing IT fast”, supporting prototyping and iterative development, rapid delivery, continuous and process-based governance, and value to the business (being business-centric and close to the customer).”

    The reason that Gartner promotes the idea of Bimodal IT to CIO’s is to help them see that it can be dangerous trying to optimize processes, human resources, infrastructure, and tools to cover such different modes, and as a result, optimizing to neither.  Rather, the right move according Gartner is to allow agile teams room to develop a brand new set of capabilities that can then help transform the whole organization. Lydia continues in her blog:

    “We’ve found that organizations are most successful when they have two modes of IT — with different people, processes, and tools supporting each. You can make traditional IT more agile — but you cannot simply add a little agility to it to get full-on agile IT. Rather, that requires fundamental transformation. At some point in time, the agile IT mode becomes strategic and begins to modernize and transform the rest of IT, but it’s actually good to allow the agile-mode team to discover transformative new approaches without being burdened by the existing legacy.”

    The Contrast Between Agile and Traditional IT

    Traditional IT and Agile IT are different in a number of ways.  Perhaps an effective way to explain the difference is to picture what these applications and teams look like.

    The classic agile IT initiative in the enterprise is around a mobile, e-commerce or web-centric application that is aimed at moving into new markets, improving engagement with new customer segments, or disrupting a current market.  The application is fully virtualized, and the preferred infrastructure is a public cloud such as AWS.  The team is conceived as a unified, DevOps team of line of business product managers, developers, testers, and operations folks working collaboratively on an agile development methodology. Automation is built deeply into the process, with infrastructure as code tools used to manage public cloud virtual machines and related infrastructure components via well-documented RESTful API’s, plus other DevOps toolchain elements automating and managing most processes, including continuous integration, continuous delivery and continuous deployment of code into production.

    Traditional IT stands in pretty stark contrast.  Let’s consider an industrialized, mission-critical application that has evolved slowly for years.  The application (which is usually composed of anywhere from 5 to 10 or more components) is likely running on a mix of legacy (think RISC UNIX), dedicated (x86-based) and virtualized servers (VMWare and perhaps Hyper-V) running in a private or hosted private datacenter, using a mix of traditional and software-defined storage and connected by Ethernet and Fibrechannel switches.  The application components themselves may be legacy code, making them difficult to quickly port to more modern infrastructure.  For example, I was talking recently with a colleague who told me about his sister who still writes code in Fortran for a major bank.    With such a large, complex, long-lived and mission-critical application suite, the IT organization maintaining it and the developers creating updates and upgrades are highly concerned with quality, reliability and predictable performance.  The nature of the overall team working on an industrialized application is a far cry from the sort of “two pizza” DevOps teams on the agile IT side.  Rather, it’s more of a loose consortium of teams such as developers, testers, security and compliance, plus outsourced contractors and vendors.  The development process is waterfall-based, managed by an application lifecycle management (ALM) suite of some sort.   Automation is scant, and in particular it takes a long time to pull together infrastructure for those dev, test and other teams to perform their jobs.  Despite that, a production-like environment for testing, security, compliance, etc. is considered necessary to minimize downtime and other quality risks.  As a result, release cycles can stretch into many months.

    Modernizing Traditional IT

    When my wife and I remodeled our 1908 Craftsman-style house about 15 years ago, we discovered that an earlier renovation had actually cut out a third of a key supporting beam, leaving one part of the house literally hanging on a beam that was only attached to one side of the house.  Needless to say, we were a bit alarmed to find that out.  When dealing with mission-critical applications and infrastructure, you can’t be careless.  As mentioned earlier, simply taking the playbook for a greenfield, agile IT application and trying to apply wholesale it to a legacy, industrialized application usually won’t work.  Making traditional IT more agile requires a step-wise renovation—a risk-mitigated path that leads towards agile and DevOps practices, but without a great leap into the dark.  The steps need to establish the building blocks to agile/DevOps practice without disrupting the application, without introducing downtime, and while delivering solid returns along the way.  Successful legacy application and service ‘remodeling’ efforts observed in highly traditional organizations such as telecommunications and cable operators provides good ideas on how to take those steps:

    • Identify or Procure Automation Skills:  The initial steps to remodeling Traditional IT are about incrementally improving current practice with automation and at the same time making it ready for agile and DevOps.  This means that to be successful, you need to get some automation skills into the mix.  A team that can’t take hold of its own destiny in modernizing a Traditional IT application is not going to have a sustainable change, and that means identifying or procuring some automation expertise and protecting that person’s time to focus on the renovation rather than on firefighting.
    • Private Cloud IaaS:  One of the most serious obstacles to agility is the painful amount of time and effort it takes to allocate and provision infrastructure for developers, testers, etc. and the lack of standardized, consistent infrastructure environments, due to manual processes.  This is exactly the issue that drives some development teams to go shadow IT and start developing on AWS.  Often times, these development teams then discover that integrating that software into the production environment is plagued with translation issues.  Nonetheless, the first order of business then is for the infrastructure team to establish IaaS that can serve up full production-like infrastructure environments to devs, testers and other constituents.  This isn’t trivial when you’re dealing with a combination of legacy servers, bare metal x86, VMs, and perhaps networking, security and other devices.

    The IaaS delivers a number of key improvements.  First of all, it speeds up access because developers, security, compliance and other personnel can now get access to infrastructure in the space of minutes rather than the space of days or weeks.  More than just speed, IaaS enables asynchronous productivity by various teams to happen 24×7, so that quality progresses in an even fashion, unimpeded by office hours.  This is especially helpful if there are global teams, contractors or vendors involved.  IaaS also provides standardization and consistency across all efforts.  Finally, IaaS saves costs.  Significant amounts of operations personnel time that was devoted to painstaking manual infrastructure assembly can be repurposed to higher value activities, and infrastructure utilization rates can easily double or triple almost immediately, which reduces the need to purchase more capital equipment.

    A word here about GUI’s.  One of the key notes of dissonance that often occurs is when people hear developers say that they don’t want GUI’s, they want API’s.  That in my view is absolutely valid, but more so for Mode 2 Agile IT teams.  It turns out that IaaS GUI portals can be rather helpful in providing an easily understood reference point to multiple teams that may have highly varying understandings of the end-to-end picture of the application and its infrastructure.  For example, if an IaaS self-service portal provides a full visualization of the end-to-end infrastructure involved, a developer who might assume that latency is always near zero might become more aware that there is a WAN in the middle of the end-to-end infrastructure.

    • Test as a Service:  Many development and testing teams have taken some stab at test automation.  However, test automation tends to live and be maintained at the individual level.  The natural follow-on to IaaS is to build a standardized regression or certification of automated tests that can be offered from the IaaS portal—test as a service (TaaS).  This allows teams to access production like environments, do their development work, then easily launch a comprehensive certification test.  Tests naturally should report their results into the ALM tool so that individuals and teams can review results in near real-time to keep the process moving.  The benefits are similar to IaaS:  increased velocity, standardization, productivity and efficiency.
    • DevOps Evolution:  With a combination of IaaS and TaaS, the stage is now set to deploy a DevOps toolchain and start doing cross-functional technical collaboration, and agile methodologies.  For example, the IaaS and TaaS can be launched by a unified continuous integration server upon software development check-ins from any team.  Of course, DevOps doesn’t just mean tools and automation, but the process of coming around collaborative devtest infrastructure and common certification tests to build a common, agile development practice is one of the steps towards a more broadly responsive cycle.

    Conclusion:

    Traditional IT may not be the sexiest beast in the technology forest, but it’s often mission-critical.  Gartner’s Bimodal IT concept encourages CIO’s to let go and let Mode 2 Agile IT teams do their thing to create new culture and practices.  Translating that to Traditional IT requires a more step-wise approach.  Progressing from manual processes to IaaS to systematized, self-service test automation as the foundation for DevOps evolution is a sound way to proceed.  With these steps. Traditional IT can “do IT right” and do IT faster.

    About the Author/ Alex Henthorn-Iwane

    AlexAlex Henthorn-Iwane joined QualiSystems in February 2013 and is responsible for worldwide marketing and public relations. Prior to joining QualiSystems, Alex was vice president of marketing at Packet Design, Inc., a provider of network management software, and has 20+ years of experience in senior management, marketing, and technical roles at networking and security startups.

    Through his roles at QualiSystems, Packet Design, CoSine Communications, Corona Networks and Lucent Technologies he has acquired expertise in cloud computing and the opportunities presented through virtualization. He has written for Embedded Computing, Virtual Strategy Magazine, Datamation, SDN Central, Datacenter Knowledge and InformationWeek.

    Connect with him on LinkedIn, Twitter, or SlideShare.

  • The Simple Math of DevOps

    The Simple Math of DevOps

    We are living in an information- infused society, much dependent on various technological innovations taking place all around us. In such conditions, as consumers become more connected, they are empowered with more information and choices. They expect quick and consistent information available at all times. Likewise, our business leaders expect their IT teams to build relevant applications and stay ahead of their customers’ needs with an excellent customer experience.

    My IBM colleagues and I have been working very closely with major enterprise clients as they begin their DevOps transformational efforts. We’ve found few key points and messages that resonate very well with decision makers who need to set a new course for their teams in the wake of impact from mobile, big data, analytics, cloud, and the Internet of Things technologies.

    So what is it about DevOps that is so appealing? First and foremost is the notion that DevOps is all about attaining Speed to Value. Speed is king right now because so many of the business leaders we work with are under the gun to deliver value as quickly as possible. Yet, because of the high cost of technical debt they have come to a state where speed has to be sustainable. It’s no longer easiest to go outside their organizations for the high priority key projects as mobile applications were done recently. They need a holistic approach that builds on their existing capabilities.

    Well what does that have to do with math? Here’s the thing, everyone is trying to minimize the time it takes to deliver value and attain feedback.   We can think of the Time to delivery as the following equation.

    TDELIVERY = TPLAN + TDESIGN + TDEVELOP + TBUILD + TDEPLOY + TTEST + TFIX + TRELEASE + TEVALUATE

    In an optimal world or software factory that is fully automated the TDELIVERY is optimized by minimizing the time for each of the tasks required to complete the delivery. Most organizations follow a SDLC that is based on this simple math. They estimate the time to do each part and then the total project plan is the sum of the parts. Further, they tend to define work in relatively large chunks or big-up-front style of work definition which inherently increases the time for each task (TX). As a result, the industry has about a 50% (or worse) failure rate when it comes to completing a project within the estimated time. That causes a lot of hardship because the business can’t count on IT to deliver value to customers in the projected time frames let alone with speed.

    Because application delivery is a set of very human oriented tasks, a key factor that will determine the speed to value is TRUST. It’s pretty obvious when you draw out the value stream mapping of how work gets done at a given customer site. As members of software delivery teams lose trust in the validity of the work as it flows through the lifecycle then a large amount of rework and waste is introduced. In mathematical terms our equation becomes:

     

    Lee Reid Blog equation

    That is, the Tasks we do in a delivery cycle are impacted by the degree of trust we have in the hand-offs from one to another. If we have zero trust then our TDELIVERY will be infinite (divide by zero). 100% trust and our TDELIVERY will be only limited by how fast each task can be performed.

    Check this scenario that represents what we’re hearing from our clients in the workshops:

    “On a given project team the plan has about a 50/50 chance of being right, and the design is about 85% right, and the developers will get about 90% of the implementation right, and the testers have about 90% of the test cases right, and the release team has about 95% reliability of having the right stuff together to release, then your trust factor is something like

    .5 x .85 x .9 x .9 x .95 = 32% Trust”   (and that’s much better than what we usually hear)

    Ouch! That’s a 3x multiplier of the time it’s going to take no matter how fast we do all the delivery tasks.   In other words, we’re always limited by our trust factor. That multiplier comes into play with additional tasks we have to add into the equation to counterbalance the lack of trust. Then our equation becomes something like this:

    TDELIVERY = TPLAN + TRESCOPE + TDESIGN + TARCH REVIEW + TDEVELOP + TTECH DEBT + TBUILD + TREBUILD + TDEPLOY + TREWORK + TTEST + TRETEST + TFIX + TREFIX + TRELEASE + TROLLBACK + TRE-RELEASE + TEVALUATE

    And that’s the issue our customers are facing today. There are a lot of wasteful tasks, checks, and balances that have crept into our delivery process due to lack of trust.

    So, how does DevOps help this problem? It’s simple really; the DevOps approach is to attack the TRUST issue head on while simultaneously reduce the task time (Tx) in order to shorten the overall time to delivery. For example, if we apply a DevOps practice of breaking work up into small chunks, getting it out to users early, and getting the feedback, we can immediately impact the overall TDELIVERY. That’s because we’re positively impacting the numerator and denominator with that practice. That is, by limiting the scope we make it easier to understand, less effort to transform to working code, test, and deploy, sooner to obtain feedback, and more likely to know if we’re on the right track.

    Likewise for other practices!

    The key is finding the balance of what practices to apply to maximize this equation for a given organization and their current bottlenecks & wastes.

    DevOps practices address with three main impact points:

    Speed to Value depends upon TRUST

    TRUST is enabled by:

    1. Clarity: A clear definition of desired outcome(s)
    2. Collaboration: Team-wide communication and visibility
    3. Consistency: Systematic and repeatable steps

    When a team can master these three elements the time to perform each task will shrink and degree of TRUST will increase. DevOps practices impact these trust building elements:

    Clarity:

    • Break work up into smaller chunks and iterate
    • Seek a minimum viable product (MVP)
    • Define clear outcomes, ‘sponsor’ users, and playback (Design Thinking)
    • Reduce dependencies with loosely coupled architectures (containers, micro services, SOA)

    Collaboration:

    • Form cross functional teams (end to end)
    • Use big visual radiators
    • Have a ‘single source of truth’ for all development assets – Requirements, Code, Deployable Assets, Infrastructure as Code, etc
    • Be transparent with metrics
    • Plan and reprioritize frequently
    • Actively seek user feedback

    Consistency

    • Automate, automate, automate
    • Continually improve by replacing manual tasks with automation

     

    Speed to Value will be enabled by eliminating those bottlenecks and waste that have developed due to lack of trust. The key for organizations is to recognize that the current practices are maxed out and not sustainable when trying to move at higher speed. There’s a perfect storm amassing with big data, analytics, cloud, mobile and IOT that will either drive customers to make a DevOps transformation quickly or be a victim of the storm. Try using this simple math to help organizations understand how to move ahead and how our IBM solutions can be applied to attain speed to value.

    This year I have had the great experience to work with our DevOps CTO Sanjeev Sharma, our customer thought leaders such as Carmen DeArdo of Nationwide, and our field teams around the world addressing DevOps transformations. Sanjeev, Carmen and I decided to summarize our experiences in a three part blog. This is the first of that three part series.

    To learn more about IBM’s DevOps approach, check out www.ibm.com/devops. Also, watch the replay of a recent webcast on Variable Speed DevOps, I had a chance to present on, with Sanjeev Sharma and Carmen DeArdo.

    About the Author/ Lee Reid

    Lee ReidLee Reid, Senior IT Specialist, IBM, is a senior solution architect with focus on practical adoption of software engineering tools, software delivery solutions, application life cycle management, and DevOps. He has over 25 years of experience in software engineering, design, programming, testing, development, tools & methodology, team leadership, and strategic planning.

  • Follow the Unicorn: Transform your Enterprise Applications

    Follow the Unicorn: Transform your Enterprise Applications

    For those of us that work on Enterprise Systems such as the mainframe, the claims that the Unicorns (1) make, can be pretty astounding. Dozens and sometimes hundreds of releases a day from big companies like Netflix (2) and Etsy (3) are hard to comprehend. But look a little closer and you can see that the key difference is in the way changes are released to customers, not so much the total volume of changes. A traditional enterprise application may have thousands of changes made over the course of 3 to 6 months, but all of those changes are released at once. The Unicorns are typically able to release a very small number of changes at a time because they can develop, build, test, and deploy these changes very efficiently. Small batch releases to customers has significant value. It enables you to get feedback very quickly, and it is significantly easier to verify because the change is not mixed in with other changes.

    So how can you transform your development environment to deliver small batch of changes? I like to tackle the problem like any other computer science problem, no doubt because of my background. Break the large problem into a set of smaller problems and then solve those smaller, less daunting problems:

    Step 0: Start with a Proof of Concept

    Pick a Proof of Concept (PoC) to begin with that is important, but not mission critical. The PoC can be used as a learning ground and hopefully as a template for subsequent PoC’s. Make sure you have a team that culturally is willing to transform. Often the hardest issues to tackle have nothing to do with technology, but are cultural.

    Step 1: Understand your Application

    You need to have a good understanding of what your application consists of. Not only does the source code make up the application, but what source files are used, what the middleware configuration might be, what scripts you may have to build and deploy the application, and what data files (e.g. flat files, databases) that you use are also important. Some of these components may be shared with other applications, so you need to understand those dependencies as well. Once you have a good handle on the application, you can then automate the application build and deployment process so that all members of the team can work efficiently.

    Step 2: Understand your test cases

    If you can build and deploy the application quickly but it still takes days or weeks to test, then testing prevents you from delivering to your clients. An important shift for testing needs to be from testing the entire application to testing the change. You need to focus on running the right tests to ensure the change is correct and causes no regressions. Tests that do not exercise the code change are irrelevant and can be skipped. For many existing applications, the test suites may consist of hundreds if not thousands of test cases. Many of those test cases may be duplicates or testing areas of the code that are not being changed.

    Step 3: Understand your processes

    How fast can you get your updates to your customer? If your bug fixes and enhancements have to sit on the shelf for days, weeks or months before the customer gets them, they will not be satisfied. Streamline not only the development processes but the operations processes in your organization.

    To know more about the topic with the help of a real life case, watch the replay of a recent webcast which IBM in partnership with devopsy.kinsta.cloud hosted with Canada Mortgage Housing Corporation’s Jeff Blackadar on how breaking down IT silos helped speed up mainframe development for them.

    Also, do let me know your thoughts on the blog and on the topic.

    1 the born on the web technology teams

    2 http://www.slideshare.net/jedberg/devops-at-netflix-reinvent

    3 http://www.slideshare.net/beamrider9/continuous-deployment-at-etsy-a-tale-of-two-approaches

     

    About the Author/ Mike Fulton

    MikeFaceMedium-150x150A IBM Distinguished Engineer, CTO Enterprise DevOps at IBM,  Mike is a software development professional specializing in compilers, debuggers, profilers and virtual machines. At IBM, Mike works towards understanding and influencing trends and directions in Enterprise IT delivering new technologies into the DevOps Portfolio. He also overlooks integration of the DevOps Portfolio into IBM and Enterprise Software Solutions. Mike is an IBM Master Inventor with several patents to his credit.

    He is an avid blogger and regularly writes on his blog site – makingdevelopersliveseasier.wordpress.com

    linkedintwitter

  • Webinar: Build, test and deploy mobile apps with back-end mainframe services securely in a hybrid cloud

    Webinar: Build, test and deploy mobile apps with back-end mainframe services securely in a hybrid cloud

    You may already have a good understanding of the hybrid cloud and its benefits. But how do you get the value of the last three decades of investment in your backend infrastructure into the hands of your end users faster?

    In this webcast we will demonstrate how you can take advantage of the latest IBM technologies to quickly and easily incorporate your backend services into your mobile applications running on IBM Bluemix. We will also highlight the latest capabilities of IBM DevOps Services (IDS) and IBM Bluemix that support the end-to-end mobile development lifecycle.

    Join Kristal York, Executive Mobile Strategist, PointSource an IBM Business Partner and Rosalind Radcliffe, Distinguished Engineer, Chief Architect for CLM and DevOps as they take you on an in-depth tour of the IBM DevOps Services and Bluemix, an open-standard, cloud-based platform for building, managing and running mobile apps that connect with your back-end services securely.

     

    Recorded Thursday, June 25, 2015

    VIDEO

    SLIDES

    [seoslides embed_id=”2e765888697b” script_src=”https://devopsy.kinsta.cloud/embed-script/build-test-and-deploy-mobile-apps-with-back-end-mainframe-services-securely-in-a-hybrid-cloud/7999/” overview_src=”https://devopsy.kinsta.cloud/slides/build-test-and-deploy-mobile-apps-with-back-end-mainframe-services-securely-in-a-hybrid-cloud/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”Build, test and deploy mobile apps with back-end mainframe services securely in a hybrid cloud” /]

    Your Host:

    alan_new_head_shot Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

    About Panelists:

    kelly-ibm-devops

    Kristal York, Executive Mobile Strategist, PointSource an IBM Business Partner

    Kristal joined PointSource in 2012 and has led teams in the financial, retail and insurance verticals. She excels at fostering a collaborative environment and leading others to solve complex business problems.  Kristal’s prior experience as a business analyst has helped as a mobile strategist to define and analyze our customer’s mobile moments. She translates those mobile moments into a mobile strategy across the organization’s business processes and systems.  Mobile demands an iterative approach so Kristal helps analyze strategic planning, usability, research, as well as consistent updating.  She uses her business analytics skills to help define adoption rates and sentiment analysis once the app is launched.  Previously, Kristal was at Cartus for 12 years, most recently Senior Business Analyst, Business Analytics and Mobile Product Owner.

    RosalindRosalind Radcliffe, Distinguished Engineer, Chief Architect for CLM and DevOps, Member of the Academy of Technology

    A Distinguished Engineer within the IBM organization, Rosalind is Chief Architect for CLM and DevOps. She is responsible for driving the DevOps for multi-platform architecture; this includes System z and Power system.