devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.
Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers. Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role, it creates an opportunity for others.
The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale offered.
We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:
A new study by mabl found a correlation between complete, fully automated test coverage and a significant increase in customer happiness and DevOps maturity. In contrast, those with moderate DevOps maturity and nearly automated testing coverage tend to experience a sharp decline in end-user satisfaction.
Mabl recently released its 2021 State of Testing in DevOps Report, a study that highlights the state of DevOps adoption and quality testing throughout the software industry. According to Dan Belcher, co-founder, mabl, the study results clearly show that true business returns are made in the last mile of DevOps adoption.
I recently met with Belcher to hear his viewpoint on the major takeaways. Below, we’ll explore these and other insights from the 2021 State of Testing in DevOps Report.
State of DevOps Maturity
Nearly one in four teams have a mostly mature DevOps methodology and automated process. Still, a significant portion, 52%, are still aspiring or striving to fully embrace a mature DevOps model. A small percentage, 11%, have a fully automated DevOps software development pipeline in place. The bulk of teams are still using manual deployment processes and disparate frameworks, limiting the potential for full automation.
Interestingly, non-technical barriers remain the most common inhibitor to realizing a completely automated development pipeline, found the report. Out of these obstacles, reluctance to change was the most common barrier, cited by 29% of respondents. Other challenges to DevOps adoption include budgetary constraints, DevOps not being a company priority and internal politics.
When added up, non-technical roadblocks account for 82% of the problems that hinder complete DevOps adoption. On the one hand, this depicts the cultural challenges associated with introducing DevOps in an organization. On the other, it could signify the wealth of DevOps packages and open source tooling available to manage areas like automated deployment and version control. The report found GitHub, Jenkins, Gitlab, Azure Pipelines and BitBucket among the five most commonly used DevOps Tools.
Although it’s growing rapidly, continuous delivery is still an emerging trend; almost half of developers still deploy code less than once a month. Only 15% of teams are deploying code daily or multiple times per day. This echoes findings from CDF’s State of Continuous Delivery Report, which pegged this figure at 11%.
Fully Automated Testing
Testing is a critical component of the software life cycle. With the need to ensure functional applications and high-grade security, automated testing is helping teams discover more errors earlier in the development process. According to the report, the most popular test types include UI or functional tests, unit tests, regression tests, integration tests and end-to-end tests. Non-performance tests and visual testing ranked lower. Naturally, the teams that have implemented fully automated pipelines are automating more types of these tests.
In general, it appears test automation aligns with DevOps maturity. The report found that those with fully automated testing experienced significant net customer experience gains. For example, 72% of teams that were automating regression testing indicated their customer happiness is pretty good or amazing, whereas this figure sank to 6% at companies not automating regression testing. And 80% of teams with high test coverage report high customer happiness, whereas only 30% of teams with low test coverage report high customer happiness. Nonetheless, much has yet to be fully automated—similar to the state of continuous deployment, the bulk of teams rely on a combination of automatic and manual testing approaches.
In terms of tooling preferences, Selenium ranked as the most popular option for functional testing, with 41% of developers using it. The report also found migration toward Cypress, Smartbear and other functional testing tools. Interestingly, the report also uncovered a noticeable lack of adoption when it came to automated API testing—only about one out of three are automating their API tests. Postman, SoapUI, internal tools and ReadyAPI are among the most popular tools for running manual API tests.
As I’ve covered before, APIs are surging in use across digital transformation initiatives. Web APIs are an increasingly common mechanism for delivering data to partners and consuming third-party software-as-a-service (SaaS). Full API testing coverage will be essential to audit the entire end-to-end digital experience. Low-code API testing is one way to reduce barriers to auditing the highly technical area of integration.
Key Takeaways
DevOps success is a ‘last mile’ problem. There is much variance in DevOps maturity and testing coverage. It’s pretty flat until you reach that last point, when breakthrough results occur. “Success in DevOps is a ‘last mile’ problem,” said Belcher. “The difference between 90% and 100% of the way there is dramatic.”
Quality really matters. Though much tech discussion focuses on increasing delivery speed, code quality is just as important. “This isn’t about speed at all costs, it’s about innovation with velocity and quality,” said Belcher. “Quality engineers are just about as key to success as developers writing code.”
DevOps success is less about technology and more about people. As the report found, the majority of the roadblocks to DevOps maturity are non-technical. “The things holding us back, as an industry, are more about leadership and figuring out our processing than introducing more technology,” said Belcher.
Breaking down role silos is still fundamental to DevOps. Some see DevOps as instrumental to opening collaboration between roles. Simultaneously, there is the idea that new tooling dashboards will arm individual developers with complete ownership to develop, test and deploy software (known as full cycle development).
Belcher believes that the full cycle momentum has been misinterpreted to mean developers alone have full accountability. Instead, he frames developers as a pitcher on a baseball team; leading the game, but utterly incapable without the rest of the team. Similarly, disparate roles should be working together, said Belcher. Reaching that ‘last mile’ of DevOps is not only about CI/CD or full cycle development; it’s about working together as a group.
I’ve only scratched the surface of many findings from The State of Testing in DevOps. The report queried 600 quality engineers and software development professionals and offers loads of additional insights on the state of DevOps, testing, CI/CD and more. You can view the full results here.
DevOps, as we understand it, is a set of protocols and value-systems that enable development and operations teams to work in perfect harmony within an organization. Surveys of DevOps response teams reveal that the strategy of building bridges between developers and marketers has helped organizations speed up software release cycles, improve product quality and augment platform security. We know for sure that DevOps improves performance, strategic outcomes, company productivity and, more importantly, the product’s market share. But there is a glitch; apparently, everything isn’t as rosy as we imagined it to be.
There is the elephant in the room, a problem that lurks in the background, an issue that refuses to go away. It would appear that there is a growing chasm between Marketing and DevOps that businesses are struggling to bridge. Some voices would say that developers are opposed to the traditional ways of marketing and the “My way or the highway” attitude that marketers sometimes adopt, which is not conducive to collaboration. Far from helping organizations work harmoniously, is Marketing killing the golden goose of DevOps? Are we in desperate need of reorienting our business culture?
Miromind’s SEO strategist Agnieszka Podemska believes the growing impact of technological change has made it obligatory for developers and marketing professionals to meet on a common platform. As the DevOps methodology takes control, marketers are increasingly joining the conversation and influencing the outcome, and this need not be the friction-ridden, nerve-jangling process it is made out to be. Let’s come to terms with the role-playing we see in the DevOps arena.
DevOps needs marketers to collaborate and provide access to policies for determining the thrust of business growth. If marketing aims to improve the user experience and customer satisfaction levels, marketing needs DevOps to create a strong and reliably efficient IT backbone to facilitate that experience.
The developer working in backroom isolation would be far removed from the battlefront where the customers are changing preferences and deciding product choices at a fast pace. For developers, it’s easy to lose track of what fulfills customer intent most effectively. Without regular feedback from marketing and sales teams, developers wouldn’t know how, when, and where functional gaps need to be plugged to improve the user experience. At the same time, marketers must become aware of what is engaging the developer’s attention so that a coordinated effort can be railroaded to smooth out product promotions and software rollouts.
Whatever misgivings marketers and DevOps teams may harbor regarding each other, both are locked in a mutually interdependent relationship in which cooperation and coordination are necessary to achieve business goals. Can we prevent marketers and DevOps teams from working at cross purposes? Yes, it’s possible if we’re clear regarding the principles and the culture promoting successful business growth.
Marketing and DevOps Can’t Function in Isolation
Marketing and DevOps are like two sides of the same coin that rings the cash registers in business growth. Their aims are the same. If Marketing aims to bring in new customers and plan strategies to target specific audiences, developers will focus on improving the product and speeding up delivery so that customers enjoy a friction-free user experience. This is a symbiotic relationship where the guy promoting products and reaching out to customers is as critical as the dude deploying customized code.
You need Marketing to promote the software and an efficient sales team to improve the customer’s interaction with the product. The paying customer doesn’t stop at engaging the product; they’ll want to talk about it. The marketer will go social, they’ll go mobile, hold webinars, and host trade shows to forge a deeper connection with the paying customer because it’s not just about acquiring customers but of retaining customer loyalty to the brand. The point is that Marketing can’t do this in isolation; Marketing needs IT support and services that only DevOps can guarantee.
Software Development and Product Marketing are Symbiotically Wedded
In every aspect of business development, the software release cycle and sales funnel are mutually interdependent. When Marketing promotes products across social media and blog posts, and through channels such as emails and press releases, every software update launches simultaneously to enhance the user experience across all platforms.
Strategic partnerships lubricate business growth, and partner programs and reseller programs are automatically updated by DevOps to ensure that the product is shareable with prospective customers. Each software update can be programmatically controlled as Marketing gathers and shares customer feedback. DevOps can leverage these insights to improve services.
Marketing feedback is the driving engine propelling software development, and every feature request or design change improves customer satisfaction. It’s possible to make a significant improvement in customer fulfillment levels only if Marketing and DevOps work in tandem.
CRM Optimization Peaks When Marketing and DevOps Collectively Analyze Data
Predictive data analytics is a hugely collaborative endeavor where Marketing and DevOps teams need to get their act together. With the help from IT-driven automation, it should become possible to organize and view data regarding the customer’s browsing history and how frequently the customer interacts with the product. The consumer database mutually analyzed lays the foundation for formulating policies that promote customer retention and sales growth.
The DevOps team should make it possible for customer relationship managers to view consumer usage and responses in real-time so that the feedback enables more satisfactory support solutions that enhance upselling options.
Marketers essentially breathe content and life into digital ads aiming to multiply the number of paid users over time. DevOps, having built the product from scratch, is more aware of the product’s USP and can give a positive direction to marketers regarding the message that is conveyed to the consumer.
What DevOps Ought to Be Telling Marketing: ‘We Believe in You’
A common perception among DevOps members is that Marketing really doesn’t comprehend what the software is capable of doing. What DevOps needs to understand is the consumer is not as focused on the thrills and spills of the cutting-edge software that is packaged and presented to them. The consumer is more concerned about how the software can benefit their business.
If consumers are not personally invested in the product and do not see something that is customized to solve their business issues, they’re least likely to buy the product. This is the reason why Marketing focuses a lot on tailoring the message to fit each demographic to fulfill a specific need. The message may not match the expectations of a developer, but it might indeed be what a customer wants to hear.
For DevOps, testing or updating any kind of software involves strict adherence to a protocol of rigorous standards. The same approach can’t be expected of Marketing. Marketing is more invested in imagery and the message, which may differ drastically when different types of consumers are approached. In Marketing, strategies may change by the hour, if only to understand how different audiences resonate better with the product.
This is where DevOps and Marketing ought to be communicating with each other through all stages of the sales funnel. If, for example, marketing is leaning heavily on mobile software but that happens to be the weakest link in the chain, it is for DevOps to step in and suggest features that deliver more value for the consumer.
What Marketing Expects From DevOps: ‘Plug the Weaknesses and Play to Our Strengths’
Improving Marketing-DevOps relations is vital to any growing businesses. Marketing can’t stop at tabulating requirements and then leave it for DevOps to come up with the perfect solution. The Eureka moment in software development comes only when marketing hand-holds DevOps through each stage of the development process. For example, marketing could become more involved in user model testing.
DevOps knows the strengths and weaknesses of the software; Marketing is better aware of the audiences’ needs. Both teams have access to predictive data analytics that tracks consumer behavior concerning the product that is being improved. If Marketing can pinpoint user models that are not likely to work in a real-time situation, that model can be rejected at the drawing board. Proper communications and effective collaboration mean that the consumer is less likely to be presented with a product that promises a lot but delivers far below expectations.
Conclusion
If the universe of product acceptance and consumer satisfaction is like a gigantic jigsaw puzzle, Marketing and DevOps are the pieces that have to lock in place harmoniously to complete the picture. If parts go missing, it will show by way of an inferior product.
Even if their priorities differ, both Marketing and DevOps have to work in harmony to fulfill business objectives. Mutual trust and communication are two vital cogs that turn the wheel of progress and business growth.
The future will be molded by teams of DevOps, Marketing, and Sales that work together, aggressively analyzing consumer feedback to deliver user experiences of high quality consistently.
What marketers and developers should be asking themselves is, “Am I a Lone Ranger riding off into the sunset?” or, “Am I a team player guiding the company through wild terrain, conscious that there’s a destination to be reached together?” The answer determines your business trajectory.
Almost since the beginning, there has been a tug-of-war between whether better toolchains or increased communications were “real” DevOps. The answer to that question is, Yes.
Better tools undeniably speed the delivery process and streamline operations. Anyone who claims differently is not living in the real world. Jenkins alone can make your development world a better place, and it is but one tool—with hooks into like a million more, but still one tool.
Increased communications speed the delivery process and streamline operations, if they are frank and honest. A developer who knows that his choices for included dependencies can make life easier or more difficult on maintenance is far more likely to include that consideration in their choice, for example.
Gains Are In the Doing
But the rock-star gains that some shops have seen from DevOps? Are a bit of both, and something else. The sudden improvement of 4x delivery frequency most often comes from no longer avoiding that thing you don’t talk about, or the legacy piece of software that eats an increasing amount of time just being kept alive because it’s necessary.
And I would argue that is the best place to start. I’ve touched on this tangentially before, so I thought I might be more direct.
You have it. That thing in the process that is a bottleneck. No one talks about it. There are reasons—some because a few years ago you tried to resolve it and couldn’t; some because the bottleneck is a natural outgrowth of some requirement; some because “it’s always been that way,” But there is that step (or more often three or four steps) in the develop/test/deploy cycle that consumes a huge chunk of time to do little work.
There are also those tools/processes so old that they consume an inordinate amount of resources. Most shops more than a few years old have them. I’ve worked in a couple of 100-plus-year-old companies and frankly, these bits of outdated software were part of the genotype of the org because they’d been in IT so long.
Manual processes are known to take time, simply because they’re manual. Development itself, even when broken into smaller pieces and implemented piecemeal in the manner of Agile, still takes time. Testing, too, is still (or again, depending upon your background) a largely manual process. And security checks are also in a ton of shops.
These are known. And if you’re approaching the problem from the “find the bottlenecks,” I would exclude them. Better tools or more automation can help all three, streamlining who does what can help test and security, but these aren’t the places that I’m thinking of.
Aging Support Software
I worked in a shop once that spent an inordinate amount of time keeping a “database” alive that was in existence before RDBMS. Yep. There was mission-critical software that used the database, so it was maintained as well as possible internally. Internally because the vendor no longer existed.
Several analyses were done, and each time it was decided that the DB couldn’t be gotten rid of without a major rewrite of the systems it supported. But as time went on more and more resources were poured into those systems and the database. Eventually, it was forced from above that the database had to go. The estimate to do so came in at an insane number and the project was dropped. Meanwhile, an increasing amount of resources were being poured into the DB and the systems that supported it. All were outdated, and all required special skills that were also outdated. Soon the org was paying exorbitant rates for the few people who could work on the system to do so via contract.
Finally, with hard dollars attached to the preservation of this system, a forced upgrade was a viable project, and it went forward.
This is all pretty standard enterprise stuff, it’s kind of the way IT has functioned in the past. But had IT management gone to business units with improvements that could be offered during the upgrade, all of the resources poured into not upgrading over the years could have been used for new product/feature development. Identifying the fact that replacement was inevitable and wouldn’t get cheaper for waiting is the type of outdated software issue I’m talking about.
Bottlenecks
From the bottleneck side, there is often a “this monster log file must be reviewed by a human” step on the way to production, too. Think about simple automation. What is the human scanning for? Talk to those responsible and see if they can offer guidelines concerning how they would train a new person to review the file. Then write a small script to do it—not as a final solution, but to show that a person doesn’t have to if the review is well-bounded. People won’t trust it, so run it in parallel for a while, and learn from what it misses, point out what it finds. Long term, eliminate the delay of someone pouring over logs looking for the same things over and over. Take time to make it possible. It won’t be a ton of time, but it will reap gains. Just talking to the team that must accept the log output might reap gains.
There isn’t a need to immediately install 15 DevOps tools or reorg all of IT before starting your DevOps journey. Just look for the places resources are being invested to little long-term gains, or where the process is held up in a manner easily eliminated. And keep rocking it.
Lynda: Technology and Creative Skills taught by industry experts.
Tuts+: Thousands of free tutorials and online courses to help you learn software development from mobile devices to web applications and everything in between.
Source control:
GitHub: GitHub is a web-based Git repository hosting service. It offers all of the distributed version control and source code management (SCM) functionality of Git as well as adding its own features.
Bitbucket: Bitbucket is a web-based hosting service for projects that use either the Mercurial (since launch) or Git (since October 2011) revision control systems. Bitbucket offers both commercial plans and free accounts.
Versions: Versions offers the best way to work with Subversion on the Mac. Thanks to its clear-cut approach, you’ll hit the ground running.
Tower: Version control with Git, made easy. In a beautiful, efficient and powerful app.
SourceTree: Harness the power of Git and Hg in a beautifully simple application.
Continuous integration and deployment:
Circle CI: The modern continuous integration and delivery platform that software teams love to use.
Travis CI: Easily sync your GitHub projects with Travis CI and you’ll be testing your code in minutes!
Shippable: A declarative CI/CD and release automation platform that streamlines software delivery.
GO CD: Open-source continuous delivery server to model and visualize complex workflows with ease.
Xebia Labs: Continuous delivery at enterprise scale.
Electric Cloud: Powering continuous delivery and release automation.
CloudBees: CloudBees is the hub of enterprise Jenkins and DevOps, providing companies with smarter solutions for automating software development and delivery.
Development platforms:
Heroku: Deploy and run apps on today’s most innovative platform as a service.
Cloud 66: Simplify DevOps—build, deploy and maintain any application on any server, on Rackspace
Docker Cloud: Build, ship, and run any app, anywhere.
Appfog: A platform for creating, scaling and managing cloud-native apps.
Engine Yard: Reliability and support you can count on. Built and proven on over 1 billion AWS hours.
Bug tracking and monitoring:
Bugzilla: Bugzilla is server software designed to help you manage software development.
Bugify: Bugify is being used in many different industries. If there’s anything you need to keep track of, keep track of it with Bugify.
Usersnap: Collect feedback and track bugs. Your central place to organize your web projects.
BugHerd: Bug tracking so simple—it’s like sticky notes on a website. Capture client feedback, resolve issues and manage projects visually.
New Relic: New Relic is the first, best place to examine and understand your digital business.
Browser add-ons:
Measureit: Draw out a ruler to get the pixel width and height of any elements on a webpage.
Ghostery: Protect your privacy. See who’s tracking your web browsing with Ghostery.
Foundation: The most advanced responsive front-end framework in the world.
Bootstrap: Sleek, intuitive and powerful front-end framework for faster and easier web development.
Framework 7: Full-featured HTML framework for building iOS and Android apps.
Some cool tools:
Metricfire: Metricfire operate Hosted Graphite, a powerful way for teams to measure technology.
Snippets: Snippets is a powerful application for Mac and Windows that stores the most valuable pieces of code you can reuse in different projects many times.
Lingohub: Master your translation workflow and connect with world leading translators.
Flowdock: Chat and inbox for teams. One place to talk and stay up to date.
These tools can definitely help you do DevOps and software development efficiently.
As indicated by the “2016 State-of-DevOps Report,” multiple compelling enterprise business performance improvements provided by well-built DevOps solutions are driving IT transformations for development and operations across many industries.
While some enterprises have implemented DevOps to gain near-term efficiency benefits, DevOps is becoming a competitive essential for all enterprises to implement DevOps. Enterprises that fall behind risk long-term success in their markets. Yet, many organizations are struggling to get DevOps working effectively. What is the secret to success with DevOps?
A solid foundation for DevOps requires mastery of seven areas that we at Trace3 refer to as “The Seven Pillars of DevOps.” These pillars are all necessary to support effective DevOps delivery pipelines together with end-to-end orchestration of all pipeline stages and workflows. If any of the pillars falter, the DevOps pipeline will fail to produce high-performing benefits of the most successful enterprises.
So what are these essential seven DevOps pillars?
Collaborative Culture: End-to-end goal alignment and cooperative workflows are essential. No amount of technology will suffice if Dev, QA and Ops leaders and teams do not cooperate.
Design for DevOps: DevOps prefers products that are designed in modular fashion using microservices, 12-factor apps and containers—those are easily integrated into high-performance DevOps. That is not to say legacy products cannot benefit from DevOps, but modular, immutable architectures are most readily suited to take full advantage of DevOps.
Continuous Integration (CI): Merging forward quickly with competent integration practices that minimize rollbacks, interruptions and costly delays in the pipeline.
Continuous Testing (CT): Relevant quality testing at speed requires multiple strategies that ensure efficient coverage throughout the pipeline with minimal failures delivered to production, yet quick enough to not bottleneck the pipeline.
Continuous Monitoring (CM): Real-time lifecycle intelligent active monitoring and analytics are essential to accelerate real-time decisions at each stage of the pipeline and avoid bottlenecks.
Elastic Infrastructure: Infrastructures that are resilient and elastic perform much better. DevOps applies to most types of infrastructures including private data centers, special purpose bare-metal systems, virtualized functions, containerized packaged applications, private and public clouds and hybrid cloud environments.
Continuous Delivery (CD): Modular delivery packaging preparation and deployment solutions with orchestration of virtualized and containerized applications are preferred over monolithic mutable applications.
While DevOps implemented with all seven pillars provides a strong foundation for long-term enterprise business improvements, it is important to understand also that DevOps is not an island. Enterprises implementing DevOps should be aware that DevOps interoperates with other IT systems and practices. Enterprises are well-advised to choose tool-agnostic IT partners that can provide solutions that best suit the needs of each unique enterprise and can integrate and evolve DevOps together with all enterprise IT systems.
We believe DevOps is an essential part of enterprise success. Keep a look out for future blogs describing best practices for each of the seven pillars of DevOps in coming months.
It seems IT practitioners haven’t realized yet the scale of digital disruption. Mired in the old IT thinking, they firmly believe that sophisticated tools are all businesses need to survive the ongoing digital disruption waves. Most of them warn, “Digital transformation is changing the way we do business, the way we deliver IT services must change, businesses need to adapt the way they work.” The problem is, there’s nothing new in what they offer to help businesses work the “right” way.
Indeed, the same old IT thinking’s practices are still applied with the illusion that deployment automation and configuration management tools on their own will make businesses agile, responsive to market opportunities, and therefore in line with the digital economy’s competitive challenges. That belief misses the point for two reasons: First, it’s an incorrect understanding of what business agility is, and second, it’s a misunderstanding of the global competitive environment’s transformation.
Turning your IT organization lean and agile is the competitive differentiator your business lines desperately have been calling for. Authentic DevOps implementation is the way to go. That’s the price to pay to keep up with the pace imposed by new leading-edge companies such as Google, Apple, Uber and the like.
The changing competitive environment forces businesses to focus on innovation, market responsiveness and timely revenue
A digital economy threatens the existence of all businesses. Yes, you read it right, their existence is at stake. And that fact is underestimated by IT vendors and consulting firms.
As illustrated, we’re shifting from business environments where established businesses (incumbents) control a large percentage of market segments to competitive contexts where, attracted by the amazing digital opportunities and the adoption of cloud which significantly reduces infrastructure expenses, a growing number of startups disrupt entire industries:
The proliferation of startups created by highly qualified unemployed seniors and creative entrepreneurs, coupled with the propagation of highly innovative digital services (e.g., Internet of Things [IoT] applications) substituting traditional services, have been disrupting the vast majority of industries.
Several examples substantiate that fact: the taxi industry shaken by the emergence of technology-driven companies such as Uber, the banking industry facing new breed of competitors including PayPal, Google and Apple; and the healthcare industry increasingly disrupted by companies such as GlowCap.
To grow and prosper in the digital era, your scale, brand equity or market capitalization aren’t enough anymore. To succeed, your business lines must be on top of the digital economy’s competitive standards: competitive innovation (the ability to continuously improve customer experience), market responsiveness (the ability to deliver added-value services to the right market segments at the right moment) and timely revenue (the ability to continuously increase customer value).
The digital economy has taken IT to an inflection point—deploying sophisticated tools isn’t enough; being lean and agile is the way to go
The obligation for business lines to focus on innovation, market responsiveness and timely revenue is unprecedented for techies; it forces them to think beyond tools and address issues as unusual as organizational and operational effectiveness.
Indeed, innovation, market responsiveness and timely revenue assume greater cross-functional collaboration, IT focus on business priorities, organizational flexibility and accelerated time to market. Make no mistake, you’ll never achieve them by only deploying tools, but by also making your IT operating model flexible through proactively eliminating the organizational and operational dysfunctions that prevent cross-functional collaboration, fast problem-solving and decision-making.
That’s what is meant by making the business agile.
The new IT thinking is summarized in that simple arithmetic: Digital Competitiveness = Lean and Agile Operating Model + Effective and Efficient Tools. Without the lean and agile operating model, innovation and timely revenue are wishful thinking. Without effective and efficient tools, innovation and market responsiveness are wishful thinking as well.
DevOps is the IT asset businesses need to succeed in the digital economy
Contrary to a now (unfortunately) established belief, DevOps isn’t a technology; Chef, Puppet, Jenkins, OpsWorks, alike aren’t DevOps, they’re only pieces of it. It’s important to be clear about it.
As I’ve been implementing it, DevOps is a system of principles, practices, roles and responsibilities, governance structure and tools purposely arranged to establish cross-functional collaboration, enable accelerated applications delivery and, in turn, make the business responsive to market opportunities:
As illustrated, DevOps as a business capability is made up of three components: the Rules of the Game, the IT Operating Model and the Continuous Delivery Pipeline (CDP). Let’s explore them.
DevOps Rules of the Game create the conditions for lean and agile IT environments
Rules of the Game are a fundamental dimension of DevOps: They enable the establishment of lean and agile environments. I refer to them as the DevOps non-technological piece.
In practical terms, they’re a set of principles, practices, roles and responsibilities and tools institutionalized to ensure accelerated applications delivery.
They serve as catalysts to specific organizational and operational effective practices. Let’s take the principle, “Facilitate with system thinking (involvement of all relevant stakeholders)”—it forces application development stakeholders to adopt a collaborative mindset, which in turn breaks down organizational silos to eliminate the impediments to operational flexibility and institutionalize cross-functional collaboration.
They’re the poor cousin of today’s DevOps practices, which ignore them in favor of more technical and technology issues. That’s a terrible mistake that reduces DevOps influence vs. the digital economy’s challenges.
The agile IT Operating Model establishes the lean and agile work environment
The IT Operating Model reflects the interactions that take place across your application development value stream. In practical terms it represents the work environment derived from the application of DevOps’ rules of the game.
I always remind my clients that DevOps’ rules of the game aren’t theories, they’re the foundations of a tangible strategic capability: the lean and agile IT environment. They demand a thorough transformation of your application development work space to put together business, application development, and operations:
The lean and agile IT work space for the digital era illustrated (Credit: O.C. Tanner)
The picture illustrates what’s meant by lean and agile IT environment, it substantiates Adam Jacob’s point that “Fundamentally DevOps is about taking the behaviors and beliefs that draw us together as people, combining them with a deep understanding of our customers’ needs, and using that knowledge to ship better products to our customers.”
The IT operating model is the poor cousin of today’s DevOps practices which ignore it in favor of more technical and technology issues. Once again, it’s a terrible mistake that reduces DevOps influence vs. the digital economy’s challenges.
Make no mistake, technology matters, the CDP helps to meet digital technologies challenges
The importance of the rules of the game and the resulting IT operating model don’t suggest at all that technology doesn’t matter. Make no mistake about it, the CDP is essential; I refer to it as the DevOps technological piece. Through deployment automation and configuration management tools, it significantly accelerates application development, testing, resources provisioning and deployment.
However, one thing to be aware of is, digital economy raises technological challenges that transcend speedy delivery issues. They include:
The importance of IoT
The pivotal role of predictive analytics
The increasing importance of APIs
As a matter of fact, IoT devices generate massive data and making use of it to generate revenue requires big data technologies to integrate, automate and analyze them.
On the other hand, this ocean of IoT data has generated an API business; the idea is, to monetize their data and generate revenue, businesses must provide their customers and partners with APIs that easily give access to their systems.
Implementing the CDP as part of PaaS cloud services can help to prosper in the digital economy; it allows businesses to benefit the cheap and on-demand computing, storage and network resources provided by the cloud.
Takeaway
In hindsight, with a business-oriented perspective, the ITaaS delivery model and DevOps follow the same goal: Provide business lines with the lean and agile IT environments they need to be flexible enough and responsive to meet the competitive challenges of digital economy:
Like DevOps, the ITaaS delivery model (…) takes advantage of an agile IT operating model to help businesses succeed in the digital era. It implements consumer-provider relationships across the IT value stream to ensure organizational flexibility and operational agility.
CIOs must realize that what matters to the business is to continuously generate revenue through improving customer experience and increasing customer value. Deploying applications at the speed of light for the sake of speed doesn’t make sense from a business perspective; as long as expected business benefits aren’t achieved, speed is a useless gadget.
Implement DevOps as what it is: a three-dimension IT capability including rules of the game, IT operating model and, of course, continuous delivery pipeline.
HM Heath Solutions delivers new business applications in the healthcare industry to 35 million customers. In order to embark on their DevOps journey to improve software delivery, Valerie Scott, their Manager of Shared Services Division, had to show senior management an ROI on a successful project, before they would invest fully. On June 2, Val Scott along with Rick Slade of IBM joined Alan Shimel of devopsy.kinsta.cloud in a webcast to discuss this interesting client case study. During their discussion, they illustrated in vivid detail how HM Health Solutions showed success in DevOps to their senior executives, for them to buy in and sponsor the project.
When I meet with senior LOB, Finance or IT executives — they shout a similar refrain:
“All I want to do is buy a business outcome. I want to invest in an IT project, and have it pay back. Unfortunately for many application development (or other types of enterprise IT) projects, that pay back is illusory, and ROI difficult to measure.”
— Jane or John Executive, representing nearly every IT executive or CFO I have ever met
As you undoubtedly have experienced yourself, senior executives respond to clear business value and benefits articulated as financial returns, as ROI. But how do you do that for DevOps, a set of technical practices and associated culture change? As Val and Rick described during their informative webcast, comparing productivity, time-to-market, speed of delivery, and quality, both before and after a DevOps pilot, are crucial. These operational metrics will be improved by adopting DevOps. However, to win the hearts and minds of senior executives, you have to monetize the results, in other words – show them the money! Technical techniques and practices such as those Val and Rick described to Alan, shifting left, test driven development, and automating application build, deployment, and test are absolutely necessary, but they are insufficient to win the argument with senior executives. The gains they produce are necessary, and impressive. The operational results have been stellar thus far at HM Health Solutions, per Val:
a 67% reduction in resource demands on the release team & process,
a 75% reduction in relative hours to repair defects per environment,
an 82% reduction in application deployment time.
Yet as impressive as these operational results are, they are insufficient. As Val described, arguments about business value, technical value, or improvements to developer or operations staff productivity, alone did not persuade the management. The magic word is an economic and financial one: “investment”. Making a strategic investment to improve delivery speed and quality of business applications was the key to winning the hearts and minds of the senior executives.
In addition to the technical practices described above, Alan asked Val to describe the tools HM Health Solutions adopted. A continuous delivery solution with application release automation software from IBM UrbanCode was implemented, including application build, deploy, and release.
As a way of summarizing the webcast for the audience, Alan asked Rick and Val for their two key takeaways; the two most important messages and things to remember. Rick’s:
Knowing which metrics are critical to your organization. There are many benefits to adopting DevOps, and many potential hard numbers that are straightforward to capture and measure. Deciding which metrics have the most impact and are most persuasive to your stakeholders is critical to making the case to invest in DevOps.
Implementing tools and automation: automated testing, and linking that to build and deployment processes and automation.
Val’s: Rick’s two takeaways of course! And one more…
DevOps is new in the industry, and is not yet well understood or common practice in enterprise IT or among its leaders. Understand your audience, and become good at explaining it in straightforward and clear business and financial terms to senior executives. Especially persuasive are other client proof points, and the results of pilots in your own enterprise IT environment. Make sure pilot results show that the solution works and delivers timely business value, and that the related facts and metrics clearly quantify the results.
This was a very informative, fast paced, and information rich webcast. I hope that you find the replay useful in continuing your DevOps adoption journey.
If you’d like to explore more about management responsibilities and know-how for establishing an ROI for DevOps and app release & deployment automation, see this ROI web page, and read this ROI blog for additional resources on method, approach, making the case, and calculating the ROI. And please don’t hesitate to reach out to me on twitter: @paspung.
I look forward to hearing your success stories in making the ROI case to senior executives, and delivering DevOps value to your organization!
Peter Spung, DevOps Deploy and UrbanCode Integration Executuve, IBM Cloud, @paspung
