It’s holiday time again — high time for retail app crashes


It’s that time of year again: Time for enterprise web apps to crash, crater and crumble at the worst possible time — just as customers swarm in an attempt to shower a company with cash.

Black Friday and the few weeks that follow are hugely important for retailers everywhere, the period when organizations will reap up to a third of their annual sales totals.

And yet, we see so many retail sites go down during the holiday period? It seems to happen every year. Why? Spoiler alert: Because too many companies fail to pressure-test their systems before the money hits the fan.

Either they haven’t conducted sufficient tests to ensure that their systems can accommodate demand that can be 100x usual. Or they haven’t sufficiently tested compatibility with third-party dependencies, such as payment or inventory systems. Or they haven’t ensured compatibility between new apps and Point-of-Sale (POS) applications for service clerks.

If your development teams are not using Service Virtualization to test from the outset of development, your company might be next, because your system might not have been tested in every way possible.

Here are three questions companies should be asking before plunging headlong into the critical holiday period:

  1. Is your Order Management System (OMS) ready for the volume and type of traffic it’s likely to get during the holidays? That question goes beyond just ensuring servers can handle a massive volume of traffic. Instead of making estimates, you could be using Service Virtualization to capture the performance profile of underlying systems (inventory, delivery, payment, etc.) on an actual business day — the busiest day of the year. That way, you could account both for volume and a range of response times or timeouts from those systems. Remember: It’s often not your system but the performance of dependencies that causes you to fail. Be sure you’re ready.
  2. Are you ready for curveballs from third-party dependencies? Let’s say your app is dependent on a major credit card company to process payments. What if that company rolls out a major upgrade? How will you ensure compatibility before D-Day so your app can serve the customer effectively? Instead of waiting for a finished test environment, that credit card company could have delivered a Virtual Service based on all the known requirements and API changes, so your team could test months ahead of deployment.
  3. Do you understand your own system’s performance level? In the e-commerce realm response time is among the most important factors in determining whether a customer spends his money with you or the competition. You need to be sure you understand your site’s performance and, just as importantly, how to improve it. Since conventional performance testing happens from an end-user interface perspective, it can only tell us that something is wrong somewhere — not where the problem is in the composite application or how we can solve it. Most of the business logic, and thus your ability to improve an app, is played out in machine-to-machine transactions. Instead of waiting until just prior to production to validate and tune performance, you could be using SV to simulate machine-to-machine transactions and get a jump on improvements — or even make performance-enhancing choices in design.

Come Black Friday, customers will have no mercy. The ability to innovate and deliver new business capabilities for customers via IT is no longer just a perk for most companies—it is the differentiator.

If your team isn’t using SV in its development process — to confirm critical compatibilities and performance values — you’re most likely flying blind into the holiday season. Good luck with that. If you’re lucky enough to emerge unscathed, maybe consider making SV one of your New Year’s resolutions for 2017.