Insights from Red Hat Summit and OpenShift Commons
Here in this blog, we will learn about Insights from Red Hat Summit and OpenShift Commons.
The development of financial services platforms
Whether we are self-taught IT specialists, skilled software engineers, jet mechanics, bakers, bankers, or something else entirely, humans have a tendency to think in steps when it comes to finishing tasks: step 1, step 2, step 3. We cannot just write down what we want and then have it assembled or completed—for example, “I always need 10 cookies” or “I always need these transactions reconciled in my paper leger”—while maintaining the balance of the books or creating the perfect warm chocolate chip cookie. The anomaly is our world of software-based systems. We do have systems that let us specify basic commands (for example, “I always want this application version deployed with these parameters”), and they “magically” materialize, manifest, and—above all—maintain their existence.
To change from our steps 1, 2, and 3 thinking to, “Here is the state I want, your system, go figure it out and make it so,” requires preparation, work, and above all, a mental shift. Nevertheless, once you do, the amount of work that is removed from running your platform as a product, completing your subsequent platform migration, or delivering your end-user application is simply amazing. Red Hat Consulting assists our clients in undergoing this transformation on a daily basis, even though your organization only needs to go through it once.
Our industry is prone to thinking of platform operations and application development, delivery, and deployment as two distinct and seemingly unrelated worlds, except in cases where one depends on the other. However, as everyone is realizing, these two worlds are really the same. Software remains at its core a platform upon which applications can be deployed. Source control, versioning, continuous integration, delivery, and, at the end of the day, maintaining a continuous deployment state are all necessary. These days, this way of thinking is known as platform engineering. For others, it’s just software engineering. The best way to understand this is to consider these statements:
- As a platform operator, I hope to support my application developers compliantly within the confines of my application platform by outlining the desired state of my platform and having it regularly and consistently reconciled against the current state.
- Declaring the desired state of my application and having it continuously and consistently reconciled against the current state is how I, as an application developer, want to deliver capabilities in the context of my end-user application efficiently and compliantly, so that my application users are supported in a compliant manner.
Notice the distinction. If you replace “application developer” with “platform operator,” there isn’t one; instead, the “application user” of the platform is the “application developer.” “I need to deliver and operate my platform, as a versioned product, using all the same methodologies and lessons learned as my application developer users,” is the fundamental—if still challenging—mindset shift that organizations must undertake. This entails switching from mandatory processes that operators initiate based on tickets to an objectively declared state that operators maintain and make available to platform users as self-service API when appropriate.
Although it might seem like a difficult undertaking, you are not the first to attempt this cultural and mentality change. Financial institutions, one of the sectors with the highest levels of regulation, are among those at the forefront of this effort. And you can do this shift if they can find the time, motivation, and ability to do so in between all those rules.
However, where should one begin, and how can one try to steer clear of the inevitable pitfalls that lie in wait?
Red Hat Summit’s OpenShift Commons
Come hear from others who have made major strides in the FSI space at our panel, Platform as Product: Benefits Seen in Financial Ops, at Red Hat OpenShift Commons at Red Hat Summit on Monday, May 6, 2024, in Denver, Colorado. It is our hope that you will participate in the discussion and leave with suggestions on how to advance your company.
- OpenShift Commons Gathering and Community Day, May 6, 2024 The OpenShift Commons core sessions can be experienced in their entirety by visiting the landing page at https://red.ht/commons-denver. Alternatively, you can add all four sessions to your registration by utilizing our online portal at https://www.redhat.com/en/summit.
- May 6–9, 2024: Red Hat Summit and AnsibleFest. To sign up, click this link.
