ARUN MURUGAN, Senior Director, WMS Development
Last week at Oracle OpenWorld, Larry Ellison touched on topics that garnered a lot of attention in the media. Like most of the audience in attendance I could only nod my head in wonder at the scale and scope of projects that Oracle is currently undertaking. As I am still fairly new to the organization I am amazed by all of the projects and research that are underway here every day.
So I listened passively to his talk, excited by all of this activity, but also thinking that it would have, as yet, little to do with my corner of the Oracle universe. That was until he brought up a topic that I have actually spent quite a bit of time thinking about and that I have spent years trying to solve.
And so I thought it might be useful to post a blog about it. What Larry said that struck me didn’t have anything to do with Machine Learning or IoT, and it didn’t have anything to do with new security features or with the potential promise of blockchain technology either. What the topic was, was a problem in IT that is actually quite fundamental. Larry Ellison brought up the very basic idea of patch management and how it continues to be a source of IT headaches.
Now anyone who has worked in the IT industry for more than a few days knows that managing the seamless integration and complexity of various operational systems is probably one of the most taxing things an IT team has to deal with. The work is time consuming and hard to control. It’s high-risk and can directly impact business performance. It slows down new releases and takes teams away from solving core business issues.
In the old era of on-premises software this context was frustrating, time-consuming, and expensive to solve. However, in the modern era of continuous delivery – an IT team stuck fixing patches is unacceptable. It is not a context that can continue.
So what’s to be done?
THE CLOUD WMS PROMISE
One of the fundamental differences between cloud and on-premises WMS solutions is the idea of paying for ongoing patch management and the impact of that on the Total Cost of Ownership (TCO).
To illustrate the difference, here is a simple thought experiment:
You have invested a million dollars in an on-premises installation that helps you manage your supply chain business. This is a huge outlay of capital, but it’s been justified as a necessity to modernizing your business operations.
A year later, when you are reviewing your costs you notice that maintaining your infrastructure has cost you close to 20% of your original investment. You have spent $200 thousand dollars to keep the thing running.
A fluke, you think — a speed bump. It’ll get better next year. Only next year comes and you find that you’ve spent an additional $200 thousand dollars. It’s the same the year after that, the year after that, and the year after that.
After five years, you realize that you’ve essentially paid for your installation twice. And now it’s time to upgrade your system and start all over again.
This is a waste of money, and it’s the headache that is caused by patch management. That $200 thousand dollars annual expense should be going toward innovating your business or aligning your supply chain infrastructure in other ways — anything that helps generate new lines of revenue.
The idea of a “maintenance” patch-management fee on technology is an outdated, outmoded way of thinking, and not at all aligned with the digital era of cloud-computing we find ourselves in.
You’re not paying a 20% fee for updates to your cell phone or your operating systems. You’re certainly not paying it on updates to your Facebook, Netflix, or LinkedIn accounts. You’re not paying it in online banking. Not even cable television charges you for software maintenance.
This is because nearly everyone, everywhere, understands that in the digital era, software development is an ongoing, iterative process and updates happen all the time.
So why should WMS solutions be any different? It’s code like all the rest.
FUNCTIONAL AND NONFUNCTIONAL REQUIREMENTS
The thing to understand about developing software is that it is made up of functional and nonfunctional requirements. Your functional requirements offer you the core reason and specific behaviors of the software that solve your specific business problem. These are the automated tools, processes and workflows that add value to your business. In the case of WMS solutions, these could be capabilities like inventory visibility or process optimization. Anything that allows you to scale your business.
Nonfunctional requirements, on the other hand, are lines of code that impact the performance and operation of your software. For example, nonfunctional requirements could be a security patch or an upgrade, an increase in speed and performance, enhanced usability, or integration with other systems and databases.
Patch management is entirely concerned with optimizing those nonfunctional requirements.
The reason modern technology companies give you free software updates is because from version to version -- while change regarding your core behaviors might be slow -- changes improving your nonfunctional requirements are ongoing. Everything regarding how well your software performs is always being tweaked or revved up.
Why should you pay for that? Software companies are selling you the best software they have — at a moment in time — and to keep you, they make sure their software stays ahead of the pack. It’s in a company’s interest to improve their software. It is what gives them a competitive advantage over another company in the same field.
Why should you subsidize that?
When you pay an on-premises WMS vendor a maintenance fee, all you’re paying for is the right to get an update that in any other industry you would get in the original cost. That is all.
Think about that.
You are not paying for new functional features or toolsets. You are mostly just paying for patches, performance updates, etc. It is the reason we think your software vendor should begin picking up their own maintenance bill.
Explore Modern End-to-End Supply Chain for Real Business Growth.
Integrating supply chain with ERP provides the function needed for end-to-end digital transformation.
What is the size of your WMS standard codebase and how is that determined?
A software’s codebase determines the upgrades that need to be added.
Here’s how cloud technology optimizes this:
With Oracle Cloud WMS, every piece of new functionality that has ever been created goes directly into a standard, non-customized, codebase that is available to every client. As far as product features are concerned, everything we learn at every implementation around the world — and that benefits our customers — goes directly into our codebase.This is the virtue of cloud technology. Every Oracle Cloud WMS implementation uses 100% standard product functionality every time and it is built upon all the learning that has taken place up until that point.
The same is true of any patch management that occurs during a release.
And a cloud deployment model makes for the most optimized, cost efficient, distribution of technology.
On-premises solutions don’t work this way. On-premises solutions are disconnected occurrences, and every installation is a reinvention of the wheel. On-premises solutions have not figured out nor have any interest in sharing or transferring performance knowledge.
After an on-premises installation, the on-premises vendor then spends the next several years charging their customers to patch those one-off installations. They spend the next several years implementing the changes and adding solutions that could easily have existed from the beginning if they’d actually had a robust, standard codebase
This is not the way to optimize your business. Ecommerce and omni-channel retail require a digital fulfillment strategy. End of story. Part of that strategy means building your digital fulfillment on a foundation that leverages cloud capabilities.
With the era of digital fulfillment in full swing, we foresee that in the next five years there will be a mass migration to cloud computing in the supply chain world.
It is an opportune time to get ahead of that curve. If you wait another three to five years before you take the plunge, all you’ve done is paid a second time for something you only needed to pay for once. You’re forcing yourself to play catch-up when you have no reason to.
Check out some of our customers who have taken the plunge already and who are experiencing the benefits of a 100% standard codebase. These companies have eliminated the headaches of patch management and are already benefitting from cloud computing. You should be too.
And for on-demand videos from Oracle Openworld, including Larry Ellison's keynote, visit us online here.