Hybrid Release Management Means Creating An Application Schema
February 14, 2024 Marc Dallas
In a hybrid computing world, no application is an island and similarly no system running those applications and the databases underpinning those applications can be an island, either. And yet, many IBM i shops still behave as if they can be islands when it comes to application release management.
Despite this, based on our own experience and the anecdotal evidence we gather from IBM i shops like yours, there is a clear separation between release deployment in the IBM i world and the “other” release deployments in the enterprise. We need to talk about this.
First of all, application deployment is not driven by technology. Release deployment or application release orchestration if you want to call it that, is an enterprise activity. It is strategic, and as such it will involve different teams from within the organization. And so it is nonsense to make a differentiation in release management based on the technology that is driving it. There is not application release management “on the IBM ” and then other kinds of application release management on Windows Server, Linux, or mainframe platforms.
That is why when we talk about application release orchestration, we first need to think about cross domain activities. We need to think about communication, sharing different capabilities and constraints, and coordination between different teams. It is not just restricted to DevOps, about how to deploy into a particular development environment of QA environment. It is about thinking about the totality of the infrastructure and the interconnectedness of the applications across platforms and having the end-user and their experience with those applications in mind.
That means that the IT organization, all of the people working on different teams, have to change their mindset and instead of thinking of their application stacks on their specific platforms, they need to start thinking about an application schema for the entire organization, mapping out different levels of capability and functionality – and across platforms that have their own uniqueness that is valuable to the business.
This is precisely the thinking behind the DROPS solution. Instead of working at the level of objects and files and other kinds of artifacts that are deployed to specific systems, we define and deploy an application schema across environments. It is a more holistic view. Environments differ according to their function. When we refer to training environments or production environments, the constraints are different, not only the platforms. A system that serves critical operations will have very different constraints from those environments further “left” in the cycle.
Once you take a high-level view, you can now start creating a hybrid application release orchestration workflow, one that respects all of the interconnections and constraints in the company-wide application stack – taking into account the different infrastructure and the myriad environments that run atop each type, the different teams that create applications and their workflow, and the different security options needed for the environments and their applications. All of these things are part of the risk management for the application development process and they have to be part of the corporate vision and the business strategy.
Once this is done, and we are thinking this way, then adding a cloud environment or another on premise environment or a completely different kind of distributed system either in the cloud or on premise is not a big deal. It is part of the process to be able to absorb new platforms and environments as well as to change existing ones. We are not just building an application release orchestration method for today, but for the future – that can accommodate a different future, which will surely arise. Evolution is very important to build into the process.
And throughout this process, at every layer up and down the stack and across application stacks and their underlying systems, we need to have security, which has been pretty medieval up to this point if you want to be honest about it. Literally, castles and moats, with security perimeters but not really a way to build zero trust security into every part of the applications and their systems.
Perhaps it is best to think of security as a kind of climate in which applications grow. We need security and accountability for every part of the hybrid application creation and deployment process. And just as happens in agriculture, the application deployment orchestration process has to respond to new constraints, which will surely arise. And because you are automating this whole process, it is resilient and does not fall apart just because one person leaves a team in the organization. Because the process is known by everyone and adhered to by everyone, release management becomes not just a way to deploy applications, but to maintain and increase security, quality, and functionality while at the same time lowering costs in the IT organization.
Sometimes, getting a new feature into the applications to help the company compete against a rival is a life and death situation. Time to market matters, and increasingly so. Is your IT organization up to the task? Can you deploy to the cloud or on premises at will? Does your application development team function as a team, or as separate silos that do not share ideas and that sometimes mock each other’s platforms? All of your platforms, all of your applications, and all of your people are strategic. And you have to start by telling them that and then building an IT organization – and an application deployment orchestration platform – that reflects this.
The future of your business depends upon it.
To learn more:
[Webinar] Synchronous IBM i and non-IBM i deployments
[Case Study] System U cuts application deployment costs by 40% using DROPS on IBM i and Linux
Marc Dallas is vice president of research and development at ARCAD Software.
This content is sponsored by ARCAD Software.
RELATED STORIES
Take A Progressive Approach To DevOps
The First Step In DevOps Is Not Tools, But Culture Change
VS Code Is The Full Stack IDE For IBM i
Realizing The Promise Of Cross Platform Development With VS Code
If You Aren’t Automating Testing, You Aren’t Doing DevSecOps
The Lucky Seven Tips Of IBM i DevSecOps
Git Is A Whole Lot More Than A Code Repository
Learning To Drive Fast On The DevOps Roadmap
Expanding Fields Is A Bigger Pain In The Neck Than You Think
Value Stream Management: Bringing Lean Manufacturing Techniques To IBM i Development
Unit Testing Automation Hits Shift Left Instead of Ctrl-Alt-Delete Cash
It’s Time For An Application Healthcheck
The New Economy Presents New Opportunities For IBM i
Creating Web Services APIs Can Be Easy On IBM i
Jenkins Gets Closer IBM i Hooks, Courtesy Of ARCAD
DevOps Transformation: Engage Your IBM i Team
The All-Knowing, Benevolent Dictator Of Code
Software Change Management Has To Change With The DevOps Times
Attention Synon Users: You Can Automate Your Move To RPG Free Form And DevOps
Git Started With GitHub And ARCAD On IBM i
One Repository To Rule The Source – And Object – Code
Data Needs To Be Anonymized For Dev And Test