What an Open-First Approach Can Do for Mainframe Innovation | CIO
You may be familiar with the term “open” in the context of software development. Chances are you think of it as synonymous with “open source.” Like many modern economic models and movements that have been born out of the era of smartphones and digital innovation, the definition of “open” is evolving in response to the need for more innovative customer experiences.
Transformative applications depend on greater interoperability and data exchange – and are driving a shift in the architectural principles and values of digital leaders.
Take ridesharing and how its definition has evolved from cars-for-hire to redefine mobility. Or Airbnb and how it’s morphed from rooms for rent in private homes to making trusting staying in a stranger’s home so second nature it’s changed the way we think about travel and homeownership.
These services were successful because of the growing popularity of the “pay for just what you consume” mindset and peer-reviewed services. But they also prospered because they didn’t have to invent everything. For example, the location maps in Airbnb were pulled from Google APIs they sourced into their apps. Airbnb opted for embracing what’s been shared by the community and the organic process.
Both Airbnb and Uber have reaped tremendous commercial advantage out of embracing the open community. Traditionally, development organizations have relied on councils of architects to review a design to make sure the team was using the right standards and approaches. Now, modern methods for innovation are more about emergent architecture. Architects are increasingly choosing technologies based on the number of GitHub forks and stars acquired versus looking to a council that makes decisions based on past, private, existing investments. They’re relying on capabilities driven by the community in an organic way vs. a highly controlled manner. Decision-making at the design level is pushed down– without sacrificing quality. The decision made is based on what’s already been out and tested in the open world.
Mainframe Considerations
The open and shared technology movement extends to the Mainframe ecosystem. Once thought of as a “black box”, the mainframe can be “opened up” significantly. For example, it now includes partner APIs and open APIs. Partner APIs make services available to those with which they partner, e.g., one bank may share what they’ve built with other financial institutions within their network. For example, Bank A is working with an API that needs to call another API to check what your bank balance is. Bank A partners with Bank B to access that data for their debit cards. This sharing of assets fuels innovation that was stifled by a lack of access to data in the past. Open APIs are not limited to use by a specific network.
In contrast, they are available to anyone in the community and published without any expectation for the final application. When Google opened up the APIs to their maps, they never imagined their data would be overlaid with data from car GPS’s to develop a ridesharing app. But because those maps were open, it enabled Uber to use this data in a novel way allowing a new business opportunity to be born.
Redefining ‘Open’
Openness and agility have become the new mantra for CIOs. For these leaders, technology choices are all about getting to results faster and a universal language that fosters collaboration and efficiency among all technologies and teams – including the mainframe. This movement drives intense excitement in mainframe “open” tooling and the ability to easily consume and automate mainframe services externally, whether through an API catalog or modern Integrated Development Environments (IDEs). This strategy is becoming increasingly important as analysts suggest wholesale migration off legacy systems is fraught with risks and lower-than-expected ROI.
Broadcom is taking the lead in redefining what open means in response to these changing needs. We believe that delivering better quality software by working with the community is paramount. Our commitment is grounded in the idea that innovation is achieved when your environment is architected to amplify the value of each piece of the ecosystem – especially the mainframe.
For us, “open” means going beyond working with open source tooling. It means making mainframe services consumed and automated externally with ease, whether through APIs, SDKs, CLI’s or IDE interfaces.
We call this approach “Open-First.”
We are fully embracing the meaning of open, breaking down industry silos with the following community-focused, industry-wide initiatives:
1) We are a founding member and major code contributor to the Open Mainframe Zowe project, the first project dedicated to z/OS. Zowe enables the mainframe community to open up APIs and CLI in a consistent, secure, and discoverable (through an API mediation layer) manner.
2) We are opening up all of our tools and data across our portfolio with Zowe compliant APIs. An Open-First approach allows our customers to achieve deeper integrations and more easily orchestrate and automate mainframe solutions across Development and Ops processes.
3) We embrace Open IDE initiatives and are making sure that all our development and debugging tools follow the open protocols required to fit with popular IDEs like Visual Studio code, and cloud-native IDEs such as Eclipse Che, RedHat CodeReady Workspaces, and others.
We’re partnering with our customers to achieve desired business outcomes by opening up their mainframes. We’re behind them as they embrace an open-first approach. Some, first, subscribe to Zowe to establish CI/CD pipelines. Regardless of their path, once they’re up and running, they’re leveraging the Zowe framework as their next-gen interface to the mainframe, making it just like any other platform, and automating mainframe solutions that span all mainframe processes: DevOps, AIOps, Security, Infrastructure, and Database.
Buyer be Safe and Smart
Sure. Alternative approaches do exist. Some claim to be “open,” but in truth, their approaches restrict innovation and come with vendor lock-in. These approaches eschew standards and the community in favor of control. Subscribing to a private approach means you give up the ability to integrate easily with other tools, the chance to exploit innovative things others have already done, and the confidence that your API is secure and can be trusted. Think about arriving in say, New York City, and the car services all have handmade Uber signs, and peer reviews are non-existent. With which driver would you ride?
The open ecosystem is becoming more valuable as participation increases. Broadcom is collaborating closely with this community and the Open Mainframe Project, which falls under the Linux Foundation. The OMP is the same organization that is leading Node JS, CNCF, and Kubernetes. All the tools that run modern IT today.
At Broadcom, we’re investing significantly in connections – not proprietary integrations. We encourage the industry to define “open” similarly and to participate and contribute to the open-source community to foster widespread adoption of conformant tools. In the end, everyone benefits: the contributors, the collaborators, and the end-users.
The next time you land in an unfamiliar city, imagine trying to find your Airbnb or track your Uber without the google map integration because the companies didn’t have the resources to develop ALL the innovative technologies in their roadmap. How would you find them?
Likewise, the next time you investigate an open solution, ask about its open APIs, Zowe Conformance, and free IDE integrations. Is the answer they are Open-First? If not, learn how you can architect an open, cross-platform enterprise approach with your mainframe.