Photo from Unsplash
Originally Posted On: https://diginomica.com/dont-be-next-southwest-two-oracle-partners-weigh-avoiding-technical-debt
The consumer tech world might be infatuated with ChatGPT, drizzled with the hyperbolic seasoning of Web3 and Metaverse prognostications.
But in the enterprise, it’s a different story. The biggest headline might be the renewed preoccupation with technical debt – aided in no small part by Southwest’s scheduling software systems meltdown (What just happened to Southwest Airlines? A cautionary tale about underfunding key IT technology).
In a valiant attempt at silver lining, I wondered if this might be the motivational kick in the posterior enterprises need to keep their tech investments justified:
Southwest’s let’s-kick-the-can-on-technical-debt systems meltdown is a cautionary tale that should hopefully wake up more CEOs, who may think it’s safer to ignore their employees’ warnings and skate by with shareholders, rather than to take the financial hit of a transformational IT investment. Ironically, this end-times-experience for Southwest passengers might do more than anything to keep enterprise tech budgets somewhat on track in 2023.
Older ERP releases and technical debt – do they go hand in hand?
Aren’t customers on older ERP releases at a higher risk of a tech debt predicaments? I believe the answer is yes – though that’s a vast oversimplification, given customers’ (extremely) heterogeneous landscapes. One good thing about 2022: vendors with so-called “legacy” install bases are providing better answers to the problem of systems modernization. Why does that matter? Because in 2023, we need alternatives to doing a massive cloud ERP upgrade, for customers where that is not the right option for this year’s budget (and business priorities).
I was particularly encouraged to hear some fresh approaches from ERP systems integrators. Why? Because historically, SIs are the biggest reason why customers have found themselves in ERP-related technical debt. As I said in a yet-unreleased podcast:
My problem with SIs is basically: ‘Yeah, take on all the custom code you want; take on that work; just charge the client; make as much money as you can, and leave them with a messed-up architecture that prevents them from upgrading in the future,’ just to solve something they think they needed in the moment that they probably don’t need.
Okay, that was a bit over-the-top, but am I really that far off? At Oracle CloudWorld 2022, I interacted with a couple of Oracle partners that are going about it in a much more forward-thinking way. One of those partners, vFunction, nailed down the tech debt issue well before Southwest’s incident. As Bob Quillin, Chief Ecosystem Office at vFunction, explained to me in October:
It’s the legacy applications and technologies that get left behind – the tangled mess of spaghetti – leaving a growing trail of technical debt and unmet business goals. The funny thing is that we all are still working on those monolithic applications, those older database technologies, those pre-cloud infrastructures. Even the most advanced organizations – and dare I say unicorns – I spoke to at the conference are still dealing with this growing technical debt, and monolithic apps and infrastructures – as they build new cloud native greenfield apps, and get educated on the latest releases and techniques in software development and engineering.
I asked Quillin: how did the Southwest failure impact his views? He responded:
There are far too many organizations – Southwest being the poster child now – that have kicked their technical debt “can” down the road for far too long… The bill for all that technical debt and all those festering monoliths will come due for many in 2023. For Southwest Airlines, their bill came early this year. And it’s likely to reach $1B or more when all is said and done. Let this be a warning bell to all, a harsh reminder of the cost of technical debt, and a call to start finally addressing the problem.
Beyond cloud lift-and-shift – a new type of ERP systems integrator is needed
The biggest reason I wrote this piece? I’m seeing the emergence of a new type of ERP partner – one that can offer customers different modernization choices. Up until recently, most ERP partners I ran into were really providing two options: massive cloud ERP upgrades, or cloud hosting “lift and shifts,” the latter of which does very little, in and of itself, to address technical debt, whether you want to talk yourself into calling it cloud or not. Quillin has a different take: don’t just lift-and-shift, press on.
Many organizations have tried to buy time by migrating their monoliths to the cloud. But typically they just lifted-and-shifted-and-stopped, meaning they migrated their monolith to the cloud and just forgot about it or celebrated that they were in the cloud – then lost focus/moved on.
Ah – now we can have a much more interesting conversation. Can we provide customers with proven cloud deployment paths beyond lift-and-shift, with steps that have “outcomes” as we go? Quillin says for Oracle customers, the answer is yes:
The blueprints and garden paths are there today to develop, deploy, and operate greenfield apps for the cloud, from the underlying autonomous database platforms to powerful new microservice frameworks and everything in between. They are exciting to talk about, get trained on, demo, and workshop.
And yet, we’re not there yet – not by a long shot. Too many customers are stuck with transactional software that is not well equipped for today’s needs. Quillin:
My informal survey of organizations at the Oracle CloudWorld conference indicated that 70-80% of these teams were still in the process of modernization – either evaluating how to do it, how to accelerate it, how to facilitate what they’re already doing, or just how to give to the next person that comes along because they’ve had enough. The last 20-30% have either completed their efforts, have actually given up, or perhaps may have been the wrong team to talk to.
So how do we solve that? Maturity models, better tools, and different SI business models are clearly part of it. But I think a big part of it is community: mixing business and tech users, bridging the gaps between infrastructure and code. Quillin captured that vibe:
The vFunction CloudWorld booth sat smack between the JavaOne Lounge Developer Hub and Oracle Cloud Developer Hub – a perfect bridge between the Java developer world and the Oracle Cloud Infrastructure developer services worlds. This offered a unique opportunity to track where we were (as an industry) on the lift-and-shift, move-and-improve, monolith modularization, and monolith to microservice movements that have been the go-to playbook moves for cloud migration and application modernization projects over the last 10 years.
Syntax – moving from custom code to platform extensions
In my Oracle CloudWorld roundup, Syntax’s Marc Caruso explained how Fusion development is really shifting from custom code to API-driven platform extensions:
When you look at what cloud is and what it’s supposed to be, the API is the key to all of it. That’s what allows you to integrate cloud apps with whatever applications you have running. The fact that Oracle is now going to be essentially exposing their whole Fusion development platform, with Redwood and all those capabilities – I think it’s going to be compelling for customers.
It will give them a singular user experience, and give providers like us the ability to create these apps. I don’t want to call them custom – they’re extensions for particular functions that allow you to interact with the data, however it is you need it.
During our CloudWorld interview this fall, Caruso had a different view on ERP modernization:
Most of the customers we’re going to move to the Fusion Cloud ERP apps have done so. And the ones who are still on Oracle E-Business Suite, JD Edwards, PeopleSoft. They’re going to be there for a while, because there’s no compelling reason for them to move to – unless there are major feature gaps.
Customers need a compelling reason to upgrade. It bothers me when “end of maintenance” is that reason; I want to see a genuine business case for a cloud ERP move. To Oracle’s credit, they have supported this older software for a long time, much longer than I expected (and continue to do so, though a complete discussion of this topic is outside my scope today). In turn, that has given partners like Syntax a chance to hone new modernization approaches. If a customer isn’t ready for a big upgrade, they should have appealing options besides standing pat. Caruso talked about a “bluefield” option, where your older ERP core remains, but you add new cloud components, often via OCI (Oracle Cloud Infrastructure):
We’re seeing a lot more now of bluefield type deployments where they keep their apps on limited ERP system. And for a new piece of functionality. They’ll deploy that in the cloud. So things like transportation management, Oracle’s new Supply Chain Cloud, that are things that they’ll implement in the cloud apps paradigm – and just integrate.
Caruso emphasized that Oracle customers on older releases sometimes need expert advisory on getting their support and licensing agreements sorted and stabilized. That frees customers up to make their calls on modernization – and/or moving apps to OCI.
My take
Don’t let my bias towards smaller, expert SIs negate a more important truth: every customer is different. No services firm fits all. Still, I wish more customers would cast a wider net when evaluating SI expertise, including firms with industry, cloud, or app development specializations.
Caruso framed the problem older ERP customers face with massive cloud upgrades well:
Most customers that are running manufacturing; they’re running distribution; they’re running supply chain. They’ve adapted their ERP system to be a system of differentiation and a competitive advantage for them – if they’re doing it the right way. But a lot of them customized – or customized the wrong way -and they’re kind of stuck.
Discovering the extent of your technical debit is unpleasant – especially when that realization comes in the midst of plotting bold moves, or due to a career-altering systems failure. Oracle has documented boatloads of Oracle Fusion Cloud success stories, but it’s also good for customers to know: if they aren’t ready for that just yet, they can still modernize – with the right partners, and a platform like OCI.
What business problem are you solving/opportunity are you seizing? To borrow from Quillin’s earlier example, if you want to move into Oracle’s Supply Chain Cloud, then the reduction of tech debt and the modernization of the stack – those are just byproducts of pursuing a business priority. As Quillin told me, the time for talk is over; it’s time to act:
How can we be so far along this cloud journey, but have left so many key apps behind? Technical debt continues to be a huge concern, as I’ve heard many a story of slow engineering velocity, long test cycles, prolonged release cycles, slipped product schedules and feature updates – not to mention the hit on engineering morale and culture.
But there is a happier side. He added:
Shifting the drag that tech debt has on development teams and moving that investment over to innovation has immediate business, technical, and people benefits. We demoed our Assessment Hub product at the booth to help kickstart the process of modernization and tech debt removal – it’s free for three apps, so that’s one contribution to the process of creating a catalyst – but the industry is in need of many more.
Caruso went so far as to say that customers on older ERP releases do not have to experience any tech debt at all – if they go about things as he described. That’s a strong statement; I’m not sure I agree. But it’s the right conversation.
