Prepping for the Cloud
“Behind every cloud is another cloud.”
Part 2 of this 4 part series presented 12 things to consider when creating a budget to re-develop your manufacturer pricing program.
Digging through the layers of complexity with the cloud can be a daunting task. So now that you’ve rebuilt your manufacturer pricing program for easier kitchen quoting and bidding, how will your dealers access it?
Below are my top 9 things to think through before rushing into the cloud. Like the Judy Garland quote to the right, the cloud has layers upon layers of things to think through.
- Security. A site that’s hacked or brought down maliciously will have serious ramifications to your business as orders are coming in. Don’t forget about SSL certificates, DNS and all the other minutiae in this category.
- Data. Where will the data physically reside? Verify that your dealer’s data will be physically located on U.S. soil and not in some other country that has no problem mining the data to sell to some unscrupulous party. Be sure to look at everything from your vendor’s staying power to whether or not you can actually talk to someone on the phone in the case of an emergency.
- Scalability. Will your pricing program scale or will it crash after the 5th user? This is one part application, five parts architecture and four parts infrastructure — and it gets all the way down to the hardware level in some cases. Volume testing and serious architecture skills are required because web applications can reach critical mass quickly and crash with unexpected memory leaks, browser issues, bottlenecks and more.
- Performance. Unlike the performance of your pricing program’s code, launching into the cloud also brings additional performance considerations. What kind of hardware do the dealers typically run (i.e. how much of their desktop’s performance will your pricing program take advantage of)? What about network bandwidth, web server and database server performance?
- Hardware. Will you go with a dedicated hardware option or maybe virtual servers? Or will you choose some sort of variation here? Countless vendors with their own unique pricing models need to be explored and evaluated. Make sure to do your homework about performance impacts of whichever route you decide to take.
- Multi-tenancy vs. Multi-instance. Will you choose to put multiple dealers in one environment, sharing one giant database? Or will you choose to separate them out into unique environments with their own databases? If it’s the latter, who will maintain all those environments? The decision here can significantly impact things like full-text searches and backup/recovery. It can also create thorny reporting challenges your team will have to solve.
- Multiple environments. Remember you’re in the cloud now so you’re going to need recreate problems your users are experiencing. Multiply any monthly fee on hardware leasing by at least 3 so you can adequately test and resolve problems.
- Backup & Restore. If multiple dealer’s databases are physically stored on one box, and one dealer’s data becomes inaccessible, how will you handle that? Make sure that one dealer’s problems don’t inadvertently affect other dealer’s just because they happen to share some hardware.
- Usage. One major benefit of the cloud is that you can see who is using your application — and how often. This let’s you know how well your dealers are adopting. How will these analytics be captured and who will monitor this on your team? If usage at a few dealers starts to drop precipitously, who gets notified to place a call with the dealer to find out why?
Of course you can always just create an application your dealers can download, but then that’s no longer a web-based pricing program, is it? If you choose that route, then I would recommend not touching your current pricing program and leaving it as-is.
If you’re not going to take advantage of the web, why re-develop it?
Stay tuned for part 4 of this series where I’ll go over getting dealers to adopt your manufacturer pricing program.