devopsy.kinsta.cloud

Tag: devops adoption

Embracing a DevOps Culture, Part 2
In Part 1 of this series, we discussed the fact that more organizations are looking to embrace the “DevOps culture.” However, unlike ITIL, implementing DevOps into an organization does not happen overnight. DevOps is more a philosophy than a procedure, and choosing the right leadership team is as important as choosing the right tools.

In Part 2 we look at other important elements of organizations successfully embracing the DevOps culture.

Without Proper Collaboration, DevOps Initiatives Will Fail

A good test to determine if your organization has truly embraced the DevOps culture is how well your IT department responds when a major incident occurs in the product environment. For example, an e-commerce company’s dramatically slow website, a hospital’s unresponsive electronic medical record (EMR) system, and a malfunctioning airline reservation system. In these chaotic situations, every minute counts and all Dev and Ops hands need to be on deck to keep your organization afloat.

When incidents occur, it’s critical that your organization’s Dev and Ops teams work together to resolve the problem and restore failed service as quickly and efficiently as possible.

Incident Response: The Critical Incident Team

An international company with global operations may have network operations centers (NOCs) in the United States and the U.K. that support more than 50 mission-critical business applications, development centers in China and the United States and a service desk in the United States. When an incident occurs, the company’s service desk is flooded with alerts, ranging from various IT monitoring tools and customer phone calls to open tickets from online users and inquiries from stakeholders. When that happens, the only concern of the service desk is to fix the issue—not tracking down a department head on the other side of the world that may be responsible for the problem.

DevOps should enable an organization to assemble its critical incident team in only a few minutes. The Ops team should know exactly what team(s) to contact for a given incident, and who from those teams is assigned to application support. They should know who is on call based on the time zone and day of the week, and have the correct phone numbers easily accessible.

Next, the team should review the technical details of the issue provided by the incident manager. The universally used DevOps toolset enables everyone to speak the same language, quickly identify the root cause, put a remediation plan together to have approved by the emergency cab, deploy the fix, test it out and confirm service is back up and running.

IT Communication: The Glue That Holds Dev and Ops

To be successful, organizations need to be able to respond as quickly as possible during a major IT incident to limit the negative impact on the business. This is achieved when Dev and Ops works together to create a central communication and collaboration center to ensure proper communication with key stakeholders.

An organization’s ability to effectively mitigate the impact of an IT issue relies heavily on its ability to access and communicate critical information, and to ensure the right people can analyze it and initiate the appropriate actions to keep the business running smoothly. The communication hub equipped with an IT communication solution will facilitate:
- Reaching out to the right on-call people among all the different teams: infrastructure, server, system administration, middleware, network, DBA, QA, support team, service desk and the application developers.
- Because emails don’t wake up people, they will be able to leverage the IT communication solution to reach out to people via multiple channels until they respond (voice, SMS, email, push notification app, paging, etc.), or automatically escalate to the next resolver on the on-call list.
- Providing the right information so the IT resolvers start investigating the issue, identify the root cause and put a resolution plan together without wasting time.
- Get people to collaborate together using the same telecommunication and collaboration tools whatever the time zone and wherever they may be located.
- Contacting a third-party vendor in case the problem is not attributable to the company but caused by an external piece of software.
- Informing the other departments if the business impact grows so big that it affects the company profitability or reputation, such as a cyberattack leading to a data breach for instance. The CEO, legal and marketing may need to be informed to anticipate the consequences.
- Informing end users or customers to limit the number of incoming calls into the help desk.
The benefits of quick collaboration and not just handoff between the teams don’t even have to be demonstrated. Removing the broken pathways, obsolete delivery methods and redundant platforms will improve significantly the organization’s ability to communicate during critical moments. Becoming more efficient and removing the time wasted will automatically have a huge impact on the mean time to know (MTTK) and, in turn, on the mean to resolve (MTTR), hence minimizing the disastrous impacts on the business and keeping the company’s execs sleep at night.

DevOps Culture Can Happen

Embracing a DevOps culture is not a Big Bang change that happens overnight. This is a journey that will be more or less difficult to pursue based on the existing culture and the history and maturity of the IT organization. Even more importantly, it will depend on the level of commitment from upper management to introduce a new culture. Leaders need to embark on this journey keeping in mind that not only will it require new common tools and new common processes, but also they’ll need to convince people of the value of such transformation. To achieve this goal, management should consider IT communication as a key element, which will be the glue that binds Dev and Ops together. And because there always will be room for continuous improvement, the road to DevOps will have no end.

About the Author/Vincent Geffray

Vincent Geffray is Senior Director of Product Marketing at Everbridge with focus on IT Service Alerting & Communications Automation and IoT.

He has more than 14 years of experience in the information technology business, designing, promoting and selling Enterprise IT Operations Management solutions, including Critical Communications, Application Performance Management, IT Process and Workload Automation. He also has international experience as he started his career in Europe. Vincent holds a Master of Science (Mechanical Engineering and Computer Science) and executive certificates from the MIT – Sloan School of Management.

Vincent’s LinkedIn: www.linkedin.com/in/vgeffray

Vincent’s Twitter: @vgeffray
May 10, 2016
DevOps by Osmosis — Is That Even Possible?

“We don’t do DevOps. We can’t, as our development plans are agreed so far in advance and our priority from a production point of view is to keep our systems available 24/7.”

I heard this comment from a pal of mine as we had a quiet beer over the weekend, but I’m sure this comment, or a variation on it, has been uttered many times in many places. Here’s the irony: I had met my pal, who works as a developer for a major financial services company, after he had had the week from hell. His group tried—and succeeded—to fix a major system issue that had come out of the blue. He had certainly earned the beer that week.

So, I asked him: “How did you get the problem sorted in the end?”

“Well, we had to form a Tiger Team,” he replied. “Pulled together some of the DBA team, the key developers and the Ops guys, worked throughout the night and managed to keep the systems up and running the next day, while we used that time to address the root cause.”

“How did you get around the Governance guys?” I asked.

“Well, we brought one of them into the team for a few hours, and she was able to get us past some of the key bottlenecks,” he said.

“And how about QA?” I asked.

“Oh, they knew this was a major issue and so we cut out a lot of the QA and just went ahead,” he replied. “It was a bit risky, but we had all the right guys in the room to fix anything that cropped up.”

“So, you manged to get a major change through in a couple days, kept your systems up and running, kept your customers happy, and earned that beer,” I said.

“Yep, that’s about it, alright,” he said.

“So, that’s pretty much what DevOps is all about—minus the emergency element,” I pointed out. “Seems to me like you guys are already on the DevOps road.”

It was about then that the penny dropped with my pal. He suddenly realized that yes, they could do changes quickly, yes, they could do them in an orderly manner and yes, they could keep their systems up and running while all that happened. But, as quickly as the penny dropped and the realization dawned on him, the light went out again.

“There’s still no way we can do DevOps in our place,” he said. “There’s too many hurdles to overcome, too many guys used to doing things the existing way, which to be fair, has worked well for us. To be honest, there’s too many guys who would feel under threat if we suddenly changed how we do things.”

And that, in a nutshell, sums up the major challenge facing people promoting a DevOps approach. I have spent many years in the IT industry; I go so far back that I wrote my first code using punch cards (look them up) so I’ve seen change come and go, and change has been the one constant. I think many people in the IT industry have become too focused, whether it’s on the latest tools in their area of expertise, or on the newest piece of kit that has been bought, or indeed on the latest problem the business has put in front of them. The industry has become mature—if we compare the IT world to a field such as medicine, you pay passing attention—if you even notice at all—to things outside your specialty field.

Now that’s right and proper. I don’t want an orthopedic surgeon trying to fix the problem with my eye, and I don’t want a DBA to write me some code. But when something comes along that affects the whole industry, I want them to pay attention and not ignore it.

Daysha ran a lunchtime seminar last week, and we titled it “BizDevOps – DevOps isn’t compulsory but neither is survival.” We wanted to use this seminar to engage business people who, let’s face it, are the people we support and who need to understand how IT can make things better. Somewhat disappointingly, while we attracted a great crowd, they were all IT people. No one from the business attended. Now maybe we advertised this event in the wrong places, or maybe we held it in the wrong place, but here’s the thing: We attracted IT people from major companies, and none of those IT guys said to their business people, “You need to hear about this, come along for lunch.” I hope that after our seminar they went back to their business people and said just that, and maybe the next lunch will have the business people in the majority.

When PRINCE came out into the project management world, it was not bought into by a majority of project managers. The same happened with ITIL. And the same will happen with DevOps. It is fair to say that PRINCE and ITIL are pretty much standard on a worldwide basis. I am old enough to remember the time I first heard of them, and the time I did my first course and passed my first tests, but nowadays, they’re part of the furniture—taken for granted, and rightly so.

I think people are a little bit afraid of DevOps, and I can see why this is the case. Think about it for a second: Someone is now saying that the way we have done things for years has to change. That we can do things better, faster, with higher quality, but we just can’t do the massive 12-month long project in the same way. We might need some new tools, primarily on the Ops side. We might need some new skills—again, primarily on the Ops side. But, by the way, we’re not going to do away with the Ops guys (so don’t expect to make major budget savings there). But here’s the thing: Our end customers will notice the difference, and so will not be tempted by the new kid on the block—who, as it happens, is probably using a DevOps approach to develop his application, which is threatening our business.

Change is scary, it’s not easy, and making a major change while you’re still having to churn out the new business requirements, and keep the current systems running … now that’s really scary. But, like my pal whom I shared the beer with last weekend, maybe you’re not as far away from that change as you think you are, maybe it’s not as scary as you think it is, maybe it will affect people positively, maybe you just have to do it.

About the Author/John Brophy

John Brophy is currently Head of Professional Services at Daysha Consulting in Ireland, where he leads a team of 25 project managers and business analysts working on projects in blue-chip clients. He is a 35-year veteran of the IT industry, starting out as a database systems programmer, moving onto leading a team of systems programmers looking after what were then called midrange systems. He then became a senior project manager with a global IT company and followed that up by running his own IT infrastructure support company for 6 years. His background is Ops – and he is proud of that!

May 3, 2016
State of DevOps Survey – The Ultimate Feedback Loop

If there’s any consistent criticism of the larger DevOps movement, it’s that the talking heads and industry gadflies are driving the conversation, not the people in the trenches.

All the thought leadership panels and “how-to” content (including the written and AV materials on this very site) make for great watercooler discussion, but lack the input of those dev, ops and IT management pros who are actually living the DevOps experience, some critics have said.

Well, fair enough. Talking heads are paid to talk. Thought leaders are chosen to lead the debate at conferences and on webcasts. Bloggers blog. Reporters report. This is simply the way of the world. Certain voices are heard via the channels they frequent. It is, as so many people are fond of saying these days, what it is.

So what about everyone else? What of the people reading this stunning prose and listening to these talks while rolling their eyes based on the connectivity of it all to their real-world experience? How can their voices be heard?

Independent of jumping into the blogsphere or applying to speak at said industry events – which you should, btw – there’s one significant opportunity available to anyone who cares to take the time – participating in industry research.

Over the next few business days, citizens of the DevOps world will have their last chance to contribute to the industry’s most widely read and respected research project, the State of DevOps Report.

If you haven’t done so already, take the time to fill out this year’s survey, and make sure that your voice is heard when the subsequent report is published in June. Sure, it takes a little time, about 15-20 minutes; but that’s because it goes to the trouble of exploring the real-world issues that weigh most heavily on today’s practitioners.

Why is this particular project so important, or even credible? Consider that the minds behind the survey and analysis resulting in the 2016 State of DevOps Report are those authors and talking heads that actually get the most respect.

Backed by DevOps Research and Assessments (DORA), the independent think tank operated by a partnership of Jez Humble, Gene Kim, and Nicole Forsgren – perhaps the most respected voices on the landscape, along with Nigel Kersten, the project is categorically aimed at surfacing the truth about DevOps adoption today – not merely promoting the interests of vendor sponsors.

Like previous iterations of the report, the 2016 edition will focus on topics including IT performance, technical practices, culture, lean management, and organizational performance. This year’s survey also examines several new areas, including the ROI of IT performance, security and compliance, and containers.

To further entice participation, project leaders are also offering free tickets to the DevOps Enterprise Summit, along with forthcoming books from some of the industry’s leading advocates to a lucky few who take the time to get involved.

DevOps success is fundamentally based on the notion of increased collaboration and continuous feedback among the people scattered across the SDLC. Likewise, the legitimacy of this research project is utterly dependent on the input of as many real-world practitioners as possible.

If you’re one of those individuals, and you really care whether or not everyone else involved in the advancement of DevOps understands what this all means to you, do yourself a favor and participate.

Much like an application being built using DevOps practices, this quality of this project will be directly determined by the degree to which anyone with insight is willing to get involved and build toward optimal results.

Take the 2016 State of DevOps Survey… today!

April 15, 2016
Culture Change: Metrics, Tools Make a Difference
Change is in the wind.

This time of the year, as winter weather gives way to springtime renewal, this concept isn’t a cliché but rather a concrete, visceral experience. You go outside, smell the earth defrosting and know for certain that change is happening all around you. You can feel it.

Such is the case on the current DevOps landscape. Seemingly every conversation, with everyone from end users to industry analysts, reaffirms that people are making significant progress toward greater adoption. For an increasing number of organizations, DevOps is maturing from a set of budding goals into a tangible reality.

At the center of this massive shift within the software factory is the issue of cultural change; as we know in all things DevOps, culture trumps all else. So how are organizations affecting, empowering and measuring all this seismic transition, in particular the human elements?

During the recent DevOps Virtual Summit, leading practitioners representing industries ranging from banking to travel and technology shared their views on the progress of cultural reinvention.

From management tips, to tools and even metrics useful for driving transformation, here are some of their observations:
1. What’s the most critical cultural aspect of planning?
  Kazi Whitfield, director, Quality Engineering, MUFG Union Bank, N.A.: Scalability on this is the key; if you’re doing this at a new organization, you need to understand how to scale it, and starting at some smaller level helps you get there. It also helps each individual and those components that are changing to truly understand what’s changing, and why it’s changing; I think that’s a huge part of the conversation that has to happen.
1. What’s the biggest obstacle to cultural change?
  Eric Warheit, senior manager, Environment Management, Southwest Airlines: The challenges that we’re working through are organizational in nature. It goes back to the question of localization, and people maintaining a mindset that they’ve previously had, and what we do to create the conversation around what’s possible and the key impacts that we want to have. Ultimately, it’s about being productive with quality, and creating those common values.
1. How can tools enable cultural change?
  Eugene “Bear” Lehenbauer, group manager, Information Technology, Citrix: If I have to pick one that links them all, a ring to rule them all, that’s when you have an orchestration platform that can take what individual teams are already using and plug right in, or you can take what needs to be automated and automate it; that orchestration harness can now become that common thing that links them.
1. How can you ensure cross-culture collaboration?
  Warheit: Creating that concrete example, that proof case tying analytics to it, so that we have real measurable ways to make good business decisions, and being able to foster that perspective so that we can look across the organization, as opposed to in a localized way, is really critical to be able to foment that collaboration that’s needed.
1. How do you measure cultural change?
  Daniele Romano, product owner, Continuous Delivery Pipeline, ING Bank: The most important thing as an organization is to able to apply an analytical approach, meaning that for each team or department you should look at the current situation and have in mind the target situation, and then have different means to guide everyone toward that target.
1. What’s a key cultural change metric?
  Lehenbauer: We’ve a developed an agility rating scale that allows people to earn scores for something as basic as change management. Based on how those key metrics behave, and there are several of them, but they are fact-based and they’re user impact driven for the most part, they reward the right behaviors. Those types of things can draw out some of DevOps principles results, but also have hard data behind them.
1. How do you recognize advocates of cultural change?
  Whitfield: Being able to phase reward and recognition into the process is key. Organizations are doing a lot of great things and making millions of dollars, and as the individuals that are coding or testing are driving it, you have to understand how you get to those people’s hearts, to make them passionate about what they’re doing. That’s something that becomes key and it’s something that’s different per organization.
1. What’s the best way to gauge successful cultural transformation?
  Romano: There is a really only one critical human metric, which is happiness. So, if engineers are happy and they can deliver fast, at a high quality and with intense focus—that’s a very unique but important metric.
So there you have it, some of today’s most critical elements in driving the cultural transformation necessary to succeed in the DevOps world.

If you missed the DevOps Virtual Summit you can still view recordings of all the sessions including this customer panel, and stay tuned to this space for more excerpts and highlights.
March 30, 2016
The Forgotten Fourth Question
A very well-written paragraph about DevOps appears in Mike Loukides’ book, “What is DevOps”:

… Modern applications, running in the cloud, still need to be resilient and fault tolerant, still need monitoring, still need to adapt to huge swings in load, etc. But those features, formerly provided by the IT/operations infrastructures, now need to be part of the application, particularly in “platform as a service” environments. Operations doesn’t go away, a good part of it becomes part of the development. And rather than envision some sort of Uber developer, who understands big data, web performance optimization, application middleware, and fault tolerance in a massively distributed environment, we need operations specialists on the development teams. The infrastructure doesn’t go away – it moves into the code; and the people responsible for the infrastructure, the system administrators and corporate IT groups, evolve so that they can write the code that maintains the infrastructure. Rather than being isolated, they need to cooperate and collaborate with the developers who create the applications. This is the movement informally known as DevOps.

These days, recruiters to managers, engineers to analysts and, of course, CXOs all are interested in DevOps. They have questions such as, “What is DevOps?” “What are the DevOps requirements?” “What are DevOps implementations challenges?” But the key question is, “Why does DevOps remain difficult to implement?”

Adopting DevOps does not simply mean adopting new processes or toolsets. “Why DevOps” can be understood better by focusing on the benefits it will give you. So let’s dive deeper into one of the key best practices we discovered in our journey into DevOps.

Agile to DevOps

Business challenges, complexities and competition pushed companies to innovate and solve their existing business problems in a better way, adding more features and integrated solutions. Ways of implementing solutions vary from organization to organization, adoption of tools and technologies also differ by small and large organizations based on complexity of problems, but it’s clear that many have adopted agile practices in the past two decades. Agile was made clear by a few well-defined processes such as iteration planning, daily scrum meetings, scrum of scrums (in larger enterprises), iteration demos, retrospective meetings and small, empowered teams.

One of the key mindset changes most of the IT world went through while transforming themselves into agile execution was to have more verbal communications and daily scrum meetings. Daily scrum meetings required the scrum master to ask three questions:
- What was completed yesterday?
- What will be completed by end of today?
- Any blockers?
These three simple questions kept things simple and quick.

As agility is extended to Ops now, there is a need to revisit whether these three questions are enough. There is a need to revisit the attendees in scrum meetings too. There is a need to add some more responsibility to the role of the scrum masters’ communication radius.

Before we look at the fourth question, lets let look at the key reasons to adopt DevOps implementations in organizations:
- Achieve higher speed of time to market without compromising Ops stability
- Better resource utilization across Dev, Test and Ops
- Be more responsive to customers
Why would speed of delivery hamper stability in Ops? In our firsthand experience, the communication between Dev and Ops is not that rich in most of the organizations today. If one studies the root cause analysis of problems faced by Ops in trying to keep the environment stable and healthy, one will find some if not all the following issues:
- Developers are not deployment-aware
- Developers do not think of exposing or exporting the right controls for allowing Ops to configure app dynamically (Unintentionally. They simply don’t know.)
- Many configurations are embedded deep inside the app
- Adding specific third parties, changing their versions is sometimes missed in Ops communications
- Ops is unable to clearly articulate what they require from Dev, even when everyone is co-located
- Continuous firefighting in Ops results in fast fixes, better debugging, but not proactive processes
- Even if weekly meetings between Dev and Ops happen, they do not have a clear agenda or metrics
While there are many more symptoms and their causes, and while there are multiple solutions to fix processes and problems, we have found particularly one solution that seems effective.

We added a fourth question to daily scrum meeting. That fourth question is: “Are you blocking Ops?”

This question is a direct question to each developer in daily scrum meetings. This question essentially means to ask:
- Have you written in any code that requires a new configuration?
- Have you written any code that requires change in existing configuration?
- Have you written any code that is creating a new binary or file that needs to be installed in production?
- Have you recompiled existing code with new third party libraries because older ones are unsupported, even though there may be no other change in functionality?
- Have you hard coded any IP address or other configurations into the code which cannot be changed without rebuilding?
- And so on…
Ask the Fourth Question

The above list of questions is developed based on the root cause analysis of app stability in Ops. This list will be different for different developers/teams. The scrum master communicates the appropriate actions to developers based on the answers to these questions. The scrum master also alerts the Ops team and gives them a heads up on what’s coming their way, and provides timely feedback to the developers.

Is this question important enough to be the fourth question in scrum meetings?

Or is this question covered as part of the “Any blockers?” already being asked? One can debate either way. The blocker question in scrum meetings is thought of in a limited Dev/QA scope, and that scope has not included the Ops team until now. Given that Ops team faces customers, given that the DevOps movement is about improving synchronization between teams, this Ops question needs to be a first-class citizen in daily scrum meetings.

Lastly, it’s critical to to look at root cause analysis-related Ops problem as early as possible. The scrum master becomes more mature as he asks this question to his team while interacting with Ops on hearing them out. If teams are funded enough to have someone from Ops into the scrum meetings, then he/she can be the primary representative for Ops and can steer the delivery to be Ops-friendly.

Irrespective of how one achieves it, taking care of configuration issues proactively in daily meetings, and thinking about Ops on a daily basis in Dev meetings is key to successful DevOps adoption. Configuration issues are not the only focus, but they do form a large chunk of Ops issues.

From our metrics, customers have seen following benefits after adding the fourth question their scrum meetings:
- Shipping code 7x more frequently
- 45 percent fewer failures
- 12x faster ability to recover earlier in the tool chain
Please feel free to share your findings with us @ info@opexsoftware.com.

Happy DevOps!

About the Author/Sanju Burkule

Sanju Burkule, a pioneer, visionary and creator of Products in the DevOps Space @OpexSoftware. He writes about automation and strong, connected, integrated IT and tweets often about these topics.
March 25, 2016
How to Kick-Start Your DevOps Adoption

A recent survey by CA Technologies found Australian organizations are below par in terms of implementing measures to adopt and achieve successful DevOps strategies.

According to Ashok Vasan, vice president of DevOps Solutions Strategy at CA Technologies Asia Pacific and Japan, organizations are generally aware of the DevOps methodology and its value, but they either don’t know how to start or they’ve begun but then failed to move to rapid or broad adoption.

A lot of companies ask CA about the prerequisites for a successful DevOps adoption, he said. It needs to be considered as more than just an IT change, and success requires an understanding and acknowledgement that the business side must lead the transition.

Starting the DevOps Adoption Journey

The business perspective is about launching new products or services and gaining market share. To do that, companies will ask IT to not only deliver certain facilities, but deliver them quickly, so the business should see the adoption of DevOps as a first step in achieving those goals. If senior executives are looking at a particular strategic initiative, there is a greater possibility of getting the required resources across the organization, including IT.

Ideally, that first project will be relatively small, yet visible and significant to the rest of the organization.

It is important to establish a common set of goals and shared objectives, covering areas including development, testing, APIs, product management and product marketing. “Everybody needs to be measured in the same goal,” said Vasan.

Then it is time to look at the IT capabilities and activities needed to make it happen. Where are the bottlenecks? What can be automated? How should testing be performed?

The next step is to identify the weakest link in the existing product or service chain, and work to improve that. If the release process is the bottleneck, then automating that is a good early step to take. Vasan has seen speed improvements of 70 percent to 80 percent from the introduction of release automation.

One of the main reasons for the improvement is that release management can be a complex task, and automation reduces the incidence of errors, sometimes to the point of practically eliminating them. No errors means no time is wasted on remediation, so significant time savings are possible.

Reduced downtime is obviously a benefit to the business, but it can even pay dividends in terms of employees’ work/life balance. Making the release process quicker and smoother means there is no need to do it overnight, on weekends or during holidays.

Indeed, there is a very high return on automation efforts in general, he said. It is important to realize that it doesn’t matter how strong the rest of the links are: For example, even if the marketing people are doing everything expected of them, if a new app receives low user ratings, the organization has failed.

Successful DevOps Needs More than Tools

Back on the IT side, a technology platform should be designed and implemented so the people involved have the right tools, the right scalable technology and so on. A commitment to tooling is necessary to realize the benefits of DevOps, Vasan said. But it’s not just about tech, he warned, but rather a combination of the right processes, the right technology and the right people skills for successful DevOps adoption.

Where an organization is struggling to gain traction with DevOps, Vasan recommends making sure that the process really is business-led; checking that the right employees have been assigned and the right vendors and consultants engaged; ensuring good project management practices; using the lessons learned from initial projects to inform the rest of the organization (possibly by establishing a DevOps center of excellence to spread the word to other divisions and projects); and using an enterprise scorecard to help keep everyone on the same journey.

The rate of change demanded by today’s environment can be an issue for some organizations, said Vasan, but Australian banks have been very progressive and have done a lot to deliver world-class IT products.

Even outside of the banking industry, “there are pockets of [DevOps] excellence … that can serve as examples for others in Australia.” There are “exciting” things happening in the government sector, he added.

CA is working to pass on to a wider audience the experience and best practices developed by pioneers in the DevOps field. “We have seen how companies have started to work in all these [technical] areas, and we take these experiences to our customers.”

March 25, 2016
Taking Stock of DevOps: Where to from Here?

Have you noticed how every technology trend goes through a series of stages on the path to mainstream adoption? First comes doubt and denial, then tacit acceptance and finally acknowledgement that it works fine after all. The DevOps movement is no different.

First came questions about what DevOps actually is and its usefulness in an enterprise context (whatever an enterprise actually means these days), then a trickle of success stories and finally the publication of tangible and quantifiable benefits.

Thankfully, we’ve moved on from the “Is it a bird or is it a plane?” stage. Of course, that doesn’t stop hype, but at least the publication of benefits—such as those recently illustrated in the global study, “Assembling the DevOps jigsaw“—allow us to cut through all the “DevOps solves global warming”-type of nonsense being written.

So with the value jury finally in, the next question we should be asking about DevOps is, Where to from here? Interestingly, the old Wikipedia entry for DevOps provides some guidance, stating that DevOps is:

… a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.

That’s pretty good, because it emphasizes the importance of collaboration across all IT functions (not just Dev and Ops). However, this still doesn’t quite cut it for me. Although lots of cultural and automation heavy lifting has been done to bridge Dev and Ops, more work is needed to understand how aligning other IT functions to DevOps actually benefits the function itself and the business. Also—and perhaps just as important—how aligning other business functions, such as HR and finance, can lead to more success.

DevOps Works Because It’s Good for Business

Business leaders talk in terms such as faster lead times, customer conversions and time-to-value, which (putting cultural discussion aside) is really the essence of DevOps. And because DevOps adoption directly correlates to making a buck, it has a fair chance of garnering attention and investment from the business.

That said then, information security and other professionals would do well to hitch their wagon to DevOps. One of the beauties of the movement is that teams collaborate and provide input much earlier in the development life cycle, with processes then automated to ensure faster release time and quality. By also involving security earlier, businesses could feasibly harden security, balancing all those “rain on your parade” audits and checklists with automated methods that ensure compliant configurations lead to faster deployments.

An interesting but important benefit is how this approach helps align IT security to business outcomes. Rather than proving its worth through a whole raft of technical sounding measures, such as penetration test scores, patched vulnerabilities or security incidents detected, security can report functional value in context of business goals, such as how automated compliance equals faster releases, leading to increased revenue.

Of course, DevOps doesn’t just involve Dev, Ops and security, it also will involve other functions providing valuable input to help increase speed and quality. Think of it like the old “Stone Soup” story but without the trickery—everyone, be they software designers, product managers and enterprise architects, providing advice and expertise earlier in the software life cycle so essential elements of resilience, supportability and scale are baked in right from the get-go.

DevOps Shouldn’t Start and End in IT

The DevOps way suggests that we shouldn’t just restrict ourselves to IT functions—start there, yes, but other facets of the business should also participate. This sounds like common sense, but in reality it’s more critical because the boundaries between business and digital have blurred significantly. Fail to recognize this and we could end up a silo of good intentions: culturally correct but lacking any teeth.

This explains why even the much-maligned HR function has a DevOps role to play. For too long, many HR departments have been fundamentally back-office, dipping their toes in the muddy waters of organizational culture with periodic staff surveys and performance appraisals. But this doesn’t go far enough. Now, HR leaders must step out onto software factory floor and work hand-in-step with other DevOps practitioners to identify all the organizational and psychological barriers that inhibit business growth and the development of talent.

Finance, too, must become aligned to DevOps. This involves moving beyond traditional IT cost-center thinking to developing new fluid funding models needed to stimulate software innovation by agile teams. This means business change agents must join forces with DevOps practitioners to look at better ways to capitalize or expense software development costs or optimally monetize new apps, APIs and information assets. Once again, the earlier this happens in the software life cycle, the better.

From an IT perspective, we’ve come a long way with DevOps in a relatively short amount of time. But this is only the start of the journey. Most businesses haven’t even considered transformation of the whole organization using DevOps principles as a change agent. Those that do most likely will gain first-mover advantage—and that’s a good place to be in an economy increasingly shaped by application software.

March 9, 2016
Embracing a DevOps Culture, Part 1

DevOps is popular right now. So it should come as no surprise that organizations across all industries are eager to embrace the “DevOps culture.” However, unlike ITIL, implementing DevOps into an organization does not happen overnight.

Compared to companies such as Netflix or Amazon, most organizations do not have thousands of application deployments per day. In fact, it’s usually newer companies that are able to fully embrace DevOps, since all of their business operations rely on IT already.

DevOps Philosophy > Procedure

There are many articles out there that try to define DevOps, but DevOps is more of a philosophy than a procedure. If you polled 100 organizations on their experiences implementing a DevOps strategy within their existing business processes, you’d likely get 100 different answers.

An organization’s journey toward DevOps is usually unique, since there are so many different factors that influence a DevOps integration. These include the size and age of the company, what industry it’s in (banking/finance, retail, health care, e-commerce, education, public services), how sophisticated its technology is, the nature of its IT (data center or SaaS), organizational structure (siloed or integrated), development methodology (agile or waterfall), the nature of its mission-critical applications (Web 2.0, virtualized, client-server … ) and more. For most companies that exist outside of the startup ecosystem and rely on Web 2.0 and agile application development, Dev and Ops just don’t get along.

Dev vs. Ops

Trying to collaborate with Dev and Ops can feel like trying to mix oil and vinegar if the goals of each department are not aligned. As a result, IT’s ability to deliver maximum business value is greatly reduced. To efficiently drive the business forward, Dev and Ops must get along.

Most often, the conflict between Dev and Ops is because the focus of one department is at odds with the focus of the other, which creates tension when it comes time to collaborate with one another. While Development is focused on continuously delivering new products and/or features to meet business needs, IT Operations strives to preserve the availability and the stability of IT services and the IT cost-efficiency.

DevOps Can’t Be Limited by Tools

First, for a seamless collaboration to occur between Dev and Ops, both departments must use compatible tools. Mismatched toolsets create bottlenecks, misunderstanding and miscommunications, which result in so much wasted time that the implementation process ends up hurting the business.

Next, processes must align; compatible toolsets with conflicting processes are useless. For example, it’s not unusual to find the service desk is using a ticketing system which is separate from the application development tools used to manage product defects and enhancements.

Developers tend to rely on toolsets that are optimized for rapid development to provide fast feedback on code changes, to automate build creation and for application release deployments. In addition, the Dev team may be unaware of the runtime environment, which makes it difficult to adjust the code accordingly, whereas Operations uses solutions on the target runtime environment, where stability and performance outstrip flexibility requirements.

Since the integration process is unique to each organization, it’s key to find tools that are the right fit for your new processes and employees. Just because a team uses the latest application release automation tools to consistently drive repeatable deployments of application into production, does not mean they have adopted DevOps.

In fact, version control, application release automation and application auto-discovery of business transactions are all tools that help developers meet their objectives, but may not address the other portion of the equation: Operations.

At the end of the day, one of the most important decisions is choosing the right leadership team across your business—from your C-level executive team to the heads of your Dev and Ops teams. The integration process for DevOps can be difficult; to merge two separate departments and processes together to drive collaboration, both the Dev and Ops team need leaders with clear vision of the bigger picture and what’s needed from everyone to drive the company’s forward.

About the Author/Vincent Geffray

Vincent Geffray is Senior Director of Product Marketing at Everbridge with focus on IT Service Alerting & Communications Automation and IoT.

He has more than 14 years of experience in the information technology business, designing, promoting and selling Enterprise IT Operations Management solutions, including Critical Communications, Application Performance Management, IT Process and Workload Automation. He also has international experience, as he started his career in Europe. Vincent holds a Master of Science (Mechanical Engineering and Computer Science) and executive certificates from the MIT – Sloan School of Management.

Vincent’s LinkedIn: www.linkedin.com/in/vgeffray

Vincent’s Twitter: @vgeffray

February 29, 2016
How DevOps Can Effect Culture Change to Improve Business

The rift between Dev and Ops teams has long been one of the main obstacles for organizations managing their IT capabilities. Overcoming it can be crucial for a successful business. In fact, every company should be able to achieve harmony by improving process automation, implementing better procedures and refining workflow regulations. This is where DevOps culture steps in.

To be successful, your DevOps approach must include a detailed understanding of your culture and learned behaviors that will influence the changes you want to see in your organization.

According to recent Gartner research, DevOps will only work when both Dev and Ops are willing to collaborate. They need to embrace change at a behavioral level to initiate and achieve culture change. If not, there is a 90 percent likelihood that any DevOps initiative will fail.

In discussing the importance of communication in implementing DevOps know-how with Consultancy UK, Gartner’s research director Laurie Wurster explained: “With respect to culture, DevOps seeks to change the dynamics in which operations and development teams interact. Key to this change are the issues of trust, honesty and responsibility. In essence, the goal is to enable each organization to see the perspective of the other and to modify behavior accordingly, while motivating autonomy.”

Theory vs. Practice

In reality, the existing autonomy of the operations and development teams is one of the most common reasons for a possible failure of the DevOps approach. While the business culture of developers is founded on innovation and breaking the status quo, life in Operations can seem unthinkable without a procedure-based routine.

Going further, these two teams can be pushed apart by their own executives. After all, handing out separate tasks and objectives without actually putting the Dev and Ops teams in a room together (even when working on the same project!) has been a traditional approach that dates back decades.

Deadlines and Objectives

With Dev and Ops each being unaware of the business value of the other, the departments end up sharing only two business factors: deadlines and objectives. This often leads to a blame game—explaining a delay or a failure seems much easier when you have someone else to blame and a team with an unknown value is always an easy target.

Putting a stop to this poor practice by initiating cooperation and reminding both they are part of the same organization is the best way to improve efficiency and speed of innovation. IT managers must build bridges and encourage Dev and Ops to discover new ways to accomplish their shared objectives.

DevOps for an Agile Reboot

Modern business has realized that while Agile improves speed and service delivery, it may have skipped some very important aspects of culture change resulting in the birth of “fragile infrastructure.” The term is used to describe the damage that can be caused by Agile’s ‘shortcut policy,’ in which teams may compromise to meet their deadlines.

Many see DevOps as the savior that comes just in time to influence business on a cultural level and unite with Agile toward excellence.

One of DevOps’s flagmen, Mike Kavis, vice president and principal architect at Cloud Technology Partners and a Forbes contributor, points out that “the solution is for dev and ops to collaborate on the environment specs and together build the appropriate automation scripts that can provision environments with a single touch of a button without the need of additional configurations.”

When implementing the DevOps approach, developers can be the toughest audience. They may remember all the arguments and rifts with operations, potentially caused by tentative coding leading to functionality issues within the environment—a destabilization every Operations team fears and detests. So, one question remains: How can you build this collaboration?

Incentivize Accordingly

As stated by Forrester analyst Kurt Bittner, IT companies of today are helping the cultural rift between dev and ops by incentivizing the teams to do different things—developers are prompted to deliver quickly, while operators are targeted to keep the services up and running.

Encouraged to pull in opposite directions, it is only natural that the two business units end up facing a rift, making cooperation seem more illusion than reality.

Because most companies set their priorities based in part on its incentives policy, it is important that those priorities agree with the company goals. In short, once you “go DevOps,” make sure your incentives policy is encouraging rather than hindering collaboration.

Set Shared Goals

DevOps supporters see DevOps as a cultural movement and a philosophy, rather than a framework or simply an approach.

“DevOps is a mindset of moving away from fragile systems that take too long to deploy to reliable software that can be deployed quickly. DevOps requires great collaboration and teamwork, not just within IT, but also with management and product,” Kavis notes.

Identifying a goal that can bridge the gap and make teams work together is a great way to initiate a change in a positive direction. As Bittner explains, “Part of that means measuring devs on stability, and part of that means measuring ops on innovation. But the best thing is to reward everybody on improving the customer experience.”

A recent case study presented by Orbitz Worldwide’s senior software engineers Greg Burton and Ori Rawlings at the Velocity Conference neatly demonstrated how setting a common goal for Dev and Ops can bring actual results.

The goal itself was simple but ambitious: to double the hotel search capacity across the whole website. While achieving it by working closely with operatives, the development team managed to get a hold of many issues plaguing the system on day to day.

In fact, being a back-end developer himself, Burton defined the term “feature guilt”—the belief among developers that any time spent in aiding operations to resolve outstanding performance issues is lost and unproductive, so everything that does not involve new features must be completed quickly.

Like many other professionals, Burton also believes change should be realized as soon as possible throughout the organization to prevent substantial losses for everyone. Working on a shared goal, such as improving the customer experience, for example, can help influence developers to appreciate that maintaining a system is as important as developing new features.

Change the Culture of Fear

As Bittner notes, “If agile was the opening act, continuous delivery is the headliner.” Once the culture change is favorable and the company is running at full capacity thanks to the DevOps approach, favoring innovation and experiments within the organization becomes one of DevOps’s main advantages. Still, allowing it to work might prove unattainable to some companies. What lies beneath is the fear of failure that can paralyze every manager and employee.

Randy Bias, director of the CloudStack Foundation and vice president Technology at EMC, speaks of “a culture of fear” that exists within organizations, which is driven by an “endemic” fear of failure.

This is caused by the widely adopted practice of heavily penalizing every form of failure instead of focusing on how to minimize the potential losses and still allow experimentation for the sake of innovation.

The real question is, How can you make this possible when your business is at stake? The secret to success, according to many industry experts, is creating a structure based on separate components that can malfunction without leading the company to bankruptcy.

As hard as this may be for companies relying on monolithic applications, it is best to adopt microservice architecture that will permit managers to allow developers freedom, even if this means paying the cost for the potential mistakes.

According to Mike Kavis, vice president and principal architect at Cloud Technology Partners, and Etsy’s CEO Chad Dickerson, it is essential to allow people to make mistakes as freely as reason allows and turn postmortems into productive and proactive meetings, not a blame game.

One of the greatest success stories of today’s business practices, the e-commerce platform Etsy is a great example of the benefits of DevOps practices and blame-free meetings.

Senior vice president of Technical Operations John Allspaw, who is in charge of Etsy’s “blameless postmortems,” told Business Insider: “Less-skilled companies name, blame and shame. It’s not about avoiding accountability. In a blameless culture, it’s easier for people to take responsibility for their mistakes and learn from them. Developers already feel quite guilty when they break the site.”

Seeing is Believing

One-on-one meetings with management, prearranged brainstorming and specially made presentations are no longer enough to effectively influence culture change. Encouraging communication between teams with the right incentives is vital, but modern management needs to push even further.

The best way to make developers understand operations and vice versa is to get them together and even share job descriptions.

Companies like OnShape, for example, have taken a big step in reorganizing on-call duty by making developers and operations actually work together. According to Paul Beltrani, webops at MC10 Inc. and former techops at Onshape, this has been a win-win game, as the change has helped both teams.

Developers have gotten a grasp of the after-effect of a faulty code, while operations have gained a better understanding of how the code works. Furthermore, making dev and ops share a responsibility has also proven to be less stressful, as developers and operations were effectively cooperating by exchanging knowledge to handle the issues.

CenturyLink goes even further in this direction, by transforming its dev and ops teams into product teams able to support the entire service.

“It aims to be light on management and process, with each product team assigned each aspect of the product with a laser focus,” explains Jared Wray, CTO of CenturyLink Cloud and head of the development center. “There’s no throwing it over the fence, and there’s no distractions between the two organizations.”

Patience is a Virtue

If you’re willing to transform your organization according to DevOps, you should invest all of your patience and good will; be ready to listen and improve.

As every business is unique in its organizational structure and services, and is counting on many individuals, there is no strict route to follow when implementing DevOps. Of course, there is something all professionals agree on: “Most people think they’re going to snap their fingers and it’s going to happen overnight by doing a reorg. But it’s a full culture shift. It took us three years to make this model, and we’re still evolving it,” Wray says.

According to Chris Nowak, senior vice president and head of DevOps Services at Bank of America, it’s natural to face initial resistance when presenting teams with new requirements and processes and the best way to handle it is with care. Nowak recommends the human approach: finding and encouraging opinion leaders who can influence change and “eventually help other teams let go and embrace a new way.”

So, setting clear goals is the first step to becoming a DevOps success and rushing change has only ever resulted in a temporary workaround. DevOps is gaining more and more popularity, making it possible to gather opinions and learn from the forerunners.

Industry experts have come together to found the DevOps Institute and share a common language through the DevOps Foundation course, so maybe now more than ever is a good time for your business to “go DevOps” and see the value.

February 10, 2016
Leveraging DevOps to Expose The Entire IT Iceberg

On September 16th I attended and spoke at a CIO Magazine event in Chicago. These are some of the best events to attend as the audience is typically CIO or senior IT leadership. One of the speakers on the day, Martha Heller, Author of “The CIO Paradox”, presenting on new competencies for the modern CIO, presented a very eye-opening perspective on limitations moving IT forward into a digital age.

Anyone who has worked in IT for any length of time, or even watched the British comedy show, “The IT Crowd,” probably has some concept of what it means to work in IT. But never have I seen it so explicitly spelled out from an executive level as Mrs. Heller does in her talks relating the brutal reality as expressed by one of her clients. I present the excerpt here from her talk:

“Do not under any circumstances expect applause or a raise when you have dismantled the iceberg. Since no one in the business sees the iceberg and no one understands the iceberg is real and that it is ours they cannot understand what used to be under the water looks and behaves completely differently. Business leaders will understand cost, headcount, throughput and all of the new capabilities that run on top of iceberg. These are the likely places for applause. Expecting recognition and compensation for what you do below the water line is not advised; do not fight that battle. Praise for what happens under the water line only comes from industry peers.”

Clearly the iceberg is IT itself and the waterline represents the separation between what the business can see and touch, e.g. user interfaces, accessibility of data, application performance and IT support, and all the stuff that enables the aforementioned that sits below the water line. If advice by counsel, such as Mrs. Heller, to CIOs is not to expect recognition or compensation for making what happens below the water line work optimally, then it will be very difficult for CIOs to engage and keep personnel that excel in this capacity.

To be clear, I’m not saying that Mrs. Heller is telling her clients not to pay attention. She is merely reiterating the paradox that all CIOs must confront as they inherit and deal with the ever growing mess below the water line caused by acquisitions, aging systems, disruptive technologies, aging labor pools leaving the work force, and workers going to companies where they receive better pay and recognition by because they focus on providing below the water line management services, etc.

The industry has been telling CIOs for at least three years now that they need to pay attention to what is occurring with DevOps. Yet, many still view DevOps as a deep below the water line activity focused on development and system administration. What they are ignoring is that DevOps may very well be the answer to this paradox that Mrs. Heller puts forth. Leveraging DevOps is not only advisable, but necessary for these leaders to succeed.

DevOps has the ability to help lower the water line with the business. As Mrs. Heller reiterates, the business understands costs, headcount, throughput and all the new capabilities that run on top of the iceberg. We have concrete evidence that companies that adopt DevOps philosophies and institute continuous delivery capabilities are able to respond to business changes more rapidly and are more profitable than businesses that are hindered in these areas. DevOps typically increases the level of transparency between IT and the business giving them greater input into direction and providing them a wider perspective for how what is below the water line today impacts the very attributes the business cares about.

Increased automation associated with continuous delivery opens up greater opportunity for self-service, which again moves more of what is below the water line today to above the water line. Self-service provides more touch points for the business to directly control their own agenda and direction leveraging IT resources. Indeed, there are additional ways that DevOps can help to lower the water line that for readability I will not go into here.

Mrs. Heller’s point that attempting to battle the business to gain recognition for what happens below the water line is a losing battle that will tear at the credibility of the CIO that chooses to engage in this battle. However, if CIOs cannot hire and retain the best talent, their ability to stop the iceberg from growing below the water line will continue to diminish. Their only hope is get the water line to drop and expose more of the iceberg. The more of the iceberg that gets exposed the more opportunity the CIO has to obtain recognition and compensation for his/her team.

So, Mr./Mrs. CIO, is DevOps important to you now?

September 28, 2015