There is a drama playing out in the landscape of today’s technology corporations that rarely makes it onto the slides of a board presentation. It’s a quiet identity crisis, the technological equivalent of split-self syndrome. On the one hand, the company is investing millions in a flexible, innovative and scalable cloud, creating an image as a digital leader. On the other, its fundamental business processes - those that generate 99% of revenue and guarantee business continuity - still rely on armored, reliable but perceived “obsolete” mainframe systems. These two technological personalities not only don’t work together; they actively compete with each other for the company’s budget, talent and strategic future.

Symptoms of this condition are well known to any IT manager. It’s the endless budget battles, where innovative cloud projects are pitted against the “cost of ownership” of core systems. It’s conflicting KPIs, where one team is rewarded for speed of deployment and another for zero production incidents. It’s a culture of blaming each other when an ambitious digital project falls through because it’s stuck at the integration stage with systems that no one on the “new” team understands. This phenomenon creates not only a technological debt, but also a much more dangerous cultural debt - a growing gap in communication, trust and shared goals. The purpose of this article is to diagnose and offer concrete, long-term therapy to cure the organization of this costly ailment.

Why chasing ‘cloud-native’ talent can be a strategic trap.

“Companies that strategically scale AI report nearly 3x the return on AI investments compared to those pursuing siloed AI proofs of concept.”

— Accenture, The Art of AI Maturity | Source

With the pressure to innovate, the simplest and most tempting answer seems to be aggressive recruiting. IT leaders, encouraged by boards of directors, are launching programs to attract the “best cloud-native talent” in the market. In theory, this is supposed to accelerate transformation. In practice, if this is the only strategy, it leads the company straight into a trap that becomes painful and costly to slam after about 18-24 months.

What is the hidden cost of ignoring domain knowledge?

Domain knowledge is a quiet, invisible asset whose value is only revealed when it is lost. It’s a deep understanding of “why” a system works a certain way. It’s the realization that a particular, seemingly illogical line of code in a COBOL module from 25 years ago is actually a safeguard resulting from a historic settlement with a market regulator. A newly hired, brilliant “cloud-native” engineer can optimize that code, unknowingly exposing the company to multimillion-dollar fines.

This hidden cost materializes in the form of:

  • Increased operational risk: Changes made without a full understanding of the business context lead to subtle, hard-to-detect errors in key processes such as interest accrual, invoicing and policy management.

  • Increased troubleshooting time: When an incident occurs at the interface between new and old systems, cloud teams don’t have the tools or knowledge to diagnose the problem on the mainframe side, and shrinking mainframe teams are swamped with requests they don’t understand.

  • Loss of ability to innovate at the core of the business: Over time, the company is afraid to touch its central systems because no one fully understands how they work anymore. This leads to a paradox in which a company is able to implement an AI chatbot, but is unable to modify the way it charges for its core product.

Are you ready for an ‘integration wall’ in 18 months?

The initial phase of a cloud-only team-based project is usually full of successes. An elegant user interface is created, the application runs rapidly, and the first demos impress the board. However, every digital project in a mature organization at some point has to hit an “integration wall” - the point at which it has to start communicating with transactional systems and mainframe databases.

Without the right talent on board, this collision is catastrophic. Cloud teams, accustomed to flexible APIs and distributed databases, design integrations naively, generating thousands of inefficient queries that degrade the performance of the central system or, worse, lead to instability. The cost of fixing such poorly designed integration, often requiring fundamental architectural changes on both sides, can exceed the initial project budget many times over.

Who is a ‘hybrid professional’ and why is he worth more than his certifications?

Since neither orthodox adherence to old cadres nor the cloud-only revolution is working, where does the solution lie? In consciously creating and nurturing a new species of IT specialist: the hybrid professional. This is not a mythical figure who codes in COBOL and designs Kubernetes clusters in equal measure. Rather, he’s a diplomat, translator and bridge engineer in one person. His core competency is not an in-depth knowledge of each technology, but the ability to move seamlessly between them and understand their interdependencies.

The value of such a specialist goes far beyond the list of AWS or IBM certifications held. The certification validates knowledge of the tool. A hybrid professional has wisdom - the ability to choose the right tool for a given business problem, regardless of which platform it resides on. He or she is an invaluable gas pedal who can, in 15 minutes in a meeting, solve a problem that two isolated teams would discuss for three weeks, sending formal requests to each other.

Anatomy of a hybrid professional

CompetenceWhy is it crucial in a hybrid environment?How to develop it in the team?
**API-First thinking**It allows mainframe business logic to be treated not as a monolith, but as a set of services usable by cloud applications. This is the foundation of integration. Organizing workshops on REST API design for mainframe teams. Introducing tools (e.g., Zowe) to facilitate service creation and management.
**Deep Domain Knowledge**Ensures that new cloud solutions do not violate key business and regulatory rules, buried deep in core systems.Actively involving mainframe veterans in the design phase of new products. Creating mentoring programs where they share knowledge with younger employees.
**Architectural Pragmatism**Allows decisions based on facts (where data is to be processed) rather than technological fashion. Prevents "flipping" everything to the cloud without justification. Create blended architecture committees (Architecture Review Boards). Promoting a "Request for Comments" (RFC) culture for key design decisions.
**Competence of the "Interpreter"**Ability to explain CICS transactional limitations to front-end developers and vice versa. Reduces frustration and errors due to lack of understanding. Rotation of team members between projects. Organizing joint "show & tell" sessions where teams present their challenges and successes to each other.
**End-to-End Automatio **Ability to look at CI/CD processes holistically, from the code in the Git repository, to the Jenkins pipeline, to deployment on mainframe and cloud environments.Investing in automation tools that support both platforms (e.g. Ansible, Broadcom Endevor Bridge for Git). Building a so-called "Value Stream Map" for the entire process.
**Cost Awareness (FinOps)**Understand the fundamental differences between the CapEx (mainframe) and OpEx (cloud) models. Allows you to design solutions that are optimal not only technically, but also financially. Integration of financial analysts into project teams. Training for architects on FinOps and TCO (Total Cost of Ownership) principles for various platforms.

What career path do you propose to breed such talents internally?

Hybrid professionals rarely appear on the labor market as a finished product. The most effective strategy is to “grow” them within the organization. This requires creating conscious development paths that promote versatility:

  • Rotation Programs: Intentionally moving talented engineers between mainframe and cloud teams for 6-12 months.

  • Creation of an “Integration Architect” Role: A formal position whose sole responsibility is to design and oversee consistent, efficient and secure connections between platforms.

  • Bonus System: reward employees not only for success in their home field, but also for contributions to cross-system projects and involvement in knowledge transfer.

Are ‘fusion teams’ just a trendy buzzword or a viable prescription for organizational silos?

Simply having talented individuals is not enough if the organizational structure forces them to work in isolation. The answer to this problem is a model that is gaining popularity in mature IT organizations: “fusion teams” (fusion teams). This is more than a fashionable buzzword - it’s a fundamental change in the way work is organized, with teams being formed around a product or business value stream, rather than around technology.

How to build and launch an effective fusion team in practice?

Creating such a team is a process that requires careful preparation:

  • Pilot Selection: Start with one strategically important but not too complicated project, such as “creating a new mobile app for claims processing.”

  • Defining the Business Objective: The goal must be clear and measurable to everyone, e.g., “reduce claim handling time from 5 days to 24 hours.”

  • Composition Selection: The team must include all the necessary specialists from day one: a mainframe developer familiar with the policy system, a cloud engineer to build the front-end, a security expert, a data analyst and, crucially, a fully empowered Product Owner from the business line.

  • Establish Common Rituals: The team needs to work together in a single sprint, have joint planning, daily meetings (stand-ups) and retrospectives. This builds a sense of unity and shared responsibility.

What are the most common pitfalls and how to avoid them?

Implementation of fusion assemblies faces typical obstacles. Awareness of their existence makes it possible to avoid them:

  • The “Mini-Waterfall” problem: The team is formally one, but in practice, the work is still sequential - the mainframe team prepares something first and then hands it off to the cloud team. Solution: Plan work based on “vertical slices” of functionality that immediately require work on both platforms.

  • Lack of Product Owner Empowerment: The business representative is only a nominal member of the team and must consult the hierarchical structure for every decision. Solution: Ensure that the Product Owner has real decision-making authority over product priorities and functionality.

  • Middle Management Resistance: Managers in traditional silos may see fusion teams as a threat to their authority. Solution: Include these managers in the process as mentors and coaches, responsible for developing the competencies of their people rather than day-to-day task management.

What to do when invaluable knowledge of core systems is preparing to retire?

The demographic problem in mainframe teams is a reality. Many of the key experts who have been building and developing mainframe systems for the past 30-40 years are approaching retirement age. The “somehow it will be done” approach, or the belief that everything can be written in documentation, is a straight road to operational disaster.

Why is traditional documentation a strategy doomed to failure?

Many leaders believe that the solution is to force departing experts to “write down everything they know.” This is an illusion. First, a huge part of expert knowledge is so-called tacit knowledge - intuition, experience and context that caot be fully verbalized. Second, in a dynamic IT environment, documentation becomes obsolete the moment it is written down. No one has time to constantly update it, and new employees quickly learn to ignore it because it is unreliable.

What modern methods of knowledge transfer work in practice?

Effective knowledge transfer must be an active, social process, embedded in everyday work. Instead of creating graveyards of documents, investment should be made in:

  • Pair Programming and Shadowing: A junior engineer works “side-by-side” with a veteran for several weeks on real-world tasks, observing not only “what” he does, but “how” he thinks and approaches problem solving.

  • Reverse Mentoring: It’s a two-way street. A junior employee teaches an experienced colleague new tools (e.g., how to effectively use VS Code to work with COBOL), and in return gains invaluable knowledge of business logic and system architecture.

  • Modernization Projects as Talent Forges: The best way to learn is through practice. Instead of abstract training, form mixed teams with the goal of, for example, refactoring an old module or exposing its functionality as a modern API. This is the most effective form of knowledge transfer.

Is GenAI the nail in the coffin for mainframe experts, or a powerful ally?

The advent of advanced language models capable of analyzing and translating code in languages such as COBOL has sparked a wave of speculation. Does this mean that the role of human experts is coming to an end? Our experience and market analysis indicate the opposite. GenAI is not a threat to experts, but is becoming their most powerful ally, multiplying their productivity and value to the organization.

What opportunities does GenAI present for modernization and onboarding?

Tools such as IBM watsonx Code Assistant for Z act as a powerful gas pedal, democratizing access to core systems knowledge:

  • For Modernization: AI can analyze millions of lines of code in minutes, identify dependencies, suggest microservice partitioning or automatically translate code fragments into Java. These are tasks that would take a human to do for months.

  • For Onboarding: A new employee, instead of spending six months trying to understand complex logic, can ask the AI a question in natural language: “Explain to me step-by-step how the process of charging this fee works” and receive an immediate, understandable answer.

  • For Testing: GenAI can automatically generate test data and even entire test scenarios based on code analysis, dramatically reducing the time and increasing the quality of the quality assurance process.

What risks should be controlled when implementing AI in critical environments?

However, the use of AI in the context of central systems requires a great deal of prudence. Key risks must be managed, such as:

  • Confidentiality of Data and Code: Is our source code, which is the intellectual property of the company, not being sent to external AI models in an uncontrolled ma

er?

  • Accuracy and “Hallucinations.” AI models can be wrong. Any code change proposal or logic explanation generated by AI must be verified by a human expert (“expert-in-the-loop”).

  • Overconfidence: There is a risk that teams will begin to trust AI suggestions uncritically, which can lead to the introduction of subtle but dangerous errors.

Need testing support? Check our Quality Assurance services.

See also

Are you ready to build bridges, not walls, in your IT department?

In summary, the biggest challenge of digital transformation is not technology. It is overcoming the internal divisions, competence silos and culture wars that cripple an organization’s potential. Success in the hybrid era is not about choosing between the mainframe and the cloud, but about masterfully combining the stability and reliability of one world with the dynamism and innovation of the other. The key to this combination is people - consciously shaped hybrid professionals working in integrated fusion teams.

At ARDURA Consulting, we specialize in diagnosing and treating the “technological split ego.” We understand that building bridges between platforms must start with building bridges between people. From strategic organizational transformation consulting, to flexible **Staff Augmentation ** delivering missing hybrid competencies, to deploying complete, action-ready fusion teams, our services are designed to help your company turn internal friction into a driver of real innovation.

****If you feel that your IT department is spending more time on internal battles than on delivering business value, contact us. Let’s talk about how we can help you design and build a cohesive and effective technology organization for the challenges of the future. ****

Feel free to contact us