devopsy.kinsta.cloud

Tag: mainframe

Convert COBOL Easily? Yes, Please!

I was reading Mike Vizard’s article about IBM previewing an AI tool to convert COBOL to Java and mentally cheered this move. No, seriously—massively cheered this move.

There are a lot of uses of large language models (LLM) right now, and many of them are not all that exciting, in my opinion. This one, though? This is huge. In the course of my career, I have been involved in three projects to convert COBOL and one to convert FORTRAN, with some projects that required interfacing with RPG III systems. In all of these cases, the costs were prohibitive. Two of the three COBOL projects never made it past estimates because the cost of resources who know both COBOL and Java were prohibitive, as is the complexity of most mainframe applications as they were modified over the years. The Fortran project never got past resourcing, and the RPG III interfaces were just that. We had to pull the data as it was presented by RPG III systems and only act on our copy, with a separate process used to update the core systems. Why? Because modifying the RPG was impractical, but we could be agile. It was … painful, to put it mildly.

What all of these projects shared was the lack of a skilled workforce. And what IBM is offering is an LLM that acts as that workforce. If you get the application into Java, there is a large pool of developers that can then troubleshoot it. While the environment issues will still exist and people skilled in tools like JCL are increasingly hard to find, that part can be rebuilt in the new environment. (One question I have about IBM’s project is, “Can it convert to Java for a Linux LPAR/VM?” I suspect that this iteration converts within z/OS, but it would be cool to see increased options in the future.)

Honestly, this trend will only increase. While IBM’s use of LLM is aimed at moving COBOL to Java, there are an incredible number of lines of Java out there to train on, so soon enough, there will be other conversions in and out of Java. And that’s all good news. We recreate the wheel a lot. The longer-term implication of AI-assisted conversion is that we won’t have to. Think about it: We could feed in a mathematical routine in Fortran and get the language of our choice out the other side.

Way back in the day, a collection of compilers named TopSpeed let you develop in any of several languages, even mixing and matching to create applications that used each language (and developer) for their strengths. This is the TopSpeed dream writ large. (Disclaimer: I was a huge TopSpeed fan. Bought their intro kit and wrote systems mixing C/Pascal/ASM without having to mess with things like parameter sequences. Yeah, I was cool.)

We have had too few developers for a very long time. Now, we are about to have a world where developers can focus on truly unique functionality, and the rest is generated based on the mass of implementations we already have. Think in terms of sorting algorithms—99% of the sorting problems out there were mastered decades ago, and yet we frequently see people re-implementing, even today. Now we can tell a system, “Generate a tree sort,” and just make calls. Every time we implement a new language, this type of thing has to be re-implemented, and often it is re-implemented because we don’t know about the available solutions. In the future, we will have solutions at our fingertips.

And as with the other benefits of automation, we’ll do less busy work and add more business value. While there will be some pain, I think in the long term that is a huge benefit. And you’ll still be there, making things go zoom.

August 30, 2023
IBM LLM AI: COBOL to Java ASAP ¦ ARM IPO is GO!

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: Translating legacy COBOL code to a slightly more modern language, and Arm will go public (again) next month. (more…)

August 23, 2023
Improving DevX Gives Your Business a Boost
As organizations transform and grow, different methodologies and development tools can come together, creating an extra level of complexity for your mainframe application development teams. In a perfect world, developers would be able to focus on delivering solutions without worrying about all the infrastructure necessary to make that happen. Building a better developer experience, or DevX, can make that a reality.

DevX is about meeting developers where they are, at every stage of their career, delivering compatibility with and connectivity to the tools and devices that they want to use so they can focus on what they do best: Coding and releasing high-quality mainframe applications faster and more frequently and fostering better productivity and more innovation.

Automation is integral to removing friction for developers. A modern integrated development environment (IDE) with built-in automation allows developers to find and manage code more efficiently and with greater quality and move quickly and easily from coding to editing to debugging to testing.

Modern tooling can simplify and accelerate how developers work by giving them a visual representation of their code layout in a single-pane-of-glass view. They can move quickly in a natural, easy way with more information at their fingertips while built-in automation offers assistance at the right moment without getting in the way.

This can seem difficult when dealing with mainframe application development and longtime mainframe developers who are still working with tools from the 1980s haven’t directly benefitted from the intervening decades of improvements. What they might not realize is that the improvements made for other platforms are available to mainframe developers, too. By engaging them in your DevX modernization efforts, you can improve their experience—and that of their team members.

Elements of a Productive Mainframe Developer Experience
- A modern DevX adopts flexible agile processes that give developers predictable capabilities and enable smaller, iterative changes with faster feedback. It also syncs distributed and mainframe development teams to foster greater collaboration for additional process improvements.
- A better DevX is platform-agnostic, creating a development environment where developers can focus on the functionality of the applications they’re building instead of the deployment mechanism, leveling the playing field for every generation of developer.
- With an improved DevX, developers can achieve the full potential of DevOps. Implementing DevOps for source code management (SCM) functions allows developers to understand the scope of any changes needed before they start coding, which helps speed approvals through concurrent work streams.
- The single biggest boost to productivity—and an integral component of DevX—is shift left automated testing that enables developers at all skill levels to test new code immediately and find and fix bugs earlier in the development cycle when they’re easier to fix—and before they reach the end user. Continuous testing also automatically prepares test data within the DevOps toolchain.
- An improved DevX delivers operational insights, so developers aren’t just catching issues but also understanding and prioritizing them, working hand in hand with the operations team to make the overall system better. It also empowers newer developers to address and correct any issues that arise in legacy code without poring over hundreds of modules to find what they need to improve. DevX tools work together to give developers an opportunity to leverage operational data in a whole new way.
Once you have the tools, your mainframe developers need to be supported by a culture and education that teaches them how to use them and understand the benefits they offer. If you implement new tooling that nobody will use, the transformation is for naught. It’s important to start with the user experience and find the right tools to address it rather than starting with a tool and forcing its use just because it’s new. Continuous improvement is an important part of this; otherwise, you could bring the mainframe developer experience from the 1980s up to today’s standards only to have it freeze in place. This is why metrics and analytics are so important.

As you speed up delivery, you also want to make sure the quality improves. With an improved DevX, you’re consistently finding defects earlier in the life cycle, which results in safer, more efficient delivery of better-quality code. By tracking velocity with metrics such as user stories delivered in one sprint, you can gauge how those changes are making a difference. You can also demonstrate how automation helps eliminate human error, increases code drops, and improves business agility.

If you’re giving your mainframe developers everything they need to do their jobs easily and more efficiently, they’re exponentially more likely to adopt the tool and advocate for it—because a better DevX improves the day-to-day employee experience for longstanding and next-generation developers. By removing the drudgery of tasks that take developers away from writing code, you’re unleashing their creative and enabling them to achieve even greater levels of innovation—and you’re also improving your hiring and retention practices.

Improving the mainframe DevX pays dividends across your business, from your developers to your customers to your stakeholders, so you can bring more new features to market faster and enable a competitive response for revenue-generating solutions. The mainframe is here to stay. Make sure you’re building a modern development environment that empowers your developers to respond nimbly in the face of change and make change your advantage.
May 22, 2023
Six Mainframe DevOps Predictions for 2023

DevOps, or the automation of application development and hand-off to operations, is more prevalent than ever on the mainframe. As we begin 2023, below are six predictions for what the coming year will bring. The composite themes will undoubtedly be speed, alignment and experience.

1. Enterprise DevOps Will Break Down Silos Across Core Systems

DevOps practices will continue to expand beyond cloud and distributed systems to include more core systems than ever before. Core platforms, including the mainframe, are the functional backbone of mission-critical applications that drive the world economy. In a recent IDC survey, 82% of organizations reported taking steps to prioritize using the same application development tools across distributed and mainframe teams. 2023 will continue to see a rise in enterprise DevOps that will bring down the silos between platforms. As core system workloads increase, organizations will see the benefit of aligning platforms such as mainframe and distributed to realize the full benefit of their DevOps initiatives.

2. Growth in AI/ML as Key Components for Measuring DevOps Performance Metrics

The value of analytics will increase as organizations emphasize the use of key performance indicator (KPI) data to measure the performance and maturity of DevOps pipelines. In this way, organizations will not only gain more insights into their pipelines, but will also be able to proactively manage the data in real-time. They will be able to adjust loads as needed and create smart pipelines with advanced error handling. Organizations will leverage benchmarks within the analytics to see how they compare with their peers.

3. Cross-Functional Pipelines Will Create Hybrid Automated Everything

This will enable the cloud, core systems and data to deliver a more holistic view of “platforms, processes and people.” Silos will finally disappear. Automation will become a key priority in this effort as organizations seek to free up time for developers to innovate and achieve greater velocity, quality and efficiency. A single integrated and connected pipeline will emerge that automates the creation and testing of applications in a single flow. The rationale of prioritizing this alignment between distributed and core systems includes the reuse of best practices, workflow simplification, cost-effectiveness, application integration and streamlined training.

4. DevOps Will Embrace Platform Engineering and Site Reliability Engineering (SRE)

Platform engineering is the next evolution of DevOps, taking a DevOps platform and turning it into a self-service product to improve the developer experience. It treats DevOps as a product and allows organizations to create an end-to-end offering that serves developers, operations and platform teams. SRE focuses on the “Ops” side of DevOps, specifically how to automate operations capabilities. This is vital to the DevOps mission since it provides the data that allows organizations to manage what they can measure.

5. DevSecOps Will Play an Increasingly Central Role

Security must become a central part of the toolchain and a “first-class citizen” in the pipeline. Static application security testing (SAST), also known as white box testing, along with dynamic application security testing (DAST), also known as black box testing, will be further integrated into processes to enable security teams to scan large loads at rest or in real-time quickly and efficiently.

6. Git-Centric Enterprise Source Code Management (SCM) Strategy Will Grow

Git has become the de facto standard for SCM for distributed application workloads. In a recent IDC survey of industry professionals across 11 countries and multiple industries, 87% said they will migrate all or some of their mainframe source code to Git over the next three years. This means Git and Git-native development will become important capabilities for mainframe DevOps companies to support. Organizations will increasingly prefer implementation approaches and tools that offer flexibility in both scope and pace.

The techniques highlighted in these predictions are, naturally, related. They point to an ever-increasing capacity for efficiency and quality that will enable core and distributed technologies to work better together.

February 24, 2023
FAA Ground Stop due to Technical Debt? | Don’t Do DIY Crypto!

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: The FAA’s NOTAM database gets corrupted, and Threema shows why DIY cryptography is bad. (more…)

January 12, 2023
Saying Goodbye to Legacy Systems
Are you still using a rotary phone, tube television or Rolodex? Probably not. But if you were, you’d still be using newer technology than what many enterprises still rely on every day to drive mission-critical applications that we use every day when shopping, banking or hundreds of other normal tasks.

At least two-thirds of large enterprises are running mainframe-based apps that date back 10 to 20 years and more than 25% of businesses feature applications that are between 20 or 30 years old. Today, businesses are often running and maintaining legacy applications built on traditional databases while simultaneously building microservices-based apps to accelerate new services and innovations. The mantra “If it ain’t broke, don’t fix it” certainly applies here; and while there are many reasons organizations continue to rely on mainframes and legacy systems, there are also many organizations that want to begin modernization initiatives but don’t know where to start.

However, the past few years saw a wave of new digital-first companies in all industries putting pressure on legacy systems-based businesses—from retail to finance to manufacturing to technology. The COVID-19 pandemic accelerated many organizations’ modernization plans and made clear that for those that wanted or needed to modernize to stay competitive, avoiding the problem just wasn’t an option. Companies found that if they weren’t proactive about modernizing, the cost of being reactive when they needed to update and evolve was exorbitant.

Accelerating IT modernization initiatives can be a major challenge: Safely modernizing those legacy apps and mainframe systems and the critical data in them can seem impossible, but it can be done. Companies like Kroger, for example, have already made that jump and there’s a lot to learn from them. Here are three things that can help any enterprise on their journey to say goodbye to mainframes and legacy systems:

You Need a Frictionless Path for Legacy Apps

Many modern solutions are only focused on greenfield applications and helping newer born-in-the-cloud companies and projects; however, the reality is most Fortune 1000 companies have a lot of existing applications they can’t afford to ignore or completely rebuild all at once. Supporting existing applications with standard interfaces like Postgres while delivering the scalability and resiliency to support modern applications is critical to providing a bridge from where companies have been to where they are trying to go. Distributed SQL databases provide a seamless path forward to modernize existing apps while supporting new and current initiatives.

Embrace Automation

It’s time to stop relying on complex code or fragile systems with bolted-on third-party tools. Being able to rely on intelligence and automation in the data layer for distribution, resiliency and availability is critical to minimizing changes and impacts on current applications. Doing so will reduce risk, offload legacy app tasks and ensure systems have the intelligence to work properly. With a distributed SQL database, you can deliver a single logical database that appears to applications like a monolithic, single-server database but with the underlying intelligence to allow it to stretch across hybrid, private and public clouds.

Finding Flexibility and Becoming Future-Proof

To avoid being tied to specific systems or architectures, it’s time to adopt a future-proof mindset. Businesses can achieve this through:
- Multi-cloud/hybrid cloud: With a distributed SQL database, you can deliver a single logical database that looks like a monolithic, single-server database but with the intelligence to stretch across hybrid, private and public clouds—providing the flexibility to be deployed wherever the application is needed or is best served.
- Any hardware: No two data centers look alike and there are a wide variety of hardware needs, from bare metal to VMs and containers. The right modern distributed database provides ultimate flexibility in where the data layer can be installed to match whatever hardware and configurations are already in use.
- Any deployment: Existing organizations have a wide variety of environments and deployment types, from single data centers to two or more private data centers to more and more hybrid environments that span on-premises and public clouds. A modern distributed database provides the freedom to support a wide range of deployment options, including synchronous replication, geo-partitioning and cross-cluster asynchronous replication.
- Open source freedom: While many databases provide some open source components, there are still a few 100% open source solutions committed to the Apache 2.0 license. Users can benefit from the full set of enterprise features and capabilities in these open source solutions as well as benefit from the security and transparency that comes with a 100%-open source solution.
It’s time to update the old adage, “If it ain’t broke, don’t fix it” to “If it ain’t fixed, it could be broke,” with regard to modernizing legacy systems. If you’re considering starting a modernization journey, save time, resources and money now to make upgrades that might later be costly, time-consuming and overwhelming for your internal teams.
June 6, 2022
Git for Mainframe: Back to the Future
Software delivery modernization should be done with care, especially with mission-critical mainframe apps. But for some, modernization will feel like a trip back to the future.

Mainframe applications are typically systems of record with high-value transactions, significant compliance risk and an essential need for stability and security. They’ve been running reliably, often for decades, with code changes made by teams of dedicated developers using time-tested interfaces like ISPF (green screens) and Eclipse integrated with mainframe-based source management tools—Endevor is the most widely used example.

So Why Modernize?

Three primary drivers of change are present:
- Business Agility: Digital disruption is generating an increased volume and velocity of business demands often resulting in cross-platform application architectures. It’s increasingly common to have cloud/mobile customer-facing apps calling back-end mainframe services for seamless experiences.
- Staffing: A talent crunch resulting from career mainframers retiring while traditional mainframe practices and tools lack appeal for the next generation. Backfilling is a challenge as next-gens would rather be using popular, cloud-native tools that offer broader career potential.
- Performance: DevOps adoption has raised the bar in terms of productivity, delivery velocity, quality, lead times, etc. The opportunity to achieve comparable performance levels with mainframe development is entirely possible but requires modernization.
The confluence of these drivers leads to an obvious conclusion—the time for modernizing mainframe application development is now. Version control is the foundation of software development, acting as the focal point with IDEs/code editors, Agile tools, DevOps automation tools (like code scanners and CI/CD orchestrators) and service management tools. This article focuses specifically on the adoption of Git as a critical enabler of modernization.

The Role of Git

The next generation of talent, typically millenials and Gen Zs, know and love Git. With 94% of professional developers viewing Git as a fundamental development tool per Stack Overflow, it has become the de facto standard for enterprise IT, eclipsing all alternatives. Built initially for open source development of Linux, it offers a decentralized model where devs can work independently in branches yet collaborate closely through pull requests, issue management, etc.

It has become so dominant that popular editors like VS Code have built-in Git capabilities. With the introduction of the free Code4z extension pack by Broadcom, VS Code and compatible tools (e.g., cloud-hosted GitHub Codespaces) are now viable options for mainframe developers, making Git adoption a natural, ‘parallel’ modernization opportunity. The Developer Cockpit Simulator illustrates the Git-ready experience using VS Code for mainframe application development.

Back to the Future

Beyond version control, leading Git platforms like GitHub and GitLab have expanded to become comprehensive DevOps platforms (e.g., GitHub Issues, Actions, Codespaces, Projects, etc.). Yet the precedent for this evolution was set decades ago when Endevor was envisioned as an environment for development and operations with SCM at its core. Yes, DevOps before ‘DevOps’ ever existed. For many mainframers, seeing the Git version control tools evolve into comprehensive platforms comes with a distinct feeling of déja vu.

With automation that has stood the test of time, Endevor delivers code changes reliably and, with workflows optimized for the platform, does so very efficiently and securely. And while Endevor is continuously updated with new DevOps capabilities—including the recently introduced Dynamic Environments to facilitate developer self-service—there is no denying that Git is valuable from an enterprise perspective. In addition to attracting next-gens and facilitating onboarding, a Git experience empowers any developer, if authorized, to easily update mainframe apps. All they need is a few mainframe basics and experience with the relevant languages (e.g., COBOL, PL/I).

Back when the mainframe was the sole enterprise platform, a single, common experience was the norm, but IT evolved along many dimensions resulting in a sometimes disparate and siloed environment. Today, however, most developers are comfortable using multiple languages in a hybrid environment, so normalizing around a modern developer experience makes sense and brings things full circle.

Git-Native Approach

One option to take advantage of Git is to move source code to a Git enterprise server, but the inherent costs and risks associated with this approach should be carefully considered. Career mainframers are some of the most productive developers around and moving to a new paradigm will naturally be disruptive. In addition to changing workflows, this approach reestablishes build and deployment automation that has been working reliably for decades, which is both time-consuming and risky. Mainframe applications are often monolithic and complex with career mainframers’ expertise often filling gaps in documentation, so preserving this institutional knowledge should be a priority.

Career mainframers can, of course, learn Git, but training takes time. And as many are nearing the end of their careers, will they be motivated to embrace the change? Repo migration may have the unintended consequence of accelerating the retirement of a critical knowledge base. As Deloitte forewarns in their Modernization and the Aging Workforce paper, “Don’t underestimate the value of legacy coders.”

There are also costs associated with the migration—testing, documentation, training, project management—so the opportunity cost of porting code rather than investing in other high-priority business initiatives further qualifies this option.

With these factors taken into consideration, migration should start with applications that are both stable (e.g., infrequent change requests) and pose a low risk to the business (e.g., lower dependence on career mainframers).

A Git-native approach would require a specific tool such as Team Build, for example; a lightweight processor-based build engine that enables teams to collaborate natively using enterprise Git repositories while building on the z/OS platform. It is independent of Endevor and can be used for any build-and-ship needs for z/OS. It converts build logic in JCL and makes it maintainable off-platform with JavaScript.

Hybrid Git Experience

This ‘risk-managed’ option offers the benefits of Git—easier recruiting and onboarding, increased collaboration, etc.—while eliminating many of the costs and risks outlined above. With it, career mainframers continue working as they always have with existing tools and practices, without disruption, while next-gens use the tool they prefer, Git.

Endevor Bridge for Git enables the Git experience with Endevor continuing to serve as the main repository. It accomplishes this by synchronizing a ‘source control mirror’ on the Git enterprise server. With this option, those who prefer to use Git can do so while colleagues using native Endevor can work on the same codebase at the same time. They can use Eclipse, VS Code or VS Code-compatible cloud-based IDEs, which offer the added benefit of working in Git without a local copy of the code.

And with enablers like the Zowe CLI, modernizing-in-place offers the best of both worlds: Mainframe and off-platform tooling. For example, run Jenkins CI/CD pipelines for code scanning, testing and other functions off-host following a code change while allowing developers to continue to use the ISPF interface. To summarize, this option offers the advantages of the Git-native model without repo migration.

Recommendations

Due to the nature of mainframe applications, risk management is usually paramount so a thoughtful, pragmatic approach to the adoption of Git is recommended. Provide those career mainframers that are open to adoption with the time they need to embrace the technology by introducing Bridge for Git, for example. As organizations become more comfortable with the hybrid model and are satisfied they have enough Git-based developers with institutional knowledge of their codebase, they can identify apps to port to their Git enterprise servers.

At the other end of the spectrum, for companies with a Git-only imperative, one option is migrating an initial set of applications quickly using, for example, Team Build. However, a cold cut-over at the portfolio level could be excessively disruptive and it’s not recommended. Accelerated retirements and/or increased retention costs are a real risk, so a phased approach over time is the best approach. The key to success with Git adoption is recognizing it is a journey for the organization that requires a well-thought-out plan.

For a third-party perspective on the adoption of Git for mainframe apps, IDC has published an Infobrief, Git for Mainframe: Considerations for Enterprises, highlighting the opportunities and the challenges.

There are many paths to modernization, so take advantage of others who have blazed the trail. But whatever the approach to Git adoption, younger team members should be prepared for a “We were doing that way back when” story or two.
May 4, 2022
BMC Integrates DevOps Mainframe Portfolio With Git

BMC has expanded its efforts to bring DevOps best practices to the development of mainframe applications by integrating the BMC Compuware ISPW continuous integration/continuous delivery (CI/CD) platform with Git repositories.

In addition, the company tightened integration between BMC Compuware ISPW and BMC AMI Ops platform and integrated BMC Compuware Topaz Workbench for building applications with code scanning tools from Vercacode.

Finally, there is also now a BMC Enterprise Connector for Illumio that provides a bi-directional interface between the zero-trust segmentation platform from Illumio and the mainframe. In addition, the BMC AMI Command Center for Security system can now also surface malicious performance activity to accelerate incident response.

John McKenny, senior vice president and general manager for intelligent Z optimization and transformation at BMC, said the overall goal is to make the mainframe just another platform where IT teams can apply DevOps best practices to build applications faster. That’s more critical than ever because mainframes are often at the core of digital business transformation initiatives and require integration with a wide range of distributed computing platforms. A recent survey published by BMC found two-thirds of respondents (66%) are investing in new technologies such as AIOps and artificial intelligence/machine learning (AI/ML), DevOps and integrations.

That approach enables organizations to leverage existing mainframes in a way that minimizes technical debt rather than duplicating functionality, added McKenny.

When it comes to DevOps in mainframe environments, the biggest challenge these days has more to do with culture than the maturity of the tools being provided, he said. Many of the IT teams building mainframe applications still rely on waterfall processes mainly because of simple inertia and a general fear of change, McKenny noted.

There is, however, a new generation of IT professionals that have embraced modern development practices across all platforms to accelerate the rate at which applications are built and deployed, said McKenny. That shift is leading to the wider adoption of DevOps best practices within both mainframe and distributed computing environments, he added. In fact, as a result, enterprise IT has never been more hybrid, he noted.

IBM continues to invest in mainframes, so the platform should remain relevant well through this decade and into the next. Though it’s been nearly 60 years since the venerable platform was introduced, it continues to host mission-critical applications for a broad range of enterprise IT organizations. Most recently, IBM added an IBM z16 edition of the mainframe that adds a dedicated on-chip AI accelerator in addition to quantum-safe cryptography. It’s not clear how quickly organizations that have mainframes will upgrade, but that level of investment suggests IBM is still investing heavily in mainframe research and development.

Regardless of how—or even who—builds applications for the mainframe, tools such as Git repositories will be more widely used if for no other reason than to more easily share code. Now, the issue is improving the overall level of DevOps maturity within mainframe environments to keep up with the rapid pace at which applications are being built and updated across the rest of the enterprise.

April 29, 2022
IBM ‘is Ageist and Sexist’ | IBM Mainframe-aaS | IBM Vaccine Mandate

Think! Welcome to Big Blue Week here at The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: IBM’s employment practices scrutinized, IBM z/OSaaS breaks cover, and IBM encourages staff back to the office.

1. ‘Dinobabies’ and ‘Dated Maternal’ Workforce Woes

First up this week: IBM’s defense in an employment age discrimination lawsuit looks to be shredded. Internal emails “appear to show high-level discussion about paring the ranks of older employees.”

Analysis: Not a good look

According to one of the plaintiff’s lawyers, unnamed “top IBM executives were explicitly plotting with one another to oust older workers … to make room for millennial employees.” On the face of it, they seemed to be doing the polar opposite of the Age Discrimination in Employment Act.

Noam Scheiber: Making ‘Dinobabies’ Extinct: IBM’s Push for a Younger Work Force

Top IBM executives were directly involved in discussions about the need to reduce the portion of older employees … sometimes disparaging them with terms of art like “dinobabies.” … Documents made public by a Federal District Court … show executives discussing plans to phase out older employees.
…
The newly unsealed documents, which quote from internal company emails … show top IBM executives specifically emphasizing the need to thin the ranks of older workers and hire more younger ones. [One] email refers to IBM’s “dated maternal workforce,” an apparent allusion to older women, and says: “This is what must change. They really don’t understand social or engagement.”
…
Adam Pratt, an IBM spokesman, [claimed,] “IBM never engaged in systemic age discrimination.” [He] said that some of the language in the emails “is not consistent with the respect IBM has for its employees” and “does not reflect company practices or policies.”

Yikes, ageism and sexism? Experienced staff are valuable, says MrBanana:

I did some time at IBM [and] remember being invited to a meeting with a new group, headed by a new “thinker,” who had something to present to myself and a colleague. We walked past the foosball table to the meeting room. Naturally the room had no chairs, and was covered in multi-coloured Post-it Notes. Once they had gone through their mood boards and the non-linear presentation of this new idea, I turned to the other old geezer in the room. “Didn’t we look at something like this 8 years ago?”

“Yeah, we worked out that compute power just to run the UI for one session wouldn’t be available for a couple of decades.” The children were somewhat disappointed, and (fortunately) we were never asked back to their romper room.

But experience can be both a blessing and a curse, learned aahortwwy:

I experienced both sides of this in five years at a company in hypergrowth. … I learned so much at that job: … In year 1, I was determined to accomplish X and ignored the skeptical comments of some colleagues who’d been at the company longer than me. I failed and wasted some time. In years 4 and 5, new colleagues were determined to accomplish X and ignored my skeptical comments.

2. IBM Wazi as-a-Service Confusion

“Mainframe” is not a dirty word. It’s secure, vertically scalable, and it put the VM in VMware. Now, what IBM Wazi did for on-prem LPARs, Wazi aaS promises to extend to hosting z/OS instances.

Analysis: Mainframe-as-a-service reinvented

Mainframes and cloud-native DevOps need not be incompatible. To modernize legacy apps using hybrid cloud instances for dev/test—and even prod—can be a big productivity boost. But isn’t it weird that IBM spun out its mainframe-as-a-service zCloud offering only a few months ago?

Mike Vizard: IBM Shifts Mainframe App Testing to the Cloud

While many workloads over the years have been migrated off mainframes or simply retired, the applications that run on z/OS today are still among the most mission-critical that organizations run. … IBM this week revealed it has added the ability to set up testing environments on the IBM Cloud for z/OS mainframe applications.
…
IBM plans to make IBM Wazi as-a-Service (Wazi aaS) for z/OS generally available in the second half of this year, [which] will enable DevOps teams to self-provision an instance of a z/OS virtual server on a secure private space running on IBM Cloud. … At the same time, it will become easier to modernize mainframe applications by making them more accessible to other applications via a set of secure APIs … using a cloud-native set of DevOps tools that run in a Kubernetes environment.
…
Modernizing mainframe applications is a less complicated endeavor than migrating them. The challenge is that building, deploying, maintaining and securing all the APIs required to do so represents a significant amount of effort.

OK, boomer, why are we talking about 1960s mainframes on devopsy.kinsta.cloud? Here’s ArchieBunker:

Mainframes are different beasts altogether, almost alien when you compare them to PC hardware. You have binaries written for the S/360 system in the 1960s? Good news you can still run them natively without a recompile.

You think virtualization and containers are a hot topic? IBM was running multiple OS instances inside a VM in the 1970s. … The engineering is incredible.

But z/OSaaS? It’s déjà vu time for Beleagured Greybeard:

“Cloud Managed Services for z” AKA “zCloud” has been around for over 10 years. … IBM offloaded it with the Kyndryl spin, so its odd that they now want to re-invent it.
…
If it’s a strategic platform, why didn’t they hold onto it instead of spinning it off to Kyndryl? Sounds like yet more daft leadership decisions.

3. IBM’s Return to Work Plan has Vaccine Mandate

IBM wants to “keep employees safe” as they return to office work after being fully remote. In practice, this means a vaccine mandate.

Analysis: IBM Digital Health Pass is divisive to vocal minority

Although there are exemptions on medical or religious grounds, IBM has promised to place dissenters on unpaid leave. As you might expect, the policy has a few employees up in arms.

Cassie Werber: How Salesforce, IBM, and HSBC are approaching return to work

When the pandemic hit, and IBM moved 95% of its workforce to fully remote, it was pleasantly surprised to discover no drop in productivity. … Still, they planned to return to offices.
…
The company saw this as a way to keep employees safe. … One example … is its development of the IBM Digital Health Pass as an alternative to vaccine cards or paper vaccine certificates, which they use to make sure all the staff that come into their offices are vaccinated.
…
Arvind Krishna, IBM’s CEO, meanwhile came up with what he called the IBM Work From Home Pledge. [It] included commitments to flexibility, kindness, sensitivity to family, setting boundaries, and acknowledged video fatigue. It concluded with a commitment to “be connected.”

Tricky to “be connected” if you’re not allowed back in the building. Anne D’Innocenzio, Heather Hollingsworth, Tali Arbel, Mae Anderson, Ken Sweet, Matt O’Brien and Dee-Ann Durbin:

IBM software engineer Justin Albano said his company recently notified employees that it would be revoking badge access to workers who aren’t vaccinated or haven’t proved that they are. “We’re not able to enter an IBM office at this time,” said Albano.
…
He said some workers have successfully sought religious exemptions but “my thought process was I shouldn’t have to explain to my company my faith” to get out of a policy that’s “immoral in its foundation.”

What’s the alternative? With a perspective, it’s Chris Haney:

Or, get the vaccine. Protect yourself and the people around you. You people really are detached from reality.

The Moral of the Story: Those who know do not speak; those who speak do not know.

You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

Image: Marcin Wichary—cc:by; leveled and cropped (ask your parents)

February 17, 2022
The Role of APIs in Mainframe Modernization
Mainframes are historically clunky systems. They are incredibly secure and can process impressive calculations, yet they are complex to manage and challenging to extract data from. This reality is at odds with modern cloud-native infrastructure, which emphasizes distributed computing and portable microservices. So, how can existing mainframes adapt to this connected, data-driven economy?

I recently met with Dr. Alex Heublein, president at Adaptigent, to talk about the state of legacy modernization. According to Heublein, many mainframes are here to stay for the foreseeable future. However, enterprises are continuing to get value from these systems by adding an integration layer on top of them. By using a REST API layer on top of a mainframe, enterprises could finally open up these systems. This could facilitate bidirectional communication with newer cloud-native services, enable phase migration and edge closer to real-time processing.

State of Mainframe Modernization

The software industry changes every day. “Nothing in the tech field is permanent,” said Heublein, yet some legacy technologies will persist into the foreseeable future. In terms of mainframe adoption, Heublein sees a couple of categories of users. First are the large financial services organizations, such as large banks and insurance companies, which are considerably invested in their mainframe architectures and which will likely continue to rely on mainframe environments for their policy management and core infrastructure. “I think there’s a lot of good reasons for that,” explained Heublein. “If you want to process billions of transactions a day, [mainframe] is still a good option.”

That said, regulations and market pressures are influencing a global movement toward open banking. For example, PSD2 mandates open banking in Europe and industry consortiums like Financial Data Exchange (FDX) are directing it in the U.S. market. These initiatives are encouraging financial services to transform their legacy environments and spurring cloud migration, especially for applications that aren’t mission-critical.

Heublein pointed out a few different patterns in enterprise mainframe modernization. One approach is that enterprises are rewriting or re-architecting old COBOL applications and keeping them on-premises. Or they are porting and re-platforming the application; moving a COBOL app to a Windows or Linux system, for example. Finally, some are shifting straight to the cloud. For solutions that don’t need to be on the mainframe, enterprises may shift toward cloud-native to free up capacity.

APIs Enable Legacy Modernization

Distributed cloud technology is helping businesses scale to the right level. Yet, it’s difficult to jump off the mainframe entirely, noted Heublein. “Very rarely can you take all your stuff and move it all at once,” he said. “It’s a tough pill to swallow.” It’s especially difficult to move core banking infrastructure to a distributed environment—an instant shift could introduce security risks. For this reason, he recommended a ‘phase migration’ approach in which individual components are slowly migrated. For example, an insurance provider may shift their claims engine, policy engine and ratings engine to the cloud one at a time.

As a result of phase migration, however, engineers must simultaneously support both on-premises and cloud-based applications. They must also ensure bidirectional communication so that these systems can exchange data. This is where a REST API transactional layer is necessary, Heublein explained. Such a layer could enable bidirectional communication between the mainframe and cloud-native applications, abstracting complexity when calling out to the modern world, or intercepting cloud data and filtering it into a format mainframe technologies can process.

To increase developer usability, abstracting complexity from the mainframe integration process will be the key to building out connectivity. This could involve a codeless development approach with a COBOL sub-routine to call external systems, Heublein said. Automatic restructuring of data will be necessary to enable fluent bidirectional communication, too.

Four Business Drivers of Mainframe Integration

So what is the end result of putting an integration layer on top of mainframe systems? According to Heublein, there are four key business benefits of using such an abstraction layer:
1. Orchestration: Software ecosystems often need to make multiple calls to different applications to collect and transform data. Yet, mainframe environments are very complex and challenging to integrate with. More usable integration fabric for mainframe systems could enable better orchestration of workflows in a developer-friendly manner. By using a REST interface, all apps could be calling the same interface, thus greatly simplifying orchestration between disparate services.
2. Sustained Adaptability: The world is rapidly accelerating, and enterprises need to maintain and modify these APIs very quickly. Organizations require “sustained adaptability” to adapt and survive in the digital world, said Heublein. Mainframe systems, however, were not designed for the 21st century. Thus, low-code integration layers are critical to empowering rapid development.
3. Data Transformation: Data is powerful for the business. Data is not only a commodity in and of itself but also is required for AI and machine learning. However, mainframes have a completely different way of encoding data. Thus, there is a need to transform this data into a modern format that businesses can consume. An integration layer between these systems can deliver an improved data consumption model.
4. Real-Time Processing: You may think online payments happen in real-time; however, payment apps like Venmo are really just an abstraction layer over bank transactions, which may clear as little as twice a day. In short, mainframes are not great at real-time processing. However, more usable integrations to this infrastructure could enable user-facing applications to interact more closely to real-time.
Another concern is security. Opening up mainframe environments that house core financial infrastructure must be done with extreme care—especially as API attacks remain the number-one rising threat in the software landscape. All organizations building out new integrations will require a secure layer from an outbound standpoint. Heublein said this often involves placing an API management layer or gateway in front of the integration layer. This system enables authorization and functions like a firewall between the internal and external world. It can also enable logging and prevent denial of service attacks, he explained.

Improving Agility for Legacy Systems

Legacy systems are entrenched in older technology and carry lots of technical debt, forcing operations to move at a slower pace. Maintainers are also culturally a bit different than the newer breed of cloud-native engineers. “Mainframe people are not … fast,” said Heublein.

DevOps folks want to build, test and promote projects to production very quickly and, arguably, this agility is necessary to satisfy rising digital innovation demands. Improving integration capabilities for on-premises systems could enable businesses to better utilize preexisting investments while also improving agility.

Low-code/no-code capabilities could also increase collaboration potential, Heublein added, which could bridge the gap between on-premises engineers and fast-moving business folks. When adopting low-code/no-code tools for mainframe integration, he cautioned against general-purpose citizen developer frameworks. Whereas universal integration layers can work well for many situations, he stressed that a very specific boundary box is best for building APIs for mission-critical applications.

How is your organization approaching modernization for legacy systems? Let us know in the comments below!
October 4, 2021