devopsy.kinsta.cloud

Category: DevOps at IBM

Avoiding Common Executive DevOps Mistakes

A seasoned DevOps practitioner with experience leading both HP and Macy’s on continuous delivery transformations, Gary Gruver has learned the ins and outs of implementing Agile and DevOps at enterprise scale through the “school of hard knocks.” Now the president of Practical Large Scale Agile, a consulting business designed to help other enterprises navigate similar DevOps journeys, Gruver stepped in front of the crowd at IBM InterConnect last week to offer up some lessons he learned in those processes. His experience provides some valuable advice for executives hoping to avoid pitfalls while leading the charge for DevOps.

Scrum Doesn’t Equal Agile

The scrum methodology may be useful, but Gruver explained that executives must understand that in the enterprise, Scrum does not equal Agile. The problem with leaning solely on Scrum is that it emphasizes teams locally optimizing their work, while the entire organization is still not fundamentally transforming its ability to release code for the highest priority features on a more frequent basis.

“If you don’t scale over time, you’re going to end up with the classic implementation that you see in most enterprises which is a water-Scrum-fall,” he said. “Your teams are sort of doing stand-ups, they’ve got burn-down charts, they’ve got burn-up charts, they’re collaborating and doing all that work. But they’re still trying to deliver plans that were developed a year or 18 months in the future. And then when you integrate your code it is still taking days, maybe weeks, maybe months or even quarters to release code.”

Too Many Hands On The Steering Wheel

Letting teams loose in the organization lead only by Agile coaches and without some executive and management interface to bring things together results in “too many hands on the steering wheel,” Gruver said, explaining the prevailing attitude.

“You’ve got a layer of management between the CFO and the teams and you know what their role in Agile transformation is? ‘Stay out of the way. Don’t bother us, you don’t know anything about coaching teams and you’re in the way,’” Gruver said. “Most Agile transformations completely disengage the management team. If you get this continuous improvement process going at the executive level and they’re engaged in setting objectives, and they’re spending time in the organization working with teams figuring out what’s working and what’s not, that changes culture.”

Gruver says that executives and the management team should be working as “investigative reporters” looking for impediments to progress and helping to remove them.

Be Realistic About Architecture

It can be discouraging for DevOps champions in the enterprises who take lessons from organizations like Google or Netflix that thrive on the microservices model and then try to apply them within their traditional organization. The problem is that large, legacy organizations often have applications that are “too tightly coupled to the rest of the architecture to be independently developed, deployed and qualified.”

While organizations would do well to decouple these applications to allow for better incremental improvement, that’s not always realistic, Gruver said. This means enterprises will need a lot more coordination effort—led by executive prioritization—to scale DevOps, because “you can’t wait for a complete rearchitecture to fundamentally start improving your business. So you’re going to have to find a pragmatic balance between the two.”

Branches Are Evil

Gruver is a strong proponent for Trunk Based Development and used his executive oversight to set his enterprises on that path to efficiency in spite of strong push-back from the developer ranks.

“Branches are evil, branches are evil, branches are evil. They’re duplication in the process, and especially if you have any manual testing, they’re absolutely going to kill you,” he warned. “Try to avoid them where you can. I get that large, traditional organizations are very dependent on branches and it is going to take you a while to transform that. But every time you see a branch, you should think of it as waste in your system and try to figure out what’s the root cause for having it and how to eliminate that.”

Failing To Set Prioritized Backlog

Gruver advised enterprises that they shouldn’t start their DevOps or Agile transformations without having business managers who manage line of business “What is the business reason for transforming your organization.”

“This is going to be hard. It’s impossible to do everything at once, so you’re going to need to figure out where to start,” he said. “If you don’t have a clear business value for doing this, then it’s going to be hard to get momentum and have the vision for your organization to follow if it doesn’t know what to prioritize first.”

March 3, 2015
7 Great Thoughts on Real-world DevOps Transformations

Last week, IBM InterConnect brought together quite the gathering of IT pros engaged in DevOps, continuous delivery and digital transformations of their core businesses. Throughout the week, speakers from the Fortune 500 brought forth stories of real world experimentation, success and lessons learned from their DevOps journeys.

Here are some of the best chestnuts to make it out of the show:

Chris Nowak, senior vice president of DevOps for Bank of America

“We’re in sales. Our job is to sell DevOps inside the organization and unless I have the reporting and the data, I’ll get questions every week from CIOs that I can’t answer.”

Nowak recommends that organizations interested in gaining executive support through incremental shifts to DevOps and small wins along the way do their best to collect baseline metrics so they can offer evidence of the potential for improvement through DevOps.

Rich Moran, vice president of web architecture for Fidelity Investments

“When you automate bad processes, you just do bad things faster.”

A longtime architect, Moran explains he’s never seen a tool solve a process problem. In his opinion, DevOps transformations require organizations to think through processes and processes before implementing an automated pipeline, getting a good understanding of how software will be delivered, which groups are involved and when, what the flow will look like, how code will be checked and how approvals will work. Because when those details aren’t addressed and people just start running tools, that’s when they fail.

Gary Gruver, president of Practical Large Scale Agile

“You will probably write more code for test automation than you will code for running your product. And that is not bad.”

According to Gruver, test automation is one of the most important pieces to a DevOps transformation at enterprise scale and it’s also one of the things most often done wrong. Organizations must strive to getting it reliable, stable and maintainable.

Heather Cox, chief client experience digital and marketing officer for global consumer banking at Citi

“The payments and banking space is being fundamentally transformed. It has been said that people need banking, they don’t necessarily need banks.”

Cox kicked off the conference with this well-Tweeted thought, introducing the idea that large enterprises may be dragged kicking and screaming into DevOps and continuous delivery due to overwhelming competitive pressures. Small companies are now able to operate at previously impossible scale and completely disrupting enterprise dominance within their markets.

Jim Neumyer, senior application developer for HM Health Solutions

“Take small bites. Don’t shove the ice cream cone in our mouth all at one time.”

As Neumyer explains, the smaller the bite, the easier it is to tweak things along the way. Just as continuous delivery emphasizes iterative improvements in software development, the DevOps and Agile journey isn’t meant to be made in one massive leap.

Matt Ellis, vice president and CTO of architecture and technology for IBM Software Group

“You don’t know what the user wants until they see it.”

As one of the lead executives in charge of leading the internal IBM DevOps transformation, Ellis emphasized the importance of fast cycles of end user feedback in driving timely innovation through continuous delivery.

Pascal Eymery, vice president of strategy and business development customer support at Airbus

“The good thing about cloud and mobile is you can develop very quickly. You can scale fast if it works or just try something else if it doesn’t.”

Eymery’s organization has been tasked with helping deliver more value to airline customers through technological innovation. This includes developing iPad apps for pilots for Airbus cockpits that allow them to optimize takeoff and landing performance for fuel economy and baking in better telemetry improve maintenance windows. The fail fast and iterate mantra has been strong at Airbus.

March 2, 2015
Q and A with Carmen DeArdo: DevOps at Nationwide

Just before the IBM Interconnect show in Las Vegas last week, we had a chance to speak with Nationwide’s Carmen DeArdo and talk about some of the challenges he has faced at Nationwide as DeArdo and his team work to bring DevOps and Agile principles to their delivery value stream.

DeArdo is no stranger here at devopsy.kinsta.cloud, and recently shared his column Nationwide banks on DevOps to drive towards Continuous Delivery. At Nationwide, DeArdo is the director of application development tools and technologies. DeArdo is responsible for driving continuous delivery utilizing DevOps, Lean and Agile techniques across mobile, distributed, mainframe and other technologies.

Here, we interview DeArdo on the importance of transparency into DevOps processes and the importance of attaining efficiencies throughout the delivery value stream.

devopsy.kinsta.cloud: Talk to us about how, as you optimized certain aspects of your delivery value stream, you found wait states in other areas of the chain created delivery backlogs?

DeArdo: If you actually look at the entire delivery value stream, we started out optimizing the middle because we started with Agile design, development and acceptance testing. We gained a lot of benefit out of that. If you take a step back and think about your entire delivery stream, and your continuous delivery efforts, what you realize is that on the upfront process you end up with wait states and lack of visibility flow at that end.

What is happing is that as your teams get better, they actually run out of things to do. There’s nothing for them to pull forward anymore.

Then, on the downstream side of delivery, you still have the issues through your path to production – especially if you have managed test environments. You still have manual processes, manual testing steps in deployment. Even if you’ve automated some of them, you still have manual processes. And you end up moving at the speed of the lowest common denominator. What you find is that you’re going to get diminishing returns now unless you start to address those wait states or contention points on either side of design, develop, and test.

These inefficiencies, on the planning side, start to bleed back into the business. Many times your business areas still have a fixed mindset in terms of their budget and yearly cycles. They’re not used to determining how to continuously feed high priority work into the backlog of your Agile teams. And then on the other side of the pipeline, how can you take what’s being produced by these teams and move that more quickly into your path to deployment?

devopsy.kinsta.cloud: That’s interesting. Your challenge is taking your continuous deployment and continuous improvement mindset and then feathering that into the annual and quarterly planning mindset of the business?

DeArdo: On one side, what you’d like to have is more of a continuous planning, continuous flow so you’re not dumping a lot of stuff in a bursty way onto your teams. They’re going from wait state to being overburdened. You don’t have that continuous flow. And then on the downstream side, how do you start to automate some of the things and get rid of some of those manual practices? We’re very good at deploying to our continuous integration and deployment to our dev environments.

But then beyond that, things tend to get bogged down. We sort of go slow at the beginning and slow at the end and go very fast in the middle. Well, if you’re going to improve your overall speed, you need to look at those beginning and end spots and say, “How can I try to address those?”

devopsy.kinsta.cloud: To improve throughput throughout, it sounds like you need more feedback, more planning throughout the year with the business.

DeArdo: There are a couple of things we need to do, and part of it is around driving more towards continuous planning. The other side is about of having an automated deployment capability. Giving the business more capability, it goes faster if it makes sense from a risk and value capability perspective.

We’re actually focusing more on that latter part right now. We are building this automated delivery pipeline, which starts with release planning and then goes all the way through deployment.

devopsy.kinsta.cloud: What are some of the high-level challenges that you’ve had optimizing that last mile phase?

DeArdo: I think one of the biggest challenges, although people like to talk about tools, is is around the variance in your own processes. If you have too much variance in your own process, then you don’t want to instantiate that into a tool because all you’re taking is a bad current state and making it a permanent current state.

So we have meetings with vendors. The last one we had, we’re pretty far along this path, but the last one we had, we probably spent 90% of the time just talking about the variance in our own process and the fact that it’s not one-size-fits-all, but you have to have a small number of patterns that you’re trying to instantiate and implement. You have to be able to tell the difference between business value-added variance and waste variance.

I sometimes quote “The Wizard of Oz.” It’s like are you a good witch or a bad witch? Are you good variance or are you bad variance? Everybody wants to think what they’re doing differently has value, but in reality, most of it is arbitrary. There might have been a good reason for it at one point, but at this point, there is no value add in having that variance.

One of the variances we have is our path to production: what environments, what phases and things like that. One pattern might be an urgent need to get a business capability out very quickly. So I have a certain environment, a certain way to get certification in an expedited way. It’s not about going through an environment. It’s about proving that you have the quality that you need to deploy.

That one pattern might have a lot of automated testings run in one environment that you can get to very quickly to certify the quality and then release it. Another pattern might be around a record keeping system which is managing financials. You just have things that you have to go through. The system will have dependencies. So you’re going to go through a more elongated path to production.

That’s just an example of two patterns you would use based on a technology and a business need, not just because I’m in Organization A versus Organization B or Organization C. I don’t care what organization you are, if it fits this pattern and this technology, if it fits this pattern, use that and then if it fits this other one, use that. Those are good variances based on the fact that there’s a business need. There’s a technology driver that defines how you’re going to deploy.

devopsy.kinsta.cloud: That is an excellent explanation. I think many people get caught up in their “one right way” of doing things and have a tough time looking objectively at alternative ways.

Let’s talk about your “hidden factory” metaphor. Is the “hidden factory” a metaphor for a lack of transparency into different areas of IT?

DeArdo: Right, and the fact that you really don’t have a model. You have views. One of the things I point out is that you have a business development view, you have a project planning view, and you have release metrics, project metrics, and you have a release view. You have a path to production. None of that is visible. Some of it is hard to find. Some of it is visible if you’re in the tool of choice. But there is no visibility and no linkage or integration of that as you move from putting in your business needs at one end and seeing the code moving into production at the other end.

DevOps is about shining the lights on that. My view is you can’t manage what you can’t see. Another example sometimes I use is a basketball coach. Let’s assume you’re a basketball coach but you’re not allowed to watch the games. What you get after every game is a score sheet. It has the score. It has maybe your shooting percentage and turnovers, assists, but that’s it. Now you have to practice for the next game to work on improving something. Well, how do you know what to improve? So let’s say your shooting percentage was low, assuming you have enough metrics to know what low is.

Maybe your shooting percentage is bad. Maybe you think, “I’m just going to practice shooting.” Well, maybe that’s not it. Maybe the wrong people took the shots. Maybe you took contested shots, bad shots. There are a number of reasons you can have a bad shooting percentage, none of which have to do with the fact that you have bad shooters.

But that’s sort of the way we manage IT today. We’re asking executives to manage things they can’t see based on a set of metrics, but they don’t really watch the game.

March 2, 2015
IBM InterConnect: HM Health Solutions shows how continuous delivery helps cure healthcare IT headaches

As a spin off business unit of health insurer Highmark, HM Health Solutions is tasked with helping not only that insurer but also other third-party insurers across the industry to optimize systems that run core functions like benefits design, member enrollment, claims processing and customer service. And according to key members who opened up about the organization’s on-going DevOps transformation at IBM InterConnect this week, continuous delivery will increasingly play a role in HM Health’s ability to do that.

Utilizing IBM Urbancode, the business has been able to improve the application delivery process by giving application teams more control over how they stand up new environments, better visibility into builds and deployment , and much speedier configuration management. As a result, not only are they able to deploy more quickly, they’re keeping their developers happier and better engaged, with a higher rate of productivity.

“We save time and a good amount of it,” says Jim Neumyer, senior application developer for HM Health Solutions. “The (app) teams have the ability to look at their builds, configure their builds how they want to do it, strip down the builds with our standard templates and go very quickly from an SCM check-in to deploying in very few steps.”

As he explained, the teams are able to stand up their own environments, they’re no longer hampered by lengthy approval processes. Streamlining of approvals was perhaps the biggest time saver, Christina Felts, team manager of open solutions engineering, explained that one team said they experienced a savings of an hour of deploy time per app—something that can add up on release nights dealing with dozens of applications.

“One of our app teams was able to setup a new environment in less than one day, which previously we couldn’t do. So it could take a couple days before they got everything set up in that new environment,” Felts. “And it also eliminated the need for them to work with my team and put in a request and have to wait up to a couple days turnaround to get configurations done.”

Additionally, Neumyer says they can also easily roll-back when necessary. Perhaps even more impactful, though, has been the visibility piece in overall enablement of developers, Neumyer said.

“So the teams can check everything. If they have an issue, if they don’t know what’s going on in their environment they can go out there and look. It takes me out of the mix,” he said. “They can see it very clearly and easily and try it again. And most of the issues can be resolved on their own. And we can automate things a lot easier.”

HM Health Solutions says this is only the start of their DevOps journey—as things stand, it’s still a waterfall development shop moving toward Agile—but the early successes have garnered more buy-in from across the organization. Neumyer recommended to colleagues in the audience to follow the baby-steps approach that has worked for his organization when it comes to getting started with continuous delivery.

“The biggest takeaway for me is to take small bites,” he says. “Don’t shove the ice cream cone in your mouth all at one time. When you take small bites you’re able to tweak things very quickly.”

February 26, 2015
Streamlining no matter how many speeds your IT operates at

IBM InterConnect 2015 took over the Mandalay Bay and MGM Grand conference centers this week with an estimated audience of more than 20,000 attendees. The event is filled with DevOps evangelists, hybrid cloud experts, and IBM customers converging to share information in presentations and panel discussions.

On Monday I had an opportunity to attend one such panel discussion titled Mobile to Mainframe Experts: DevOps Best Practices for Systems of Engagement and Systems of Record. Yeah, the title doesn’t exactly “pop” but I didn’t let that dissuade me. The panel included a number of respected names in DevOps such as Carmen DeArdo from Nationwide Insurance, and Rosalind Radcliffe and Sanjeev Sharma from IBM.

In spite of the title of the panel discussion most of the conversation revolved around the concept of two-speed IT. In any organization—no matter how streamlined—there are going to be different processes or teams that function at different speeds. Applying the Pareto Principle, even if the organization figured out a way to operate more efficiently there would still be 20 percent doing 80 percent of the work and 80 percent doing the other 20. It would just be a matter of degree.

The problem is that if the speeds are too different problems arise. First, it’s just a waste of resources to have skilled workers sitting idle waiting for a different group or process to catch up. Second, those workers will often get antsy and go rogue—writing code and introducing features that weren’t part of the initial requirements and aren’t part of the planned testing. Now you’re just adding chaos that disrupts the workflow even further.

According to the esteemed panel the goal is to find ways for those processes and teams to function at their own pace without it impeding the overall efficiency —hence two-speed IT. Rather than trying to force a square peg into a round hole, or getting frustrated that the square peg can’t just be round in the first place, you have to find ways to maximize efficiency with the teams and processes you have.

Carmen DeArdo from Nationwide Insurance applies another term as well: variable-speed DevOps. In essence two-speed IT frames the challenge, and variable-speed DevOps is the set of processes and tools organizations can utilize to address the challenge. Removing some of the friction between different groups and enabling the organization to function more effectively is one of the primary benefits of DevOps.

When I spoke to Rosalind a couple weeks ago she stressed repeatedly that the foundation of effective DevOps is breaking down silos and finding common ground. That doesn’t mean all the teams have to be restructured under one organizational unit, or even that everyone has to adopt the exact same tools and processes. It means figuring out how they’re different and how they’re alike, and determining ways to make the most effective use of the common ground where their similarities overlap. It provides a starting point to get the ball rolling, and then things can mature and evolve from there.

In the session at IBM InterConnect Rosalind agreed that variable-speed DevOps is a great approach, but cautioned attendees regarding how it’s used. She told the audience that variable-speed IT should be driven by business needs, not by tools or processes. In other words, you have to stay focused on the business requirements and the need to achieve business goals and then find ways to do that. You can’t try to shrink or adapt the business requirements and goals to fit the processes and tools you already have.

DevOps tools and processes can—and in most cases should—speed processes and teams up. One of the hallmarks of DevOps is speed. Even as organizations embrace DevOps and introduce more automation, there will still be different teams and processes functioning at different speeds—and a need to implement variable-speed DevOps to enable those different speeds to exist in harmony.

February 25, 2015
InterConnecting the Internet of Things

In every direction one turns in the so-called Internet of Things there is fragmentation. There are many programing languages, devices and, more recently, a disparate set of IoT development and management platforms that are all vying for the market and developer’s attention. They hope, to become the standard in IoT in the months and years ahead.

One of the biggest obstacles to widespread IoT adoption has been the difficulty attracting developers to use the low-level programming languages on which most run. “IoT has been really hard to work with for a long time because a lot of it has required working with the Arduino tool set, for example, which is a lot of C++,” says RedMonk senior analyst Donnie Berkholz. “A lot of developers these days aren’t very interested in working in low level languages anymore,” he says.

Enter the Ethernet IoT Starter Kit for the IBM IoT Foundation. The kit from chipmaker ARM, Freescale, and IBM aims at the industrial Internet of Things apps, and is based on ARM’s mbed operating system, the Freescale-designed development board, and BlueMix – IBM’s cloud service.

According to the ARMmbed blog, the starter kit for the IBM IoT Foundation provides a slick user experience, and makes it possible to get data from the board sensors to the IBM BlueMix cloud within minutes. “It is particularly suitable for developers with no specific experience in embedded or web development, as it provides a platform for learning new concepts and creating working prototypes,” the announcement states.

“After the initial out of box experience, the infinite possibilities of cloud applications can be explored through IBM’s production grade BlueMix platform, in which deployment and device management is as simple for one device as it is for one million. The starter kit hardware can be modified and extended to explore the device design space, and a finalised design can be taken to production using the mbed SDK and HDK,” according to the announcement.

There were additional IoT announcements this week at the IBM InterConnect 2015 conference. Enterprise cloud provider CloudOne announced the launch of their CloudOne Internet of Things (IoT) Lab. The CloudOne IoT Lab hopes to be a platform for real-time collaboration to build IoT solutions. According to CloudOne, it will shortly build a technical center in Chicago, IL to house the companies technical team and provide a space for customers to get hands-on experience with the CloudOne platform, including IBM continuous engineering, asset management and analytics technologies.

“The CloudOne IoT Lab allows our team to brainstorm IoT-enabled solutions with customers in real-time. This will speed delivery of connected products while embracing and extending existing customer investments in partner technologies, data and processes,” John McDonald, CEO of CloudOne, said in a statement.

Also this week at InterConnect 2015, stream network PubNub announced that it is partnering with IBM to bring realtime data streaming and messaging capabilities to BlueMix.

PubNub demonstrated what it called realtime secure device connectivity, powered by its easy-to-use data stream APIs, at the conference. And, according to PubNub, IBM BlueMix customers will be able to leverage PubNub to securely and reliably deliver large scale realtime IoT, web, and mobile solutions.

There has been much movement in the IoT space in recent weeks. Earlier this month, the Raspberry Pi 2 was announced, with operating systems being provided by both Microsoft and Canonical. The increased processing power of the Pi 2 means in can be used in more smart devices from robots to drones.

Many of the recent announcements hope to make devices, data, and development tools more accessible to more developers. All of that is a must if the IoT is to reach its full potential soon.

February 25, 2015
IBM InterConnect: Disruption and the stakes of DevOps

It’s only a day into the main sessions at IBM InterConnect and it’s already clear that the most persistent theme that’ll be impressed upon the 21,000-strong crowd this year is one of business disruption. Woven throughout programming about cloud, mobile, analytics and DevOps innovation, the case studies already presented yesterday offer a testament to the disruptive power of IT transformation—and there’s more to follow in the next few days. Most important to the DevOps community, these stories don’t just show the hows of making good on DevOps, continuous delivery and iterative IT strategies. They also show the whys driving DevOps momentum.

Sometimes the DevOps community can get so fixated on the intricacies of orchestrating DevOps practices and processes that it misses the forest for the trees. Ultimately, DevOps is about helping the business completely shake up product delivery models, customer interactions and core business processes through a makeover in how IT delivers its services. And so, it becomes clear through this disruptive message that the show this week offers an informative glimpse of what the stakes are for DevOps transformations.

Throughout the day, IBM talking heads and a number of big-name customers explained how its become a eat or be eaten digital world across all industries as new technologies introduce new modes of doing business.

“If you don’t believe that your industry is changing, then you’d better step back and take a look at what your competitors are doing,” said Robert LeBlanc, senior vice president of cloud and software solutions for IBM, “because there are going to be disruptors and the disrupted. I’ll tell you that it is much more fun to be a disruptor than disrupted.”

It’s a real concern in the financial sector, according to Citi’s head honcho for consumer digital experience, Heather Cox. In the general session yesterday, she explained that her two biggest challenges are caused by disruptive technology forces. The first is facing up to new entrants into the field of financial services that has had barriers to entry diminished by increased mobility and connectivity.

“We have new people stepping into our landscape every single day,” said Cox, chief client experience digital and marketing officer for global consumer banking at Citi. “The payments and banking space is being fundamentally transformed. It has been said that people need banking , they don’t necessarily need banks.”

Almost equally challenging is the fact that her customers’ expectations for digital interactions are being rewritten by forces completely outside of her industry’s sphere of influence.

“I no longer look to my competitors to try to determine where we need to go or how we need to think about innovation,” she said. “I have the likes of FitBit, Uber, Nest–things that have nothing to do with banking but have everything to do with setting our clients’ expectations.”

In order to meet head-on the kinds of challenges Cox outlined, IT executives are going to need to do a better job taking advantage of the data and the tools already available to them, explained Pascal Eymery, vice president of strategy and business development customer support

“Look around 360 degrees, because I’m sure you have customers and suppliers and employees who have tons of data ready to be shared to create value for others,” he told the crowd, explaining that speed is paramount, especially as cloud and mobile technologies put continuous delivery in the realm of possibility. “One very good thing with new technology is its capability for agility; with cloud and mobile you can develop very quickly, you can try something and then you can scale fast if it works or just try something else if it doesn’t.”

Fundamentally, both IT and line-of-business executives grappling with the decision to start a DevOps journey should ask themselves a big question, said Gary Gruver, president at Large Scale Practical Agile.

“If you could start to say yes to all of the business requests coming in to IT and become two to three times more productive, would that matter for your business?” said Gruver, who explained in his InterConnect session yesterday how he was able to achieve that kind of productivity gain through DevOps practices while managing a team of 800 developers in HP’s printer firmware division.

“As executives leading large organizations, if you felt like you could deliver 2x to 3x productivity as opposed to trying to go out and hire two to three times more people and ruin your cost structure, there probably isn’t anything more important that you could be focused on.”

February 24, 2015
Dibbe Edwards, VP Rational Software Development at IBM, On Standardizing Tools, Process, and Technology to Build DevOps Success

We had the pleasure, for IBM InterConnect 2015, to speak with Dibbe Edwards, vice president, Rational Software Development about the success IBM has had in implementing DevOps processes within their organization. In her current role, Edwards is responsible for leading Rational’s development business that includes application lifecycle management and reporting, quality and requirements management, systems development and architecture management, and integration and open software development across both the IT and Systems domains.

Here is our conversation with Edwards about IBM’s internal DevOps transformation and the importance of, and challenges associated with, standardizing on tools, process, and technology to build DevOps success.

devopsy.kinsta.cloud: Can you tell us a little about what your presentation will be about on Tuesday? It’s about how IBM has led its own internal DevOps transformation, and I think that is something that would be of great interest to devopsy.kinsta.cloud readers.

Edwards: From an IBM perspective, we’re moving aggressively towards adopting DevOps practices. We have a larger software group, DevOps Center of Competency. The group is really taking these practices and the transformation efforts and rolling them throughout IBM. The session and the talk will kick off about that, and transformation at scale across the entire IBM company.

devopsy.kinsta.cloud: In a presentation you gave at DevOps Enterprise Summit, you highlighted the challenge of standardization as one of the top three challenges in an enterprise move to DevOps. Could you share a little about what you meant by that for our readers, and maybe some of the lessons learned at IBM as you worked to standardize your people, processes, and toolsets.

Edwards: We talk about how there are three elements to any transformation. That’s the process or the ways of working. There’s the culture of getting people to think differently and work differently. And then there are the tools. It has to be a combination of those three things that will drive any sort of successful transformation, you can’t really do one very well without the other.

So standardization, or coming to a common way of achieving DevOps practices, is an important aspect because it gets people speaking the same languages. You’re able to have, then, a single version of the truth in terms of the viability of the project and where you’re going and you know that you’re communicating effectively. That’s been an important part of us being able to not only get this off the ground, but be able to scale it up at a company the size of IBM.

devopsy.kinsta.cloud: What were some of the challenges that IBM encountered working to standardize? Did you identify those processes that worked and saw that they could be applied horizontally and then slowly put them in place across the different groups? How did you get buy-in to do that?

Edwards: I would say the culture and the ways of working, or process, go hand in hand. I think if you don’t view that that’s the case, than you are in for a real challenge. If you try to just write down a bunch of processes and apply them in an organization without acknowledging and understanding the culture of that organization you are going to run into a lot of challenges. And getting buy-in from the organization is also a very essential part of it.

What I’ve done in many of the organizations to drive towards a more standard way of working and modifying the process is to get the teams personally involved. What we did as a part of our transformation in both the web organization as well as the Rational team is start with a look at our current process and look at what was working and what was not working.

We had set our business objectives. We wanted to deliver more quickly. We were delivering once per year. We wanted to deliver on a quarterly basis to speed up our time to market and get more valuable capability in the hands of our clients. We wanted to eliminate waste. That meant spending more money on innovation and less money on maintenance.

What we did is we looked at our process from beginning to end. That meant everything from how we worked with our product management team, who help us make our business decisions and set our investment priorities, to a complete analysis of our development process, our testing process and our deployment process. We looked at those and we said, “What are the biggest inhibitors to us moving fast?”

We built very specific plans. We actually established work group leaders to go and bring in other members of the team to determine how to go about addressing any inhibitors. We just started picking the biggest inhibitors, the ones that were our biggest pain points and put plans in place to address those.

I think one of the important things about this is that you have to recognize that in order to improve the situation, you have to prioritize those investments along with your product investments. From our perspective, it certainly wasn’t something that could happen overnight. You also can’t stop the delivery train while you’re doing all this stuff. So, it has to be prioritized alongside the other work that you’re doing.

Then the key thing is once you establish what your key focus areas are and you have the buy-in from the teams and recommendations from the different work groups, you begin to implement those things. At the end of each one of your sprints, you reflect on how you did and reflect on the improvements that you’ve been able to make and you identify your next set of inhibitors.

It really then becomes a focus on continuous improvement, gaining momentum and reporting on whether you are really removing the inhibitors that you set out to remove.

devopsy.kinsta.cloud: Are there a specific set of challenges around a large organization standardizing on toolsets?

Edwards: One of the things that we’re big believers of in IBM and even within my organization and other parts of IBM is that there are certain things that you need to standardize on. If you’re managing a large program, you need to have the ability to, like I said, have a single version of the truth on the status of the project. So, things like how you do the tracking of your work, your dashboards and how you report on things, how you track your defects. The definition of a sev-1 defect should be consistent across teams that work together.

But then underneath that, there’s flexibility that we give our teams in terms of tools that they might want to use. As an example, we support Git with our products. Sometimes we acquire companies and they want to use Git as their source code management repository. We’re okay with that. We just need to have this single sort of way to govern and manage the projects so we know that we’re meeting our business commitments and quality commitments that we make to the business.

Another example is, from a testing point of view, I use in my organization Selenium for some of our automated testing because it was a solution that worked best for the type of Web-based situation that I have. We use some page object frameworks, which is a principle that is supported in Selenium. It helped us to be more efficient.

The message I wanted to come across is that standardization is important with tools, but it doesn’t mean that every single thing has to be from the same vendor and it doesn’t mean that you can’t bring in things that work really well for your particular team. That’s another thing, I think, that helps from a cultural point of view is that there are some things that people can be pretty passionate about or have been effective for them in the past and bringing them into this overall governance structure is something that has helped us also sort of break down some barriers around people wanting to move forward with new approaches.

devopsy.kinsta.cloud: What helps drive the cultural shift? I would imagine success begets success. When teams start to see success with other teams it probably makes it easier to get buy-in horizontally through the organization.

Edwards: That’s true. There are multiple aspects of that as well. One of the key things that I have always believed in with the team is that you need to have some quick wins because, like you said, success breeds success. If you can get some good momentum under your belt with something that really has a positive impact, then it will get other people to buy-in.

As an example, one of the things I talk about is our build time. It was a very frustrating thing that touched every developer and every tester in our organization because it took them a really long time to get a build. That was viewed as one of our key inhibitors. We spent quite a bit of concerted effort focusing on eliminating the amount of time that it takes to get a build. In many organizations, that can be an inhibitor.

We had to invest in multiple different ways, but our initial leap was from 36 hours to 12 hours, which is huge, and along the way we had incremental improvements. Every time it got faster, it built more momentum and more excitement on the team and they could see immediate productivity impacts in a positive way for themselves.

Another key area for us was implementing the use of patterns in our test organization. We found we were spending a tremendous amount of time setting up the test environments where we needed to actually validate our product and customer-like scenarios. One example is it took us 30 hours to setup an environment because we were doing it manually.

We were able to implement patterns, which took us some time to build, but once we had those in place, we were able to deploy those environments in an automated way in three hours. We could then spend that 27 hours doing useful, constructive testing and being able to be more creative with our testing and finding more problems and being able to test so much earlier.

Those are examples of things that were real momentum gainers for us.

devopsy.kinsta.cloud: That’s fantastic. I think you’ve shared a lot of useful information for people who are thinking about going down this path. I would like to ask you about one objection, or belief, that repeatedly comes up in my conversations with enterprises. They’ll say that they can’t embrace DevOps in their organization because they don’t have the resources. They’ll say “Well, that’s Netflix or that’s Amazon doing those things or that’s IBM, a software development company doing that. We can’t do that because our core competency isn’t software development.” What’s your response to those types of positions?

Edwards: Definitely. I think as I look at this, I’ve spoken had, myself, almost 50 briefings last year just talking to clients about this topic. People in every single type of business, everything from manufacturing to banking to insurance to retail, everyone is under a similar pressure: “How do I respond more quickly to the market? How do I make my company more competitive?”

The reality is that IT is a very critical part of that today. There was a point where maybe IT wasn’t a differentiator. But today, IT is absolutely core. So, what is this all about? It’s about being able to be more agile and interact more rapidly with their clients and provide value-added capabilities to them and get their feedback. I think that certainly the business need is there.

Now, as you start to think about some of the companies that aren’t running their business off of this, we talk a lot about some of the challenges: like how do you get the stakeholders brought in to want to participate in doing this type of development? What I’ve seen with many clients that are not “IT companies” is that they usually start with a pilot of some project that’s a reasonable size. And they have agreement from their business stakeholders and from the IT organization and they bring all their testers and developers and their operations and their business stakeholders together and they run some pilot projects.

When they do that, the types of results I have heard insurance companies and banks have from such pilot teams have been outstanding. They’ve been able to get wonderful feedback from their stakeholders around how much more the application that was being built addressed their business needs. How they got into production so much faster.

The types of results were excellent. That has helped, I’ve found, to drive the momentum to other parts of those of businesses. Because at the end of the day, just like the rest of us, it’s about return on investment. It’s about having confidence that what you’re doing is the right thing. This process is really about helping to shine the light on that. And using these types of DevOps approaches is about doing that.

February 24, 2015
IBM to the Enterprise: It’s Time to Glue All of Your Clouds

According to the research firm IDC, more than 65 percent of enterprises will commit to a hybrid cloud by 2016. With that change in architecture, organizations will face new challenges when it comes to accessing data on their legacy systems and public clouds: from having visibility into the applications across various clouds systems to ensuring that data is secure and managed in a way that adheres to local laws and regulations.

Today, at IBM InterConnect 2015, IBM announced a number of services, software, and partnerships that are designed to ease those frictions and more.

In 2014, IBM earned roughly $7 billion in cloud revenue, an increase of 60 percent year over year, and IBM SVP Cloud Robert LeBlanc said during a press conference here in Las Vegas today that IBM fully expects that growth to continue to outperform the broad cloud software and services market. Part of the strategy to get there was announced today.

The announcements, below, are made available APIs in IBM’s BluxMix cloud development platform for web and mobile apps:

Portability services: IBM says new open standard services will make it easier to move workloads across different environments.

IBM Enterprise Containers: According IBM, IBM Enterprise Containers will help developers to create and deliver applications via native Linux containers with Docker APIs to provide enterprise–class visibility, control and security and increased automation. Cloud applications, when necessary, could be transferred to on-premises infrastructure to improve security, performance, or for other factors.

BlueMix Local: BlueMix Local extends BlueMix into a company’s on-premises data center with borderless visibility and management across Bluemix environments: public, dedicated, and local. BlueMix Local will provide many of the developer services found today in IBM’s BlueMix cloud platform for enterprises to use on-premises. “BlueMix Local enables enterprises to bring their public cloud to on-premises and install capabilities found in public cloud behind the firewall and operate all of their clouds together,” said Damion Heredia, VP cloud platform services, IBM Cloud.

There were many other announcements today, regarding IBM’s push into hybrid cloud management with the goal to improve cloud visibility, control, and security.

Here are the relevant management tools IBM announced today:

IBM DataWorks: New, intuitive tooling and experience to find, refine, enrich and deliver trusted data. This allows developers to subdivide and manipulate data sets from the treasure trove of public and private data.

Collaborative Operations: Enhanced visibility and control of clients’ hybrid environments with a single, end-to-end view.

Orchestration: Available as a service enabling management across hybrid environments that is the largest federated orchestration library in the industry.

Security: New features that protect the most vital data and applications using analytics across the enterprise, public and private clouds and mobile devices.

Increasing Developer Productivity: New services that enable developers to more quickly, effectively, and securely connect apps, data and services across an open and flexible environment of traditional systems, cloud platforms and any device, seamlessly weaving data and services with APIs to compose new apps and services, including:

Secure Passport Gateway: Allows self-service to developers to securely connect data and services to Bluemix in minutes through a simple Passport service that keeps IT in control.

API Harmony: Find a perfect API match for a client’s application using the world’s largest knowledge base of APIs; easily expose and manage APIs.

Many of the services are based on open technologies, IBM said, including Cloud Foundry and OpenStack.

IBM also announced cloud related partnerships. IBM will team with Tech Mahindra to build a cloud-based development platform for its clients on BlueMix Dedicated – the BlueMix single-tenant edition. Tech Mahindra’s developers will now be able to build cloud-native and enabled applications. Tech Mahindra plans to train 5,000 of its own developers on building BlueMix apps.

Additionally, IBM is expanding its partnership with CSC, where CSC will extend BlueMix to CSC’s developer ecosystem as they build out their cloud apps and infrastructures. This partnership will be through the CSC IBM Center of Excellence.

Finally, IBM said that it would build more SoftLater computing capacity, this time with new cloud data centers eyed in Sydney and Montreal. Both centers will be open within the next 30 days. This is a big deal for customers in those regions, and follows similar recent expansion in Frankfurt, Germany; Querétaro, Mexico; and Tokyo, Japan.

February 23, 2015
Live Blogging IBM InterConnect 2015

February 20, 2015