Insights from financial operations for platform as product at OpenShift Commons Gathering co-located with Red Hat Summit

Continuing the countdown to Community Day at Red Hat Summit and OpenShift Commons in Denver, Colorado on May 6th! Last year at Red Hat Summit we had a case study session that discussed the Consumability of Platforms and using development services and enablement teams to guide technical implementation. This case study was from a financial services perspective, namely ABN AMRO, and showed how FSI companies are enabling a global landscape on global platforms.

The progression of platforms in financial services

Whether a trained software engineer, self-taught IT professional, a jet mechanic, a baker, or a banker we humans tend to think imperatively when it comes to completing tasks: step 1, then step 2, then step 3. While baking the perfect warm chocolate chip cookie or balancing the books, we can not simply write down the definition of what we want and then magically have something assemble it or complete (e.g. I always need 10 cookies or I always need these transactions reconciled in my paper leger). Our software-based world is the exception. We do have systems that allow us to state simple instructions (i.e. i always want this application version deployed with these parameters), and “magically” bring them into being, and, most importantly, keep them in existence.

It takes planning, effort, and most of all a mental shift to switch from our step 1, 2, 3 thinking to, "here is the state I want, you system, go figure it out and make it so." When you do though, the amount of toil eliminated while operating your platform as a product or doing your next platform migration, or delivering your end user application, is, in a word, fantastic. While your organization only has to go through this transformation once, Red Hat Consulting helps our Clients go through it every day.

Our industry often gets pulled into the trap of thinking of our platform operations and our application development, delivery, and deployment as two separate, seemingly unrelated (other than one depending on the other) worlds. But as everyone is (re)discovering, these two worlds are actually identical. A platform for applications to deploy on top of, is still, fundamentally, software. You need source control, you need continuous integration, you need versioning, you need delivery, and ultimately you need to maintain a constant state of deployment. Nowadays people call this mindset platform engineering. Others simply see it as software engineering. This is made most clear when thinking about these statements:

• In the context of my application platform, I as a platform operator, want to deliver the correct capabilities efficiently and compliantly, so that my application developers are supported in a compliant manner, by declaring the desired state of my platform and having it constantly and consistently reconciled against current state.
• In the context of my end user application, I as an application developer, want to deliver capabilities efficiently and compliantly, so that my application users are supported in a compliant manner, by declaring the desired state of my application and having it constantly and consistently reconciled against current state.

Spot the difference. Swap “platform operator” for “application developer” and there is none, the “application user” of the platform is the “application developer”. Given this fundamental, if yet still tricky, mindset change organizations need to make is, “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”. Which means moving from imperative procedures invoked by operators based on tickets, to impartially declared state maintained by operators and exposed as self service API, where applicable, to the platform users.

This may seem like a daunting task, but you are not the first to approach this cultural and mindset shift. One of the industries leading from the front on doing this is one of the most highly regulated industries there is, financial institutions. And if among all those regulations, they can find the ability, drive, and time to do this shift, so can you.

But where to get started, and how to do your best to avoid the inevitable traps along the way? 

OpenShift Commons at Red Hat Summit

How about learning from others who are well along that progression in the FSI space, by joining us at our panel, Platform as Product: Benefits Seen in Financial Ops, at Red Hat OpenShift Commons at Red Hat Summit on Monday May 6th, 2024 in Denver, CO. We hope to see you there engaged in the conversation and walking away with ideas about how to move your organization forward.

• Community Day and OpenShift Commons Gathering - May 6, 2024 - Reserve a spot for the events through our online portal https://www.redhat.com/en/summit or register for the complete OpenShift Commons core sessions experience by adding all four sessions through the landing page https://red.ht/commons-denver
• Red Hat Summit and AnsibleFest - May 6-9, 2024. Register here.