Tag: DOES

  • DOES 15 – The 7 habits of successful DevOps

    DOES 15 – The 7 habits of successful DevOps

    Dipping back into the DevOps Enterprise Summit 2015 well, today’s feature is my talk with Sam Guckenheimer of Microsoft.  Sam presented on the transformation he oversaw at Microsoft’s Visual Studio moving to Visual Studio Online. It is the story of COTS to SaaS and all of the pitfalls and idiot taxes Sam and team paid along the way. 

    From this ordeal Sam and his team developed the 7 habits of successful DevOps. Like my earlier interview with Jeff Snover, it is a great peek into how things have changed in Satya Nadella’s Microsoft.

    Here is Sam’s complete presentation at DOES 15. Just a heads up that it is about an hour long, but I think well worth the time.

    If you like what Sam is talking about and want to learn how the 7 habits of successful DevOps can help you lead the transformation in your organization, stay tuned for podcast I just recorded with Sam that will be in our leadership suite next week. In the meantime you can download and find out more about Sam’s 7 successful habits here.

  • DOES 15 videos – Adrian Cockcroft

    DOES 15 videos – Adrian Cockcroft

    At this years DevOps Enterprise Summit we were very happy to partner with Gene Kim’s IT Revolution and Electric Cloud to conduct on site interviews with just about all of the speakers from this years conference, as well as many other attendees. All in all devopsy.kinsta.cloud conducted something like 86 video interviews over the 3 days of the Summit.

    Over the coming weeks we will be highlighting some of the best of the best here for you. We will present them in different formats.Some will have commentary around their sessions, others will feature background info on the topic and speaker and finally we will have updated info for some of the others.

    In that vein I wanted to lead off the series with this interview of none other than Adrian Cockcroft of Battery Ventures and formerly Netflix. My conversation with Adrian touches on really just three questions:

    1. What was his presentation about: Systems integration or systems thinking. It offered an inside look at the Netflix culture and talent density.
    2. what did he think of DOES 2015 – Adrian is on the program committee though by his own admission he was a bit pre-occupied on other business this year to help too much. But like many who attended Adrian is was really impressed at how deep the penetration into different verticals were.
    3. What does he see in the next 3-5 years for DevOps? Adrian says that companies that don’t adopt DevOps ways run the risk of disappearing.

    if the short 7 minute interview above wasn’t enough, here is Adrian’s complete session at DOES 15 (warning it is 31 minutes long)

     

  • 7 Sets Of DevOps Success Metrics From DOES ‘15

    7 Sets Of DevOps Success Metrics From DOES ‘15

    Beyond the moral support, the executive management coaching and the tips on how to build DevOps momentum in the enterprise environment, last week’s DevOps Enterprise Summit 2015 offered a boatload of excellent fodder for those seeking to prove the value of DevOps patterns once they got back home.

    DOES wasn’t just about cheerleading—alongside lessons on the soft, squishy elements of transforming IT, nearly every speaker offered up stone cold numbers to back up why those transformations make business sense. The performance metrics shared by speakers were impressive and could go a long way toward swaying skeptical stakeholders. Here are some of the highlights.

    Ticketmaster

    Ticketmaster CTO Jody Mulkey offered a ton of excellent examples of how an organization-wide commitment to DevOps has fueled innovation and stability at his company. For example, he described how what Ticketmaster calls the ‘Boom Team’ has used a completely integrated team of devs, operations, QA and other staff of about 20 to shift its Ticketmaster.com property—which accounts for 40 percent of the company’s revenue—from a duct-tape and bubblegum affair with 2000 ModPerl at its base into a modernized system continuously delivered by that team. Similarly, its technical operations team has embraced the DevOps ethos in order to deliver what it calls ‘support at the edge’ for WebOps incidents. The success of this approach has resulted in:

    • 90 percent reduction in mean time to repair (MTTR)
    • MTTR from 47 minutes down to 3.8 minutes

    “This was a phenomenal change,” Mulkey says. “The business went crazy over this. These are measurable outcomes that have really helped demonstrate that we are making progress.”

    Target

    Target brought forward speakers to discuss the retailer’s innovation in a number of key areas. Heather Mickman, director at Target, talked about how her API team worked hard to not only easily expose product and store information via its APIs, but to also challenge itself in the way it was delivering its work.

    “We wanted to deliver new capabilities in days and not months,” she explains, saying the team needed to be sure that it could scale its APIs because it new that they would be highly reused—both internally and by partners. Target has:

    • more than 90 APIs
    • monthly volume of calls to these APIs have grown in one year from 1.5 billion to 17 billion
    • deploy 80x per week across stage and production enviornments
    • all that, with fewer than 10 incidents per month
    • this volume helped support in 2014 a 42 percent increase in guest traffic and 280,000 orders fulfilled on Black Friday alone

    HP

    HP CIO Ralph Loura says HP didn’t go for the big bang approach, but through careful pilots and the use of communication afforded by ChatOps infrastructure, his team has been able to drag HP IT slowly into the DevOps fray. That’s a good thing, considering the massive scale of the organization:

    • 7,000 developer and operations staff
    • handling over 20,000 change requests per year
    • supporting 1,400 apps
    • and 1000s of builds per day

    CapitalOne

    After four years of hard work to move toward DevOps and continuous delivery, CapitalOne Product Manager Tapabrata Pal had a number of impressive statistics to share on its its progress:

    • Code commits have moved from random occurrence to hundreds per day for any given product team
    • Integration has moved from 1 per day to every 15 minutes
    • QA performance has shifted from monthly to four times per day
    • Production releases have moved from quarterly to one per sprint
    • Defects have been reduced by approximately 60 percent
    • Feature delivery rate has increased by approximately 50 percent

    CSC

    Paula Thrasher, application delivery lead with CSC, stepped up in front of the DOES audience to show them how it is possible to battle bureaucracy at any organization—coming from the government sector, she has first hand knowledge of what it takes. In one example she shared, her organization helped a client move its cyclew time from automating deployments to staging:

    • from 12 hours down to just 12 minutes and 30 seconds.

    IBM

    IBM’s Angel Diaz, VP of cloud architecture and technology, talked about how enterprises can still innovate at the pace of startups while delivering at scale. The thing with IBM is that it puts its money where its mouth is when it comes to DevOps—the company has doubled down to not only offer a number of products viable for the continuous delivery pipeline but to also completely transform its own business through DevOps practices. Some of the results it has seen by shifting its 2,000-plus developers and 100-plus squads in the Cloud Services division to DevOps:

    • 300 percent increase in “pure coding time” for its Cloud Services developers
    • reduction of deployment time from 32 hours down at first to 6 hours and now to minutes
    • an increase of release frequency from months to every three weeks.

    Disney

    Disney’s Jason Cox, director of systems engineering, got the crowd pumped up with a slick mash-up video of Star devWars and DevOps themes (not to mention a private showing of the most recent Star Wars trailer at the end of his talk!). But he didn’t favor style over substance. In his talk he described how much success Disney has grabbed up through DevOps, including:

    • 75 percent reduction manual steps
    • reduction in deployment time for large online/digital experience systems from 3 hours to 20 minutes
    • ability to provision 300-700 srvers within 15 to 30 minutes
  • 5 DevOps Success Factors Surfacing At DOES 15

    5 DevOps Success Factors Surfacing At DOES 15

    Two days into a breakneck schedule of energizing presentations at DevOps Enterprise Summit 2015 (DOES 2015) and  there are already some common themes bubbling up from the speakers and attendees. As IT practitioners from big name enterprises like Capital One, HP, Target, Ticketmaster and more step up to the podium to share their personal stories about the journey to continuous delivery, they’ve proven that their transformations rely on similar success factors.

    Success Factor: DevOps Champions

    DevOps change agents and champions are the engine that can help turn an enterprise IT ship around. And while it will eventually take a lot of people to power a large organization’s shift to DevOps, the passion and vision of a single DevOps change agent is contagious—particularly when they can demonstrate and document the results of new process patterns.

    “One person can make a difference,” says Sherry Chang, chief architect of DevOps and continuous delivery with Intel, who says when she first started helping her firm in its transformation, she had no formal DevOps title or role, but she believed strongly that changes needed to be made and was determined to drive them. She says she connected with others to start small and spread the DevOps gospel.

    Success Factor: The Yin/Yang of Grassroots/Executive Support

    Building DevOps momentum can’t depend solely on support from the bottom up or the top down. Those experienced in walking the DevOps path say that buy-in must come from both sides of the coin to truly transform the business.

    Most transformations tend to start at the grassroots level—that’s what those champions are especially good for kick starting—because risk-averse executives tend to like to grab onto new initiatives that already look like potential winners.

    “Those change agents are important in the early days because they can demonstrate success, which then helps to start growing a grassroots movement, where more and more passionate folks start to get bought into the different changes that are being talked about, and then that got us to gain our tops-down buy-in,” says Heather Mickman, director at Target.

    Success Factor: Internal DevOps Events

    Many of the biggest enterprises that shared their stories explained that a key component of the culture shift at their organization has been some sort of large-scale internal event—essentially in-house DevOps conferences. These events give DevOps champions the chance to bring in outside thought leaders and practitioners at other companies to demonstrate to people within the host enterprise that there really is something to DevOps, automation, continuous delivery and the like. For example, CapitalOne recently hosted more than 1,200 software engineers for an in-house event it calls SECon and brought in many of the same speakers we’re seeing this week at DOES.

    Target has also hosted numerous internal DevOps days, as well as an executive summit that Ross Clanton, senior group manager at Target, called a “tipping point” for gaining top down support from executives.

    Success Factor: Empowerment

    Giving staff the tools the need to do their job and then getting out of the way to actually let them do it has been another common theme weaving its way through DOES talks.

    “Teams crave responsibility,” says Jody Mulkey, CTO at Ticketmaster. “Folks on our development teams, they all want responsibility to run their products. They didn’t all want it in the beginning, to be quite honest. But once they saw how quickly teams were able to deliver and how they were able to minimize these business disruptions based on the ability to quickly make changes to their software, it was pretty incredible.”

    He says of the 73 development teams at Ticketmaster in North America, 100 percent push their own code.

    Success Factor: Test Automation

    Time and time again, presenters have called out the importance of test automation in eliminating waste and idle time in the development lifecycle and elevating the process. On Monday, there was a whole panel dedicated to the topic with representatives from Intel, Quicken Loans and Bluware talking about how to scale this across the enterprise. And as Paul Schmid explained in his description of the DevOps transformation at Sherwin-Williams, like many organizations, his has been learning the hard way that test automation ideally should be one of the first steps to shifting gears to continuous delivery.

    “Tests for us are really important, and we are not mature in this at all. So a lot of what was talked about this morning hit right at home,” he says. “Testing is really important and it’s definitely the next step for us, and we’re putting a lot of time, effort, and money into it.”

  • Live blogging DOES 2015

    Live blogging DOES 2015

    We will be live blogging from DOES 2015. Ericka Chickowski and Alan Shimel are live at the show in case you can’t be here yourself.

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

  • DevOps for Systems of Record – A new hope (Preview of DOES talk)

    DevOps for Systems of Record – A new hope (Preview of DOES talk)

    I am speaking at the DevOps Enterprise Summit later in the month and thought I give people a teaser of what I am going to talk about, so that they know what to expect. I am looking forward to share my story – a story of adversity but also of hope – with many of you. (See me on Wed, 21st October at 11:15 at the Bayview B)

    So we have all heard about the DevOps and Continuous Delivery stories from our favorite Web companies (Google, NetFlix,…). It is much harder to come across successful case studies with Enterprise-grade Systems of Record. While I cannot provide the 50 times a day deployments for SAP (yet ;-)), I wanted to share my story so far and what I have learned in the journey (both in regards to solved and unsolved issues).

    Hopefully this contribution to the discussion helps some of those out there who are looking for a first step. But why should we even deal with COTS and other systems of record? Ultimately for me this comes back to the two gear analogy that I keep using (Two Gear Blog Post) . If you can just ditch your “legacy” applications completely, then congratulations you don’t have to deal with this and can probably stop reading this blog post. For all of you out there that cannot do that, you will be confronted with the reality that even though your digital and custom applications can deliver at amazing speed you are still somehow constraint by your “legacy” applications. Hence speeding up those will help you achieve the ultimate terminal velocity of your delivery organisation. So how do I approach Systems of Record and the DevOps adoption of it?

    DOES1

    3 Key steps:

    1. Look under the hood to find the ingredients
    2. Recreate the IKEA manual
    3. Understand the path to production/operations

    Step 1.  Let’s open the Hood

    DOES2Ultimately the two things that I am always looking for are the moving parts of the application and the processes to build and deploy the application. Sounds easy, right? Well it often isn’t as easy as you think, especially COTS application try to abstract those processes away. Look at SAP where you make configuration changes in one environment that then somehow get transported to other environments, but you have little visibility into the underlying process (Ok – my SAP experience is 10 years old, so it might have changed, but you get the gist).

    Why do we look for moving parts? Well we want to use the common software engineering practices as much as we can and don’t necessarily want to trust the inbuild features for version control for example. So we look for ways to find the source code files or ways to extract the relevant information in text format (well SQL, XML, etc count as text in my world view), this is sometimes relatively easy (Siebel .sif files are just a type of XML for example) and sometimes it is pretty difficult or impossible. These underlying files is what we will store in source control to make sure we understand at each point in time the configuration of the application.

    Once you have found the source code, you will have 3 things to do with it:
    a) Get it out of the proprietary solution
    b) Integrate it with your IDE
    c) Solve for Merges
    (I will explore this further in another blog post later)

    Step 2. Recreate the IKEA Manual
    DOES3Once you have all the moving parts, you need to understand how it all fits together. Custom applications usually require explicit instructions which makes it much easier to define and automate the instruction set. For systems of record packaging and deployment is often done through UIs and there is usually more than one way of doing it. Experienced operators have found their own short cuts and the reliability of the system depends on having the right guy in the operating centre (I have some stories to tell about not having the right guy on go-live weekend).

    Your goal needs to be an “Ikea Manual” that creates the system from the moving parts we identified earlier without requiring complex interactions or decisions from human operators. Ideally all instructions work from the commandline or some programming API, but when all else fails a UI driver like Selenium can solve the really tricky parts of creating and automating the manual user entries in the application. Every black-box step should be drilled open so that you understand what is happening within the system and so that you understand the variations that could cause you trouble down the path.

    Step 3. Understand the Path to Production
    does4Speaking of paths…Of course for systems of record the same rules apply as for any other system. You should practice the exact things that you will do to establish the system in production in all previous environments and minimise the difference between configurations. The challenge for systems of records is often the cost associated with production like environments So you might have to look for creative ways to minimise the difference and to parameterise configurations so that you can at least automate for the differences.

     

    So all is good in Mirco’s land of the Systems of Record?
    Unfortunately not, there are still many challenges that I am working on. The progress we have made so far allowed for a step change in velocity and reliability, but there are still areas that I want to find better solutions for:

    • Unit test automation
    • Unsupported activities or no API
    • Performance
    • Configuration Management skills – the curse of the configurators
    • Common Objects
    • Operations – the last mile…

    I will speak at much more detail about my experiences at the DevOps Enterprise Summit, if you are attending, come say Hi. I am always happy to show you the scars of working with Systems of Record and share war stories.

    And for two “legacy” technology stacks that I have done extensive work for (Siebel and Mainframe ) I promise to write more in-depth blog posts in the future.

  • The Women of DevOps

    The Women of DevOps

    No, this isn’t about some new calendar featuring scantily clad IT chicks. In fact the fact you even thought that is half the problem. This article arises out of the fact that I was speaking with a colleague the other day and once again had to regretfully recite that something like 95% of you reading this article are male (as well as every other article here).  Why is this? Why aren’t there more women in DevOps specifically and IT in general?

    Don’t get me wrong this is not a DevOps specific issue. We go through the same issue in the infosec realm as well. In spite of the fact that many trade mags in security have featured prominent woman in security and many security conferences have featured panels and discussions on this. The good news is slowly but surely this is starting to change. We are seeing more woman in the infosec world.

    So lets take that strategy from infosec and lets use it for DevOps.  Lets feature some prominent woman in the DevOps world.  I want to emphasize that these woman are here not just because they are woman and not men, but irregardless of their sex, they are remarkable people worthy of the recognition.

    Also before we get started, let me say that I compiled this list based upon people I have met, heard or read about. I don’t know all of these woman personally, though many of them I have met. Feel free to comment and add your favorites and choices.

    So here is my first list of the women of DevOps:

    1.

    bridgetBridget Kromhout is a Principal Technologist for Cloud Foundry at Pivotal. Her CS degree emphasis was in theory, but she now deals with the concrete (if ‘cloud’ can be considered tangible). After years in site reliability operations (most recently at DramaFever), she traded in oncall for more travel. A frequent speaker at tech conferences, she helps organize the AWS and devops meetups at home in Minneapolis, serves on the program committee for Velocity, and acts as a global core organizer for devopsdays. She podcasts at Arrested DevOps, occasionally blogs at bridgetkromhout.com, and is active in a Twitterverse near you.

    So that is the official bio (from her speaking appearance at Velocity). I only met Bridget in person recently but have been a fan for a long time. From her leadership in turning the DevOps Days MSP into one of the best in the world, to designing the DevOps against humanity cards and just the respect she gets from her peers in the DevOps community she is worthy to be the first person on this list.


    1. julie tsaiJulie Tsai,
      here is her official LinkedIn bio:Director of Engineering, Information Security for retail giant. Technical Operations leader and Systems Architect with proven decision-making and managerial ability. Experienced as CISO reporting to CEO, and concurrent Ops/IT head, for privately-held $100 mm Internet Advertising company with Fortune 1000 clients. IPO-readiness audit response; PCI,GLB compliance; SOX significant deficiency remediations; forensics experience. Ops due diligence representation; post-transaction department merging; deep budget cutting. Contract negotiation and budget optimization. Change management, incident management, uptime and DR/BC. Developed intuition for “what’s going to break next.”

    Notwithstanding the above, I couldn’t wait to add Julie Tsai to this list. She presented at our DevOps Connect: DevSecOps at RSA Conference last year (8 months pregnant and all) and just blew me away. She was so bright it was like a shining star up there on the stage. Her accomplishments speak for themselves. To me she represents the kind of person I would want my daughter or son for that matter to grow up and be professionally.

    3.
    helen
    Helen Beal
    , fanatical about making life on earth fantastic – with nearly 20 years’ experience working with companies to elicit real business value from software, Helen heads up the DevOps practice at Ranger4 focusing on how organisations can embrace DevOps philosophies to influence their IT culture and behaviours and implement tools for change. Helen is also a bibliophile and fond of llamas.

    The first person on this list that I also consider a personal friend, Helen has become a DevOps evangelist bar none over in the UK and beyond. She is constantly appearing, speaking and evangelizing on behalf of Ranger4 while organizations should adopt DevOps. She has also developed several DevOps workshops and lift offs.  If you get a chance you should catch Helen at a DevOps event near you.

    4.

    terri_potts1Terri Potts is an Engineering Fellow at Raytheon where she is the Information, Intelligence and Services Business Software Technical Director. She has worked at Raytheon since 1998 and has been an advocate and champion for modern software development methods since 1999. Her current professional interests include software and systems architecture, model driven software development, domain specific languages, software product lines, software factories and DevOps. Terri has been successful leading adoption of DevOps on Raytheon programs. Prior to working for Raytheon Company, she served eleven years in the United States Air Force in all phases of software acquisition and development of defense systems.

    Another speaker from last year DevOps Connect: DevSecOps at RSA Conference, she is also speaking at DOES next month. Terri is a dynamic individual who is spreading the DevOps gospel in the federal market and is smart enough to relate the story as a lesson for us all. Terri is a true leader, man or woman in the DevOps world.


    1. HeatHeatherMickmanher Mickman
      is the leader for the API and Integration team at Target and a DevOps enthusiast. Throughout her career, Heather has continuously embraced hard technology challenges from consulting large Fortune 50 companies on Supply Chain approach, implementing warehouse automation technologies, running large Ops & Support organizations, and establishing enterprise security approaches. She has a passion for technology, building high performing teams, driving a culture of innovation, and having fun along the way. Heather lives in Minneapolis with her 2 sons and 2 dachshunds.

    Taking the disaster that was Target IT and using it as a tool for transformational change via DevOps is worthy of all of our praise. If you get the chance to hear how Heather has helped lead this transformation (another DOES speaker) you should not miss it. Interesting note is how many large retailers have adopted DevOps successfully. Somewhat of a little known secret, but retail seems to be a prime vertical for DevOps adoption.

    6.
    Rosalind-Radcliffe1Rosalind Radcliffe is a Distinguished Engineer within the IBM. She is Chief Architect for CLM and DevOps. She is responsible for driving the DevOps for multi platform architecture. This includes z System and Power system. In addition she is responsible for the architecture for the Collaborative Management capability for Enterprise solutions. This includes UrbanCode Deploy and Rational Team Concert’s support for standard Mainframe development activities. She is a member of the IBM Academy of Technology and a Master Inventor. Prior to Rational, she was in Tivoli responsible for the SOA Management Strategy for IBM.

    Another person I have met in person and interviewed several times here on devopsy.kinsta.cloud.  Rosalind’s CV is beyond impressive. Speaking with her though you know you are in the presence of intelligence.  I enjoy speaking with her and reading what she writes. She recently wrote Mobile to Mainframe DevOps for Dummies as well.  Rosalind is a real thought leader in every sense of the word.

    These are my first 6 women of DevOps. I will add to this list in the weeks ahead.

  • DOES15 – A Focus on DevOps Execution

    DOES15 – A Focus on DevOps Execution

    “I recently attended my second DevOpsDays, and even one year later I noticed that the audience had changed a lot” – says Travis Cunningham a Software Engineer at SmartFile during an interview about their development environment. What Travis is speaking to is the fact that DevOps has matured dramatically in a short amount of time. Around two years ago the community was a members only club. It consisted of the innovators, and smaller organizations who could adopt DevOps in one fell swoop. But now the benefits of DevOps are shared objectives for most organizations.

    (more…)