devopsy.kinsta.cloud

Tag: agile

The ROI of Enterprise DevOps

Ever since the 1996 film Jerry Maguire, I can never think about any technology development without hearing Cuba Gooding Jr as professional footballer Rod Tidwell screaming out, “Show me the money!” So I was not surprised when the CIO of a large enterprise recently asked me the enterprise exec version of that famous line:

Q. Where is the ROI in Enterprise DevOps?

Fortunately there is plenty of evidence to show enterprise executives exactly where to look when trying to determine the ROI of DevOps.

“Show me the money!”

Here on devopsy.kinsta.cloud, Rajat Bhargava has posted on talking to your CFO about DevOps, outlining four key areas of financial impact: generating cash, reducing expenses, enabling growth, long-term stability. I also had some ideas about financial aspects of getting executive support for DevOps in a great article by Erica Chickowski. And site editor Alan Shimel has posted some excellent insight on vendor-sponsored research from IDC on the cost-benefit of downtime avoidance.

“Show me the money!”

Not enough? Well, we also have several years of research on ROI factors associated with DevOps adoption in both small businesses and large enterprises. The company I work for, CA Technologies, has commissioned independent third party research into enterprise DevOps adoption since 2013; Puppetlabs has run similar research [PDF] with good data on all sized organizations, but especially mid-sized businesses.

You can see in the chart below the areas where benefit accrues through the adoption of DevOps (taken from CA Technologies/Vanson Bourne research released in November 2014):

Still need more? No problem! There is also good data on how much of a return you can expect from DevOps. Again, the following chart is taken from the same CA Technologies/Vanson Bourne research:

Figure 2 Respondents report seeing double-digit improvements in key technology and business areas. Total varies by benefit. Figure 1 & 2 Source: Vanson Bourne/CA Technologies 2014

“Show me the money!”

Okay, I get it – you still want more, and you want a straight answer – a single, simple heuristic to work with. In talking with many enterprise CxOs, faster application delivery is a pressing goal, so just this one factor can act as a key ROI driver. At the Continuous Delivery (CoDe) conference in Copenhagen in October, Jan Bosch (Professor of Software Engineering at Chalmers University of Technology) showed very elegantly how faster delivery acts to reduce (i.e. shorten) the ROI period.

His theory is based on the premise that for many (most? all?) businesses, time to revenue is dictated substantially by product release cycles. Maximum revenue accrues around product release, then tails off before spiking again for the next new product release. For example, a smartphone manufacturer will get revenue in 6-month peak and trough cycle as they release a new device twice a year; a software vendor will get a revenue peak with a new game release, which tails off until new DLC is released or a new game hits the stores.

Because DevOps can accelerate business cycles, Jan theorized, business can bring in revenue faster, which in turn makes a DevOps-based business more profitable over the mid- to long-term. This is especially critical in the modern application economy where almost every business is a software business.

So, for example, if DevOps allows a business to release twice as fast, they can effectively double their annual revenue, as seen below.

Figure 3 Proportional revenue acceleration from doubling product release frequency with DevOps

The impact is exaggerated for this illustration, but based on actual data (see above), a 20% increase in annual revenue would be on par with enterprise averages.

“Show me the … costs!?”

Of course, any discussion of ROI must realistically reflect costs too. Adopting DevOps in a large enterprise is not free – it requires investment in people, process, and technology. On the people side, even just a small cultural change often requires new activities and other behavioral shaping. Process change requires training and often impacts short-term revenues. Technology investment includes procurement of automation and measurement solutions – key components of a CAMS (Culture, Automation, Measurement, and Sharing) approach to DevOps, especially in a larger enterprise.

Many of the investment factors can be seen in the following chart, again using CA Technologies/Vanson Bourne research:

Figure 4 Which of the following is your organization likely to invest in over the next year as part of your implementation of a DevOps methodology? Total = 499 ITDMs who have already or plan to implement DevOps in the next two years. Source: Vanson Bourne/CA Technologies 2014

“Show me … my own ROI!”

These ROI factors are of course a combination of averages, research data points, and anecdotes. As with all generalizations, when it comes to a specific enterprise your mileage may vary. However, this is certainly a good starting point when building a business case to prove the expected ROI for your organization.

You may find other areas for ROI too – upstream in the PMO, DBA, or downstream in NetSec, training, documentation. If you have additional data points on finding the ROI for DevOps, I would love to hear about it. Add your ideas here in the comments, or connect with me and/or devopsy.kinsta.cloud on Twitter – at @AndiMann and @DevOpsDotCom respectively.

March 9, 2015
DevOps is Agile for the Rest of the Company

IBM held its InterConnect 2015 conference last week in Las Vegas. The event covered on a range of topics including hybrid cloud, mobile apps, and DevOps. One session I attended focused on Agile development and the parallels to DevOps were apparent.

The session I attended at the Mandalay Bay Hotel was titled “How a Major Telco Improved Cycle Time and Business Results by Leveraging Agile”. Elliot Olschwang and Claudio Cozzi—both IBM employees—talked about helping a specific customer reach its goals by introducing Agile development principles. What struck me throughout the presentation were the many ways that the concepts the two talked about implementing at a developer level for this customer are very similar to the concepts companies must embrace on an organizational level to make the transition to DevOps.

Rosalind Radcliffe actually deserves credit for pointing out the similarities to me. When I spoke to her a few weeks ago she told me that DevOps is just the Agile principle taken to the full enterprise. It provides a more comprehensive end-to-end perspective that enables enterprise-scale transformation.

Agile development was an evolution from the Waterfall method. The Waterfall methods treats project analysis, design, coding and testing as separate and distinct phases that have to occur in order. There are many inherent problems with Waterfall, such as the fact that you don’t actually develop code until half way through the project. Testing would often be cut in the interest of time, and even if testing is done it’s actually too late. Any issues identified in testing mean you have to go back at least to the coding phase again—possibly back to design or even analysis.

Agile removed the linear dependencies of Waterfall to enable development to occur more effectively and efficiently. Aside from imposing a more efficient workflow in general, Agile improves quality because testing occurs earlier in the process and more frequently throughout the process. Subsequently the risk to the project is reduced because there is continuous feedback that enables developers to adjust on the fly rather than having to go back to the proverbial drawing board at the end of the project lifecycle.

DevOps is just a natural extension of Agile. It takes the guiding principles and best practices that Agile brought to developers and applies them on a much broader scale across the organization. As I pointed out in a previous article from IBM InterConnect, “Removing some of the friction between different groups and enabling the organization to function more effectively is one of the primary benefits of DevOps.”

Part of DevOps is to streamline by automating those things that can be automated. Allowing tools to perform tasks so that other resources—namely the human beings—can provide greater value by performing less mundane work.

The other part of DevOps, though, is a culture shift. It’s a change in the ruling philosophy of the organization that erases traditional barriers between departments and processes and enables everyone to function more efficiently without unnecessary overhead or “red tape”.

That second part is where the principles of Agile development come into play. Implementing continuous monitoring for continuous feedback that leads to continuous improvement rather than staying mired in a linear flow that creates hurdles and roadblocks and results in resources sitting idle waiting for other teams to complete a task before the next task can begin.

DevOps is hot now, but eventually it will mature and evolve into something else just like Agile has. It will be interesting to see in a few years how organizations that have embraced DevOps begin to take it to a whole new level.

March 4, 2015
Digital Transformation with Agile and DevOps – Something “Wicked” This Way Comes
Our world is full of wicked problems, like climate change, urban planning and social injustice. They’re called wicked because they’re hard to recognize, define and solve. Furthermore, complex interdependencies mean solving one aspect will just expose or create other problems.

Today’s digital transformation imperatives are creating wicked problems for IT. So wicked in fact, they make managing technology in the traditional sense look like child’s play.

Suddenly, businesses are faced with complex dilemmas. How can they compete in a world where their customers place less emphasis on physical products and more on the total experience? How can we adjust marketing from driving consumer behavior to responding to it? How can they adapt business models in context of the customers’ world? – a world that’s increasingly dependent and driven by digital technology.

The short answer is of course software, but the problem is our approach to delivering it just isn’t suitable in a wicked business world – why? Well its simple – we keep working on the assumption that we understand the problems we’re trying to solve, when in fact we don’t understand the problems of our customers at all – that is, until we have a solution.

Head scratching stuff huh, but consider this –

Did you know you had an entertainment problem before Apple gave you iTunes? Was booking hotel accommodation such a pain before AirBNB introduced the whacky notion of people renting out their own rooms?

So faced with such wickedness what can we do? Well, we can start by accepting our current IT failings, develop some wickedness of our own, and mitigate against what can derail your efforts.

Small is Beautiful … really it is!

In the past we’ve tried to solve business problems with what I call IT “bigness” – big iron, big software applications, big teams, big projects, and big expectations – oh, and let’s not forget big funding. The results, however, haven’t set the world on fire have they? – Big IT white elephants, big budget blowouts and big executive fallouts (literally and through the revolving door).

But surely we can’t lay the blame squarely on IT. After all, traditional models of software design and project management where we diligently survey the client’s needs are baked in common sense. Add to this the rigor and procedure around sign-offs, budgeting, design, development, testing and deployment – doesn’t this guarantees success?

Of course it doesn’t. Apart from the big fat fails, we also end up with what I call a big “sucking culture”– your software sucks, IT operations sucks, this job sucks, our business sucks – we’ve all been there, haven’t we?

All of this isn’t due to bad people and technology. It’s because we work on the premise that the business understands what it wants – it doesn’t. Much better then to put aside “bigness” and start listening (maybe insisting) that the business first lays all the wicked cards on the table, like – what are our markets and how is this changing? What are our target demographics? What are our barriers to entry?

After all this ‘warts and all’ revelation, it’s time to get busy. Now, with a shared understanding, we can start quickly prototyping elements that perhaps only solve one small problem. Then we continuously develop, test and demo, knowing and accepting other problems will surface that need to be solved. And, as we know from agile development, it’s all a case of ‘rinse-and-repeat’ – hopefully achieving a state of nirvana – giving your customers software answers to problems they don’t know they have. Problems that lead to increased market share, revenue and profitability.

So is a liberal scoop of Agile or its younger DevOps cousin the answer? Not necessarily — that is until some essential toppings and flavors are added to my somewhat vanilla perspective:
- Executive Flag Waving – try selling a methodology or philosophy based on the premise you’re trying to solve problems you don’t yet understand. Good luck with that. If executives simply want faster, better, cheaper, it’ll be much easier (and safer) to hold back grandiose talk about experimentation, “failing fast” and continuous improvement. Understand, however, that without tangible commitment, half-assed agile or DevOps is like a fast melting ice-cream cone – messy and hard to handle.
- Behavioral Hacking – even with executive champions, persistent and rigid organizational behaviors will need to change. Just hiring lots of agile coaches or mandating DevOps won’t work until there’s willingness for people to be engaged around new ideas and fresh thinking. With that in mind, be prepared to do some heavy lifting – socializing and selling new concepts, but also looking for opportunities to show how the smallest of changes (e.g. team refactoring, incentives) lead to improvement.
- Show me the Money! – So how to you fund agile and DevOps? It’s going to be tricky to cost something exactly when you don’t know the exact outcome of a new project, but businesses may initially insist on this to minimize risk. My advice here is to tread carefully. Stakeholders should be more interested in ROI than coming in under budget, so fixed-cost might not be actually what want anyway. Your job therefore is to convince them by continuously demonstrating ROI – not just from a single project, but also by the accrued savings that agile and DevOps deliver the whole organization when they systematically reduce technical debt and waste.
Developing the wicked traits I’ve described doesn’t mean IT has suddenly become an evil entity. Nope, it’s just a case of tapping into fantastic business opportunities in a constantly changing digital world. Agile and DevOps can help you solve and even create some wicked problems for your customers, but that involves confronting and challenging entrenched thinking as it relates to just about everything.
March 3, 2015
DevOps Perspectives from Pink15

I recently had the privilege of covering the Pink15 conference on behalf of devopsy.kinsta.cloud. Pink Elephant is a renowned leader in ITIL and ITSM education, consulting and conferences. Now in its 19th year, the Pink conference brings together attendees from a wide range of vertical markets to learn and share about IT service management and related topics. My mission was to take the pulse of DevOps in the ITSM enterprise community, many of whom represent the operational side of IT.

Let me start by saying that this was a well-organized and executed conference. The attendees that I spoke with unanimously agreed that the sessions were relevant and the peer networking invaluable. And while there was not a specific Devops or Agile track, the core concepts were directly or indirectly present in several of the sessions.

One particularly interesting session was on “Enterprise Change Management in an Agile, Fast Moving World” from a large retail organization. The presenter did a good job of describing how they are adapting their categories of their changes to meet the growing requirements for a more agile change management process. At present, only 5% of changes are categorized as “fast track” – an even more expedited route than what is normally considered a standard change. This organization’s goal is to exponentially increase their ability to fast track more changes in response to increasing demand. This session was a good indicator of how enterprise IT is recognizing the need to adapt for continuous delivery and more automation.

More than one attendee shared their appreciation at being able to interact with other IT organizations about specific ways to bridge the practices between Dev and Ops so as to make service management more agile. One person mentioned that while some of the sessions did not specifically call out DevOps or Agile, presenters often had to address these in depth during the question and answer period. There was particular interest among attendees in learning how to engage developers in processes such as Event, Demand, Capacity, Availability, Change and Release Management.

Some attendees expressed concern about the perception that ITSM and ITIL have no place in a DevOps culture or that DevOps would somehow invalidate the investments that many organizations have already made in establishing better processes for managing services. Kaimar Karu, the ITSM Product owner for Axelos (who owns the IP for ITIL) strongly believes that ITIL is absolutely a key player in the realization of DevOps as a philosophy. ITIL processes are not specific to operations – they enable the entire lifecycle of a service or product from development to deployment and into operations. ITIL was meant to be adopted and adapted; nowhere does the guidance recommend that the processes be complex, bureaucratic, lengthy or manual.

So what does all of this mean? While DevOps is not yet fully understood, organizations are taking tangible steps to make ITSM processes go faster, integrate with other practices and leverage automation in order to deliver more business value. Wouldn’t you call that DevOps?

February 27, 2015
DevOps & Continuous Change

A remark by a colleague while waiting for the coffee machine to complete its cycle started my train of thought. “Should we have multiple minor releases or just do a few major ones in a year?”

In large organizations, due to many factors, the turnaround time for a single successful release is quite extensive; but if the conceptual change which we are talking about bringing whilst using the #DEVOPS methodology would not only reduce these long cycles but deliver quicker and quality software.

I have already discussed in my earlier article “DEVOPS: Getting our organizations aligned” on the traditional approach and how the combination of this two (DEV & OPS) has been proven beneficial in various organizations and how many are still hesitant in embarking on that path.

Continuous Change which encompasses both Continuous Integration and Delivery is paramount to achieving this objective. To attain the objective of delivering rapid and consistent value to the stakeholders regularly, we have to have Continuous Change happening.

I am sure we have already moved out from the Mainframe era to a more Distributed systems state. But unfortunately we have yet to let go of that culture where we pile up components on a single quasi Distributed Application, instead of creating smaller independent, yet interdependent systems.

So, back to the same question; shall we go with a few Dinosaur sized, labored releases or make multiple short and swifter runs? In my opinion, we should strive towards the leaner model. Easier said than done you say! Agree. If I have to, then I would go about it this way:

In an environment having a suite of Distributed Applications, start with Analyzing the components which make up the Major release, List out the changes (fixes and new features) which are planned, asses functional and technological impact, Identify dependencies, upstream/downstream connectivity’s, architectural deficiencies, list out the identified subset of components or group of components by functionality, which can go as an independent release.

I am resisting the urge to say ‘standalone’ as with the current set of complex intervened collection of applications, it would be an incorrect statement. It would rather be a subset of components which can be independently upgraded. Now the big task is to review and decide if this subset or group would add functional value to the overall suite of applications without the rest of components going in.

Once identified, the success of this release working as expected would be in the extensive testing (Unit/ Regression/Performance) of these components, and as we gain confidence in this split and deploy procedure, we can start with, prioritizing and scheduling critical must have features or bug fixes which also should be backward compatible with other components lagging behind. We can even come up with scenarios where these components are not just getting updated frequently, but would also have multiple independent tracks. Of course it goes without saying the testing and signoff process is strictly followed albeit in a shorter window.

Deployments to production have always been a source of heartburn to the OPS teams, we have often seen finger pointing and firefights to contain change fails. In order to maintain stability and maximize availability, stricter controls and reduced deployment windows are put in place. In promoting frequent and smaller component level changes, OPS will also be in control of what’s going in, and smaller component level releases can be rolled back quickly within the Green-Zone window if the change is not working as expected. Though I would categorize this rollback, as a process fail than a deployment fail, and should be reviewed very seriously with right mitigation plan and lessons learnt retrospection, Continuous learning after every successful or failed sprint ensures competent and confident releases.

Another major factor impacting multiple runs of Production releases is the long Green-Zone windows, by moving to the quicker and leaner deployments cycles, these requests can be substantially reduced, and can eventually aim to reach a stage where changes are deployed online without extensive downtime.

Similarly, frequent maintenance activities when there are no planned deployments, effectively has the same risk on environment unavailability. Analyzing and moving to a state where these activities are conducted online without a Green-Zone would alleviate the maintenance downtimes and ensure seamless availability, adding stakeholder value.

I have not touched on the Continuous Integration or the Automation of the deployment process for obvious reasons, we can’t achieve the objective of Continuous Change without having the Integration process in place where incremental changes to code are build into a package swiftly and seamlessly, even a sanity or basic testing might be integrated to ensure the quality of the builds. Same goes for automating the deployments, develop & integrate tools required for rapid deployments. We have seen instances where automating a single activity or revisiting a process has created substantial time savings.

While it’s easy to propose changes to the Release Process or advocate rapid deployment cycles, we have to ensure adequate checks and balances are in place, compliance adherence and audit trails are created.

Now to the most important measure of this article, Cost Savings!

Proponents of the Dinosaur Releases would argue that the common activities which entail a single release like the builds, Testing, Release Management, OPS availability or reduced GZ would cut costs and multiple runs to PROD would logically increase costs.

But it’s definitely the other way around, we wouldn’t need to feed the Dino anymore, it will be a cost worthy rapid delivery with optimized resources, a leaner process where DEV and OPS are working together to ensure quality value added deliverables are made available to business faster.. This cultural change and collaborative effort also creates new vistas of growth and provides a perfect platform to excel. The cost benefit analysis would eventually be in favor of Continuous Delivery.

Opportunity cost is another variable which has not been considered; an innovation or a new feature available to customers quickly with reduced time to market cycle will provide the much needed edge in these competitive times. I recall some conversations where a few must have’s were pushed out due to various reasons, frustrating the business.

DEVOPS was never meant to replace the traditional approach to software development; rather it is an efficient use of the existing resources within a collaborative model to rapidly deliver quality software products. A major cultural shift in our approach is required and to reach that goal we need to embrace the shades of grays, many a times over 50 (sorry, couldn’t resist) when it’s not truly black or white.

Thank you for the time.

Visit my blog http://askhurram.com/

Read On, Live On.

February 24, 2015
Why are we still asking, “Can DevOps work here?”

It’s easy to get tired of buzzwords, especially in the software development and testing world where they’re so prevalent. But while it’s easy to blame the thought leaders and evangelists for creating them, and publishers and powerful marketing teams for inserting them into every content channel imaginable, the buzzwords that truly stick around do so on their own merit.

Agile, big data, and cloud have been written about and philosophized for years—and I hate to break it to you, but they’re not going anywhere. While they may not be the panacea that some make them out to be, their impact on the way we develop, test, deploy, and release software has been documented in every market and industry around the globe. This gives the words their staying power. Not relentless press coverage that’s been covertly sponsored by marketing and PR dollars.

Members of the academy and esteemed buzzwords in the software hall of fame: join me in welcoming our newest member: DevOps.

You may say it’s too early, and that DevOps hasn’t been around long enough to earn such universal acceptance. Many quickly cite John Allspaw and Paul Hammond’s 2009 presentation, “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr” as the real inspiration behind Patrick Debois’ coining of the term, and if you’ve never viewed the session, I can’t recommend it enough.

Skip ahead to today and we’ve got multiple conferences that focus on DevOps exclusively. Devops Days, DevOps Summit, DevOps Connect and DevOps Enterprise feature some the most respected speakers and writers alive today.

But they’re not the only ones speaking there. CTOs, CIOs, chief architects, IT heads, and QA directors from every bank, retailer, hospitality group, government agency, and software development shop are there, too, and with a captivatingly similar story behind their employer’s decision to “do” DevOps.

They were stuck. Their software was late. It didn’t address their customers’ real needs, and it didn’t address their own company’s needs. Their application stacks were growing increasingly complex, the bottlenecks in their SDLC were increasing, and their ability to innovate, accelerate, and stay ahead of their competition was slipping further away from them.

What I find especially interesting in re-watching many of these conference sessions is that a lot of them were also leveraging the other buzzwords mentioned above. They’d been practicing agile for years, and they’d started to look to the cloud to lighten their hardware dependence and provisioning headaches.

What they all needed, and thankfully found, was a disruptor. And no matter what definition you attribute to DevOps (and good grief, there are so many) there’s no denying its disruptive nature.

It disrupts the culture of your dev, QA, and ops teams. It requires constant communication, more deploys, earlier testing, shifting left, an embracing of “failing fast and failing often” and what’s often described as “relentless automation.” Some would even argue that the hardest part of DevOps is getting executive buy-in and sponsorship so that you can even begin your initiative. Though to be fair, your ground level troops should be just as on-board as your commanding officers in order to have the best chance for success.

Joachim Bauernberger at InfoQ recently looked into whether DevOps can work in Telecoms, and it turns out, like in any industry looking to resolve the constraints and bottlenecks listed above, it most certainly can—however, it requires support and commitment from “all links in the delivery chain.”

And this is the only reason you should be asking, “Can DevOps work here?” Do you have the right people, and are you the right person to increase the likelihood of this disruptive shift within your company? Stop wondering if (or worse, doubting) your industry will support DevOps, because each year and each conference that passes proves that it can.

And soon enough, if the people at your organization are exposed as the real constraints and bottlenecks, they’ll be removed. Don’t be one of them. Be disruptive.

About the Author/Noel Wurst

Noel Wurst, Managing Editor at Skytap, Noel is responsible for setting and executing Skytap’s content marketing strategy. That includes overseeing the creation and distribution of high-quality, targeted content, and managing the team and external resources associated with those efforts. By leveraging deep online marketing, project management, and editorial experience, Noel plays a crucial role in helping generate and nurture leads with compelling content. You can follow Noel and Skytap at @NoelWurst and LinkedIn and @Skytap, Skytap’s LinkedIn

February 12, 2015
Healthcare information provider streamlines deployment with DevOps

Streaming music and online shopping are just two of the ways technology and the Internet have changed our way of life. One of the other major shifts in culture has been the ability to research symptoms and self-diagnose medical conditions. One online healthcare information provider recently teamed up with IBM and embraced DevOps to streamline development and deployment of features and information for customers.

In a case study titled A healthcare information provider cuts deployment time down to minutes, IBM details how this healthcare information provider—which remains anonymous—used IBM UrbanCode Deploy to get products to market faster. While the name of the company is not disclosed, IBM does reveal that it is a United States company that employs approximately 1,500 people, and develops and maintains more than 200 applications.

The case study describes a scenario that is probably common across many companies regardless of industry:

The organization’s existing deployment solution combined tools designed for other purposes, such as administration or content management, and strung them together with custom scripts. The process also involved many manual steps, which introduced the potential for human error. Developers and quality assurance (QA) teams were bogged down with the numerous administrative steps required to request a new deployment. And the company’s web operations team was spending much of its time deploying production and QA environments.

“In many ways they are a classic DevOps story for a mid-sized organization (1,500 people) with a heavy tech component,” stated Eric Minick, DevOps evangelist for IBM. Minick explained that development at the organization had shifted to agile, and that applied pressure downstream on operations. The natural evolution from there to keep up with development and continue to meet business needs was to automate aggressively and improve collaboration between developers and IT operations. In other words: embrace DevOps.

Minick told me, “The medical element almost doesn’t matter here—except that this is a place where I would go to get health information to make decisions that impact the well-being of my kids. They trade in trust.”

An outage would have financial consequences as it would for any company that engages with customers over the Web, but the more crucial issue for this company is its reputation—and the need to earn and maintain the trust of its customers. “In a lot of ways, this is the same fundamental challenge that banks have. You have to be consumer facing, compete with new money transfer startups that move fast, but if people can’t deposit their paycheck in time to make rent, you lose customers quickly,” said Minick.

For US Health insurers, the past couple years have been very interesting. The Affordable Care Act has forced the health industry to shift from thinking of the insured as a secondary customer (the employer being the primary) to really shifting into a business-to-consumer (B2C) business model. The change in perspective makes their systems of engagement more critical to the business, and being able to experiment and rapidly deliver has become more important.

Minick stressed, “At the same time, they have significant regulatory burdens requiring them to have strict controls, and security protections. Meanwhile, operating efficiency has become even more important as overhead / profit is capped as a percentage of premiums. This nets out to a requirement to be able to change more quickly, without additional risk or cost.”

A vice president from the healthcare information provider shared some thoughts on the benefits of working with IBM and embracing DevOps. “The fact that we had development, QA and ops engineers all in the same room choosing the tool, that process and the standards really created a sense of collaboration and let everyone walk in the other person’s shoes, understanding the challenges others face. To me that’s what the DevOps culture is about: breaking down the walls and letting staff understand everyone’s challenges. Everyone benefits from using tools and processes like this.”

February 12, 2015
DevOps: Where are we with that?

There’s a great scene in the Kids in the Hall movie Brain Candy, where the CEO of a major pharmaceutical company informs his executive team that the board has recommended a massive restructuring plan that will cut their research outlay by 60%. Only seconds after first mentioning this undertaking, the CEO turns to his yes man, Marv, and asks:

“Where are we with that?”

Marv responds: “The thing you just mentioned just now?”

And after getting an affirmative response, Marv foolishly, yet not surprisingly answers:

“Oh, we’re on top of that, Don.”

It’s not hard to imagine this same scene playing out in real life where the restructuring being recommended is that found in DevOps. Marv and his fellow executives have agreed to a restructuring plan that’s going to dramatically affect the flow of work and the lives of many people at their company, but without having any real idea of why this plan is needed, how much it will cost, or even where to begin. They’ve just been asked to reduce the cost of their product by 60%, and to begin, well, five seconds ago.

Sound familiar?

There was a time when DevOps was possibly an even bigger buzzword than it is today, but that doesn’t mean it has gone anywhere, or lost popularity. In fact, its adoption has only increased since the term was coined, and it can be found everywhere from the smallest shops—all the way to massive enterprises.

So why is it still so hard to successfully pitch DevOps to executive leaders?

We’ve written before that the ambiguity around DevOps’ definition is one of the primary causes of the confusion surrounding the term, and the debate between whether it’s a “mindset” “practice” or “cultural shift” will likely never die (just don’t let anyone tell you it’s a “tool”).

Rather than argue the buzzword’s definition, many at last year’s DevOps Enterprise Summit argued that the best way to promote a DevOps initiative at your organization, especially to your executive leaders, is to not call it DevOps at all.

Since I’ve always liked the term DevOps, it’s taken me a while to come around to this concept, but I think those esteemed speakers are on to something.

Vendors, analysts, the media, and other stakeholders have all had enough time to develop their own personal assumptions around DevOps. Maybe it was first proposed to them by an overblown consultant, or it was part of the failed vision of a former executive who is now on the outs. All it takes is one negative DevOps word association within your leadership and your noble pursuit of its buy-in could be quickly derailed.

So if you don’t call it DevOps, what do you call it? “Lean IT?” “Agile Innovation Processes?” “Continuous Flow Delivery?” “ Industrialized Software Development?”

It’ll take you more words, but I’d recommend using DevOps’ results, and not any perceived buzzworthiness of the term alone, as its primary selling point. While “more words” means “more time”—something your e-staff likely has very little of—you’ll both get and hold their attention much quicker than just saying “DevOps” and expecting the applause and champagne to start flowing.

Gene Kim’s definition of DevOps supports this concept, and in a recent interview he remarked:

I would define DevOps by the outcomes. In my mind, DevOps is those set of cultural norms and technology practices that enable the fast flow of planned work from, among others, development, through tests into operations while preserving world class reliability, operation and security. DevOps is not about what you do, but what your outcomes are.

For those who are somehow just learning about DevOps, or for those who have known of its existence for years now, but who have been hesitant to pitch it to their own leadership, the good news is that the outcomes of DevOps are being proven not just at big names like Disney, GE, and Netflix—they’re even being felt by those who’ve implemented it at non-Dev or Ops fields like Security, and even Design.

Your VPs of App Dev and QA will likely be impressed by your mention of accelerated feedback loops and reduced defects. Your IT Operations leadership, no matter what distrust they harbor for app dev, would have a hard time arguing against increased visibility into the delivery pipeline, and better quality when the software lands in production. Then when the CEO hears about faster service delivery and improved time to market, you may as well start sketching out your plans for that corner office.

(Editors note: Author’s promise of a corner office is his own, and is not guaranteed by Skytap)

About the Author/Noel Wurst

Noel Wurst, Managing Editor at Skytap, Noel is responsible for setting and executing Skytap’s content marketing strategy. That includes overseeing the creation and distribution of high-quality, targeted content, and managing the team and external resources associated with those efforts. By leveraging deep online marketing, project management, and editorial experience, Noel plays a crucial role in helping generate and nurture leads with compelling content. You can follow Noel and Skytap at @NoelWurst and LinkedIn and @Skytap, Skytap’s LinkedIn

January 30, 2015
Five essential Ops strategies that help make DevOps the real deal
With its roots in Agile and Lean thinking it’s not surprising that DevOps is often looked at through a development lens. After all, it’s proving absolutely essential to support accelerated delivery times; providing a much needed jolt of velocity to protracted development cycles. But of course with the increased need for speed there’s always the danger that quality can be compromised – so much so that faster time-to-value can very quickly become faster-time-to-failure.

In what seems like a byzantine age of enterprise computing, IT operations tended to call the shots when it came to delivering quality. Sure, a transactional system might suffer a glitch or two, but since constituents were largely internal and customer’s generally one step removed from the application and business process, the impact could often be controlled. Ah, so much for the good old days.

But as we know this model hasn’t just changed, it’s been completely disrupted.

Quality is now a different headed beast that bites hard in many places. It bites when customers engage directly with your brand during discrete mobile moments – like when they compare your goods in the shopping aisle with a mobile app, or assess car insurance based on your ability to provide usage-based policies from their in-vehicle software system. Yes, speed is important in the application economy, but it’s also a high quality customer experience that shapes the winners from losers.

The fabulous thing about DevOps is the fundamental premise that teams can collaborate in real-time to establish, maintain and continuously improve the quality of software systems and applications. For operations this doesn’t mean waiting for applications to reach production stage before enacting performance management processes. Rather, it involves instantiating best practices throughout the development cycle – that way teams resolve quality issues much earlier in development (where they are cheaper to fix), while also preventing a cumulative buildup of crippling technical debt.

So with application quality and customer experience being essential for DevOps success, what are some of the ops related strategies we can employ to support better business outcomes?

I see five essential, ‘rubber meets the road’ strategies ops can use to help DevOps become the real deal:
1. Focus collectively on the user experience – too often organizations become detached from business reality by looking inside-out from a silo’d technology and diagnostic perspective. DevOps practitioners put themselves in the shoes of the customers by constructing, visualizing and managing end-to-end user-centric service views that traverse functional boundaries. Additionally, user-experience management will involve gaining deeper insights into real-time performance of externally facing applications and mobile services, bringing to the forefront analytics to guide decision making and drive continuous improvement.
2. Give Developers a clear view of how code works in the real world – operational intelligence shouldn’t wait until applications are moved into production. Rather, it should be instantiated across every stage of the lifecycle – whether that’s during regression and unit testing, or pre-production. Many teams recognize this by for example activating monitoring during release automation; giving developers critical insights into both functional and non-functional code behaviors. Others go further, taking user-experience to another level by exposing key behavioral and usage-based intelligence – especially for newer mobile apps, APIs and digital services.
3. Create a single source of the truth using a common framework – to be fully effective, developers and operations should reference a single version of the truth when it comes to problem triage and resolution. Traditionally this has proved difficult with teams having discrete tools providing diagnostic insights into one aspect of technology. This however falls short due to the complex interdependencies across technologies and results in finger pointing and blames games when problems can’t easily be pigeon-holed. To address this, operations teams use a common unified framework that quickly discovers and exposes infrastructure and application configurations, and importantly the relationships and interdependencies that exist between them. Now, root-cause can be quickly established from either an application or infrastructure perspective, but always prioritized according to business and customer impact.
4. Define common goals across teams and use shared metrics – traditionally development and operations teams have been incentivized according to separate goals that are often diametrically opposed (e.g. speed of producing code –v- resilience and availability). By using shared customer and business-centric metrics, developers and operations build a ‘common language’ for evaluating progress and understanding the impact of change and continuous delivery. My advice here is quality over quantity; building out metrics that are actionable by all stakeholders. For example, this could include lead and cycle times to pinpoint operational bottlenecks and waste during deployments, or transaction response monitoring in pre-production to pinpoint code deficiencies and avoid technical debt associated with provisioning unnecessary capacity.
5. Converge around a common understanding to transcend organizational boundaries – a collection of diagnostic based monitoring and alerting provides little more than vanity metrics and feel-good green lights. Sure, they can alert operations to when something is broken, but they do little to drive the more essential element of DevOps success – feedback. Therefore common understanding involves operations automatically correlating performance information end-to-end so as to expose far more beneficial insights that developers can use to improve the code base.
At the recent Gartner Data Center, Infrastructure and Operations Management Conference in Las Vegas in December, I presented a session – Unified Infrastructure Management is Critical to Enhancing the Ops in DevOps – that further described these strategies together with supporting use-cases. It was certainly a dynamic and lively session, highlighting the viability of DevOps. As organizations look to increase speed to market of new applications while both lowering cost and increasing quality, DevOps will continue to gain traction, and I can’t wait till everyone truly understands its transformative power.

About the Author

Aruna Ravichandran is vice president of DevOps Solution Marketing and Management at CA Technologies, responsible for cross-portfolio solution marketing for DevOps across all product lines. Before joining CA Technologies, Aruna held several management positions in product marketing and engineering at Juniper Networks and HP. Aruna earned an MBA and master’s degree in Computer Engineering from Santa Clara University and holds a bachelor of science degree in computer science from Bangalore Institute of Technology. Ravichandran is on twitter @aruna13 and on linked in
January 9, 2015
Awkward questions for those getting started with automation
This blog asking awkward questions for folks jumping on the microservices bandwagon was enlightening from the perspective that many of the same questions are applicable to operations as they begin to tackle operationalizing all the things in an application lifecycle.

For example: “What is your deployable unit?”

Great question, isn’t it? What is your deployable unit of automation? Is it per service? Per device? Per cluster of devices? Per container?

Wait, but there’s more from this great list of awkward questions:

Is it acceptable for another team to take your code and spin up another instance of your microservice?

Can team A use team B’s microservice or are they only used within rather than between teams?

Do you have consumer contacts for your microservices or is it the consumer’s responsibility to keep up with the changes to your API?

Is each microservice a snowflake or are there common conventions?

How are these conventions enforced?

How are these conventions documented?

What’s involved in supporting these conventions?

Are there common libraries that help with supporting these conventions?

All these questions are applicable to devops, in particular, as you go about building out automated scripts, systems and orchestrating processes that operationalize the data center and make it a lean, green deployment machine.

You are going to have some kind of code, whether it’s a script or a recipe or a template of some kind, and questions regarding the usage of that code is important. Can others use it? Change it? Claim it as their own? Are they useful in a general, “here’s a basic load balancing provisioning and configuration script” or are they specific, as in “this is a piece of code that provisions and configures the networking required to ensure all 18 tiers of this very specific application can communicate”?

And as you’re developing those scripts (that code) are you documenting it? Are there <gasp> comments? Do you use a standard convention for code formatting (cause let me tell you, where you place your brackets is a matter of great technical religious significance)?

Most of those jumping into automation head first aren’t thinking of the long term ramifications of the choices they are making right now. Proof of concepts turn into pilots that turn into systems upon which all of IT relies. Rarely are you given the opportunity to go back and put any kind of standard conventions or practices into place. That’s what builds technical debt in software and, no matter what you think you’re building with those scripts, you’re building software.

Adopting the technical and methodological practices of agile development is a good thing, but let’s not ignore that along the way from waterfall to agile developers have learned a lot of lessons the hard way. That means we should, as practitioners of software-related activities within operations (and that means any one of the four operations groups in IT), pay attention to those lessons and try to avoid the pitfalls that developers have already encountered and, one hopes, overcome.

To do that, don’t just ask the awkward questions; answer them.
January 7, 2015