Your customers are the lifeblood of your organisation, they provide the revenue that allows you to continually develop your applications and provide ongoing software support. They provide the marketing funds that are used to advertise your product and pay your executives. They are, in a nutshell, the whole reason you exist, and so you listen to them, seek their opinions, understand their challenges, trying to accommodate their needs within the limited resource pool that any ISV has.
The question is, are we all really listening to our customers, or are we choosing to hear the issues that the ISV (we) can deal with while leaving the customer to their own devices in areas where we feel we have limited input?
Understanding ISV revenue growth
There are two types of relationship that we see in the ISV space, and one is infinitely more successful than the other. Acting as a trusted advisor and partner beats the ‘sell and run’ approach every time. More importantly, it creates long term value for both the client and the ISV.
Sometimes it is good to go back to the beginning and understand the origins of the relationship between the client and the ISV. The client will have had a business need for a solution, and the chosen ISV application will have been the ‘best fit’ to solve that business need, whether it be a logistics problem, a planning problem, or a retailing issue.
Never forget that the customer has a choice of vendors or could have decided to develop a solution in house. In most cases, the customer would have had to modify or adapt existing processes to get the most value out of the solution provided by the ISV.
The solution is no longer ‘off the shelf’, it is customised and integrated. It is very rare to see an application that is 100% fit-for-purpose out of the box, and once the application becomes integrated the ability to migrate to new applications diminishes. That is not to say it cannot be done, it means it’s often very expensive, time-consuming and carries a great deal of risk for the consumer. The ISV has a loyal customer that generates revenue through software maintenance and support agreements, allowing the ISV to continually innovate and adapt their products to suit an ever-changing marketplace. Change is the keyword, embraced and feared in equal measure.
As stated, ISVs change and adapt their software to meet market demands, and the market has seen strong demand for Software as a Service (SaaS). The reasons for this are two-fold, there is a push demand from ISVs, as some only sell the application on a SaaS basis, and the pull demand from customers who will only consume cloud-enabled software.
It is a matter of opinion as to why there is such a push demand being generated by ISVs. One such reason may be that the satisfaction derived from the ISV’s application is measured by its return on investment, and in order to generate that return, the application needs to be available. Application uptime has become a key performance indicator.
In a traditional on-premise environment, three factors determine the application uptime. Firstly, the hardware platform that the application sits on. Secondly, the reliability of the software that it services and lastly the orchestration between hardware and software.
How can an ISV build on their KPI?
Increasing the resilience of the hardware and limiting the role of the orchestration layer, while still providing fit-for-purpose software, are vital factors in hitting KPIs. In other words, provide SaaS on the cloud.
SaaS is great for new software sales and new requirements, but what is happening to the customers that have had the application installed on-premise software for years, the ones that have customised and integrated it?
Let’s explore an example to demonstrate, it could be any customer, using any application, but I will choose an ERP application running on IBM i, as this is a common and relatable scenario.
Ten years ago, the line of business stakeholders decided a certain application was the best fit to deliver against the requirements that were specified by the business. It met 90% of the criteria, and with some integration and customisation, would more than do the job. The hardware platform was IBM i, recommended by the ISV, due to its reliability, thus improving the likelihood of meeting the application availability KPI.
A hugely experienced IT director was tasked with hiring three capable individuals to look after the application hardware and a team of development resources employed to help with any customization that needed to be done, the project was expensive, but a huge success in terms of ROI.
Let us fast forward 10 years and paint the new picture. The IT director has retired, as have most of the line of business executives that made the initial decision to go with the application. New executives have come in, with new ideas and new goals. ‘Cloud First’, ‘Cloud Native’, ‘Human Capital optimisation’, ‘do more with less’ and ‘scale on demand’ are the new buzz phrases.
The CFO wants an operational model that will allow him to better predict cash flow. He mandates that the company should deploy a cloud strategy. The IT team are gung-ho and achieve this in months. The old computer room now only has one rack in it, they have managed to get rid of the storage, the tape and nearly all the Intel servers are all virtualised and in the cloud.
All that remains is the comms and that black box in the corner which runs the backbone of the organisation, the heavily customised ERP application running on legacy hardware that no public cloud provider will take.
That is not the only problem, the ERP vendor is withdrawing support for the version of operating system that the application runs on, and IBM is withdrawing support for both hardware and software, in order to bolster their quarterly new hardware numbers.
It’s not what the CFO wants to hear and hinders the strategic objective, but the CFO will need to decide around the lesser of the two evils:
- On-premise hardware, managed by a team, through capital expenditure
- Migration to a new application
This is the last thing the ISV wants to hear. There is a solution, that will mitigate the risk and expense whilst fitting the strategic goals, and we will come to that, and it is a solution that will benefit the ISV as they can keep the customer’s support and maintenance.
Let’s do more with less
The on-premise hardware specified to run an application is mostly sized on peak workload, with a yearly growth factor added to that. Infrastructure analysts will size the hardware for peak capability, not average workload. The CFO will pay for that peak workload, even if the average workload is 10% of that peak, thus tying up 90% of capital, with no return for prolonged periods of time. No wonder the CFO wants an operational model.
Luckily, a few of the manufacturers are now in the business of selling golden screwdrivers to unlock capacity ‘on demand’. All you need to do is get your credit card out to get the key, under the proviso that the capacity is there to be turned on, but what if this is not the case?
There is a solution for that which we will come to in a minute, but why should the ISV be concerned? Well, what happens if the ISV recommends the wrong cloud? The one that cannot flex up and down or has no capacity to flex at a moment’s notice? Or worse, the cloud that forces them to change the underlying operating system? Surely, if the changes need to be that drastic, you may as well go the whole nine yards and change the application.
Workforce optimisation, multi-tasking, or expecting the same tasks to be done by fewer people with no impact on staff morale and preferably for less cost. That’s the stuff of nightmares for a Human Resources director. They need to cut headcount to meet expense objectives, but you cannot expect to run a 24×7 shift with anything less than three operators. Even then, this would severely stretch the team. Holidays and sickness need to be covered, by skilled people, which entails wage drift.
Skilled operators are becoming scarce on certain platforms, which in turn creates demand, so keeping hold of your personnel is a problem. What can the ISV do to help the customers in this situation? Recommending a cloud provider which has a large pool of skilled resources while keeping the customer on the same platform to avoid a costly migration.
If a customer cannot keep up with code enhancements or development, it lowers their ability to adapt the application to the market demands. If we factor in the OEM’s operating system releases, and support for those, together with the ISV compatibility support matrix, customers can quickly get caught in a negative spiral, where the ISV application is no longer supported on the OEM operating system, without an upgrade.
The problem encountered by many customers is that they have legacy systems surrounding the applications causing a knock-on effect, with customers either abandoning operating system upgrades and/or application upgrades.
There is another consequence to the so-called technical debt, public cloud providers specify minimum levels of operating system for their platforms, they will not support older versions, as they may pose a security risk or be cumbersome to manage. The customer’s reliance on these older integrated applications prevents them from making the transition to public cloud.
This will be a huge concern to an ISV. Customers soon realise that there is no point in paying for software support if they can no longer get software currency or support, which translates to a loss of revenue for the ISV.
Addressing all the obstacles faced by ISVs
Given all the above, and seeing it from a customer’s point of view, do you want to be the trusted advisor to the clients who ensures revenues to allow for continuous software development, or take the ‘sell and run’ approach, which could significantly shorten the life cycle of your application?
Blue Chip is the trusted advisor to many ISVs, and we stand shoulder to shoulder with them, enabling customers to take full advantage of our private cloud, which solves all the customer problems mentioned here. A true cloud that scales upon demand, is secure and allows for synchronous replication. A team that supports not only the current operating system version but also legacy ones, all done on an operation-focused budget, with clear costs.