Foundations of commerce: Grit before glitz
The race to get a product or service in front of a customer, or the desire for a customer to want or need a product or service has been running for thousands of years.
Around 2700 BC, China mastered the ability to create silk from silkworm protein fibers. Sitting on this monopoly (the emperors of China refused to share the secret of silk production), China traded silk with other countries, creating a luxury “brand.” Demand for silk was so high that it became a catalyst for new trade routes across Central Asia and into Europe, colloquially known as the (original) “Silk Road.” The demand for silk created massive trade routes for all kinds of goods.
Leaked secrets destroyed the silk monopoly, but the trade routes persisted. Over time more and more ways to trade emerged. In fact, today’s multifaceted digital trade routes present products to customers on four or five different devices using apps, social media and chat to name just a few. For all that sophistication, as new digital routes accumulate, the foundational technologies on which they depend become overstretched. They can barely support two trade routes, let alone four.
How have we come so far and yet failed to address the importance of the commerce foundation?
One thing most of us can relate to is a commercial vision. That vision may come down from the C-suite, it may come from an industry thought leader, or it may come from you. The vision is to create a product or service and sell it; along with, creating buzz, a website, developing a multichannel experience for your customers, you have to make it all happen.
Everyone believes in the vision and gets excited. The design team begins working on next-level experiences. AWS instances are spun up. The development team begins working with the product manager who is now responsible for delivering this vision and generating hundreds of JIRA tickets.
Ready to go! Well, not quite.
What we are seeing is a fundamental shift in a couple of areas of IT. Through the 1990’s and into the 2000’s, projects started with core systems like Oracle, SAP or IBM as cornerstones. These systems were used out-of-the-box or modified to solve unique business problems. Although the “Big 3” are still in the game, innovation and technology has evolved and there is a myriad of other solutions. And, point solutions for departments may do a better job than a suite, but here’s what happens:
VP #1 has a job to do, so she brings in platform A, VP #2 has a job to do, so he brings in platform B. Then VP #3… well, you get the picture. Through acquisitions even more technologies are added to the mix. Eventually, there are multiple systems throughout the company, including numerous CRM’s, reporting tools, application stacks, coding practices and standards.
The big mess underneath
It’s easy to point to communication as the culprit, and of course it is, but let’s leave that discussion for another day. Even with disparate systems, “the vision” still must be implemented. But now the implementation strategy has shifted from the top (e.g. UI) to the bottom (core infrastructure). Working with the foundation is harder than working with the UI because the technology dots are simply not connected to provide a consistent customer experience. Customer information is almost always strewn across multiple CRM’s. Customer or partner assets are not centralized. Product data is stored in multiple repositories. Information is all over the place internally, and it’s possible only a few people can make sense of and normalize all this data. The underlying foundational technologies have left a mess.
Now, with a promised “vision” delivery, what do you do?
It is possible to deliver “an” experience even with the current back-end state, but there is very little overall focus on what the impact of that is going to be on the company or, more importantly, the customer. “Tech-debt” is a hot buzzword. At what point should businesses write down this debt? At what expense do we carry it along? Do any of us go back and address it? And if we do, what’s the ROI versus just addressing it from the get-go? Twitter is a great place to read customer complaints and many times I can guess that reluctance to deal with tech-debt ended up with “a” customer experience, but maybe not the “right” one.
So, why do we continue to operate in this way? Are we just falling prey to the perception of growth using new and glitzy technologies for us to tell new stories to customers? Is looking to the glitz before the grit ever worth it?
How to overcome this? Start from the bottom-up
Sure, there are solutions out there like MuleSoft or microservices, that attempt to stitch up a unified architecture so that delivering on the vision is possible. But is that the right thing to do? Even if it is, stitching still involves time which a lot of us do not bake into promised delivery dates. It will take courage, but we need to reverse our promises of delivery in too short a time. We need to make sure the foundation is solid before we start the work up top. Building on a solid foundation will pay off for customers and the company. Customer experiences will be more targeted and more relevant. Those two things alone would increase growth and build corporate reputation.
I recently went through this situation with a scratch build out of a commerce site, but our vision was severely hampered by the current state of our foundation systems. It is difficult to explain to upper management the “why” since most likely they’re business minded and expect the results. They are not interested in the technical challenges of where data may be hidden, or the lack of any API or connector to that data.
The build has progressed tremendously since launch, but what if we had done it right from the beginning and made sure our foundation was poured? We’d be way further ahead.
I’d love to hear your input if this is something you’ve experienced as well. Or maybe I’m the only lucky one…