One of the key advantages of modern cloud systems is that they often come with rapid development platforms that allow the vendor, partners, and even customers to build extensions and customizations to the system without affecting the underlying code or architecture of the base system. These are generally known as Platform as a Service (PaaS). Examples include the Salesforce Lightning (formerly Force.com) platform, the SuiteCloud platform of Oracle’s NetSuite, Acumatica’s xRP platform, Sage Intacct’s Platform Services, Microsoft’s Power Platform, and many others.
However, as with so many good things in life, PaaS can be used and abused.
Old Mistakes, New Mistakes
Earlier this month, I did a video interview (click to view) with James Maguire over at Datamation, on the subject of enterprise software selection. In that interview, we discussed mistakes that organizations make in the software selection process—not just the traditional mistakes, like a lack of top management commitment, but some new mistakes, such as spending too much time up front mapping current business processes.
It was an interesting discussion. But at the end, James brought up a question I hadn’t thought about previously: what kind of new mistakes will companies make in the future—say three to five years from now?
I thought for a minute and reframed James’s question in my head: With the move to cloud, what new mistakes are companies making now and in the future? In one sense, vendor evaluation has become more difficult.
The newer cloud vendors have done a lot to cut down on the need to customize their systems. A lot of this has to do with their providing platforms that allow customers to build extensions on top of their systems. These are excellent tools that allow those extensions to be carried forward to future versions of the system.
However, PaaS tools can be misused. In some cases, when cloud vendors cannot meet a certain customer requirement, they respond that they can easily meet that need through their platform. This may be fine for many small changes, but when it involves a core process within the system, it can be too much.
Just Because You Can, Doesn’t Mean You Should
The example I like to use is product costing. Suppose an organization’s financial systems are based on standard costing (we can argue some other time why this may be a good idea or a bad idea, but that’s irrelevant at this point.) If a cloud vendor’s system only supports actual costing, it would be foolish to suggest to the customer that we develop standard costing with the vendor’s PaaS. Believe it or not, I have seen this suggested to a customer. Product costing is not some small feature in an accounting system: it is fundamental. It is not something that a customer should allow the vendor to build as a one-off extension using its platform-as-a-service capability.
For some buyers, such as medical device manufacturers, another key need is serial number traceability. This should be part of the core inventory system, not something bolted on using the vendor’s platform as a service. There are many more examples.
As I say in the interview, just because you can do anything with the platform doesn’t mean you should do everything. This is because you still will need to maintain that code going forward.
Another danger is that if your requirement is something that is common with other customers, the vendor at some point may develop the same feature as part of the base system. At that point you will need to decide whether to abandon your customization and adopt the standard functionality of the vendor.
The bottom line is that you should use some judgment in terms of what you want the package to do natively and how much you want the vendor to customize the system using the platform. In the sales cycle, SaaS vendors are often quick to answer every question as, yes, we can do that with our platform. When you begin to hear that as the answer to many questions, beware.
Platform as a service is a powerful tool. But it is so powerful that buyers will need to use judgment in when and how they allow the vendor to use it to satisfy key requirements.
Watch the full video of my interview with James Maguire.
Analysis by Strativa President, Frank Scavo.