devopsy.kinsta.cloud

Tag: devops adoption

  • DevOps Chat: Enterprise DevOps Adoption, with Micro Focus’ Mark Levy

    DevOps Chat: Enterprise DevOps Adoption, with Micro Focus’ Mark Levy

    Adopting DevOps means changes from how you build software to organizational processes and cultural behaviors. Large enterprises have even greater challenges to overcome, including supporting a large number of applications and addressing technical debt while also taking on new development initiatives like digital transformation.

    What can we learn from experienced DevOps practitioners?

    In this DevOps Chat we spoke with Mark Levy, director of strategy, software delivery at Micro Focus, covering seven keys to successful DevOps implementations at large enterprises.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Mitch Ashley: Hi, everyone, this is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, we’re tackling the topic of large enterprise adoption of DevOps—no small task, for sure.

    I’m very happy to welcome Mark Levy from Micro Focus. Mark, welcome.

    Mark Levy: Thank you, Mitch, and glad to be here.

    Ashley: Would you just tell us a little bit about yourself and what you do at Micro Focus?

    Levy: My name’s Mark Levy. I am a director and working in the product marketing organization, and I focus a lot on strategic marketing initiatives as an evangelist, a DevOps evangelist. I develop and write content and commentary about the DevOps market. I’ve had a 25-plus-year career, and like many people, I’ve had many positions. I started out as like a sysadmin and was a developer and managed dev teams.

    But, in 2007, I started to focus exclusively on application delivery. And so, that has been—this whole area of application delivery, software delivery is something that I’ve been really focused on for the last 10 or so years.

    Ashley: Well, tell us briefly, a little bit about Micro Focus. Not all of our listeners might know what you all do.

    Levy: So, Micro Focus has also gone through this major transformation over, I would wanna say, the five to eight years or so. You know, we’re a global enterprise software company. We were established in 1976, we have 14,000 employees and 40,000 enterprise customers, about 4,800 software engineers, and we really focus on large enterprises, helping them run and transform their business. We have sort of focused on four key areas of how do we support our customers through their digital transformation journey, and enterprise DevOps is one of them.

    Ashley: I imagine that our folks, listeners that are from large enterprises are gonna be particularly interested, and I’m sure there are learnings and information that will be useful to other folks as well.

    So, you talked about playing in the space with large enterprises. I imagine that’s probably some global international companies, maybe some that are both European or U.S.-based as well. How would you describe how you differentiate what you do as Micro Focus as compared to other folks? There’s a lot of companies, of course, working to try to help enterprises adopt DevOps.

    Levy: Yeah, of course. And that’s sort of what I’d like to do first maybe is just sort of set the stage, because I always look at this, especially in the enterprise IT world, it’s so interesting. You know, Gartner made this sort of—you know, their strategic assumptions. And they said something like, through 2021, at least 80% of the DevOps initiatives will fail.

    Ashley: I have not seen that, no. Interesting.

    Levy: I don’t know if you’ve heard that, but—yeah. So, it’s interesting. What does that tell me—tell us, I believe? One is, the business is already in the fight. The enterprise, the business side is already in this digital economy and fight. We see that on the streets.

    And the other thing is, you know, IT is sort of behind the curve. And the reality is that our customers, the IT customers, the IT organizations have this incredibly complex hybrid landscape, it spans mainframe, mobile, on-prem, off-prem, and while the principles—the main DevOps principles—are similar to what the unicorns, so to speak, are delivering, that it’s really a whole different challenge.

    Because what’s critical is that there’s this above the line mandate to drive new digital revenue, but at the same time, you know, optimize the enterprise. And, you know, I sort of—I like one of my colleagues, his reference. It’s like, redesigning a jet plane while you’re flying it, you know? And so, I think that’s how, you know, what’s critical with large enterprises is that they’re trying to transform themselves and at the same time run the business.

    Ashley: Yeah, I would almost describe for a large enterprise, it’s like trying to build or transform the entire fleet of planes while you’re building it.

    Levy: Yes! Exactly.

    Ashley: Talk a little bit about—I mean, we all, I think, can appreciate in every business, especially large enterprise, they’re saddled with technical debt; they, of course, are working on operational efficiencies; they have applications that they’re trying to support and maintain.

    How do they take on something like a DevOps initiative successfully, as you were pointing out earlier, so that it doesn’t just stop at one group and kind of fall off from there, they really wanna be able to transform their part of their business? How do you do that?

    Levy: Right. So, I think one of the key things that we focus on enabling our customers to build on what already works, okay? They have all these core investments, and how can they take their core investments and leverage the ROI that they’re already having today, but implement new technologies and DevOps practices and capabilities? And I think that’s critical. I mean, how do they implement and scale DevOps practices, for example? It’s very, very important, and it’s hard.

    And so, we look at it from the basis of, how can our solutions and our products help them really get from point A to B? What is their current state now? Which is what they really need to understand. And it’s amazing how many companies really don’t have a current understanding, detailed, of their current state.

    Ashley: Mm-hmm, or a common one. [Laughter]

    Levy: Or a common one, because, you know, it changes a lot, but how do they deliver value to the customer? You know, what are their value streams, and what are the processes and the flow of artifacts? And so, they need to understand their current state.

    And then, they need to do a number of things that I know the people that are helping the DevOps community, the DevOps community have been evangelizing for a while—I think critical, especially in large organizations and enterprises, you know, they need to first really create this culture of continuous improvement. I think that’s critical.

    Ashley: Okay.

    Levy: You know, they need to enable, motivate and empower the teams, and the leaders really need to get on board, right? Without the leaders, it just will not work.

    Ashley: Yeah, I can speak from personal experience—instituting a continuous improvement culture is no small task in and of itself.

    Levy: Right, and you know, the thing is, the leadership style must also change, right? I mean, command and control really doesn’t work, decisions—it’s about empowering your product teams to drive as much decision making as possible. And that sort of has gone contrary to, you know, the organizational structure of the large enterprises.

    Ashley: Mm-hmm.

    Levy: So, that, I think, you know, is one of the critical challenges that these companies are faced with. Edward Deming made a great quote, “A bad system will beat a good person every time,” right?

    Ashley: Mm-hmm.

    Levy: And when I think of a bad system, I think, in its largest sense, the system. And this is where I think Micro Focus can help quite a bit is, anyone wanting to change this culture really needs to define the actions and behaviors that they desire and then design sort of the work processes that are necessary to reinforce those behaviors.

    So, you know, systems, processes, tools, help with and enforce good culture. But you know, if you have a bad system, it’s not gonna work. So, I think, you know, these are areas that we can help on the cultural side. I come back to thinking about the idea that, you know, sort of the general friction between dev and ops teams, where ops teams are really, initially, only measured by mitigating risk, and dev teams are only measured by delivering change. You know, there’s the conflict that has to be resolved. That’s critical.

    Ashley: You’re talking about culture; the other thing that occurs to me is, there can also be inherent or built in incentives that are counter to the culture that you’re trying to create. That friction is a good example for one. But, you know, there may be past punishment for failures or, you know, emphasis on down time, so the answer is always minimize change or whatever it might be. You’ve gotta take those things head on.

    Levy: Exactly, yeah. And so, I think, you know, you ask sort of where people start. I think, you know, you need to start—and everyone, a lot of people talk about this, and it is true. You really need to start instituting this culture of change, because DevOps drives a lot of change. It’s a transformational journey in the enterprise.

    Ashley: When you said, the number one thing you said was, “Leverage what works.”

    Levy: Yes.

    Ashley: What do you look for? What kind of things are you trying to say, “That’s a practice you do well, and let’s keep that, or let’s build upon that”—what do you look for?

    Levy: Well, you know, I think about, there’s a lot of legacy systems, core investments that these large enterprises have had and invested lots of money and time into it. And take, for example, COBOL, okay? That language, I think people are not necessarily aware how invasive it is. There’s still about 250 billion lines of COBOL around, right?

    Ashley: Mm-hmm, mm-hmm.

    Levy: It drives 70%, they say, of all business transactions—still, in the world.

    Ashley: That’s amazing.

    Levy: It is amazing.

    Ashley: [Laughter]

    Levy: And so, you know, I’ll give you an example of sort of what we’ve done and we’re, you know, we are very good at managing and understanding those environments. We have, you know, that’s a big part of our business. So, we can, you know, lift—if we can lift and shift, you know, COBOL workloads off of, you know, sort of the more legacy platforms into, let’s say, AWS, you know, that’s a big win for our customers.

    As an example, we had one customer that basically had—it was a major global insurer, had about eight different IT environments with a back end COBOL app sitting on the mainframe and then front end and WebOps. And basically, each environment cost about $3 million a year. And, to request that environment, to provision that environment, took six weeks.

    Ashley: Mm-hmm, mm-hmm.

    Levy: And so, we built, through our solutions, we were able to lift and shift that workload to AWS and reduce the cost from 3 million to 120K and reduce the provisioning time from six weeks to two hours.

    Ashley: And I wanna mention, too, to our listeners, too, we just had a webinar in the last week talking about mainframe APIs and frameworks specifically to mainframe environments to make it a little bit easier to adopt WebOps. So, though it doesn’t get the kind of sex appeal that necessarily new technology does, it is a huge, huge issue for enterprises and how do you bring the mainframe environment with the rest of the cloud and everything else.

    Levy: Right, it’s—you know, back to the theory of constraints. I mean, in your value stream, if—you know, you can develop and you can be an agile team, but if it takes six weeks to provision, you know, your mainframe environment?

    Ashley: Where do you suggest people get started? Is it go pick a new, from scratch greenfield project, or pick something that’s, you know, reasonably mission critical so we’ll get the support?

    Levy: Yeah. Well, I think one is, I like, initially, to set up a lab, like taking a greenfield. You need a place to learn. A lot of these things aren’t easy, or they’re not, people are not, the teams are not used to. So, like, I love the idea of what a lot of the community’s doing with DevOps dojos and building sort of a team level, maybe CI/CD, have a place to experiment and take that.

    But then, you know, ultimately, in large enterprises, they’re gonna come up. They might get easy wins early, right, but the challenge is, once they scale, they’re gonna run into some of the more challenging times. And that’s where, back to what they have to really start doing is taking this broader, system level view of the enterprise.

    So, you know, if they understand how they’re delivering value to their customers—and in enterprise, there’s many ways to do that—then they need to understand and prioritize according to the business objectives. Let’s say one business objective might be, we need to recapture value. Maybe our IT budget isn’t really growing, but we need to drive for more innovation. So, we need to—our objective is to recapture that value and redeploy it into delivering value and innovation. And so, that would drive a lot of your decisions in where you optimize.

    Ashley: Speaking of budgets being flat or not growing, digital transformation is all the rage, that’s what many, many companies are taking on, not just in customer experience, but across the enterprise, bringing them into the digital world. How does that fit on top of this if you’re trying to introduce DevOps?

    Levy: I don’t see how they can really run their digital transformation without DevOps. I mean, software today—you know, I talk about this a lot where business innovation and software innovation are generally becoming one and the same, right?

    Ashley: Mm-hmm.

    Levy: And going quick, innovating faster with less risk is critical. And so, IT is, you know, it’s imperative to really deploy DevOps practices to support the digital transformation of the business. So, I think, you know, the IT organizations that implement DevOps, those people are the drivers.

    Ashley: Well, and it’s hard to imagine how you were gonna transform systems and applications you already have as well as ones you might leverage as SaaS services or create yourself without an environment to integrate those altogether due to continuous integration testing, etcetera, as well as be responsive to the business.

    Levy: We’ve seen enterprises, they will typically start out, right, with their team level implementation and they might do really well, and it might be a greenfield app. Maybe it’s a new growth app, which is great, and they may get some early wins, which is super, but it’s still not their core business.

    Ashley: Mm-hmm.

    Levy: And so, they have to, ultimately, really transform their core business in order to be competitive in the market.

    Ashley: Mark, what’s the one thing organizations should not do when they’re looking to adopt DevOps—don’t make this mistake?

    Levy: I think the idea that they can just automate their way out of it, I think, is something that could get them in trouble. Because, you know, really leaving out the whole cultural aspect of it, it really is—you know, it’s interesting, if you read Jeff Bezos’ letter to shareholders every year, he just provides some incredibly insightful, you know, insights on how Amazon runs. He talks about this accelerated decision making process that they run, and they make these decisions, really, based on only 70% of the information that they need, basically. Whereas, large enterprises wait until they typically have 90%.

    And so, they are able to make decisions earlier because of the agility that they’ve built into their system and their culture of change. And this allows them to not only, you know, get earlier into the market, but it allows them to—everyone, it allows them that if they make a mistake, they can recover from their mistakes faster, and the cost of making a mistake actually goes down.

    Ashley: Mm-hmm.

    Levy: But this whole idea of organizational agility and providing that—there’s more than just delivering value faster to the customer, because it’s never a straight line, right, to success. So, we make a lot of mistakes and wrong turns in our journey, and being able to identify that quickly and have the agility to correct that quickly is actually more of a differentiator than just delivering fast.

    Ashley: It’s certainly required for any kind of agility. It’s not just getting things and getting decisions made faster, but changing when things aren’t headed in the right direction—or change.

    Levy: Right, right. And so, this is where, you know, if people are looking at DevOps, they’re saying, “Okay, well, we’re just gonna automate the deployment pipeline and we’re done?” No, there’s no “done,” it’s about really, ultimately, improving as an organization, right, and having that continuous improvement, the Kaizen kind of mentality of the organization. And that, to me, is what is so transformative as a company.

    Ashley: Going back to what you said in the beginning about having a culture of continuous improvement.

    Levy: Yeah, absolutely. And that, it would be, you know, frankly, the most powerful thing leaders can do—is that change. Because it really just changes the whole business. The business, then, gets more confidence, which is critical, right? With all this change, sometimes they’re not confident to make business decisions, but if you can provide them the confidence to go out there and really be aggressive, you know, that’s—you’re gonna see, you know, a whole bunch of positive results on the revenue side, on the public side of the business that’s been driven from, traditionally, the back office IT organization.

    Ashley: Well, Mark, I’d like to thank you. I’d like go for another 30 minutes, [Laughter] but I’d like to thank you for the time on the podcast. You know, I walk away with several things from our conversation. The things you shared that I heard were leverage what works, define your current state, create a culture of continuous improvement, command and control doesn’t work—you’ve got to empower product teams. Start with a lab or a dojo, some learning environment. I think your premise of, you can’t do digital transformation without DevOps is pretty intriguing. And last but not least is organizational agility, being able to make decisions quicker, get out ahead of things without having to have 100% of the information, kinda the Amazon model.

    Well, and that should wrap things up. I’d like to thank Mark Levy from Micro Focus for joining us. This is Mitch Ashley with devopsy.kinsta.cloud, and you’ve listened to another DevOps Chat.

    — Mitchell Ashley

  • 5 Considerations to Get DevOps Right in Telco IT Systems

    5 Considerations to Get DevOps Right in Telco IT Systems

    Implementing DevOps in telco IT systems, such as business support systems/operations support systems (BSS/OSS), is not easy. This is especially true with telcos that overly rely on third-party commercial off-the-shelf (COTS) vendors or systems integrators (SIs) to implement new capabilities, and to run operations. To effectively control the vendors, telcos extensively use traditional levers found in SLAs, KPIs and RFx (requests for whatever). They also reinforce the organizational and mental boundaries between the telco and vendor staff. In a DevOps setup, such a traditional approach is not likely to produce the desired results.

    How, then, can telcos ensure DevOps success in their organization? Here are five considerations.

    Know and Understand DevOps Across the Organization

    Time and again, the understanding of DevOps varies from the top-down and across the telco organization. Some top managers believe DevOps is just a “faster version” of the traditional delivery and operations, wherein the vendor executes almost everything. It takes time for the management to fully recognize that the telco will have to take up much more execution responsibility than what it is used to. Having a correct and similar understanding about DevOps is criticat to accept the fact that the nature of the work and the extent of the telco’s involvement will change significantly. The sooner this is done, the better.

    Identify Which Applications Fit into the DevOps Model

    As part of the DevOps rollout plan, list the applications that can offer the organization significant business benefits through the DevOps model. While some applications, such as eCare or mobile-apps, will fit the bill, some others may not. Highly configurable COTS applications that do not undergo frequent code changes, such as IN or core billing, may not be brought under the DevOps model. For such applications, the traditional approach with traditional SLA parameters could fetch a better cost benefit.

    Reiterate that the Mindset Must Change

    The telco will find itself in a position where it has to work more closely with vendors than it used to do. Most likely vendor staff will be part of telco’s Agile and Ops team. The telco will have to foster a one-team thinking. For this, the first few steps toward building mutual trust should come from the telco. Do not expect the first few iterative releases to go smoothly. When that happens, don’t get frustrated—see them as opportunities to learn, adapt and fine-tune the DevOps approach within the organization. These are also avenues to reiterate that success/failure are shared responsibility, and that there will be no finger-pointing, regardless of whether a person is an employee of a vendor. In this process, an environment of acceptance naturally develops—i.e. the product owner agrees to product deviations, while the agile team that consists of vendors agrees to fuzziness in the requirements. It is highly recommended that key roles in DevOps be taken up by the telco staff, and they should involve themselves heavily in the scrum workflows.

    Obviously, classic-delivery SLA/KPI parameters and values will not fit in such a setup. Those would require a major revamp. An example: Give reward points to the team for on-time delivery and release. The number of points awarded will be fewer if not all the release objectives are met, but the team will get some points. However, if the team doesn’t deliver on time, it will not be awarded any points. Payment and commercials could be tied to the reward points. Similarly, if the telco decides to manage operations through a managed services contract, then it has to look again at the target operating model and SLAs.

    Be Prepared to Invest More

    Adopting DevOps doesn’t necesarily mean immediate cost reduction. The benefit analysis should cover aspects such as duration of a release and frequency of releases, not just cost reduction. To realize DevOps, telcos will have to incur cost for talent acquisition. Expect an increase in full-time equivalent (FTE) costs, especially for onsite FTEs. Telcos will have to spend on training and reskilling their staff on new tools and technology. Job shadowing from experts could be required until the team gets a good grasp on DevOps. There will be costs in creating new agile teams and creating new reporting structure.

    Enabling New Technologies and Tools

    It is a given that microservice-based platforms enables DevOps. This is because they truly enable agile teams to work separately with minimum dependencies and undertake continuous integration and deployment, which requires tools. Telcos will have to decide and finalize the platform, tools and DevOps framework. Some aspects to consider while finalizing the platform and tools include their market maturity, ease of maintenance and skills availability.

    Conclusion

    Habits run very deep. Changing those are not easy. This why most DevOps advocates emphasize that the mindset or cultural shift is the most crucial aspect of implementing DevOps in organizations with a history of traditional delivery and operations. This is especially true with telcos, which run on a  large set of legacy systems, both COTS and bespoke.

    — Vishal Augustine

  • Survey Finds Mixed Progress on DevSecOps

    Survey Finds Mixed Progress on DevSecOps

    A survey of 5,558 IT professionals published today by Sonatype in collaboration with CloudBees, Carnegie Mellon’s Software Engineering Institute, Signal Sciences, 9th Bit and Twistlock finds 27 percent of organizations have mature DevOps practices in place, while another 48 percent are still working on improving them.

    Despite the DevOps works that remains to be accomplished, however, the survey also noted that 47 percent of respondents still manage to deploy code multiple times a week.

    The survey, announced at the RSA Conference, also finds that 25 percent of respondents now consider security to be a fundamental element of quality assurance process. But responses among the 23 percent of respondents who identified themselves as developers suggest implementing best DevSecOps practices remains a significant challenge. For the third year in a row, about half of developers reported they don’t have enough time to address cybersecurity issue.

    The survey, however, also noted that organizations that do implement best DevSecOps practices see substantial benefits:

    • Elite DevSecOps practices are 700 percent more likely to have fully integrated and automated security practices across the DevOps pipeline.
    • Almost two-thirds (62 percent) of respondents with elite programs have an open source governance policy in place that is improved via automation.
    • Organizations with elite DevSecOps practices are three times more likely to provide application security training to developers.
    • A full 81 percent of those with elite practices have a cybersecurity response plan in place.
    • More than half (51 percent) of respondents with elite practices leverage automated security products to identify vulnerabilities in containers.

    Brian Dawson, DevOps evangelist at CloudBees, said the survey results show that despite the gains being made by some organizations, there is much work to done in terms of overcoming technical hurdles and cultural tribalism. For example, 35 percent of all respondents said their No. 1 challenge in application security is that they find out about the problem too late in the process. Nearly half (46 percent) of organizations without a DevOps practice do not have application-level credentials encrypted. Half of respondents (50 percent) with a cloud infrastructure said they rely on their cloud service provider to secure their IT environment, and 28 percent of respondents admitted they do not protect secrets such as passwords, API keys and certificates.

    The core issue most organizations need to focus on first is to firmly establish a DevSecOps mindset, said Dawson. Much progress has been made in driving adoption of DevOps practices. Now those principles need to be extended to include automating the implementation of security controls as applications are being built and deployed. The survey noted that 63 percent of organizations that have elite DevOps practices are now informing developers of cybersecurity issues directly within the tools provided to the DevOps team. Armed with that information, it becomes much easier to incorporate security fixes within the overall application lifecycle management process.

    It may be a while before best DevSecOps process are widely implemented. But as cybersecurity issues continue to be incorporated within the quality assurance process, it’s now only a matter of time before applications become much more secure.

    — Mike Vizard

  • Smashing the (DevOps) Stack for Fun and Profit

    Smashing the (DevOps) Stack for Fun and Profit

    Most organizations that I deal with have a similar story for the promulgation of DevOps in their data center. The story is similar for bringing in most new technology and techniques: A team that usually does a new project without any attachments—relatively small compared to projects at the center of the business—adopted DevOps from the start. A smaller (by far) number shoehorned DevOps into an existing project as a first taste. Some decided to go “all-in” and “convert” IT to DevOps. This is a painful method; I can’t say I recommend it. I suspect my friends at those organizations wouldn’t recommend it, either.

    When I say “DevOps” in this sense, I am talking more about process and procedure changes, even cultural changes, rather than tools. My experience is that most companies that have been around longer than the last spring shower started adopting the tools of DevOps before they started looking at ways to streamline the process. And that isn’t a terrible thing at all. It doesn’t matter what marketing spin is used to sell the product; if it makes your life better or allows you to react faster, implementing it is worth consideration. I just wanted to be clear what we’re talking about here.

    Those companies that started small generally grew small, also. It is a big deal to move that 20-year-old codebase with a ton of processes that touches everything into DevOps when compared to saying, “New projects will use DevOps.” This, too, is in line with what we’ve always done. Iterative replacement has always been the case, where the large, important systems are concerned. In a couple of industries I am familiar with, I’d even argue that those large, important systems weren’t completely upgraded to Customer Information Control System (CICS), so don’t hold your breath on seeing them completely upgraded to DevOps. But that is a different blog.

    Once a critical mass has been hit, these shops start referring to themselves as a “DevOps shop” or “DevOps first shop.” This is the point I want to talk about today (though it took me a bit to get here).

    You’ve got a bunch of apps or a couple of application portfolios that are now running under DevOps. In most organizations, the tool sets are not a perfect match. Indeed, in some organizations the DevOps toolchains look like they were assembled on opposite day. Teams tend to be more standardized, but even team composition varies from project to project, as do communications.

    This is the next point of inflection in DevOps growth. You have it in your grasp to jump again, from amazing to truly amazing.

    Time to smash the DevOps stack.

    Get the teams together, build a list of each system used at each step in the process for each app, each manual intervention, each communications channel—essentially each difference between DevOps teams—and start to look for synergy. If one team is using ChatOps, check out what benefits they perceive from doing so and if ChatOps fits all teams. Does one team have a standard process to roll from continuous delivery to continuous deployment? Check it out. If you have several disparate DevOps teams, it is almost guaranteed that one team will handle DevSecOps better than the others. Take a look at what/how they’re doing and promulgate it to less security-intensive projects as needed.

    Basically, build the corporate process/toolchain from what is successful. That sounds like simple advice, but it isn’t. Teams often love their tools and processes, and are certain their choices are better than others. It takes work to get to a common understanding and there are always exceptions in a complex environment: “Well, yes that works, but for our app, we have this thing over here that makes it not possible/feasible/affordable.” It requires extra work, but that’s always true. Because the environment is complex and has been for a long time, these issues have always existed; you’re just dealing with them with new processes.

    Keep kicking it! Keeping the virtual lights on is as important as keeping the physical lights on in today’s environment. Unless your company is listed in “haveibeenpwned” emails, or your website has been suffering catastrophic outages, you are kicking it.

    — Don Macvittie

  • Survey: DevOps Progress Slow, but Steady

    Survey: DevOps Progress Slow, but Steady

    Atlassian has published the results of a survey of 500 IT and software professionals that suggest now is the best and worst of times when it comes to DevOps.

    On the plus side, the survey found that more than half of respondents (57 percent) are encountering fewer bugs and outages after deploying a continuous integration/continuous deployment (CI/CD) platform. Nearly half (47 percent) of those who have adopted a CI/CD platform also report they make changes and receive customer feedback faster. A full 71 percent who have embraced microservices have also discovered it is much easier to test and deploy new software features, according to the survey results.

    However, the survey found three-quarters (75 percent) of development teams face issues with bugs, defects or delays when it’s time to release. A total of 73 percent of software development teams also reported spending 10 percent to 50 percent of their time on updates and upgrades to self-hosted software. On average, according to the survey results, teams rely on 4.3 tools to move code from development into production environments.

    More frustrating, 62 percent of respondents reported they resort to performing manual testing due to insufficient automated test coverage, additional manual processes or a lack of build/deployment pipeline automation. However, among those organizations that have adopted feature flagging to ease management of the application development process, 63 percent report better testing a feature and higher overall rates of software quality.

    The metric IT organizations are employing to measure DevOps success appears a little soft. A full 93 percent of respondents consider customer satisfaction to be the most important DevOps metric, but 60 percent admit it’s difficult to measure customer satisfaction for the features that have been developed.

    Sean Regan, head of growth for software teams at Atlassian, said that while there is clearly much work still to be done, the democratization of DevOps continues unabated. Rather than being limited to a few high IT practitioners, Regan said DevOps processes increasingly are being pushed into the realm of everyday enterprise IT operations. At the same time, many line of business executives are being included within those teams to ensure the software being developed achieves the desired business outcome, noted Regan.

    IT organizations are also starting to apply more engineering principles to the management of IT infrastructure, added Regan. In many cases, IT organizations are discovering a single engineer can be more efficient than 10 systems administrators. However, finding and retaining those engineers is a major challenge. The goal needs to be to create a set of DevOps processes defined by an engineer that are simple enough to be implemented by IT administrators, said Regan.

    Of course, many of those IT administrators today are schooled in less agile ITIL processes. But as ITIL continues to absorb some of the concepts and best practices pioneered by the DevOps community, the divide between engineers and traditional IT administrators should become that much more narrow to bridge.

    — Mike Vizard

  • Survey Finds Wide Gap Between DevOps Adoption and Success

    Survey Finds Wide Gap Between DevOps Adoption and Success

    A recent HBR survey shows there is work to be done to advance DevOps in organizations

    A survey of 654 subscribers to the Harvard Business Review found that while 86 percent of respondents said it is important for their organizations to be able to build and deploy software quickly, only 10 percent said they are successful at it.

    Conducted by Harvard Business Review Analytic Services on behalf of Google, the survey found nearly half (48 percent) of respondents said their organization always relies on DevOps methodologies when deploying software, while another 21 percent rely on DevOps selectively. An additional 8 percent said their organization plans to adopt DevOps practices.

    Among those respondents employing DevOps practices, the top benefits cited were increased speed to market (70 percent), productivity (67 percent), customer relevance (67 percent), innovation (66 percent) and product/service quality (64 percent). Despite those benefits, however, most organizations still have a significant amount of work to do in terms of implementing best DevOps practices—the three biggest hurdles organizations face are organizational silos (50 percent), legacy technologies (49 percent) and resistance to change (46 percent).

    Melody Meckfessel, vice president of engineering for Google Cloud Platform (GCP), said these issues are precisely why Google is sharing how it operates in the form of site reliability engineering (SRE) principles, which are a prescriptive set of guidelines for implementing best DevOps practices. Not every organization needs to implement those principles to the same level, but just about every organization can benefit from adopting a set of well-defined engineering principles, said Meckfessel.

    The challenge many organizations face is the fact that most of the IT staff are not engineers by trade. Most IT staffs are made up of administrators who tend to have limited programming skills. But Meckfessel said even IT organizations that don’t necessarily have a lot of engineering expertise still can benefit from automating operations based on the SRE principles.

    Many of those organizations will need to slow down the rate at which they are building applications today to be able to speed up tomorrow. It takes time for organizations to master the cultural change required to implement DevOps practices. But once they begin to master DevOps, the benefits to the organization compound quickly. Meckfessel said two of the most important attributes of DevOps is adopting an immersive approach to training and establishing a no-blame culture within the IT organization when it comes time to conduct post-mortems. That latter goal is especially difficult to achieve sometimes, because most interactions between developers and IT operations teams historically have been less than positive.

    Meckfessel also noted it’s critical now for organizations to incorporate cybersecurity into its DevOps processes as well, which requires not only additional training for developers but also closer alignment with cybersecurity teams.

    It’s now only a matter of time before the complexity associated with emerging technologies such as microservices based on containers force many organizations to dive deeper in DevOps. The real challenge now is charting a path of least resistance that also generates the maximum level of benefit for all concerned.

    — Mike Vizard

  • Help a Student Out and Advance DevOps in Academia

    Help a Student Out and Advance DevOps in Academia

    Those of us who attended university know the pressures students face every day. Between attending classes, completing homework, figuring out what they really want to do with their life and all of the other assorted adulting they have to manage, college students have a lot going on. That’s why a little help can go a long way.

    Take Gabriel Cogo, for example. He’s a Ph.D. student at Texas Tech University in the Management Information Systems Department. He is working on his dissertation, the topic of which is DevOps, mostly focusing on the organizational impact and the factors that lead to successful DevOps adoption by organizations. He needs to gather information from DevOps professionals, such as IT analysts and managers, and reached out to devopsy.kinsta.cloud to see if we could help spread the word.

    From Cogo’s letter:

    … DevOps is an important topic, but so far not very much research has been done to help us understand how it works in actual companies.

    We ask that you participate by completing this survey. Additionally, if possible, I ask that you forward this survey to other colleagues in the IT department, preferably from different levels in the company (e.g., analyst, manager, CIO).

    This is an online survey that can be taken on your computer or smartphone, and we anticipate that it will take no more than 20-30 minutes to complete.

    This survey is completely anonymous, and we will only ask for the optional name of the company, so we can better understand the characteristics of our sample. To participate in this research please click the link:

    http://ttu.az1.qualtrics.com/jfe/form/SV_3z5Oh7ApF1za1pz

    You are free to leave at any time. We greatly value your participation in this study.

    For those interested, Cogo has shared with us the executive summary of his dissertation, which is available here.

    So whaddya say, want to help a student out?

    — Charlene O’Hanlon

  • DevOps Disillusionment? 4 Behaviors to Get Your Team to the Other Side

    DevOps Disillusionment? 4 Behaviors to Get Your Team to the Other Side

    For most teams, the adoption of DevOps and an agile mindset involves many twists and turns on the path to maturity. It’s not uncommon for teams to experience a “trough of disillusionment” period as:

    • Initial euphoria and “us-against-the-world” team mentality ushered in by adoption of new work patterns wanes with time.
    • Client demands and pressures to produce intensify.
    • Sustained leadership engagement and support fails to materialize.
    • Key evangelists move on to new roles.
    • Apologists for organizational status quo never tire.

    And before you know it, what once felt like a cultural movement seems mired in the realities of metrics, tools and keeping the operational wheels on.

    Pushing through these challenges and self-doubt is a critical step in DevOps maturity that can refine and strengthen a team’s character. Getting to the other side of “the trough” requires a team and its leaders to reconnect with why they embarked on the DevOps journey in the first place, and remind themselves that a lasting shift in behaviors is the ultimate goal. Where behaviors change, results follow.

    What are these behaviors? With so much written by thought leaders in the DevOps community, teams have the luxury of expressing the behaviors they intend to model in a way that resonates with their situation. Ultimately four actions, practiced faithfully, will build the team muscle memory necessary to get to the other side.

    Choose Wisely

    Overcoming the urge to please others and having the courage to say “no” to work that is unlikely to add customer value is perhaps the most important behavior of all. Doing it in a way that preserves credibility and trust is a skill that can only be learned through deeply understanding who your customers are and what problems they are trying to solve. Choose wisely and prioritize ruthlessly. Flawless IT delivery of unnecessary features is a shared failure for both customer and DevOps team alike.

    Commit Boldly

    Go “all in” on the work you choose to take on. Ensure that the desired outcomes and acceptance criteria of your work are clear before committing, and rely on those closest to delivery to determine how to get it done. Once established, game on! Commit boldly to small deliveries that add customer value and invite accountability for what you take on—knowing that customer satisfaction is the ultimate measure of your success.

    Adapt Quickly

    Sometimes, we fail. In big and small ways teams employing DevOps don’t always meet their own expectations or those of their customers. Our failures don’t define us; how we respond to them does. Learn. Adapt. Move on. Welcome the changes to requirements you know will come and adapt quickly by leaning in to the power of small and frequent deliveries to place you back on track quickly.

    Share Freely

    Teams employing DevOps are part of a larger community of like-minded individuals committed to delivering customer value quickly and making their organizations better. Take your obligations to continuous improvement seriously, share best practices freely and solicit expertise to help improve the pace and quality of your delivery and those around you. Helping others succeed has the remarkable effect of making yourself better in the process!

    — Chad Sands

  • Is Your Organization ‘Fit for the Future’?

    Is Your Organization ‘Fit for the Future’?

    Takeaways from a recent conference suggest more work is needed in DevOps adoption among organizations

    This was a question explored by CIO Platform Nederland and the DevOps Agile Skills Association (DASA) in a recent event I attended, hosted by Transavia. Many organizations have already embarked or are about to embark upon Agile transformation initiatives, driven by growing business demands. This event focused on sharing experiences, learning from the practical examples (successes and lessons learned) from Transavia and ABN AMRO, and exploring the way forward to successfully create a high-performing IT culture that is “Fit for the Future.”

    The event was well-attended—unsurprising, really, when you remember the wise words from the late Robert Stroud, former Analyst at Forrester: “To unlock the promise of DevOps, CIOs must lead and support a cultural change within their technology management organization, but as any leader knows, changing institutionalized behavior is the toughest of all management challenges. CIOs must recognize when a trend becomes an imperative for survival. DevOps has become this imperative.”

    DevOps and Agile transformations being seen as imperative for business survival. But not just business survival, according to the “2017 State of DevOps” report, which declared, “By 2020, half of the CIOs who have not transformed their teams’ capabilities will be displaced from their organizations’ digital leadership teams.”

    Rik Farenhorst, CIO of Transavia and chairman of the DASA Leadership Forum, presented lessons learned from Transavia. He stressed the importance of changing mindsets and giving equal, if not more attention, to creating desired “behavior” change and not relying too heavily on structure, processes and automation and hoping that the right culture emerges. “People first,” “live your values” and “lead by example” were his key messages, stressing that values must be translated into corresponding desired behaviors as well as unlearning old ways of doing things. Another important discovery was accepting that not all teams are so far and not all teams can mature at the same speed.

    A great example of “lead by example” was the leadership team’s daily standups and visualization of strategic priorities, gaining more situational awareness and shared understanding and commitment.

    Matthijs Dee and Ivo Carton from ABN AMRO presented their journey from Agile to DevOps, also pointing out the fact that teams mature at different speeds and the need to share lessons learned between teams. ABN AMRO adopted a DevOps playbook that teams could use, containing a kind of toolkit for improving team capabilities. Equally, Dee and Carton noted ABN AMRO’s challenges in moving from “command and control” and traditional hierarchic management models to new leadership styles and behaviors. In ABN AMRO’s case, the organization needed to focus on BizDevOps—it’s not all about code, it’s about delivering business value.

    Farenhorst mentioned “values” in his presentation, while Dee and Carton mentioned “principles.” Both of these concepts need translating into team behaviors and leadership behaviors must help empower teams to make this shift.

    My presentation, “DevOps Will Fail … Unless,” I revealed the findings culled from more than 400 global teams having participated in the Phoenix Project DevOps simulation and gave a Top Three set of takeaways.

    The first was the need to focus on BizDevOps—making the shift from “features” to “outcomes” and from a flow of “code-to-commit to a flow of “idea-to-value.” This was also one of the top challenges for organizations at the most recent DevOps Enterprise Summit.

    My second tip mirrored advice from Transavia and ABN AMRO: The need to define, agree and commit to “desired behaviors” and what is effective collaboration (here is an example of what I mean).

    My third tip was embedding continual learning and improvement as core behaviors. DevOps is new and all about experimenting—it is a long journey and needs to be done as iterative improvements. At the same time, the pace of change coming at us is increasing, as is the amount of change. Teams need to be able to respond to change. I also quoted Mike Orzen, author of “Lean IT”: “Improving your work is just as important as doing your work”; as such, impediments and improvements should also be made visible on the backlog of work for teams and leaders must ensure adequate time is given and reserved for work-in-progress, for teams to improve.

    Following the presentations were three break-out sessions: “Value Creation and Management,” “Organizational Design – Agile/DevOps at Scale,” and “Sustainable Culture Change.”

    These are some of the challenges raised in the Culture break-out session I attended as a follow-up to my presentation:

    • An interesting discussion was around “control” and how to empower the management layers and have them empower the teams. As a CIO, this layer between you and the work floor can diffuse your vision by the time it reaches the shop floor and at the same time leave you unaware of what is happening.
    • Management by walking around was suggested, as a CIO being visible on the shop floor and soliciting feedback. Listen to concerns and enter into a dialogue about vision, goals and what it means.
    • Teams often are faced with fear, uncertainty and doubt (FUD) about new ways of working. What will it mean to their job? To their responsibilities? And will they be able to do it? Leaders must remove the FUD and create a safe environment. Safe to take risk, to experiment, to fail, to give feedback. Managers must foster a “no blame” culture.
    • A study by Google (2012) called Project Aristotle, named in tribute to Aristotle’s quote, “The whole is greater than the sum of its parts,” looked into why some teams work and others don’t. One of the key conclusions was that “psychological safety” was the “it” factor: A sense of confidence that the team will not embarrass, reject or punish someone for speaking up.
    • Change team behaviors. We adopt these approaches and don’t see the behaviors we expect. Not everybody wants to change. Leaders need to be able to identify the silent killers, what is under the water, what are drivers for working against. At the same time, teams need to be willing and able to work effectively as a team and need team training (not just individual training). Team training also needs to address soft skills such as communication, feedback and collaboration.
    • Leaders also need new skills in organizational behavior management to be able to identify behavior drivers and how to create sustainable behavior change.
    • Lead by example was named, but what is that? What behaviors are expected from leaders? Sometimes managers are only one step ahead in this new working. DevOps is new, there is no fixed framework; it is about experimenting what is right for your organization. This is all new.
    • Ask yourself, “Why are we doing Agile, DevOps, Lean? Are we adopting these approaches as a goal in themselves? Or are they to solve a specific set of problems or deliver a specific set of results? And how does this relate to strategic goals?” This must then be translated into, “What is in it for ME?” for the various stakeholders (business, IT management, teams, customers). Success can only be achieved end to end, which means all end-to-end stakeholders must understand the “why” if they are to commit to the journey.
    • Build empathy and trust and asking questions to get open feedback—not telling (command and control).
    • Authenticity: To build trust, be empathetic to FUD; listen to concerns; demonstrate (words and deeds) how these will be taken seriously; and recognize achievements. Empathy must be authentic; if your behaviors are not seen as real, you will lose the trust you are trying to create.
    • Shift from a (real or perceived) “blame culture.” Failure is OK as long as we learn and improve as a result. If there is no trust, then people fear consequences of making mistakes and are less willing or likely to want to experiment or speak up.
    • Leaders should show vulnerability, too. Set an example of having failed and learned. Admit in these turbulent times when new ways of working really are new, managers don’t have all the answers—it is a journey of experimenting, learning and improving and giving feedback.
    • Allow teams time to learn and discover themselves. Recognize that not all teams mature at the same speed, appropriate leadership styles and coaching for teams. Use external (to the team) coaches.
    • Be prepared for the difficult discussions and decisions. Not everybody can and not everybody wants to change. If you are dependent upon heroes, get rid of them—literally or metaphorically. One example noted was a toxic working culture with teams held to ransom by the hero, while another example was having the hero share knowledge, coach and create more T-shaped capabilities.
    • Look for “change champions” in teams—peer level respect. Empower them with the right skills and recognize their contributions and the team successes. “Give a podium” to success from desired behaviors such as experimenting, learning and improving.

    From the discussions it was clear that C-level managers need to learn new skills and demonstrate new behaviors, while management layers must learn more behavioral and organizational change skills. Teams must not only learn DevOps technical skills, but also team-building and soft skills.

    CIO Platform Nederland and DASA will be organizing future events and sharing content and experiences from member organizations to address these needs as a follow up to this kick-off event.

    — Paul Wilkinson

  • DevOps Hiring: What Do You Need?

    DevOps Hiring: What Do You Need?

    IT has long had a problem with hiring. I’m not certain where it started; most of us blame HR, and that’s probably incorrect, but gives us someone to blame. It’s that we post jobs with insane requirements. Sometimes this is done to keep the applicant pool down, but most of the time it is a simple case of throwing in the kitchen sink. We have laughed at advertisements that wanted applicants to have more years in a given technology than the technology has existed. The laughter was because someone quipped, “So what we really want is only liars to apply.”

    But it doesn’t stop there. How many advertisements have you seen for a person to join an already good-sized team of developers, and the requirements include experience in every single language/tool the person might encounter—and sometimes ones the organization might use in a year or so? And DevOps, with its increase in toolsets and broadening complexity, make this problem worse.

    If you want good DevOps team members, you have to focus your search. We’d all love to have unicorns who could do it all on day one, but those people don’t really exist. Even with experience in every single tool in your chain, they still have to learn apps and environment. Try to craft job requirements that focus on the couple of core tools, and then filter for ability to learn and adapt. Because the only certainty about IT at this point is that technology will be shifting, so focusing on the tools you are using today is pretty limited.

    Role plays a part in this also. While we like to pretend DevOps is one thing, it is a rare application or portfolio for which there are not specializations on the team. If you are looking for someone who will lean more toward the DEVops side, do you really need them to be operational wizards with three years each in storage, networking and container management? Conversely, if you are hiring someone more for the devOPS side, do you need them to have expansive experience in Javascript, or do they just need to know who to call if it gets beyond their ability?

    Maybe your company is one of those shops where everyone on team X is expected to be an expert at everything. Kudos for you, but there aren’t a ton of those people out there. There is a different mindset to DEVops versus devOPS, and even if unofficial, most employees lean one way or have a more proficient side. If a candidate fits the bill in an area you are weakest, consider training them on the job in the area you are strongest, rather than waiting for who knows how long for the perfect person to fill the open req.

    And we still have a need for hardware specialists. I’ve said it before, but do you want your EMC (or Cisco or whomever) person to be a generalist, or do you want that person to make the infrastructure that underlies a huge chunk of your applications hum? Hire specialists for specialized skills, hire broad knowledge for app-spanning needs.

    It’s been a problem for years, and only you can fix it. Call out overambitious job postings and make managers ponder what they’re actually looking for. You know you have a need, you know what the position will do. Help hone down postings so that they fit the actual requirements, not some blue-sky version of potential requirements.

    And get the best people for the job. After all, you are going to have to work with them.

    — Don Macvittie