Every IT shop has a “tool chain” – all of the software other than the OS and the application that fills in the gaps and keeps everything running. This includes solutions for monitoring the application, data protection, software development, release management, provisioning and de-provisioning resources and more. These tools build up over time, often evolving from homemade solutions to commercially available software as the company grows.
The cloud presents another inflection point: a new way to manage systems and applications. When a company is considering moving applications to the cloud, IT and application development teams should take the opportunity to reevaluate their tool chain. Are their existing solutions still the right fit in this new cloud-based world, or are there better alternatives available? Here is a process for making that decision, and some important questions to consider when assessing whether a change is in an organization’s best interests.
Step One: Take Inventory of the Current Tool Chain
First, IT teams should perform a full inventory of their current stack to ensure they don’t overlook anything. This audit should include the following areas:
Provisioning tools (like Ansible or Terraform).
Identity and access management (IAM) solutions that allow IT to restrict access to servers, resources and software to only relevant users.
Development tools including IDEs, continuous integration/continuous delivery (CI/CD), source control and more.
Data protection, high availability, disaster recovery and backup software.
Monitoring and auditing software (like Datadog).
Step Two: Assess How Well Each Tool is Meeting IT’s Needs
Next, consider how well each product is meeting IT’s needs now, and how those needs will change as workloads move to the cloud. The first and most important question: is the tool and/or version you’re on still supported by the vendor? Changes like this migration to the cloud are rare, so the likelihood that one or more products are no longer supported is higher than one might think. Second, consider the licensing terms of the software and whether they allow for its use in the cloud. For instance, some tools are licensed to a specific physical server and some vendors require their hardware to be owned by the same entity which holds the license. Neither of these scenarios work well in the cloud. Third, will the application be managed in the same way after the migration? The cloud typically removes constraints; it offers nearly unlimited compute and storage, dynamic workloads, new APIs and multiple regions around the world. IT teams may want to take advantage of these capabilities by moving to a cloud-based tool (replacing an on-premises application log reporting solution, for example), or they may want to keep management as consistent as possible to minimize the amount of retraining required for employees.
Don’t forget to consider non-technical arguments. Is the team happy and productive with the current solution, or do they feel forced to use it? Is it meeting the business needs of the organization? Will the change create more work in the short term? These reasons aren’t enough to keep a tool on their own, but they should be part of the discussion.
Step Three: Create a Map of Alternatives
Next, look at the potential alternatives to the tools that may need to be replaced. This can be a good opportunity to consolidate, so start by looking at what other teams in the organization are already using in the destination cloud. The most common decision IT must make here is whether to switch to a cloud-based tool (either one offered by their cloud vendor or a separate SaaS product). These typically offer pay-as-you-go licensing and are usually easier to scale up or down, move workloads around and to expand to other regions. Licensing for legacy vendors varies widely; some now offer consumption-based options to compete with the cloud, while some are sticking with perpetual licenses. These factors may make a cloud-based tool more or less attractive for specific companies based on their needs. Last, consider if making a change would allow the IT team to expand their skill set. For engineers that like learning new things, adding new products could actually increase satisfaction and retention because it gives them a chance to learn something new.
Step Four: Talk to Existing Tool Vendors
Even if a different option seems like the better choice, it always pays to check in with the current vendor and give them a chance to keep your business. It’s possible they may offer more flexible terms to keep you as a customer. The opposite is also possible; some vendors won’t budge on their licensing because they see the cloud as a threat. Even if a vendor conversation doesn’t change what they are willing to offer, it will usually reveal useful insight about how they approach their customers.
Step Five: Create a Plan for Each Tool
Based on the information gathered in the last four steps, it is time to decide what to do with each tool and make a plan for each transition. Where necessary, note products that will need to be replaced soon, ones where more research is required, and compile any other useful information learned during the process so that the larger IT team can access it. Also consider if teams will need training, if internal documentation or playbooks need to be updated, and how new tools will plug into existing authorization/authentication solutions. Each change will also need a migration plan of some kind that details how and when the organization will move from the old product to the new one, what scripts will need to be rewritten and what to do with historical data like log files from the old product.
Cloud-based tools won’t be a fit for everyone, but their flexibility, potential cost savings and ease of scalability shouldn’t be underestimated. While no one is eager to add more work to a cloud migration project, taking the time to go through this process could uncover useful new options that better fit the new cloud model that the business is moving toward.
The story you’re about to read and its recommendations are real; they contrast with what you have heard so far about digital transformation and DevOps implementation. Its objective is to convince you about that the time to go digital is now; it’s about transforming your business, not only IT; and to do it you’ll have to implement DevOps entirely.
In September, Toys R Us, one of the world’s largest toys store chains, filed for bankruptcy protection. A better understanding of how disruption in the retail industry impacted the company would have helped to prevent its downfall and to reinvent its business model. For example, providing Toys 2.0 (a generic term referring to a new generation of toys built on cloud, mobility, IoT and AI technologies) gaming services could have helped the company survive.
Shifting to Toys 2.0 demands a revolution in thinking, vision, practice and value that business leaders, CIOs and IT vendors haven’t done yet. They must forget the obsolete notion that technology and speed determine business success. Adopting paradigms that stress innovation and solve competitive constraints is the safest path toward fast and durable revenue.
The biggest problem Toys R Us faced was the fact that consulting firms and IT vendors either didn’t understand the challenge as an industry disruption issue—or if they did, they improperly addressed it.
Let’s clarify: To tackle your industry’s disruption, you must adapt your business model including the set of interactions, staff and skills, processes and practices, beliefs and values and infrastructure and tools used across your company to generate revenue. Industry disruption is the challenge, and DevOps through its many assets is the unique business capability companies need to quickly transform and win their digital battles.
The problem, as Alan Shimel, founder, CEO and editor in chief of devopsy.kinsta.cloud, puts it:
“While so many companies have already started to use DevOps or planning to use DevOps and related methodologies soon, there is only a small percentage of companies that are end-to-end DevOps. This means there is still tremendous opportunity in bringing DevOps to market.”
How should have Toys R Us leveraged DevOps to tackle its industry’s disruption? Why did investing in that global digital e-commerce platform prove insufficient? How well did they transform their business model? How would have implementing DevOps 100 percent helped to overcome Amazon and Walmart competition?
The principles, ideas, practices and solutions in this article are part of a case study we developed at ITaaSNow to see how to help companies facing similar challenges.
What is DevOps?
Alan, who is a major contributor to DevOps, is right: Only a small percentage of companies have fully adopted it. DevOps is much more than the automation toolchains consultants and vendors talk about. If they want to help lines of business survive and keep their job, CIOs must get a grasp of DevOps’ business facets.
So, what is DevOps? Why do I think, it would have saved Toys R Us from digital downfall?
DevOps Beyond the Operations Automation
From my experience implementing it, DevOps is a business capability that seeks to optimize business operations (versus the sole IT operations). It provides companies with four competitive advantages needed to meet the digital business competitive challenges:
Enterprise collaboration
Business agility
Short time-to-value
Innovation culture
Figure 1 – DevOps Overview
As the picture shows, DevOps is a set of concepts aggregated around the notion of value stream to form a digital business management capability. It’s structured around four stages that format the company’s interactions and workflows into a powerful digital business management capability. These stages include:
Plan & Measure – addresses strategic watch, service prioritization and revenue generation through innovation portfolio management practices and infrastructure.
Develop & Test – takes advantage of agile and lean practices and infrastructure to ensure innovations design, development and testing.
Release & Deploy – leverages continuous delivery practices and infrastructure to timely deliver the right innovations to the right markets.
Monitor & Improve – stresses continuous improvement to guarantee not only premium customer experience but also customer value.
Four business value catalysts are used to act as revenue generators:
Culture & Values
People & Skills
Methods & Practices
Tools & Infrastructure
As you can see, DevOps transcends application development issues; it covers the entire business life cycle.
DevOps Framework as a Facilitator of DevOps Implementation
So, what is a DevOps Implementation framework?
Concretely speaking, it’s a bundled DevOps platform combining managed PaaS infrastructures and optimized value streams to help companies boost their digital business:
Figure 2 – DevOps Implementation Framework
The platform seeks to help businesses implement DevOps end to end and builds on three principles to guarantee digital profits:
Innovation as the revenue driver – It’s the belief that business can resist the competition imposed by technology companies such as Apple, Google, Amazon and Facebook when they use innovation to keep customers loyal, attract new ones and generate revenue.
Value stream agility as the foundation of market responsiveness – It’s the demonstrated notion that companies are market-responsive when they rely on agile and lean value streams.
Managed cloud as the catalyst of business performance – It’s the proven idea that when companies are focused on their core business, they innovate and offer superior customer experience.
The 5-Step Digital Transformation Blueprint
The 5-Step Digital Transformation Blueprint makes DevOps implementation fast and easy. As illustrated, it’s a comprehensive business transformation framework I developed to help clients with their digital transformation initiative:
Figure 3 – The 5-Step Digital Transformation Blueprint
It’s an integrated and inclusive approach to business transformation that involves the company’s relevant contributors. It structures the transformation effort into a five-stage transformation journey:
Digital strategy: In this step, the transformation team uses tools like the SWOT analysis matrix to help business and IT executives understand the changes in the disrupting industry along with the impacts on the company’s business model.
Value stream: In this step, the transformation team uses tools such as the value stream mapping to identify the required changes and get business and IT executives agree on the company’s future value stream. Interactions, staff, skills, processes, practices and tools are at the heart of the discussions.
Digital platform: In this step, enterprise and solution architects work together to identify and implement the technology and tools selected to support activities in the value stream.
Digital organization: In this step, a panel of business and IT users at the operational and executive levels experiment the new digital business model under actual business conditions. The tested digital business model is then deployed as the new digital organization.
Digital business management: In this operation phase, the value stream and the digital infrastructure are extensively used to run the business.
How Chief Digital Officers Set Up Top Digital Businesses
It would be remiss on my part not to recommend the online digital transformation course that gives DevOps practitioners—executive and operational from both the business and IT—the insights about implementing DevOps as the foundation of digital business.
Analyzing Amazon and Walmart Disruptive Impacts to Spot Guidelines for Reinventing the Company
Many bankruptcies happen because business leaders don’t take the time to understand their industry’s disruption and the impacts on their overall business.
The reality on the ground is, industry analyses and competitive strategies are either overlooked or totally ignored. Understanding the toy industry’s disruptive effects would have helped to identify Toys R Us’s transformation as the safest solutions to avoid bankruptcy.
DevOps implementation framework makes the difference, it sees DevOps as the foundation of digital business success. It considers industry and competitive analyses essential steps of the DevOps transformation initiative. Figure 4 outlines the outcomes that resulted from our industry analysis:
Figure 4 – Toy Sector’s SWOT Analysis
As illustrated, it was shown that Toys R Us should have exploited Amazon’s vulnerabilities and take advantage of the technological opportunities to reinvent itself as a Toys 2.0 gaming service provider. These vulnerabilities include little product differentiation while technological opportunities refer to the new toy generation built on cloud, mobile, IoT and AI technologies.
The company’s strengths—reputation, longtime industry presence, brand equity—combined with the cost savings resulting from managed cloud adoption would have not only simplified its transformation but also challenged Amazon on costs.
Changing the Value Stream to Establish Innovation and Invent the Company’s Digital Business Model
Business leaders don’t take the right transformation decisions because they lack insights into the changing competitive environments. Aggressive marketing and sales campaigns supporting short-term financial gains. Toys R Us failed because it bet on its debt reimbursement at the expense of its business model reinvention.
A DevOps implementation offers a value stream mapping framework that not only facilitates innovation culture implementation but also speeds up digital business models development.
Figure 5 – Value Stream Mapping, Agile, and Lean
The objective of the value stream mapping I performed was to outline the features of work environments that take advantage of DevOps Three Ways to equip the company with the competitive advantages needed to resist Amazon and Walmart. The following lines summarize the outcomes.
Implementing DevOps Flow Principle to Defeat Amazon and Walmart on Innovation: The value stream mapping recommended to leverage Agile and Lean principles to properly implement the flow principle and defeat Amazon on its little product differentiation. The Agile’s features to stress included collaboration and prioritization while focus on people engagement and customer value were the Lean’s benefits to emphasize. Their combination were likely to not only foster innovation culture but also accelerate time-to-market and time-to-value.
Implementing DevOps Feedback Principle to Guarantee Superior Customer Experience: As to the feedback principles, the value stream mapping recommended to use Lean’s value stream assessment and Agile’s review mechanisms. The objective was to institutionalize continuous improvement practices as a means to ensure superior customer experience.
Implementing DevOps Experimentation and Learning as the Foundation of the Innovation Capability: As to the experimentation and learning principle, the recommendation was to take advantage Agile’s prototyping and learning curve-lessening features to institutionalize innovation and risk-taking cultures. They were likely to not only help the company challenge its competitors on innovation but also ensure durable revenue and customer loyalty.
Enabling the Value Streams with Managed PaaS Services
Using technology ingeniously to boost business activities is clearly one of the keys to succeed in the digital business. Today’s DevOps-timid approach focused on speeding up IT operations alone not only is ineffective, but it also doesn’t make sense. It’s the entire value stream that needs optimization, not just IT.
The findings of the digital platform assessment I performed, showed as illustrated, that the global e-commerce platform wasn’t enough to compete against Amazon and Walmart. The company was at the embryonic stage of digital transformation maturity practices:
Figure 6 – Toys R Us Possibly at the Embryonic Stage of Digital Transformation Maturity
The findings suggested that using technology to innovate or creating the operational conditions to cut cost, accelerate time-to-market and be responsive to market opportunities were either overlooked or improperly addressed.
Using a digital platform engineering framework allowed me to design in a record time the following architecture:
Figure 7 – Possible PaaS Platform for Toys R Us
The digital platform would have built on two cloud services supporting the value stream: managed software as a service (SaaS) and platform as a service (PaaS). Let’s discuss them.
How Managed SaaS Services Would Have Helped to Fix the Cost Leadership and Business Agility Issues
SaaS services would have supported the Plan & Measure stage. In addition to supporting varied management activities, it would have provided two fundamental tools that possibly could have enabled the Toys 2.0 strategy: customer relationship management (CRM) and innovation management portfolio. CRM tracks, measures and improves customers’ experience, keeps them loyal and guarantees revenue. Innovation portfolio management identifies innovation ideas, supports their implementation into digital services and monitors generated value. It gives the company opportunities to disrupt and control its industry.
The on-demand and metered billing features of SaaS services would have allowed Toys R Us to get the needed software in record time while enabling time-to-market, time-to-value and responsiveness competitive advantages.
How a Managed PaaS Platform Could Have Helped to Address the Express Delivery Issue
PaaS services would have supported activities covering the Develop & Test, Release & Deploy and Monitor & Improve stages. In addition to providing the technologies needed to implement Toys 2.0 gaming services, it would have built on microservices to set up the automation tool chain and accelerate innovations development and delivery.
Wrapping Up
The recent IT innovations are disrupting several industries and expanding the digital economy. To avoid troubles, businesses must urgently start their digital transformation. Toys R Us, Sears and many others learned it the hard way.
It’s urgent to understand that the digital transformation of your business isn’t only about migrating your IT to the cloud, implementing automation tool chains or deploying artificial intelligence tools across the company. It’s primarily about transforming with a strategic mindset your company’s business model from the ground up.
Digital transformation is a complex process that engages the entire company, and requires specific methodologies, practices and tools. I renew my recommendation to take the online course, “How Chief Digital Officers Course Set Top Digital Businesses“—you’ll get from it the practical vision, approach, processes, practices and tools that’ll help you create the conditions for successful digital business with DevOps.
IT is constantly under intense short-term pressures. Line of business (LOB) executives demand a competitive advantage in digital customer engagement now. Marketing leaders demand better customer analytics now. Legal demands better audit reporting now.
In fact, much of the investment that companies are making in Agile, DevOps and continuous delivery is due to the urgent, short-term demands of the business.
But short-term actions alone are insufficient for business success. IT leaders must also strategically navigate the vagaries of the digital economy over the long term—or, as Wayne Gretzky’s father taught him, to “skate to where the puck is going to be.” Otherwise, today’s small wins inevitably will lead to tomorrow’s egregious failures and inefficiencies.
And integration of your mainframe apps and data into your enterprise DevOps tool chain is central to that long-term digital strategy.
Here’s why.
The Mainframe: Big, Nimble Iron
A DevOps tool chain is only as fast as its slowest link. For most large enterprises, that slow link is the mainframe.
Slow, waterfall-bound and underautomated mainframe dev/test processes are non-trivial—because mainframe applications and data are non-trivial. They typically are an organization’s most important apps and data. So if you can’t modify your mainframe application logic quickly or leverage your mainframe data in new ways easily, you’re uncompetitive toast in today’s fast-moving markets.
Also, mainframe applications and data typically serve as the back-end systems of record for front-end mobile and web-based systems of engagement. Your ability to innovate and remain competitive when it comes to digital engagement and digital perceived value is, therefore, almost universally contingent on lessons learned from frequent and timely mainframe code drops.
In other words, everything IT is under pressure to deliver—new mobile apps, better analytics, fulfillment of increasingly stringent compliance mandates, etc.—depends on bringing Agile, DevOps and (ultimately) continuous delivery to the mainframe.
Just about everyone realizes this. Sure, there are some holdouts who still advocate something they call “bimodal IT”—which prescribes allowing the mainframe to languish in obsolete waterfall and dev/test practices while the rest of the enterprise moves forward. But bimodal lT has proven to be a mistake. An Oct. 31, 2016, Forrester Research report titled, “Predictions 2017: CIOs Push For Speed Amid Volatility,” shines a light on the fatal realities of bimodal IT:
“In early 2016, many CIOs fell for the false promise of a bimodal strategy. They only pushed part of their team to adopt an accelerated pace — and left others unchanged. But those CIOs are already experiencing the shortcomings of operating at two speeds. Business peer frustration, polarizing and deteriorating cultures, and unsustainable operational complexities will continue, ultimately spurring most of these CIOs to course correct in 2017.”
Given the explosion of mainframe-related innovation that has taken place in the past couple of years, enterprise IT leaders and industry analysts agree that “mainstreaming” it into enterprise DevOps is the right and necessary strategy (see as examples here and here).
Some Good Things Take Time
While instant gratification may be the order of the day—and gain without pain may be an all-too-frequent vendor promise—the reality is that great IT achievements all require effort, investment and time.
Inclusion of the mainframe into your cross-platform DevOps tool chain is no exception. No CIO can achieve mainframe agility and cross-platform DevOps orchestration by simply waving a magic wand. But there is a clear, practical path to these goals for those with the requisite foresight and leadership.
That path includes:
Modernizing the developer workspace. Most mainframe development is still performed in “green screen” TSO/ISPF environments that require specialized knowledge and limit staff productivity. A modernized, graphical workspace as part of a preferred DevOps tool chain will allow staff at all experience levels to perform dev/test tasks on both mainframe and non-mainframe applications.
Graphical visibility into existing code and data structures. Mainframe applications typically are large, complex and poorly documented. These attributes are a major impediment to mainframe transformation. The right tools enable new participants in mainframe DevOps to quickly and easily “read” existing application logic, program interdependencies and data relationships.
QA “shift left.” Early detection and correction of quality issues is a central principle of modern programming—and it’s particularly important on the mainframe, where there’s an especially low tolerance for error.
Initial Agile training and adoption. Once you put the right development environment in place, you can start shifting your process from a traditional waterfall model with large sets of requirements and long project timelines to a more incremental model that allows teams to quickly collaborate on user “stories” and “epics.”
Use operational data throughout the dev/test life cycle. By using operational data in the dev/test life cycle, your DevOps team can ensure that applications perform optimally in production. They also can significantly reduce your MIPS/MSU-related costs by avoiding excessive CPU consumption caused by inefficient code.
Agile-enable source code management (SCM) functions. Traditional mainframe SCM environments are inherently designed for waterfall development and thus are incapable of supporting Agile requirements such as parallel development on user stories. The shift to Agile-enabled SCM is, therefore, absolutely essential for mainframe transformation.
Automated release management. To keep pace with today’s fast-moving markets, you must be able to quickly get new code into production. That means automating and coordinating deployment of all related development artifacts across all targeted environments.
Cross-platform DevOps. Ultimately, you need to fully de-silo your enterprise environment so the mainframe becomes “just another platform”—albeit an especially scalable, reliable, high-performing, cost-efficient and secure one—that can be modified quickly as needed to meet the relentlessly evolving needs of the business.
‘What’s My Motivation?’
With as much as IT departments have on their plates, it’s easy to continue putting off mainframe DevOps integration. But, ultimately, there are only two alternatives to doing so:
Re-platform your mainframe applications. This alternative has proven to be a costly and extremely risky undertaking that delivers zero benefits while it consumes resources and potentially disrupts IT operations, or
Continue doing nothing. This alternative puts your company at further competitive disadvantage and hastens the day when you’ll experience total mainframe paralysis due to the loss by attrition of all your veteran mainframe developers, QA specialists and operations staff.
Viewed in this context, genuine investment in the mainframe—whether you call it modernization, mainstreaming or “Millennializing”—is the only reasonable course of action. Such investment starts improving your digital competitiveness immediately, while paving the way for a future where you can make the most of all your resources and confidently transfer platform responsibilities to your next generation of IT professionals. Including the mainframe in your broader DevOps efforts (while extremely valuable) does require commitment, and there are resources available to help. Just be wary of those who may talk a good game, but whose actions don’t really convey a strong commitment to users’ best interests. Fortunately, there are truly dedicated experts who can help every step of the way, and have direct experience modernizing on platform within their own organizations.
It’s the smart, viable long-term DevOps strategy every CIO of a mainframe-enabled enterprise needs to adopt ASAP.
About the Author / Christopher O’Malley
Christopher O’Malley is CEO of Compuware. He has nearly 30 years of IT experience with past positions including CEO of VelociData, CEO of Nimsoft, EVP of CA’s Cloud Products & Solutions and EVP/GM of CA’s Mainframe business unit, where he led the successful transformation of that division. Connect with him on LinkedIn and Twitter.
Christopher O’Malley is CEO of