11. Challenge Accepted. with Boris Lokschin

Piotr Karwatka: [00:00:55] We’re going to talk about how in just five years they built the company from ground up to Gartner magic quarter. Spriker philosophy, or finding the yet unsolved business problems and then solving them with the product. I will ask Boris how they position the product between all existing SAS, PAS, on-prem overrated platforms and microservices.

Hello, Boris, thank you for accepting my invitation!‍

Boris Lokschin: [00:00:59] Hi, thank you for having me. 

Piotr Karwatka: [00:01:01] Please tell us a little bit about yourself and what you did before founding Spriker.

Boris Lokschin: [00:01:06] Yes, sure! It’s my third company, so I always was a founder in the technology commerce space. I founded my first company when I was, 17. We built what you would call today “SAS shopping system”, back then, kind of accidentally. So I started off doing some online marketing work and then it all building websites. And then, trying to participate in local, hometown startup competition where the first prize was a free office space for a year, and they did not want to accept us being a services company. So we needed to have a product. And then we put it into the business plan. Of course there was no product back then. Kind of put all the buzzwords that we got from a large computer trade show, you might remember, called CeBIT. It was actually the largest. So this was in my hometown, Hannover, Germany. Unfortunately they stopped doing it, but when I was a child, a teenager, I always loved going there and you know, I was seeing all these boosters. You know, dreamed of one day dig there as well. So I kind of  put all the buzzwords that I’ve heard, back then into this concept of business plan and we participated. We did not win, but we ended up being second and then people started calling us and asking for what was in this plan as the product, which essentially described software as a service card system, you would maybe call it today. 

Piotr Karwatka: [00:02:43] When was it? Early 2000?

Boris Lokschin: [00:02:46] Yeah, I think it was 2001, 2002... So it was very early on and we just put all the buzzwords, like fast time to market and paying on a monthly basis - not these large, big checks that people used to pay back then. People started calling us and started asking for this magical product. And we really had to admit a couple of calls in the role that there was no such product yet. And have you got a call from a very large electronics retailer here in Germany, and then they asked the magical question after hearing again, that there is no such product, how much money you guys would need to build it? Because what we read about is very interesting - I dropped to the largest number that came to my mind, like them at them and they accepted. So we ended up building it and providing what you would really call today a software as a service kind of a product, which first they scaled was at the retailers network. And then we onboard more and more customers from the outside. And then, 2,5/3 years later we ended up selling this product in an asset deal to them. So they kind of insourced it. They hired a few…  it just became too big for them. At this point I don’t remember the actual numbers but back then if you had 10 million in online revenues, this was considered to be huge, a huge amount. And they were approaching this number. So, I think that the business risk for them, you know, partnering with a bunch of young guys sitting most days at home was a bit too dangerous. I think they were looking for an equity hire, but we did not want to join this corporate, so we kind of sold it, and then we insourced it, and then we partied for two and a half weeks straight in my hometown. Still most of us being under 20… And then we founded the second business, which became the largest SI for Magento basic limitations in Europe and was then acquired by Investec listed company from the U.S. called CGI. 

Piotr Karwatka:  [00:04:58] Yeah, that sounds amazing. You founded the first product company under 20 and then a successful services expert consulting company. And the third one is another product - Spriker. Can you tell us how did this idea with building this product come to you?

Boris Lokschin: [00:05:07]  Yeah, absolutely. So for me personally it started really after the acquisition of my second company. I was with CGI for a couple of years, where the company I brought to the table, we have been 170/180 people, roughly when we have been acquired. They’ve put us together with another a hundred something people that were kind of “left over” from Oracle ATG based five-year program, where CGI built the entire Vodafone commerce, global program and initiative. And then they did some small acquisition in the hybrid space or another Hybris SI, and then they also edited the portfolio, what was back then still Demandware. So we become a 300-400 people division and just 2/3 guys, managing it. And I was one of them, which was a good thing for me because it was the first time I was working for someone. It was... As I always say, I left CGI as a PhD in Business Management and Financial Management in a way it’s good to see how a corporate and it was being managed and scaled. And more importantly, which again led to Spriker, have been a couple of observations that I had made. The first was Magento. We were mostly active in the retail space we were mostly building websites and covers experiences for retail customers, while it was a broader portfolio, it was a more global portfolio. In CGI we build experiences for publishers, for banks, for insurance as manufacturers. So for a much broader spectrum of the market than just retail customers. Second, it of course got me insights into not just a Magento platform, but also, what back then was considered to be the enterprise platforms. So, again, Hybris, Oracle, ATG, Demandware. So it helped a lot and seeing where these platforms made sense and where they did fit.

Piotr Karwatka: [00:06:58] You had pretty broad perspective on the market after working at CGI?

Boris Lokschin: [00:07:02] It was a pretty broad perspective technology-wise, vertical-wise, and also more and more it became obvious that from being on the SI side of things, it became obvious that the time of these giant, expensive, slow, the lytic application, legacy applications coming to an end, we have put thousands of days customizing very simple things where I saw the trend of not only  going beyond desktop more and more, but also applying the agile methodology is that in fact, our consulting practice was teaching and preaching very well back then to customize. But from the tool side, this was not supported at all. So I started playing around with the idea of how I would envision the next generation commerce platform to look like. And this is where I met my co-founders, where I met Alex who was also a  entrepreneur, he has founded a number of very large businesses from consulting to e-commerce in Germany, where I met Fabio, who was our founding CTO, who came over from internet, where he was responsible for building the cylinder experience, the rocket canvas platform. Did the same with his project A and we kind of put all these perspectives together and it was very, very congruent in a way that we saw the market moving in the same direction. And then we started Spriker back then.

Piotr Karwatka: [00:08:20] That’s awesome. So you put together all the experience you guys had, the great team, and started building the product. I was wondering how you’ve set the goals... Because when we started Divante together with Tom 12 years ago, it was after reading the “Getting Real” book by 37 signals. Classical book on starting a new venture. And they are giving this example that with BaseCamp they were aiming at MS Project. They were chasing like actually they were not chasing MS Project, but actually creating “Anti MS Project” - something completely different. Have you guys also had this kind of approach, like separating from your biggest competitor in a completely different way, like contending them or chasing after?

Boris Lokschin: [00:09:15] Yeah, it looks so. I think the good thing and luckily it’s still true for practice that we’re not spending with our competitors. In fact, people anticipate as, or perceived that we were spending much more time than we actually do. Of course we are aware of who is doing what and I think this is the usual homework that you should do, but we really try to focus on what we believe in and  talking to customers, talking to partners a lot. So when we started, the idea was very simple. We really wanted to build a, what you call, the productized digital best practice. So if you and I, and a bunch of smart people in digital consultance and developers, if we would all be locked in one room, so this is what you said back then you would go to a whiteboard asking if we would build, let’s say a Zalando-like business again. What would it look like from a team setup, what tools would we want to have? How does the platform have to look like, what methodologies would be used? And if we put it all together in an... like a product comes out, so this is what you build, right? We believed very strongly in that. Ultimately of course, this is the company to be the next global commerce technology leading company, right? Pretty much like there was Intershop in the beginning, in the first cycle. And it only wasn’t Magento, there was the Hybris and the SAS space, there was Demandware... Every five years or six years, because of technology waves and cycles, you would have a new category of platform that is defining the next five to six years. So this is what we, of course, from a business perspective, believed in and pitched to investors saying: look, the time of giant political application is over. Just building a shop system like Magento is over, so now it’s about to enable much more than the retail customer, so what we call today’s vision to enable transactional business models beyond retail, beyond desktop, beyond pure e-commerce to be basically the commerce operating system or the backbone of transactional business models worldwide. And so there was a vision, but it didn’t start from the competition, it was rather: “let’s put all the best practices and productize them in a way”. And then hopefully something of value will come out of it. In fact, it wasn’t the early days when we did this pitch to customers, it was a hard time because the first two years, when there was not really a demo, the product was very raw, not mature enough yet. It was very, very hard because the pitch was basically exactly what I just said. It was a lot of market education, a lot of “What is it that we can learn from the best?”. How to apply, how to deploy? Why is modularity important? Why is this decouple needed? This is a hard pitch if you do this in a non-functional way, if you don’t pitch features, but approach. At some point you either have luck and the market turns in your direction and you kind of become the thought leader who always have set things will become this way. Or it doesn’t and then you’re out of business, right? So it were very tough two years, very tough.

Piotr Karwatka: [00:12:18] I can imagine. So, as you said, this core value proposition, this USP was actually that you were implementing with this product a set of best practices, that other agencies, clients, CTOs were actually looking for, right? That’s how you see this from the perspective? That was the first USP?

Boris Lokschin: [00:12:44] Back then it was very tech focused. So we were talking to the IT departments, we were talking to developers, to CTOs. Many of them have been upset about moderating applications, for example. So we gave them modularity. Many of them have been upset about not having a decoupled systems of front-end and back-end, right? So we gave them a decoupled system. Many of them have been disillusioned about not having the right habits in place. So we gave them a system which comes without cash, which would be lightning fast. Many loved the cleanliness and architecture they knew from the Java world, but haven’t seen this being implemented in the PHP world. So Magento was kind of the most complex PHP business application people knew. You remember it yourself, it was not the best architecture on earth. So we tried to give them clean code, solid principles and good tooling. So this was the very first, and was that achieved this agility, you know. The learnings that you collected in the company building startup world. We believe strongly that if developers could produce the same outcome in, let’s say half the time, twice as fast, this would be a huge value proposition, you know?

Piotr Karwatka: [00:13:57] Of course, that makes perfect sense. I first heard of Spriker around 2016, I guess. It was at the Magento conference by the way, and the guys were discussing this architecture you had, so this Zed back-end and Eve’s, front-end. Actually it was a headless approach before it used to be so popular as today. Why was it so important for you to have headless? I always like to ask this question.

Boris Lokschin: [00:14:34] I mean, it was very, very fun, because you know, nowadays a lot of people claim to be the ones who invented this term, et cetera. So I don’t really care about who invented this. I really care about who really brought it to the market first. I remember when we first had it, no one had it. So, I think this can be looked up on Github quite easily. But for us it was really about performance and about again, decoupling teams and enabling teams to be fast. So we learned with Magento the front-end system was still containing business logic, was still not independently deployable. You know, it was still heavy, it was still not fast. You know, we always saw caching, varnish caching as a kind of anti-pattern you could say, because as the word says “caching” means you know, if you’re thinking about the French word where it comes from, it means hiding, right? So it means you’re hiding away a slow application, performance hygiene. 

Piotr Karwatka: [00:] Hiding the problems from the user.

Boris Lokschin: [00:] Exactly! And we did not want to hide the problems. We just wanted to make the application fast. So we made the application in terms of... it was modular. You just had the code that you needed. We put all the personalized data into a key value storage and the front-end sale was very lean, very stupid, not having business logic. It was easy for pure, even junior front-end developers to customize to. So you could achieve the separation of teams who could achieve higher velocity in terms of how they worked. So these were the main principles, it was not that much in the first phase. In the first 1/2 years about enabling multiple touchpoints and devices. This came later when we figured out that, of course, no mobile tablets, fablets are a thing. And hey, we already have the APIs. We already have our back-end system talking to the front-end system. So okay, it’s an easy step for us to enable experiences and other touch points. But in the first phase, it was about performance, about agility… less anti-patterns.

Piotr Karwatka: [00:16:31] That makes perfect sense. And I must say that I love the way you guys are very pragmatic and what you already said is exactly about this. So this headless approach was just because you needed performance, you needed just separation of concerns, not another buzzword. And then it was like 2018 or 2017 maybe. I read, Alex Graphs, your co-founder, blog post called “Microservices and monocycling”, saying more or less that microservices are overrated. Of course you need to have service oriented architecture, but the monolithic microservices are overrated. Is this how you see this, this another 10 microservices.

Boris Lokschin: [00:17:14] Yeah, I think this is a very interesting topic to talk about. So in general, I think we are still, still having the same view. I think, let me start from, from, from the beginning. So first of all, I think that everyone agrees nowadays that monolithic applications are not the best practice anymore. Okay. So I think this is like, checked. Okay. So now, you know, there, there are a lot of people out there in the market, especially the commerce market to try to convince the market that, you know, the only solution not having a monolithic application is going microservices, which is absolutely not true. Right. In fact, it’s even, you know, wrong. And maybe even you could say a bit dangerous, you know, telling the market, you know, that this is kind of the only approach. Why? Because. I mean, and you have consulted, I would say hundreds, hundreds of customers worldwide. I would, I would say, right. So did I, and so did many of others hopefully listen to this podcast. And I would say, you know, for my 17 years now in commerce, I’ve maybe met three to five companies in total that can master microservice architecture. Well, by master I mean get all the advantages. And not the disadvantages, 99.9% of the market can’t even operate a monolithic application well, like in terms of deploying, man, she goes, you’re a dollar times slicing the team. So getting the performance in place, and now you give them a much more complex, very technical kind of things where you’ve distributed across hundreds of small modules, different versions of API’s. Companies would collect, the wides in terms of teams. So they would not have the necessary amount of product owners in place. Architects will not be able to manage contracts well enough. DevOps is a thing. So they end up having no monolyth anymore, but much more problems. Instead, right. And no, not the upsides.

Piotr Karwatka: [00:19:08] Yes, I see. I see the same, that the DevOps problems with the microservices for example is becoming very, very important... I mean, the maintenance costs and the total cost of ownership is getting higher and higher because you have just a huge, huge complexity, you know?

Boris Lokschin: [00:19:29] Yeah, absolutely. So the way we will always. And maybe to add to it. It’s also a very technical way of thinking because business users, and this is important, do not think in modules, I did not think it versions of modules. I did not want to deal with the complexity of managing dependencies with contracts, et cetera, between them. So what they think, so the category they’re thinking is capabilities, right? So let’s think about when they come to us, they are like, Boris, I need your PIM or I don’t need your PIM because I have my own practice. I will not use your CMS. I don’t want to use the CMS. I want to use your search. I don’t want to use the search boards. I have my dedicated pricing service because our pricing logic is complex. You know, I just want your system to consume this pricing via an API. So. you know, we call this capability and Gardner refers to it as packaged business capabilities. I think, you know, in this composable enterprise kind of world that we are in, I think, you know. Us Following the PBC approach is, is, something that is, you know, much closer to our hearts. And it’s really reflecting reflected in our architecutre where, you know, you talk about business capabilities. They are completely independent coming with their own data, excess layers, API APIs, et cetera. You know, and the user does not have to care about it. How many modules underneath the capability itself, this is implemented. Right. And I think this is the kind of in-between. If you have on the law, in the left corner, you have the model modeling, which is, you know, complex to manage. and then on the upper right corner, you have the, the microservice architecture thinking between is the PBC thing. And this is something we are doing. I think this is the right approach. We are getting very good feedback from users and from customers. So again don’t get me wrong. I think every once in a while, and in many use cases, you will have the need to build maybe a dedicated service or two or three or four. So there’s nothing bad about encapsulating things to services provided via API, but just do it. The black and white managers do microservice because they don’t want them all it, I think it’s not the right approach and giving a standard average customer, you know, hundreds of services instead of one big complication is, will most likely not lead to. Better TCO or will not lead to better operational costs, but rather give them a lot of downsides and upsides. Of course, I even, I am even up to the, conclusion that the microservices should be, should be the capital and such granular as your team structure is so. If you have two teams, you can probably maintain two services and it’s good to have it separated because they can work on their own pace. But live, you have one single team and 20 microservices, the burden of maintenance is very high. And this is the reality, I think, you know that we are seeing companies struggle. So I think, you know, nowadays we are all happy that. Customer like digital maturity on customer side rises. So more and more people I get are being hired to know that they’re building their own teams. They’re finding good setups to work with SIS, but still, you know, how many customers do you know, who would have like 15, 20 teams all nicely verticalized and synchronized with each other. This is not the reality if you had Zalando-like business, right? If you’re able to now. Then of course, right. But I think the average kind of media and the customer and the market is definitely not there yet.

Piotr Karwatka: [00:22:49] Single digit number of cases I saw like this low lows, low single digit numbers.

Boris Lokschin: We at Spryker follow this package business capability based approach. We say it’s the right level of, you know, to talk to customers is the right level of implementation and the architecture and everything else customers expect just to work. You know, they don’t want to talk versions modules, dependencies. We have to manage it. If we are managing. You know, behind, behind the actual capability for them. It makes perfect sense.

Piotr Karwatka: So how do you position Spriker over the path, SAS on-premise platforms, or maybe the distribution model is secondary to your business?

Boris Lokschin: [00:23:29] It’s not. I mean, it’s a past solution, so I think this is important. It’s another semi-philosophical kind of a discussion. I think it’s pretty much like does this PBC instead of, microservices it’s for us PAS vs SAS. We are big believers in, you know, allowing much more, customization and allowing much more differentiations for customization. As you would typically do in a, in a normal sauce wireman where you need to achieve certain economies of scale. And the reason is, you know, the more, you know, the more mature a vertical is. So let’s say fashion for example. It’s a very mature digital when it comes to digital commerce, a very mature vertical. And you could also say maybe in a negative way for like, from a technology perspective, from technology’s perspective window, it’s very commoditized, right?

Piotr Karwatka: [00:24:15] And they are not early adopters.

Boris Lokschin: [00:24:18] Yeah, exactly. So the higher the maturity the more commoditized this vertical is the easier it is to have assumption and functionality, and the less castle will naturally want to change in terms of business functionality, the business logic, right? This is kind of the trajectory where SAS becomes a good value proposition because you can give them a Shopify like, make sense or something like experience. Customers can innovate on top of that builder use experience led to set for us, as I said, we try to build a transactional or to enable transactional business models beyond retail and beyond desktop and beyond e-commerce. When I think about all these verticals, our customers operate in the multi-trillion dollar industry, combined verticals, such as food, such as, marketplaces, such as manufacturer services, sports clubs, airlines, automotive. So all these verticals that are just on the rise and just start to build, not e-commerce responsive websites, but to build

transactional business models, services models, subscription models, they are by definition

non-commodity, they are by definition, more complex and by definition you have to build in, get deeper into the business logic. I can’t go to  a food and beverages international plan, give them a current API that just allows to add to cart, remove from cart, change quantity in cart. This doesn’t work this way. They have much more sophisticated requirements. So I think this is where you draw the line. And again I understand that there is a market for commodity type to enable commodity type business models. And there are some players who do provide SAS applications, which is totally fine. Also some of our competitors are more in that. I always call it more mature Shopify kind of space, which is absolutely fine. But you know, for the space we are in and the verticals we do focus on, I think path is the right way to go. So this is why it’s practice PAS, not SAS. It’s picking up capabilities, not microservices and it’s API based and headless.

(...)