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
. 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.
Ready to go! Well, not quite.
What we are seeing is a fundamental shift in a couple of areas of IT. Through the
and into the
, 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
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
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
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.