Gene Kim and Red Hat IT Part 2: The Importance of Partnership in DevOps
This is part two of a four-part series on DevOps with Gene Kim and Red Hat IT’s Inception Team.
- Part 1: Getting DevOps Off the Ground
- Part 2: The Importance of Partnership in DevOps
- Part 3: A DevOps Implementation Strategy
- Part 4: DevOps Successes and Failures
Everything you need to grow your career.
With your free Red Hat Developer program membership, unlock our library of cheat sheets and ebooks on next-generation application development.SIGN UP
- Bill Montgomery: Manager, Red Hat IT
- Steve Milner: Engineer, Red Hat IT
- Jen Krieger: Product Owner, Red Hat IT
- Tim Bielawa: Engineer, Red Hat IT
- Chris Murphy: Engineer, Red Hat IT
Introduction: Gene Kim, award-winning CTO and co-author of “The Phoenix Project,” recently sat down with Red Hat IT’s Inception team to discuss their DevOps mission. Here are the highlights from the conversation.
On the importance of partnerships in a DevOps initiative:
Gene Kim: When you say you’re trying to increase efficiency for somebody, who specifically are you trying to increase efficiency for?
Bill Montgomery: Great question. The short answer is “all of IT.” We have about a dozen teams that develop custom, COTS, and SaaS applications. Our custom app development is done primarily in Java, Python, Ruby, and PHP, with lots of open source. These applications support everything from order to cash, software subscription entitlements, customer portal, RH Training, HR systems, BI. They’re the apps that run the business that is Red Hat.
After doing some research, trying to figure out how we could make the biggest impact, we decided to focus in one specific area: the deployment processes around our service oriented architecture & enterprise service bus (SOA & ESB) team. At least six other dev teams rely upon SOA & ESB for their integrations, with each of those teams having 6-25 members–developers, testers, and BAs.
Lots of changes in Red Hat end up having to make changes with SOA & ESB–every time we add a new type of product, support offering, and so forth. They’re at the intersection of just about every major project that comes through the department.
Tim Bielawa: And, if we do our job really well, and IT is producing and working better, it means the company is supported better and we’ve got time to innovate and to think about how we can really change things. That part will indirectly help the rest of Red Hat.
Gene: What has been your biggest surprise?
Tim: The people. Some of the biggest initial ‑‑ like, “Hey, man, we really need to have DevOps” and stuff like that ‑‑ when you actually show it to them, some of those same people go, “Oh, my God, no way. No, I can’t. No, I can’t get my head around this. No thank you.”
Steve Milner: Then there’s some folks who said, “There’s absolutely no way this is possible. It just doesn’t happen,” have turned around and been like, “Wow, this would be a great time‑saver. It would make my life so much easier.” It’s surprising who ends up saying what, and who ends up being your best friend, and who ends up freaking out and running for the jungle.
Jen Krieger: Yeah, people, both positively and negatively, have impacted the ability for this team to perform. Human nature is tragically random.
Gene: What have you done to help communicate what you’re doing to the rest of Red Hat IT, and how it can potentially help them?
Chris: We’ve tried to make it a priority to attend other teams’ stand-ups, and in doing so we’ve helped change the culture here in that other teams will now go the stand-ups of the teams that affect their product or are downstream of their product.
Jen: Yeah, we’ve helped make it okay for people to attend other team’s stand‑ups, which was not common previous. That was actually pretty helpful, because not only did it let us listen for similar themes, it also helped build relationships early on.
Tim: Also, lots of public demos. My former teammate Andrew had no idea of, really, what he thought we were doing or believed in what we were doing. Then he came to a demo one day, and then finally, in his words, “I get it, and I want your product.” He had no faith or ability in us until he came to a demo one day.
Jen: We never have trouble filling a room for demos.
Bill: Tim and Jen are right, the transparency provided by frequent tech demos and other channels–internal blog posts, videos, meetups–have really helped us earn credibility and buy-in from the rest of the IT org.
Gene: What actual benefits have you realized from that transparency and buy-in?
Jen: Tim and I met yesterday with the development team working on our next-gen cloud-enabled SOA Services tier, lightblue, and realized we’re already 75% of the way to their ideal CI/CD state with the Release Engine we’re working on. (ed: more on Release Engine next week.) That connection wouldn’t have been made if we weren’t out in front talking about what we’re working on.
We’re also starting to see interest in CI/CD & DevOps from the dev teams that support our back office functions like finance and business operations. I’d like to think that’s in large part due to the open, transparent way we’re working and communicating.
Bill: We’re also focusing on our team’s own CI/CD practices and communicating those out, so we can create the framework of what CI/CD could look like for other teams in Red Hat IT. Because Release Engine is green-field work, we have a rare opportunity to do it “right” and share what that looks like.
In part three of our discussion, Gene asks the Inception team about their implementation strategy for DevOps at Red Hat.
Gene Kim is hosting the DevOps Enterprise Summit on October 21-23, where more stories will be told about DevOps transformations in large, complex organizations. Learn more about the summit and submit your own talk here!
Do you have a DevOps initiative in plan or in progress in your organization? We’d love to hear about your experiences in the comments section.
Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.