If you thought the bill for development and test was expensive, just wait till you add the cost of maintaining and supporting your custom changes. On average, a software company will charge somewhere between 20 to 30% of the original development cost each year for the life of the product.
Let’s say you purchased an LMS that is nearly exactly what your business needs. But for whatever reason you find yourself having to pay $10,000 to have it customised. The first shock: the initial high cost of development is only the start. Your custom solution also comes with a maintenance and support fee. Support and maintenance could potentially double your development cost over the life of a contract. At the end of a 5 year contract your fees look like this:
A common example might be that the terminology used in the User Interface of your LMS was all wrong. The LMS talks about “Curricula” and “Occurrences” and these terms are alien to your team. You just know they’re going to struggle with them and it would be far better to stick with your jargon. A Curriculum for you is a Course and an Occurrence is a Training Event. You’d think that would be a really simple change right? Well, maybe not. It depends on a number of things including the cloud platform and how the software was designed.
You’d be surprised how design decisions can impact the cost of making even the simplest changes. Here are just a few.
This is where the software vendor uses one database for all of its customers. Each customer is called a ‘tenant’ (just like tenants in a big apartment block). In this scenario, making a change for customer X is not possible because that change might not be appropriate for Customer Y. It’s an all-or-nothing dilema. And since everyone’s on the same database they all have to stick to the same terminology.
“Multi-Tenancy” doesn’t have to mean “difficult to make terminology changes”, but it does require the vendor to put in a lot of up-front design effort to build in that kind of flexibility. Try going to a vendor like Mailchimp and saying, I don’t like the term ‘Campaign’ I would rather use ‘Marketing Strategy’. Better to just accept it, and move on. They’re not going to change it just for your account. That’s generally ok for a generic tool like Mailchimp, but when it comes to software that you need to run your business, having to put up with inappropriate terminology would be unacceptable.
With a single tenant solution the platform and database are dedicated expressly for your use, so while it might cost you to make changes, at least it’s possible. Because you won’t be interfering with anyone else's system.
Consider the cost difference to you (the customer) when deciding between these two options. You want to make a simple change to personalise the terminology for your business. Using the same example as above you want to change Curriculum to Course and Occurrence to Training Event. You and everyone else knows this should be a simple, low-cost change.
Vendor A has made no provision for custom label changes. Your only option is to have Vendor A get one of their developers to make the changes for you. That’s assuming Vendor A has used a single-tenant platform where change is even possible. You’ll most likely be up for the following costs:
So, without getting to scientific about it, big bucks!
Vendor B has had the forethought to build in a custom label map, so you can go to an admin page and replace the vendor labels and terminology with your own. Now consider the cost:
Half an hour’s work max without having to involve the vendor at all. It’s all DIY!
An Application Program Interface (API) allows software applications to talk to each other using an agreed protocol, like a legal contract that allows companies to work together securely under a common framework. When well drafted, both parties will fully understand the rules-of-engagement and will mutually benefit from working together. As far as your software is concerned, an API means your developer can write code that talks to the vendor’s software allowing you to share information freely without having to involve the vendor and without having to know the ins-and-outs of how the software works.
Typical uses of the API include:
Software vendors who invest in APIs that give customers this level of flexibility are worth their weight in gold!
In summary, if we were talking 1990’s - a lot! But back then there was much less off-the-shelf software so most companies who wanted or needed business software had no choice but to bite the bullet and just do it.
Today the story is different, you can find commercial off the shelf (COTS) software for pretty much any application you can think of. But will it do exactly what you need it to do? Probably not. So you can customise or make do. But if you decide to customise you are far better off working with a vendor who has taken the time and effort to think about implementing technologies and services that minimise your customisation risk.