Tag: survey

Compuware Survey Connects Mainframes, DevOps
Mainframes are still necessary; integrating them with modern hardware and software is tricky; and DevOps is the answer. Those are the takeaways from a survey out this week that was commissioned by Compuware.

The survey, which was released Dec. 14, was conducted by Forrester. It asked professionals how often their organizations rely on mainframe systems and what they do to overcome the challenges associated with using legacy mainframes within modern computing environments.

The survey suggests that mainframes are not going anywhere soon: 57 percent of respondents said new business initiatives “always” involve the mainframe, according to Compuware. Even though mainframe systems are now decades old, they still have a place in modern IT.

But bridging the gap between mainframes and more modern infrastructure and software delivery practices is tough, according to the survey. This is due not only to what Compuware calls “organizational bureaucracy” and “insufficient funding,” but also the difficulty of integrating mainframes with other types of technology that were designed in a different era.

The survey shows that most professionals take one of three approaches to solving that challenge:
- Move applications off of mainframes. The downside to this strategy is that mainframe applications may not run as fast or as securely on other hardware.
- Avoid using the mainframe at all. This, too, is not always ideal, according to Compuware, because the mainframe is better at handling some types of workloads.
- “Modernize” mainframes, which entails a lot of investment and effort.
According to Forrester’s conclusion in the study, a better approach is to apply DevOps techniques to mainframe development. That means that the mainframe technology itself does not have to change or be hybridized; only the approach to mainframe app delivery changes. “Those companies embracing DevOps deliver faster and at a higher quality, all while fostering collaboration,” Forrester concluded.

These are all things that a Compuware-sponsored study is likely to say, of course. Compuware specializes in DevOps solutions for the mainframe.

Still, the survey is a good reminder that mainframe is alive and well—and DevOps teams should not leave it out of the picture.

— Chris Tozzi
December 15, 2016

DevOps Survey Says! State of DevOps, Reliance on Scripting and IT Automation

What our surveys told us about the state of DevOps, Reliance on Scripting and IT Automation

DevOps Survey Results: Scripting & IT Automation

A lot of IT Operations teams including application owners, configuration managers, middleware specialists and database administrators are managing infrastructure configuration change with manual processes, spreadsheets and scripts. They are spending a lot of time writing and maintaining a lot of scripts. Even with all those scripts, spreadsheets and processes and the resources they consume, teams are still not getting the visibility, control and error-proofing that they require.

That is the message from five recent surveys conducted by Orcaconfig among IT industry pros. Perhaps these results should not be that surprising. But several years into the DevOps and IT automation movements, there is still plenty of room for improvement.

About one-third of respondents said they spent more than half of their time writing and maintaining scripts.

In complex application environments with multiple relationships and dependencies between applications, databases, middleware and operating systems, “changing this can easily (and unwittingly) change that.” Gartner refers to this as a domino effect. So, scripting to deploy changes becomes more and more tricky and thus, requires more and more time to do, test, redo and retest.

what_percentage_of_time_is_spent_writing_or_maintaining_scripts_-_survey_from_orcaconfig-com_2

Because of the risks involved with release or configuration-related scripting errors in production environments, some organizations hand these typical operations responsibilities to developers. The question is worth asking: Is release and configuration-released scripting the best use of Dev or Ops’s time?

how_do_you_maintain_scripts_when_the_author_is_no_longer_available_-_survey_from_orcaconfig-com_3

With all these scripts holding key configurations together, are organizations at risk of “losing the recipe” if key employees leave? Apparently so. In our surveys, 30 percent of respondents admitted, “It’s a problem, we don’t really have a solution in place,” when asked about maintaining the spaghetti-works of scripts if some of those key employees suddenly leave the organization. Nearly half mentioned that they rely on transfer of information (TOI) before a key employee leaves.

Employees exit companies for a number of reasons and some are in a bigger hurry than others to move on. Does TOI provide all the safeguards needed for the enterprise?

Scripting might consume a great deal of IT resources and introduce a considerable risk with the loss of key talent. But does it at least accomplish the functionality that teams need? The next few charts provide insight to how well scripting achieves the visibility and error-proofed automation that teams need.

Ecosystem Visibility

Configuration Drift Detection

For performance, security and audit reasons, organizations have an ongoing need to maintain configuration compliance in their application ecosystems. So detecting configuration drift is essential. Automatically detecting configuration drift is the goal. Despite complaints about the method, approximately half of respondents relied on scripting to accomplish drift detection.

how_does_your_organization_detect_configuration_drift_in_complex_application_database_middleware_environements_-_survey_from_orcaconfig-com_2

how_do_you_know_which_databases_are_being_used_by_which_applications_across_your_ecosystem_-_survey_from_orcaconfig_2

Mapping Databases to Applications:

Sometimes IT operations are asked simple sounding questions such as, “What are all the applications that use this database?” and vice versa, “Which databases support this application?” Once again, nearly one-third of respondents admitted, “We really don’t know which databases are being used by which applications. Wish we did.” Another 36 percent relied on scripting or other manual processes to get that answer.

Is it reasonable (in 2017!) to still rely on scripting to get basic information about interrelationships between applications, databases and middleware? Is it acceptable to operators, managers and auditors simply do without this information? Will Visio and similar static files always provide up-to-date information that IT Operations needs?

Automation & Error-Proofing

Environment-Aware Releases
When moving an application through pre-production stages and into production environments, Release Managers want to ensure that the new release will just work … as planned … drama free. This requires among other things that

the configurations are up to date and production-ready, and
that those business-critical applications are promoted simultaneously with their production-level configurations.

how_does_your_organization_achieve_environment_aware_releases_

Thirty-eight percent of respondents said they relied on scripting and other manual processes to try to accomplish environment-aware releases. To ensure ‘everyone is on the same page’ many organizations use multiple planning meetings, sharing and updating spreadsheets and SharePoint files with (hopefully) the latest configuration information. Even among this group, respondents commented that scripting just does not work well for them.

Despite the security, compliance and performance implications of configuration and release problems, 15 percent of survey respondents admitted they “really don’t achieve environment-aware releases.”

Scripting isn’t Free; IT Ops Needs More

Scripting is quite naturally the go-to method for many application owners and IT Ops teams. The cost of scripting or even finding and fixing a scripting-based error hardly ever appears clearly in budgetary line items. In the moment, it can feel like it is free. But over time, maintaining scripts and homegrown tools can build a hidden but costly mountain of technical debt. It might well be worth these costs and risks if scripting effectively resolved ongoing operations needs such as ecosystem visibility and drama-free deployments. However, time and again our respondents said they lacked basic capabilities such as configuration drift detection, mapping applications to databases and middleware or ensuring environment-aware software releases.

— Scott Turner

December 2, 2016

DevOps: Using Games to Make it Practical

This blog stems from my experience of being one of the earliest DevOps Foundation trainers of DOI and successfully completing 19 batches of DOI Foundation course in the last year.

In retrospect of the year starting when TaUB Solutions signed up as a registered education partner (REP) of DOI, my opinion is this has been the best service portfolio offering for our customers and partners.

There are few things that appeal best when it comes to DOI Foundation course and I can summarize them with the collective feedback I’ve received so far:

“Challenges the preconceived myths and practices around DevOps with practitioner stories.”

“Gives a holistic overview of philosophy behind DevOps. Philosophy should precede science and science should precede engineering.”

“This course maintains the discipline to be truly advisory in nature by illustrating tool chain without recommending vendor-specific tools.”

“The group exercises during the class and the facilitator practical insights helped us to put the aspects in to our organizational context of delivering products and services.”

“We have never seen a course such beautifully designed that could be the first basic building block to know ‘Do’s’ and ‘Don’t’s’ of DevOps across application developers, infrastructure operations, project managers, infosec professionals and business leaders.”

To enhance the overall learning curve of the audience, we put them in to the third day of experiential learning using the Phoenix Project Business simulation. The simulation was divided into four rounds and played with maximum of 12 people per batch. The Team was entrusted to achieve a target of $300,000 within four rounds and take the share value from $21 to $45.

While the target milestones were clearly laid down at the beginning of game it was difficult for the teams to get hold of the situation due to various unknown parameters. It took them quite sometime to understand the different moving parts of flow, dependencies, business impact of projects, issues and features that came up in every round and make appropriate choices and decisions.

The teams experienced significant learning, sharing and collaboration over the four rounds and had loads of fun. One common feedback from the teams was for the game to be mandatory after every two-day DevOps Foundation course.

The consolidated feedback after playing the DevOps business simulation after the two-day course:

“It demonstrated that it is not easy to build collaboration, communication and integration. It takes time and there is a lot of patience and team work needed to make this a reality. The DevOps culture had to be nurtured through self-organizing teams with mutual respect, sense of pride and collective ownership to work toward a common goal.”

“It gave a working knowledge on how ITSM and DevOps are complementing each other [Ex. Change Management and Improved Flow].”

“The Principles of DevOps, namely the First Way (Improve Flow from left to Right), Second Way (Shorten Feedback Loops) and Third Way (Repetition through Mastery) was visibly evident over the course of four rounds.”

“The speed of execution improved over the rounds using short feedback loops, continual improvement and applying lessons learned from previous rounds.”

“It gave a good understanding of how different roles and responsibilities in the organization contribute to the overall success of the project.”

Finally, the teams made over and above the required target of revenue and stock price. The winning moment was enhanced by the significant learning opportunity and ability to bond with diversified cross functional teams.

The experience of playing the business simulation reinforced practical understanding of DevOps and also transferred skills that they could implement immediately at their workplace.

About the Author / Suresh GP

Suresh GP is the Managing Director of TaUB solutions and Regional leader of BRMI (APAC). He has more than 15 years of experience in IT Service Management, IT Governance, Program Management and Organizational Change Management. He is regular blogger and International speaker at itSMF UK, itSMF Australia, itSMF USA, itSMF Finland and itSMF Norway. He is a Certified DevOps, Agile Service Manager, Business Relationship Management Professional, PMP, CGEIT, ITIL V2 Service Manager, ITIL V3 Expert, ISO 20000 practitioner. He was awarded the ITSM contributor of the year by itSMF Singapore in 2013.

October 5, 2016
Tasktop Survey Shows Customer, Business Needs Must Align
Recently, Tasktop surveyed 120 global IT professionals on their software delivery processes. The results were based on analysis obtained from its licensed Forrester Modern Application Assessment Tool, which helps organizations evaluate where they fall on the spectrum of modern software delivery and offers insight into what needs to happen next.

The survey covered topics such as customer needs, application development and delivery objectives and strategies, business value, metrics, tools and more.

Key Findings

In spite of the increasing adoption of agile and DevOps initiatives, the survey identified the need for stronger alignment with customer and business needs and tools that increase coordination in the software delivery process.

Developers, tech leads, project managers, chief technology officers and other IT titles surveyed reported the following:
- Only 6 percent strongly agreed they could trace the contents of a software release back to business needs or customer satisfaction.
- Just 9 percent strongly agreed their application development and delivery strategies were aligned with business strategies.
- And, strikingly, a scant 15 percent strongly agreed their work management tools assist in coordinating the work of the software delivery team satisfaction.
It seems that in spite of a strong industry drive toward being more responsive to the the needs of the business, there remain large gaps in how organizations realize the benefits of the tools they use to support these initiatives.

Any parties interested in taking the survey and receiving an assessment can do so here.

About the Author / Betty Zakheim ‎

Betty Zakheim is vice president of Industry Strategy at Tasktop and is the vertex between Tasktop’s customers, the company’s product team and marketing team. She has an extensive background in software development, software integration technologies and software development tools. As a software development manager, she was an early adaptor of “iterative development,” the precursor to Agile. As the VP of product management and marketing at InConcert (acquired by TIBCO), she pioneered the use of Business Process Management (then called “workflow) as the semantic framework for enterprise application integration. Connect with her on LinkedIn and Twitter.
September 14, 2016
Are Companies’ Digital Transformations Near Complete? The C-Suite Thinks So

Enterprises have been busy in their digital transformation efforts for a number of years. They’ve been using data and software in efforts to renew and attempt to rejuvenate entire lines of their business, from streamlining deeply entrenched processes to creating entirely new business models. Interestingly, while many developers and IT leaders believe their efforts are mediocre and lagging their contemporaries, the C-suite seams convinced their digital transformation efforts are going great. That’s according to a recently released survey by QuickBase.

According to the Digital Transformation Survey, a surprising 70 percent of c-suite respondents believe they are ahead, or way ahead, of others in their digital transformation initiatives. Compare that to only 30 percent of those in the line of business and other employees who believe the same.

Such a wide discrepancy among top executives and line-of-business employees isn’t unusual. When it comes to IT security, for instance, c-level executives are not always in sync with their security teams regarding how mature their cybersecurity efforts are. This older, but relevant, story details what I mean. In the story, “Are you an IT security leader – really,” research revealed that of the more than 9,600 business and technology executives from around the world who took part in the survey, 43 percent believed their organizations are IT security leaders. However, when those responses were vetted for such leadership indicators as reporting structure, strategy, ability to respond to a breach and more, less than 5 percent of respondents actually made the cut.

However, in that survey—much like the recently released QuickBase survey—front-line practitioners were much less confident in the maturity of their program.

There have been signs of this discrepancy in digital transformation efforts in other surveys, such as, “The Persistence of Enterprise Tech Failure Rates,” and, “Developers Cite Startling Lack of Digital Leadership.” In the latter story, 40 percent of developers surveyed said that they have experienced failed development efforts due to lack of funding, and a third reported being concerned that current projects could be pulled for budgetary reasons.

Interestingly, it’s not c-level execs who typically are calling the shots when it comes to the digital transformation efforts in their enterprise. According to the survey, 47 percent said corporate IT was in charge of digital transformation, while the rest identified operations (30 percent) and line of business IT (21 percent) as the digital transformation leaders. Also, according to the QuickBase report, two-thirds of respondents said traditional IT app developers developed the digital transformation applications, while working with business users and managers occurred only 33 percent of the time. Not surprisingly, non- technical business users developed apps on their own less frequently.

Interestingly, the study found the barriers to adoption are lack of budget, management resistance and then lack of IT staff.

That lack of IT staff, the report concludes, is a reason why enterprises need to embrace their citizen developers. “Citizen developers, those in the line of business or operations who have the power to help transform their organizations from the bottoms up. These are the people who are closest to the work, but are often passed over in favor of more traditional IT leadership,” the report states.

The survey did show, disappointingly, that only 23 percent of non-IT staff in operations are developing the apps they need to make digital transformation in their departments a reality. But as we covered previously, the reality is that citizen developers can be the factor that help enterprises drive their digital transformation efforts swiftly and further forward.

Another persistent challenge is the lack of the skills enterprises need when it comes to digital transformation. Salesforce’s “State of IT” report, which we recently covered here, found that the IT skills demand gap is only getting worse. And as enterprises accelerate their digital transformation efforts, and invest more in mobile, data analytics and IoT, there will certainly be even less IT talent to go around. Roughly 30 percent of those in the report said their enterprises are having a very challenging time keeping the necessary IT skills sharp. Also, 72 percent said that IT skills development and training will be absolutely critical, or very important, for their team in the next five to eight years.

When it comes to leading successful digital transformation efforts, there’s no doubt that citizen developers are critical for enterprises to get done what they need to get done. Likewise, there’s also little doubt that the c-suite also needs to get a real realistic view of the work ahead regarding their organization’s digital transformation efforts.

August 31, 2016
REP SPOTLIGHT: Daysha DevOps Solutions

DevOps Institute: Tell us a little about your organization.

Daysha DevOps Solutions: Daysha DevOps Solutions is a leading IT services and solutions company focused on helping companies to deliver their IT projects, transform their capabilities and ultimately to provide value to their customers and stakeholders. Our goal is to help organizations benefit from disruptive technologies, such as cloud computing, Lean/Agile software development and DevOps. We work across a range of industries including financial services, government, aerospace and high-tech.

Daysha DevOps Solutions has partnered with the best-in-class product vendors to help organizations improve their ability to deliver software quicker, more frequently, with higher quality and less risk. Our DevOps solutions address all stages from project planning right through to deployment.

DOI: What other topics do you teach or consult on?

Daysha DevOps Solutions: Daysha bring proven expertise and consults across the wide domain of DevOps. Partnering with vendors such as Atlassian, App Dynamics, Chef and Zephyr, we offer expertise, training and tooling to support all aspects of the DevOps journey.

Our IT Project Services team consists of experienced IT consultants including project managers, technical experts and business analysts. These can be deployed to help augment your existing IT teams or to provide specific project help, such as requirements gathering, gap analysis and process improvement.

DOI: What type of interest in DevOps are you seeing in your region?

Daysha DevOps Solutions: The interest in DevOps is growing, though to be honest, a lot of organizations are wary of it. That said, the same organizations are heavily rooted in traditional waterfall environments. There is a recognition that DevOps is the way forward but also a realization that cultures need to change first.

DOI: How do you think that DevOps contributes to the business’ value stream?

Daysha DevOps Solutions: Primarily by delivering value earlier and increasing the visibility of the IT contribution to the business stream.

DOI: What topic area in DevOps excites you the most?

Daysha DevOps Solutions: How business can get more value from IT. In other words, turning an IT department into a revenue-generating tool rather than a cost.

DOI: Why should enterprises and individuals consider formal DevOps Training?

Daysha DevOps Solutions: It is the first step, and a certified first step, on the road to improving the value of IT functionality.

August 23, 2016
Test-First Development: Processes and Tools for Success
A lot of software development teams are talking about “test-first” methodologies. The practice involves moving testing up into the very earliest stages of development so automated tests can be written before code. Making this seemingly minor shift can result in much higher quality software and greater efficiencies. Integrating development and testing avoids needless late-stage bugs and complicated redevelopment efforts. It can help software development organizations focus on usability and features and achieve faster time to market. And because of test-first’s reliance on automated tests, organizations gain reusable tests, saving time and increasing standardization for testing and quality assurance overall.

It’s no surprise, then, that 51 percent of organizations have begun using test-first methodologies, including 37 percent in the past year, according to a recent global survey of 200 software testers conducted by our company. But, despite the enthusiasm for this practice, there are concerns: 44 percent of survey respondents said their biggest fear about moving to this approach was forcing developers to contribute tests prior to completing code, while 19 percent said they worried about removing traditional testing checkpoints on the way to production. Other barriers include the lack of standard practices or tools. That said, test-driven development promises to bring ample benefits to software development teams, the business and, importantly, customers.

Test-first development is recognized across three broad terms today: behavior-driven development (BDD), test-driven development (TDD) and acceptance test-driven development (ATDD). TDD is an umbrella term for the practice, although it has traditionally focused more on technical, unit testing. BDD and ATDD incorporate user requirements and business benefits along with technical testing. BDD differentiates through its adoption of specific automation frameworks and language for writing and running tests.

Key Changes for Successful Test-First Development

Getting started requires change across a few critical areas for most teams. First, evaluate your team for hiring and skills training needs. On the one hand, developers will need to learn basic testing skills, so they can write good tests and run tests before they develop code. Meanwhile, testers must become more proficient in automated testing tools, which usually entails acquiring a fundamental knowledge of programming. Many companies will need to hire key contributors from outside; in which case, leaders should look for well-rounded individuals with past experience using test-first methodologies successfully. An individual who is an expert at one skill, or who is too independent and can’t collaborate well, won’t be an ideal member of a team experimenting with test-first approaches. Leaders also may need to adjust by balancing the ranks more closely between developers and testers so that one group doesn’t rule over the other. Hiring additional experienced testers frequently will be necessary.

Training of existing staff is paramount, best achieved through a combination of methods including internal training, mentoring, online courses and paired development, where developers and testers can sit side by side and collaborate. More than half of the survey respondents said developers and testers would be jointly responsible for automation test creation within their organizations.

Beyond cross-training, the cultural challenge of moving to test-first methodologies can be overwhelming. It requires the development of incentives for creating quality products, not just delivering new features at speed. It requires an appreciation and respect for the practice of testing. Unfortunately, testing too often is viewed as a necessary cost of doing business, rather than bringing a clear benefit to the organization and its customers. That mind shift is not only inaccurate, but it doesn’t fly with progressive, Agile thinking. It will take strong leaders to help traditional teams understand the need to change and modernize practices. A leader may forego the buy-in process and instead decide to lay down the law to staff: Staff must move to TDD or BDD, or else. But the results won’t be ideal. Smart developers will find loopholes, such as writing tests that aren’t comprehensive or fully aligned with project goals, so the code will pass more quickly.

On the process front, organizations that have moved or are moving from Waterfall to Agile and DevOps will have an easier time adopting test-first methodologies. In fact, it’s pretty difficult to implement test-first processes and tools in a Waterfall environment because of the siloed nature of functions and the long release cycles. The survey results support this premise: 55 percent of respondents said their testing process was Scrum/Kanban-driven before transitioning to test-first, while 21 percent said their approach was iterative-requirements driven and 18 percent was Waterfall-requirements driven.

Along with that shift, test-first teams will need to adopt new metrics that align with this new way of doing business. Instead of looking solely at velocity, development leads should measure how long it takes the team to move a product from feature approval to code release. With a focus on quality and testing, companies also should measure and improve upon bugs, such as number of severe defects post-production. Those types of business and customer-oriented metrics align with the new set of Agile metrics that that many teams are working for today.

Test-first teams will need to adopt DevOps toolsets, which are designed to push code out to the pipeline faster. Specific technologies that go hand in hand with test-first development include:
- Continuous integration (CI) platforms such as Jenkins and Team City, to assist in running the automated tests immediately for quick build feedback.
- Container technology for rapid deployment of test and pre-production environments, to capitalize on having features production-ready soon after coding.
- Test management platforms including qTest Scenario or Cucumber Pro.
- Test automation frameworks including Cucumber, SpecFlow , and other open source tools which enable easier support for customization and collaboration.
There’s a lot to think about when moving toward test-first development. While it may seem overwhelming at first, all of this is achievable in a reasonable time frame if you have the right dedicated resources to see it through. One-third of survey respondents said it took them less than three months to complete the transition to a test-first approach, while 30 percent said it took less than one year. The payoff for software teams, in terms of improving quality, customer experience and reducing costs of innovation, can deliver higher customer loyalty and even faster growth in the marketplace.

About the Author / Kevin Dunne

Kevin Dunne is vice president of Business Development & Strategy at QASymphony.
August 12, 2016
REP SPOTLIGHT: Glenfis AG
1. Tell us a little about your organization: Based in Zurich, we offer consulting and training services since almost 20 years. We see ourselves as an independent enabler for the digital transformation, helping our customers getting fit for the digital age. To this end, we use the ‘Glenfis Principle’ – a holistic approach that, alongside theoretical knowledge, attaches particular importance to the mediation of practical skills (competence), which can be used to successfully and lastingly deploy this knowledge in the company or organisation (Implementation).
2. What other topics do you teach or consult on? Topics include:
  – Cloud & Sourcing
  – Lean, Agile & DevOps
  – Value Chain Service Models
  – Training and Awareness (Cloud, ISO, ITIL, Cobit, Security, Agile, DevOps)
  – Security & Cyber Resilience
  – Change Enablement
3. What type of interest in DevOps are you seeing in your region? As everywhere the interest of DevOps is rapidly growing, in Switzerland this in not different. For many it’s really to understand in a first step what DevOps is about and why it is relevant for them. In Switzerland we deal a lot with financial institutes with a high level of legacy and regulations, the question is often how to apply DevOps practices in such an environment.
4. How do you think that DevOps contributes to the business’ value stream? DevOps is all about getting faster and better and this is how it positively influences the value stream. And DevOps does it in a holistic way by looking at the value stream end-to-end, from idealization to $$$.
5. What topic area in DevOps excites you the most? Dev’s and Ops’ finally talking to each other!
6. Why should enterprises and individuals consider formal DevOps Training? Before starting any change initiative, it is paramount that everybody gets a common understanding. This is especially true for DevOps, as it includes a wide range of Agile, Lean and ITSM practices. A training or special awareness sessions definitely facilitates this.
August 10, 2016
REP SPOTLIGHT: Xellentro Consulting Services

DevOps Institute: Tell us a little about your organization.

Xellentro: Xellentro Consulting Services LLP is an emerging global provider of project, program and portfolio management, IT service management consulting and training services. Established in 2012, with headquarters in Bangalore, India, Xellentro works closely with its clients in tackling their most difficult organizational development challenges. Xellentro is a specialist organization that works with its clients to identify improvement areas and uses experienced consultants to enhance their business and development processes.

While the realm of management consulting is vast and a number of firms provide a range of advisory services—starting from niche areas to general management domains—what differentiates us is our practitioner’s approach where we don’t limit ourselves only to advisory and rather prefer to stay on till envisaged benefits are realized and final outcomes are delivered. We bring in huge experience across industry verticals.

DOI: What other topics do you teach or consult on?

Xellentro: ITIL Foundation, Intermediate, Practitioner, Expert, Scrum Master and Product Owner, PRINCE2, PRINCE2 Agile, MSP, MoP, PMP, Lean Six Sigma

DOI: What type of interest in DevOps are you seeing in your region?

Xellentro: There is interest mainly from corporates.

DOI: How do you think that DevOps contributes to the business’s value stream?

Xellentro: This will be a good extension to the ITSM and with Agile being used everywhere, DevOps will have a great value.

DOI: What topic area in DevOps excites you the most?

Xellentro: The concept of having both Development and Operations working together is very important to finally deliver value to business.

DOI: Why should enterprises and individuals consider formal DevOps training?

Xellentro: To really understand the culture change and not focus on only the tools/automation part of it.

August 10, 2016
Iterative Indicators: Measuring DevOps ROI

It’s well-established that application of ROI measurements to IT investment remains an imperfect science, and the same goes for ongoing adoption of DevOps methodologies.

The fuzzy math of vendor-driven ROI calculators aside, even the most respected industry watchers have long struggled to create concrete parameters for assessment of technology spending. This, in large part, has been related to the fact that the requirement for continued investment has outweighed the value of short-term metrics.

At the same time, it’s hard to put a price on the influence that paradigms including mobility, virtualization and the cloud are having on today’s business world. The scope of the so-called Applications Economy is only truly beginning to be realized.

For in-depth discussion of DevOps ROI, register today for the upcoming webcast “Maturity Metrics – Analyzing the 2016 State of DevOps Report” with noted industry expert Gene Kim.

With DevOps, the challenge of ROI measurement evokes similar characteristics as with these other bellwether movements. The affect that leveraging DevOps to become more agile and respond adeptly to changing customer expectations will have, long-term, ultimately will be realized as much in organizational viability as in any immediate cost-savings or other factors.

That said, the recently published 2016 State of DevOps Report, assembled by the researchers at DevOps Research and Assessment (DORA), goes further down the path toward creating meaningful ROI metrics than any other such previous effort.

For starters, the 2016 report builds on previous year’s conclusions that so-called “high-performing organizations”—those already deeply engaged in DevOps practices—are “decisively outperforming their lower-performing peers in terms of throughput,” and this gap continues to widen.

Moreover, DORA contends that high performers deploy applications code 200 times more frequently than slow performers and achieve 2,555 times faster lead times. Perhaps even more importantly, in particular as it relates to the ability to improve applications performance, the report estimates that leading DevOps practitioners lay claim to 24 times faster recovery times and three times lower change failure rates.

The State of DevOps Survey, completed by roughly 4,600 technology practitioners, also found that high-performing teams spend far less time on so-called “unplanned work and rework”—most often required to address existing problems—allowing them to spend nearly 50 percent more of their time on new work. The latter brand of effort is typically aimed at adding or improving feature functionality—or, in simple terms, innovation.

As increased software velocity and reduction of MTTR represent the most critical differentiators in today’s environment, where an end user may wait only seconds for an app to load before abandoning your brand altogether, these conclusions obviously carry impressive weight.

Finally, based on a framework established by research analysts at IDC which suggests that hourly application downtime costs can range from $1.25 to $2.5 billion for a Fortune 1000 firm, and that the average cost of a critical application failure is $500,000 to $1 million per hour, the State of DevOps Report allows for the conclusion that high-performing organizations save an average of more than $91 million per year.

Much of this advantage is found, the researchers note, in the form of lower applications change failure rates, or those updates to software code that result in subsequent performance issues or outages. While high-performing DevOps practitioners experience an average change failure rate of 7.5 percent, medium-performing organizations see that figure rise dramatically, to a whopping 38 percent.

If the undeniable adage that “time is money” applies in today’s Applications Economy as much—if not more than ever—than these ROI calculations would appear to infer substantial meaning.

Later this month, Gene Kim, one of DORA’s founders and a key contributor to the State of DevOps Report, will host a webcast with CA Technologies expert Aruna Ravichandran to discuss DevOps ROI and many other related topics. Register for that event today.

July 8, 2016