What the heck is SKOBS? SKOBS stands for: Some Kind Of Back end Systems.

I came up with the term in a pitch with a client that had an awful lot of back end systems. and since he always had troubles to integrate with new software I wanted to make clear, that the system we developed at CouchCommerce.com do not care about the back end systems a lot. For our platform it’s just important that we get the data we need from somewhere. Why did we go for that approach? The folks behind the platform made a lot of ecommerce projects and therefore know a lot about the pain of integrating with back ends. So one idea of the platform was that it needed an outstanding independence from the back end systems to create an abstraction layer that is able to do all kind of things. That approach has two major advantages. We can act fast and work with data that already exists. And the front end can stay the same even if the customer changes the back end systems down the road.

Unfortunately I didn’t create that acronym on my own… there is already a rapper by that name and also a football team. But at least I guess I’m the first to use the term in the ecommerce sphere – so I claim the credits for that 🙂

But why do back ends not matter any more???

Ok, I must admit that this is a bit provocative… and only the half truth. Sure, you’ll always need back end systems to do all the order/PIM/logistics/CRM/whatever process stuff. But for the end customer the back end systems simply don’t matter at all.

And this touches one of the major problems of merchants today. I participated in a lot of projects and met merchants over and over again that live within the limits of their back end systems. Integrations take long, features don’t work, data is not available – I heard it a thousand times. All of this thinking is thought from the inside perspective. To take a simple example: if you want to display the availability of a certain product in a specific store to the customer (assuming he likes the idea of knowing that he is entering the store for good reason) in most cases today you will get the answer that the ERP system is not able to deliver data in real time. So what? An internal back end problem is transferred into a customer facing problem. Ultimately the customer will head to a merchant that offers the desired service.

What the modern merchant needs is the outside view – the customer centric view. What is it that my customers / target customers really want? And what’s the best way to deliver that fast?

If you go that way the old back end hassle doesn’t matter any more (or at least it matters only later in the process where it simply needs to be solved). The customer facing layer becomes the most important focus. And that’s true for everything customer facing. Web, mobile, in store, crm – everything needs to be unified for the best customer experience.

The old software world with monolith system structures that are a pain to interconnect was a big leap forward to make the digital life possible. But due to the way it works, all above channels of today were added one after the other. With new integrations each time and sometimes even complete new system components and other technology stacks. So the back ends grew from something small to quite monsterous structures. But you can not move fast enough with that. That’s one of the main reasons why the merchants of the old analogue shopping world are under immense pressure from the competing pure players (take a look at my last post about the major changes of the last decades). The pure players have the huge advantage of no or only small legacy back ends. Therefore they are much faster in implementing new ideas.

The retail merchants need to innovate – simply to survive in the long run. If it’s not the pure players that will eat their lunch, it will be the high street competitor next door. The one who understands the customer centric view and is willing to take the challenge – and really serves the end customer.