devopsy.kinsta.cloud

Tag: bimodal IT

Let’s Bury Bimodal Thinking in Enterprise IT
We still hear a lot about mode-1 and mode-2 in enterprise IT. Like many other large enterprises, you might have adopted the terminology introduced by Gartner and use it every day to shape the way you deliver and operate technology. However, I have always been uncomfortable with the idea of bimodal, as it ignores architectural reality of tightly coupled systems that we have today and the cultural factors. There is also the cultural dimension that is emerging a lot in the transformations that I help clients with.

The cultural problem with Gartner’s bimodal IT view is that it relegates legacy systems such as mainframe (Z series) or I-series to mode 1 and discourages the new generation of professionals from working on these platforms. If you are in mode 2, you get access to the latest tools and training opportunities, and if you are not, then you are relegated to the end of the queue!

What do you think? Is bimodal creating two classes of people? Or am I being too harsh in my judgment?

In a recent article by BMW CIO Klaus Straub, he went on record and said bimodal IT doesn’t work due to cultural issues. As he said in the article, “Until September of last year, I also had a bimodal world in my head—but then the concept was incomprehensible to me. However, it is not suitable for permanently structuring an IT department.”

BMW is not alone. Other enterprises are joining the voices, such as Peter Jacobs, the CIO of ING Bank Netherlands, who also has expressed similar views on bi-modal. To quote Jacobs: “I would rather work agile at my core bank system than at the channels.”

The full interview of Straub is below. Unfortunately, the article is in Dutch, so you will need to translate the article to read it: https://www.cio.de/a/amp/bmw-cio-haelt-bimodal-it-fuer-einen-irrweg,3562374

A few other relevant and interesting articles are below:
1. https://www.cio.com/article/3193793/cio-role/in-the-digital-era-cios-not-buying-this-bimodal-crap.html
2. https://www.cio.com/article/3191810/it-industry/why-bi-modal-it-doesnt-really-work.html
— Aditya Vadaganadam
October 31, 2018
The Big Digital Transformation Trends Through 2017

For a number of years now, the enterprise has been well underway in their digital transformation efforts, as they use data analytics, mobile, cloud services, IoT and other technologies to transform their organizations. But while some companies have embraced digital transformation, others have lagged. They’ll be playing catch-up in 2017, while their counterparts will be busy improving and accelerating processes where they can and building upon what has been achieved.

Based on my interviews in recent months with CIOs, chief digital marketers and chief digital officers, here are a number of big trends in digital transformation that I see in the year ahead:

Some CIOs continue to struggle to shake role as IT plumbers

As enterprise digital transformation continues, even accelerates, those CIOs who focused on keeping the lights on through ensuring the infrastructure and services were in place to keep data available rather that on driving digital initiatives forward will continue to see their relevance diminish.

Those who will lead forward with increased relevance will be the CIOs who focus on new ways for their organization to better support the business with the technologies they need to succeed and partner with the business units, rather than just provide the technological infrastructure for them to do it themselves.

Business alignment with IT remains a challenge

If you are a reader of devopsy.kinsta.cloud, you know alignment between the business and DevOps is crucial for enterprise success. In other words, IT leadership must deliver the technology the business actually needs and wants. Seems obvious and straightforward. And it is. It’s just proven to be a not very easy thing to accomplish.

According to the Deloitte 2016 – 2017 Global CIO Survey, the “business expectations of IT and IT capabilities are out of sync in several areas, including customer focus, technology-enabled business growth, and business innovation. For example, even though 57 percent of the CIOs surveyed said that customers were their organization’s top business priority, less than half were involved in delivering customer experience (45 percent) or working on customer acquisition, retention and loyalty (44 percent).”

That’s interesting enough. But the survey results got even more dismal: “Even though 78 percent of CIOs said that strategic alignment of IT activities with business strategy was critical to their success, only 5 percent said it was a leading-class capability in their IT organization.”

CIOs that want to not only thrive but—at the very least—survive are going to need to close this alignment gap.

Bimodal IT gains more traction

The concept of bimodal IT is a controversial one. Essentially, bimodal IT is a descriptor from the research firm Gartner that remarks how IT organizations have a need for both agile delivery of technology services and traditional delivery modes. In the Gartner model, so-called Mode 2 teams are focused on DevOps and agile delivery methods, while Mode 1 teams focus on delivering the more established applications in traditional and more predictable ways. A brief explanation of these terms from Gartner is available here.

Also, according to Gartner, nearly 40 percent of CIOs are currently practicing bimodal, with the majority of CIOs saying they will embrace bimodal sometime in the next three years. This signals to me that the proof of bimodal success is coming in and more enterprises will continue to follow.

The trend toward Citizen Developers increases

More enterprises in the year ahead will embrace the so-called citizen developer to provide some of the apps enterprises need. According to the QuickBase State of Citizen Development Report, 75 percent of those enterprises surveyed said that they develop more than three-fourths of the app and leave the “last mile” to the citizen developer. And, not surprisingly, most (65 percent) are building apps to get work done, while 42 percent build apps to run the business and 27 percent build apps targeting customers.

“These citizen developers can go a long way to help clear the application backlog. Per the report, 29 percent have seen a 2X or more increase in application development speeds. Over three-quarters or 76 percent of respondents cited operational efficiencies as the primary reason for using the platform. And a whopping 62 percent of Citizen Developers responded that it takes less than two weeks for them to complete an application, on average,” QuickBase’s John Carione wrote in this blog.

With increased demand for more mobile and web-based apps, and the ease with which many of these apps can be started using low-code and even no-code platforms, I fully expect more enterprises to find ways to encourage citizen development within their organizations.

CMOs, others outside traditional IT, continue to drive more IT budget

This trend has been underway for some time now, and I fully expect it to not just continue but accelerate. As was discussed in Sarah White’s story, “As CMOs Start to Outspend CIOs, Collaboration Remains Key,” “marketing has a growing influence on technology spending, with CMOs slated to spend more than CIOs by the year 2017. In fact, companies reported that 25 percent of their annual budget was spent on digital marketing efforts in 2014; and out of those companies, 51 percent plan to increase digital marketing budgets in 2015.”

As that continues, that means marketing is going to have a larger say in what technology services and platforms get investment in the year ahead. CIOs in organizations where the chief marketing officer is getting more and more budget will need to partner to stay relevant.

Digital transformation accelerates

According to this 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.

For whatever reason, those in the c-suite are suffering from some form of cognitive disconnect when it comes to their digital transformation efforts. In the year ahead I think more c-level executives will see the reality of their digital transformation efforts and get to work on mobile and IoT and putting data analytics to better work.

— George V. Hulme

December 23, 2016
Overcoming Objection to DevOps Adoption

The advent of the application economy has made software arguably one the most critical and valuable assets of organizations across a broad spectrum of industries—financial, telecommunications, entertainment, and government, just to name a few. In the era of “app store ratings” and an unprecedented ability of the consumer to easily switch suppliers of whatever they’re consuming, delivering application feature updates as quickly and as safely as possible while maintaining high quality is absolutely critical.

Most of us with a pulse in the IT world are aware that the concepts and practices we know as “DevOps” and “continuous delivery” continue to dominate the software delivery conversation in IT organizations everywhere. Almost every business my company works with has some sort of continuous delivery or DevOps initiative in flight (with, naturally, varying degrees of maturity and success). And yet, we frequently encounter organizations where these ideas are anathema to many within, are considered overhyped buzzwords from consultants and vendors or, most frequently, simply do not apply to their organization in meaningful way. Others maintain that they have tried and failed so it’s back to business as usual. Many are swayed by a number of DevOps “myths” that often stop initiatives before they even get started. So, what is the objection over and some myths about DevOps that keep some organizations from taking the steps to improved software delivery? We’ll take a look at a few that we have seen firsthand and, in subsequent posts, suggest some ideas and strategies for getting past them.

Objection: “DevOps may work for some greenfield apps or startup but that’s not us.”

Many of our most reluctant customers acknowledge the benefits of DevOps and continuous delivery but maintain that their systems are too old, too monolithic, mainframe-dependent, etc., to reap any tangible benefits from a transformation. In other words, “it doesn’t apply here.” This point of view is especially frustrating because the benefits to organizations like these can be just as dramatic and transformative to the culture and IT “psyche” as found among the “unicorns.” Maybe even more so. As the 2015 “State of DevOps” study stated, “It doesn’t matter if your apps are greenfield, brownfield or legacy—as long as they are architected with testability and deployability in mind, high performance is achievable.”

Sometimes these groups will look to hybrid strategies such as bimodal where greenfield projects, innovation labs and other internal IT incubators are chartered to use new technologies and methodologies such as DevOps while the rest continue on as always. Opinions differ here, but these strategies generally are fine as a “way station” within an overall transformation road map with the potential to impede progress if accepted as the status quo. If legacy applications still change with some frequency and if deployments are painful for those involved, then those, too, should be included in the DevOps road map. We’ve done it at my company, a 40-year-old software company, and our mainframe team led the way.

Objection: “We are doing fine as we are.”

Another common category we encounter is the sense that, after some measure of improvement, perhaps the successful adoption of a toolset, that we’ve done enough. Things are better than before, our deployment pain has diminished so we have accomplished what we set out to do. A corollary to that is “we’ve implemented [Jenkins/Chef/Puppet/Cloud/etc.]” implying a belief that implementing one or more of these tools is, in effect, “doing” DevOps.

Successful DevOps is not about adopting a tool or even making measurable progress in organizational goals. DevOps is actually about embracing a culture of continuous improvement, collaboration and, perhaps most importantly, focusing first on maximizing value for your customers. It’s about adopting patterns such as the Deming cycle—Plan, Do, Study, Act—as a core tenet of the way you approach how you think about what you do. No matter what we do, no matter how well we do what we do, there’s always an opportunity to do better.

Objection: “Implementing a major change like continuous delivery is simply too large and complex an undertaking.”

When large, well-established organizations seek to undertake a major change, it’s often a task so daunting, so frequently met with skepticism and cynicism across the spectrum of stakeholders, that the initiative, no matter what it is, appears doomed from the start. Couple that with the culture-shift generally required to affect a successful and genuine DevOps transformation, and it’s no wonder that some senior IT leaders either severely limit the scope of these initiatives or, in some rare instances, veto DevOps outright. Regardless, the belief that their teams are too entrenched in current methodologies to make meaningful progress and the seemingly overwhelming weight organizational inertia stops change cold.

Transforming organizations that have functioned in, more or less, the same fashion for years, even decades in some cases, is practically incomprehensible for many. Organizational cultures generally evolve over time and changing them is not something that can be accomplished by decree and certainly not overnight. The barrier to even starting is often the sense that “we have too much work to do right now and balancing that against some intangible future state is not something we can take on.” Of course, the problem with that line of thought is that there will always be too much work to do now.

And, of course, there are many other obstacles. Barriers to entry against meaningful transformation like DevOps frequently emerge when new ideas and thinking collide with the status quo, especially pre-existing processes governing the software development and deployment. These processes generally emerged from the best practices of the recent past coupled with reactions to major problems encountered years ago that linger on as faint echoes of bygone errors. Most of these rules were put in place with good intentions, applicable at the time of implementation but may have outlived their relevance. Others may be regulatory and not optional. Regardless, if there ever was an area where DevOps and continuous delivery can deliver benefits, this is it.

Many large “traditional” IT shops have, indeed, transformed their culture and fostered environments that continuously improve. So, what do you do? Perhaps the most important step is to decide to take the first step. First, understand why you are seeking to change in the first place. What is the ultimate driver and does everyone, top to bottom, the organization have a clear understanding of that “why”?

Recognize that transformation is an ongoing process where successes and failures are to be expected in equal measure. Learn from both. Don’t attempt to roll DevOps out as a big bang strategy. Work incrementally.

In upcoming posts we’ll explore some strategies for moving past objection and making real strides toward meaningful and lasting change. What are some of the challenges you have faced in your company’s transformational journey? How did your teams get past the obstacles that inevitably appear?

— Jeff Bradley

December 9, 2016
Mainframe Apps and the Long View of DevOps Strategy
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.
November 21, 2016
Phoenix Rising: The DevOps Keys to Business Rebirth

In “The Phoenix Project,” a 2013 novel about an IT manager rescuing a late, over-budget IT initiative, Gene Kim demonstrates how collaboration between IT operations, development and business users can impact the business. In the era of digital transformation, the need to bring development and operations together—in what is often called DevOps—is more important than ever, as IT is now more than an enabler of the business. IT is the business.

What’s at stake today is more than just a project or someone’s position or even the viability of an in-house department versus outsourcing the function. Instead, it may be the very existence of the company. According to Gartner, 25 percent of companies will lose business due to digital incompetence by 2017 while IDC predicts that 75 percent of the S&P 500 will be replaced by 2027. To avoid the fate of becoming an industry has-been, today’s market leaders need to ensure they won’t be overtaken by more agile competitors that respond faster to a rapidly changing marketplace.

Automate Everything

Today’s businesses need to transform into digital enterprises to thrive in today’s digital economy, and this transformation needs to be far more profound than simply investing in the latest digital technology. Because the pace of the digital economy requires companies to roll out new services faster than ever before, businesses are challenged to move from idea to revenue as soon as possible. This need for speed leads to a desire—really a requirement—for agile applications.

For many of today’s enterprises, this means they have to stop thinking that a successful future depends solely on a traditional strategy of product innovation, using data analytics to better understand and serve their customers or building a higher quality, more profitable product portfolio. Instead, like the mythical phoenix, their survival may well depend on a complete rebirth around making the practices of agile application delivery and DevOps a core competency.

DevOps teams need the ability to efficiently develop, test and deploy new releases faster, with high quality and stability. Using automation technologies to design-in this speed, quality and scalability within the development life cycle is critical. The continuous integration and delivery processes at the core of DevOps and agile practices are enabled by many new automation tools and capabilities. Each of these tools typically targets discrete elements or steps in the entire process and DevOps teams use them as such, finding the right tool for the job. In addition to faster and higher-quality development throughput, building automation into the code of the application ensures better application services delivery in the production environment.

The good news is that 60 percent to 70 percent of these enterprise application services or jobs within most organizations are micro-batch, batch or event-driven—and can be managed with a comprehensive job scheduling solution. By automating jobs as part of the application code and subjecting the job artifact to all the other automation processes, companies can substantially reduce time and effort during and after the application delivery process.

According to Enterprise Management Associates, companies with workload automation reduce application outage time by about 70 hours annually, raise service level agreement standards, free 41 percent more IT staff for strategic projects, and defer or eliminate an average of 50 percent of IT staffing requirements.

Traditional vs. Innovative IT

Too many companies intent on being agile and innovative believe that a successful DevOps organization must be free of the trappings of rigorous change management. Business innovation and increased employee productivity, however, can’t exist without a stable IT foundation. The goal is to have a balance of both strategies in an organization. Gartner refers to this as Bimodal IT, which has two modes: “Mode 1 is a traditional, plan-driven approach that emphasizes safety and accuracy in the pursuit of reliability. Mode 2 is iterative, being largely outcome-focused and emphasizing agility and ‘just enough’ with respect to areas such as planning and process.”

By committing to balancing the two strategies, organizations can increase agility without sacrificing stability. More importantly, companies can increase employee satisfaction by different teams successfully doing the jobs they are paid to do, whether it’s to drive innovation or keep the lights on. It’s worth noting that Gartner believes many elements in DevOps apply to both modes and that by 2020, at least 80 percent of practices identified today with DevOps and Mode 2 will be adopted by traditional Mode 1 groups.

While thinking of your company as a phoenix may be essential for survival, the benefits go way beyond that. Just like the revitalized bird, your company can once again be youthful and vibrant, capable of soaring to new heights. This is a strategic goal worth investing in.

About the Author / Gur Steif

Gur Steif is the president of the Workload Automation product line for BMC Software. Under Steif’s leadership, the Workload Automation business has more than doubled in size. Previously, Steif was the general manager and vice president for both the Workload Automation product line and the Performance & Availability business line. During this time, he grew the Workload Automation business at triple the market growth rate while also delivering a double-digit increase in customer satisfaction for Performance & Availability. In his 25-year career in technology, Steif has held leadership roles in strategy, product management, R&D, sales, marketing and M&A in IT operations management, application management and workload automation. Connect with him on LinkedIn/Twitter.

October 3, 2016
Mainframes and the Myth of Bimodal in DevOps
Rewind 20 years ago when we lived in a business world where big companies with unlimited resources beat out smaller, more strapped companies. The digital era—also known as the “age of the customer”—is changing all that. Where big once beat small, fast now beats slow. The DevOps approaches of startups often make them more adept at continuously delivering the innovations and conveniences that earn customer raves. Bigger, established companies often feel disadvantaged‚ shackled by an outdated culture and inflexible processes that haven’t kept up with the pace of change.

Gartner coined the term “bimodal IT” as a way for older IT establishments to keep pace with agile startups. In the bimodal model, IT teams are separated into two distinct styles of work—one focused on supporting predictable, well-understood workloads with legacy systems and another that is more fast-moving, experimental and adaptable in meeting users’ constantly evolving demands and flourishing digital expectations.

But the bimodal concept is not well-aligned to the spirit of innovation underlying modern application development and delivery. This is especially true for bigger organizations using mainframes. Here’s why.

Successful DevOps Depends on Mainframe Agility

The goal of DevOps is to roll out high-performing software and updates, ahead of the competition and with maximum speed, ease and cost-efficiency. In a DevOps model, software delivery can only happen as quickly as the slowest team. Modern web and mobile applications tend to span multiple platforms in their end-to-end transaction—from front-end web servers (systems of engagement) all the way back to mainframes (systems of record). IT places a lot of emphasis on systems of engagement, often taking back-end systems of record for granted. The reality is, the value in systems of engagement cannot be realized without the systems of record—making it essentially all one system. Developers supporting modern applications must be able to maneuver across and between all platforms, especially within mainframe code and data.

Let’s look at a tactical example of this. According to industry research, 80 percent of the world’s corporate data—including customer data—continues to reside on mainframes. When a mobile web application is used to make a bank deposit, or purchase a product, for example, the transactional component of those applications typically is executed on back-end mainframes.

This means mainframe applications are crucial to development efforts. What happens when mainframe developers and testers are locked into waterfall processes or don’t have the modern tools necessary to understand application logic or access mainframe data for testing? Frustration mounts and the overall innovative effort is unnecessarily stalled.

Stability and Agility are not Mutually Exclusive

The longstanding myth that stability and agile cannot co-exist is simply untrue. Unfortunately, it’s at the core of negative perceptions surrounding the mainframe today—people think the mainframe environment is too slow and cumbersome to support agile development. Development teams may think if they have mainframes, the only approach it can support is waterfall.

The reality is, though, no customer will accept poor availability and performance in exchange for new features delivered quickly. People with hands-on experience painfully understand that slow, waterfall delivery methods produce far greater quality issues and missed expectations, resulting in competitive risk. Additionally, large enterprises taking the “slow and stable” route give startups a head start in beating them to market, with offerings that customers want now.

Alternatively, Agile process and DevOps tool chains enable scrum teams to test quality in terms of usability, function and stability early and often in the development cycle—when the time to remediate is the fastest and the cost the lowest. Agile process and DevOps tool chains build higher quality applications and enable continuous improvement in quality over time.

Re-Platforming is not Necessarily the Answer

Some DevOps proponents believe moving off the mainframe—to a supposedly more modern, commodity server-based distributed architecture—is the best way to circumvent perceived challenges to nimbleness and agility. But this is almost never the best answer. The mainframe retains its distinction as being the most powerful computing platform on the planet. It remains deeply embedded in large organizations, setting the standard for reliability, security and availability for mission-critical data and transactions. The new IBM z13 mainframe, for example, can handle the load of 100 Cyber Mondays every day, 365 days a year. Currently, mainframes process 30 billion business transactions per day. The post-modern mainframe is an engineering marvel unequaled as a system-of-record, business compute platform.

The mainframe also offers cost advantages. Studies have shown that the mainframe is more cost-effective than commodity servers in handling the massive computing volume increases instigated by mobile applications. This is because decreases in commodity server pricing have not kept pace with the increase in computing volumes. In addition, leading vendors have worked together to deliver intelligent cost management on the mainframe, enabling workloads to be distributed in a way that keeps mainframe licensing costs (MLCs) down.

In our view, “biomodal” advocates for the exact problem that must be solved. We think the answer is not replacing the mainframe, although if mainframe development is left unaddressed, this can present obstacles to DevOps. Rather, the answer is to evolve the mainframe to keep up with the pace of DevOps. There are mounting examples from large, high-performing organizations that it is possible to apply modern practices to the fullest extent, including mainframe applications. These organizations do this by giving developers the tools they need to work on mainframe code and data just as they would with any other programming language on any other platform, while meeting the escalating quality expectations of the digital age. For example:
- Mainstreaming the Mainframe Environment – Mainframe users need to move away from the antiquated “green screen” mainframe environment, adopting state-of-the-art interfaces and tools. This is the first step enabling developers to work more fluidly on the mainframe, in an environment that’s much more familiar and comfortable to them. Organizations that fail in this adoption will have a very difficult time enabling the next generation of development talent to leverage invaluable and irreplaceable mainframe code and data. This will place a huge hindrance on DevOps success.
- Leveraging Tools from the Java Development World – One example is visualization capabilities, which enable developers to quickly and easily identify critical interrelationships between apps and data. This helps them to sidestep unintended, undesirable impacts as they modify applications, increasing confidence and mitigating unnecessary delays.
- Make it Easier to Identify Mainframe Code-Level Issues – Developers need tools that enable them to identify problems with mainframe code; for example, when it is the source of a widespread user performance issue, or when it is consuming too many resources and driving up costs unnecessarily.
Conclusion

In our view, “bimodal” is not the solution, but a broken state of disadvantaged affairs for too many organizations. From a competitive vantage point, bimodal will only hurt DevOps teams and hold back the innovative efforts of the organizations they support.

The bimodal IT model is a road to inevitable failure for those enterprises seeking success in the digital economy. This is especially true for organizations that rely on mainframes. A smartly leveraged mainframe is an extremely valuable competitive asset that needs to be removed from its silo, evolved and smoothly integrated into modern, heterogeneous development environments.

It is possible for big, established companies to adopt DevOps, become agile, and move as fast as startups. But the ability to think and act like a startup requires some major fundamental changes, particularly at the level of software development. The good news is, the legacy technologies that are often perceived as impediments can actually be a tremendous competitive advantage, if they are harnessed and evolved in the right manner.

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.
September 23, 2016