Technical Debt in Ecommerce
In a recent Forbes article, Dr. Setrag Khoshafian discussed technical debt as one of the biggest obstacles to digital transformation. “Technical debt” is the long-term cost an organization incurs from bad IT decisions. It refers to the fact that choosing an easy solution now may cost more in the long run.
At Corevist, we’ve seen all kinds of technical debt over the years. Many of our clients come to us with legacy SAP ecommerce solutions that are bleeding them dry. They’re living the pain of technical debt every day.
How can CIOs and IT Directors make intelligent ecommerce choices now that reduce or eliminate technical debt? In this article, we’ll give you 3 questions you can use to evaluate potential ecommerce solutions from the perspective of technical debt.
1. Does the solution require you to maintain integrations on your own?
Since all your business data lives in SAP, you need a real-time integration that loads SAP data right in your ecommerce store. This matters because accurate SAP data directly impacts your customer experience. If your customer can’t get “true truth” from SAP in the web store, they’ll have to call Customer Service, which defeats one of the primary purposes for launching ecommerce.
Here’s the data which any potential ecommerce solution should load in real time:
- Inventory availability
- Available to promise (ATP) calculation, if applicable
- Scaled pricing discounts
- Shopping cart errors (SKU retired, no permission to order SKU, etc.)
- Account problems (over credit limit)
How to avoid creating technical debt in your SAP integration
Simply put, don’t plan on maintaining your SAP integration in-house. Unless you already have resources on hand who 1) have the necessary skills, and 2) don’t already have too much work, the burden of maintaining the solution will grow and grow as time goes on. This is especially true of “homegrown” solutions.
When it comes to integration, don’t reinvent the wheel. Choose a trusted partner with a demonstrated history of expertise in SAP-integrated ecommerce.
2. Does the solution rely on duplicating SAP business rules in another platform?
If you don’t have the resources on hand to maintain a real-time integration in-house, the next-easiest solution seems to be batch synchronization for all data sharing. In other words, rather than sharing data between ecommerce and SAP in real time (via web services), you might be tempted to build a solution that depends on timed uploads from ecommerce to SAP (and vice versa) for everything you need to pull from SAP.
Here’s the problem. While batch synchronization works for data with a low refresh rate (like mapping SAP sold-tos to ecommerce users), it doesn’t work for data with a high refresh rate (like scaled pricing, which depends on quantity in the user’s cart and negotiated contract pricing). When you don’t take this information in real time from SAP, you have to rebuild all that logic in your middleware and your ecommerce store.
Now you have 3 platforms that you have to maintain. The longer you run these 3 platforms, tracking down bugs, updating code, and so on, the greater your technical debt becomes.
How to avoid creating technical debt from business rules duplication
You’ve already invested in SAP as the system of record for that kind of data. All your business rules live in SAP. Rather than duplicating all those business rules (and thereby introducing the technical debt of keeping 3 platforms playing nice together), you should honor your existing investment in SAP and not rebuild all that complexity.
In the case of ecommerce, that means choosing a vendor with a real-time integration to SAP. (Hint: That’s Corevist Commerce.) This kind of solution provides a window into your SAP system rather than duplicating all that complexity and cost in 2 other platforms.
3. Does the solution require in-house FTEs to keep it up and running?
As Uncle Ben once told Spiderman, “With great power comes great responsibility.” This principle is especially true in enterprise IT. The more you own and control your systems, the greater your capacity for screwing things up.
The right answer here will look different for different companies. However, as a general rule for B2B manufacturers, it’s risky to rely on in-house FTEs to build and maintain an ecommerce solution.
Why? Because this arrangement doesn’t take advantage of economies of scale. It requires your FTEs to learn the ins and outs of SAP-integrated ecommerce through trial and error. Because the market offers vendors who have already learned the ins and outs through hundreds of client implementations, it’s simply not a good use of resources to reinvent the wheel in-house. Trust us—we’ve seen it fail countless times.
How to avoid creating in-house technical debt
Ecommerce technology has now reached the point of commodification. You can avoid ecommerce technical debt by choosing a solution that’s ready to go out of the box, generally requires no in-house FTEs to maintain, is tailored to your needs in 90 days, and receives quarterly updates to stay ahead of the curve. (Hint: That’s Corevist Commerce!)
Simply put, it’s cheaper to outsource your ecommerce solution, maintenance, and continuous improvement to a trusted partner who knows your needs, knows the technology, and owns the stack from top to bottom.
Moving forward: FREE case study
Wondering how this looks in real life? Download this case study on LORD Corporation. You’ll learn how LORD eliminated technical debt by retiring their old ecommerce solution and launching Corevist Commerce. LORD gained a scalable, cloud-based solution that’s updated regularly. By eliminating their dependence on their old ecommerce solution, they also gained the ability to upgrade their SAP ERP system.