Decoded: Our New Composable World

Phillip: [00:00:02] Welcome to Decoded a podcast by FutureCommerce, presented by Spryker. The unsung hero in digital commerce today isthe eCommerce developer. Once upon a time, IT departments held the keys to[00:00:20] the kingdom when it came to buying software and deploying it into anorganization. But then big platforms and digital experience ecosystems came inand they made it easy for an enterprise to buy loads of integrated softwarewithout the need for a developer. The downside? Well, a lot of mediocresoftware [00:00:40] that isn't good for anybody but is imposed on everybody.Developers used to be the key focus of marketing and sales initiatives for theenterprise. And today, marketers and vendor procurement often make decisionsfor eCommerce that are based on what competitors are doing. This podcast willaddress the chasm [00:01:00] between the developer and the marketer. Whilespeaking through current events, ecosystem threats, tech trends, and platformwars. And finally, we're going to build a bridge between the two: Marketer anddeveloper. I'm Phillip.

Boris: [00:01:17] I'm Boris, Co-Founder, and CEO ofSpryker. [00:01:20]

Phillip: [00:01:21] And this is Decoded. Imagine, if youwill, a symphony orchestra. An orchestra is made up of diverse parts comingtogether as a whole. People from all walks of [00:01:40] life with unique livedexperiences. The symphony is an organism. It's practically alive. Players comeand go. People, they grow old and they retire. Newcomers audition and theybecome understudies. But the organization endures. [00:02:00] An orchestraexists in discrete parts to eventually come together in concert. It's thiscomposable structure that allows for durability. It allows an orchestra toendure. On today's episode of Decoded will be [00:02:20] demystifyingcomposable commerce. We'll dig into the way that things were and how softwareis changing. And we'll examine more modern business structures and what they'redoing to modernize their stack, building piece by piece. And finally, we'll askthe question, "Exactly who should [00:02:40] be the conductor?" Iwonder if this is just a natural evolution of eCommerce becoming no [00:03:00]longer just a channel for incremental growth that sits underneath IT ormarketing, but an independent channel which has its own PnL, it has its owncategory division leaders. It has its own means of operation that standsseparate and apart from  [00:03:20]IT,physical brick and mortar, traditional marketing, or brand marketing. It hasbecome its own thing in its own discipline. And because it's its owndiscipline, it deserves its own operational model, and that means its owntechnology affordances for that operational [00:03:40] model to be more agile.

Boris: [00:03:42] Yeah, I think, maybe the closest roleto be capable or enabled to do this would be someone in product management.

Phillip: [00:03:57] Yeah. It's product management mindset.

Boris: [00:03:58] Actually very [00:04:00] close toproduct management mindset, right? If I think about like how a product managerworks for us, obviously it's very much the same. We're looking at our packagedbusiness capabilities, right? So we have kind of a composable commerce orinfrastructure within our own product, so to say, with individual completelydecoupled PPCs that [00:04:20] have their own agenda and roadmaps and KPIs,etc... But on top of that, we do have product managers who understand thesubject matter and have expertise for these PPCs. But of course, there is alsoa wider portfolio in product management on top of that to think through howthese things eventually fit together, what might be [00:04:40] the right usecases, the right technologies. There's architecture, roadmap and governance. Sothis now in a similar motion in a broad to a business, I think this isimportant. And this goes back to what we discussed before. I think at the endof the day, it's now companies understand that technology is an asset[00:05:00] and that the main asset is the platform that they own. It's not thephysical product they sell anymore and the differentiation sits within thisasset. So now pretty much like we as a software vendor, need to evolve andprotect and manage our assets by having product managers who would get all the  [00:05:20]feedback and steer the direction ofthis asset. So now the question is if this monolith if it breaks up, what is itthat you then have at the end? Do you have a collection of applications orapps? And how do you basically glue them together at the end of the day? And Ithink this is what the composable enterprise or composable commerce [00:05:40]terminology tries to frame saying, look, there are advantages of being the bestof breed and the best of suite kind of world. You can now select the bestsearch that fits the best for your business. And your business might be verydifferent from someone else's business. You might be selling fashion andsomeone else might be selling industrial [00:06:00] spare parts and someoneelse is selling books and or a travel or hospitality business. No one arguesthat you cannot train one search in a generic way on all these four or fivedifferent business models. So you want to select the best search for yourbusiness and someone else would want to select the best  [00:06:20]product information catalog.

Phillip: [00:06:21] I think it's an interesting reframebecause the way I've heard composable used was more it wasn't so much focused,I don't think on the customer experience end of search as something a customer interactswith to fulfill a desire [00:06:40]. In that case, the argument you're makingfor the terminology, is it actually, rather than being something new, itdescribes the ecosystem that we are building already because there are best ofbreed pieces of technology that have domain [00:07:00] expertise.

Boris: [00:07:01] Correct.

Phillip: [00:07:02] That have already become de factowinners in the marketplace in ratings and reviews, product gallery,user-generated content. These are all things that seem to have. For the mostpart, created the standard on which we're all [00:07:20] building some sort oflike a repeatable commerce language. But there's more to it than that.

Boris: [00:07:26] This is what ultimately leads tocomposable enterprise, to the notion of composable enterprise, to have theability of whatever you call it, again, about bullshit, right? So microservicesor microservices or packaged business capabilities. So let's just agree onmodularity, on decoupled [00:07:40] capabilities glued together, but it alsocomes with downsides. That's the problem, right? So composable enterprise isnice, but think back about the arguments that I had when I just starteddescribing it. In this world, you now end up having multiple relationships withdifferent vendors. You have all these APIs. Everyone is headless, everyone isAPI first, [00:08:00] wonderful, makes a lot of sense. Now you need to gluethem together. You need to connect them, integrate them. You end up havinginconsistent, potentially inconsistent SLAs. You have no one vendor anymore whoyou can squeeze and have leverage on because they try to upsell you the nextfeature, right? So you now have to have contractual relationships with[00:08:20] 15 to 20 different vendors to orchestrate your composable commercelandscape. So there are also challenges to it, right? So there should be noillusion about it just being shiny and good, right? So you need to it alwayscomes with pros and cons. You [00:08:40] can't just turn on or off composablecommerce. So you need to have the underlying infrastructure, all the bits andpieces need to, of course, they need to be in the cloud. They need to haveAPIs, they need to be interconnected. So [00:09:00] there are requirements interms of architecture to it. But I always like to think it back from the user,from the business. And for the business, it's pretty much what I said. So youwant to have the choice. It doesn't mean that you cannot buy two or three ofthese capabilities from one vendor. Maybe someone is excelling in all threedisciplines. [00:09:20] But you don't want to have this technical lock in. Youwant to have what is called business agility. You want to be you want to havethe ability to, you know, maybe search, maybe the technology or tech stack youuse to power your search is intentionally a very different one from the mainstack that your PIM is written [00:09:40] on and from the one that you knowpowers your logistics network or integration. So you want to deploy the bestdevelopers who are skilled in technology A, where their technology expertisematters, and not be kind of stuck in one stack, trying to use one programinglanguage or one technology stack [00:10:00] for every discipline, even thoughit doesn't make any sense.

Phillip: [00:10:02] I want to think through the enterpriselens for a moment because the enterprise tends to suffer from the complexity ofmany vendors to balance and many business cases and use cases to have toimplement. If we think about that, how [00:10:20] often are developers who areresponsible to implement and IT professionals responsible to implement thetechnology consulted in the decision making around, say, a monolith stack asopposed to the marketers or the [00:10:40]category leaders who are creating RFPs that are really basedaround feature and functionality and contracting terms? I'm curious ifcomposable helps us to avoid the pitfalls of choosing platforms that nobody atthe end of the day is very happy with.

Boris: [00:10:59] In B2B the [00:11:00] buyer of the useris almost never the user of the product. So in B2C, everything is simple. Sothe buyer of the product is the user of the product. In the B2C world, you arevoting with the most honest thing that you have, which is your wallet. So do Ibuy [00:11:20] the iPhone or the Samsung phone because you will be the user ofthis phone, right? In B2B, buying, B2B, especially enterprise software, theuser, the future user of the product is never the buyer of the product. Youwill have a sales cycle of 6 to 9 months. You will talk to everyone in thisprocess, but not the actual user in the end. It will be procurement. They willbe business decision makers, [00:11:40] they will be fine and they will belegal people. Everyone will be involved. And ultimately, in the old days, whenit's in the sweet times, the product will be put on the table of the marketeeror the category manager to do something. And here, this is the product we haveselected for you based on whatever you know, bullshit criteria and RFP matrixesand etc., etc... Right. Just [00:12:00] because we feel safe enough and youknow, the cover our asses strategy worked out well. People would say,businesses would say, hey, I want to focus on my core business and this is whyI need an agency or someone else to do the web and technology stuff for me. Sopeople try to outsource it, which created [00:12:20] a large ecosystem ofagencies in return. So now I think nowadays everyone understands, due to thesuccess of the Amazons of this world, that technology is basically the asset,the platforms that we are building or that are being built are the onlydifferentiator... It's not the product in the warehouse, not the [00:12:40]sneakers that you have in the warehouse because your competitors have the samesneakers. So if you don't want to compete on price, you compete on the actualasset, on the experience that you build, on the technical sophistication on howgood your search is, how many payment methods you have, how fast you deliver,how good your loyalty program works, how good your mobile native appexperiences, [00:13:00] etc., how fast the website is, which at the end of theday, if you drill, drill into it, it's all technology. And this is whytechnology ownership is a thing. Now the developer is important because thedeveloper experience, the DX, determines the business agility and businessvelocity. If the developer experiences shit, if [00:13:20] the developerdoesn't like, it's not good and not productive, he can execute on the businesspeople's roadmap. He can't iterate fast, he can't deliver things in a week ortwo sprints. He can't launch new countries, new ideas, new address, new courseof users, build new interfaces for new hardware devices that Apple justreleased. He can't do it. [00:13:40] And this is why I think at the end of theday now, the developer really and the developer experience in the composableworld where you now can have these five, six, seven different people focusingon different stacks, where people now try to optimize their developer experienceand if not let them be part of the selection process, then maybe even run theselection process.  [00:14:00]

Phillip: [00:14:00] Correct. Right.

Boris: [00:14:00] Because the task is, "Hey,Phillip, you know the digital roadmap we have. So now please select the besttool." Pretty much like you would never go to the construction place andtell the guys who are building the house what hammer to use. Right? You tellthem you want to build the house and they select the best, most effective tool theyneed for [00:14:20] that. And I think this is exactly happening now intechnology.

Phillip: [00:14:26] The ultimate goal for any business isto create an enduring legacy. But today, businesses are faced with bothinternal and external challenges from keeping up with the Joneses to living upto the expectations [00:14:40] set by the likes of Amazon. So what exactly thenis composable commerce? Well, for one, it means that you don't have to buy intolarge ecosystems to grow your business. But it also means being intentionalabout the kind of business you're building. This is not always the easiest way.[00:15:00] When the orchestra comes together, it's magic. But a single playerplaying out of tune can throw the whole performance off. A violin, a harp, anda piano. They're all stringed instruments, but their roles couldn't be moredifferent. The [00:15:20] same is with a developer in the enterprise. Thedeveloper may sit in different profit centers, from marketing to ops to IT.They might be UX focused or integration focused or in data analysis. I mean, adeveloper may not even write code. They might be in business analysis orM&A. [00:15:40] So when it comes to the enterprise, it's crucial that weunderstand the role that each software plays and how it impacts the largerwhole. The days of off-the-shelf best-fit average software are giving way tobest-in-class virtuosic players. There's [00:16:00] a concept in psychologywhere it takes a fairly trivial amount of change before humans notice thechange. Somewhere between... I'm speaking off the cuff here, but somewherebetween like 15 to 20% of a change is [00:16:20] noticeable. It's smallerchanges than that that tend to go unnoticed. You can create large evolutionaryshifts over time if you make smaller changes in smaller increments. And this issomething I've been preaching for so many years. The way that we implementsoftware is so aged and the way that software was built in prior [00:16:40]eras required this full-scale rip and replace. The greatest example of this, bythe way, was the backlash that Facebook faced ten years ago when they changedto a timeline rather than the old style system of posts. And this timeline[00:17:00] change, everybody hated it at the beginning because it was a massiveshift and a retraining of the consumers of the platform. Facebook hasn't made amassive design or change update ever since, but it looks nothing like it usedto. In fact, it's even if you're like me and you haven't logged into Facebookin two years, [00:17:20] when you log in, you're shocked. We need to get betterat becoming composable. How does an organization, aside from okay well now youneed new sets of technology that allow for composability. How does anorganization shift to composable? Is that more of a mindset and an operationsmodel than it is a technology [00:17:40] capabilities model? Is there areCertified B label for composable commerce out there?

Boris: [00:17:46] Unfortunately not. I would wish therewould be and there would be, you know, dedicated training, etc... But I thinkagain, fundamentally, it's about what does composable commerce enterprise, whatis enabled by that? And I think, from [00:18:00] a business perspective, if youhave the ability... So let's make a very simple case. So you are VP of Digital,VP Commerce, within, let's say, a CPG company. Getting access or unlockingbudgets, and showing success basically in [00:18:20] a fast and iterative wayis much simpler than go and pitch the entire transformation of the business,including the underlying full technology stack. So go there and say,"Look, let me prove that when we improve the speed of  [00:18:40]the content editors creating newstories or coming up with new content, we'll have a conversion impact on us.Let me show you that if we have a new modern commerce stack, we can build themarketing features and the discounts and promotions that these departments are[00:19:00] asking for much faster, which will have an impact on conversionrates again. I think this is what is being enabled, this business agility thenleads to companies having success or not. If not, then you can take it behindthe bar and shoot it if it was a new idea, but in many cases, it does give you[00:19:20] the ability to experiment and to fail and or to be successful, whichagain in return unlocks more budgets and unlocks more approvals, gives you moreaccess to more resources, and it helps to transform or digitally transform thebusiness. And so I think about it more as an enabler of business agility.[00:19:40] I think this is maybe the best term to describe it. And there issome technical preconditions and there is some implications. Which wediscussed. And some risks and some price tags attached to it. Butfundamentally, it is about enabling the business to be faster, to be moreagile, and to be more responsive to the best of breed selections. [00:20:00]And I think there are still unfortunately way too many legacy managers in theorganizations. But the good news is time will eventually take care of thisproblem.

Phillip: [00:20:14] As it does with most problems.

Boris: [00:20:16] As it does with most problems. Exactly.And because [00:20:20] a new generation of managers is now being trained andeducated on these principles, on these, let's say, methodology frameworks, youknow, show results fast, do it data-driven, have a portfolio strategy ofmultiple ideas that you will execute at the same point in time. The [00:20:40]risk by doing actually something, not by writing PowerPoints and throwing a lotof money at consultants who do PowerPoint slides for you. So I think people gettrained to it because now they can they have this ability. So over time, theremight be a certification training program for, you know, how to be a goodmanager in this composable world and master best [00:21:00] of breed and do allthe right thinking.

Phillip: [00:21:03] I'm going to make an argument that sortof argues the opposite, which is you then trade one sort of complexity foranother, which is you have a number of investments, technology investments,that all [00:21:20] operate by different rules of the road. They all havediffering idiosyncrasies in the way that they implement code and deployments.They all have their own opinionated ecosystems. Some have a little more age onthem than others. So they're maybe less desirable to work for or they're harder[00:21:40] to hire and to staff for, or there are fewer agency partners to beable to deliver them, like some that you mentioned have security and technologychallenges to have to maintain and keep up on. When does that become now acompliance burden and a staffing burden to have such [00:22:00] a plurality ofsoftware as opposed to my monolith argument would be, well, at least we haveone set of technology and an opinionated stack that maybe doesn't do any onething really well. But I have the ability to [00:22:20] staff and tocross-train in the discipline of okay well I might be a catalog expert. Ihaven't really touched a whole lot in the way of payments APIs before, but atleast I don't have to relearn the technology stack itself in order to work onthe payment stack. I'm not sure if you've ever encountered that as a challenge[00:22:40] to the composable argument.

Boris: [00:22:41] Yeah, I would say two things. First, atthe end of the day, the counterargument to your counterargument could be thatyou can now go out and hire people maybe even faster because now you have amuch [00:23:00] wider in total, the ecosystem is much, much wider. You havefunctional expertise, right? So you don't have to pre script. You don't end upin discussions like, okay, but your platform is PHP-based or Java based, right?So because the platform is not based on any [00:23:20] one technology. It'sbased on, you know, for all the different pieces on the one that fits best. So,you know, it's easier to find Vue.js developers for the front end, while youmight be searching for people with cloud-native expertise to leverage the AWSinfrastructure better, while you might have again [00:23:40] other people whoare experts in GraphQL or rest APIs and other technologies and you might havehigh data loads that are perfectly solved with Python, maybe not with PHP. So Iwould argue it gives you more flexibility. Of course, you need to orchestrateit, right? This is where governance [00:24:00] comes in and technology roadmapgovernance comes in and architecture. But again, the precondition to composableis again is in a cloud world is, you know, APIs, is cloud-native technologieswhich abstract away, you know, actual programing languages in particular. Sothey [00:24:20] make you less dependent on PHP or less dependent on Java. Youhave SDKs. And I think when these preconditions are met, if contracts are inplace, if APIs are in place, of course, still you need to glue all of ittogether. And business logic and data models, this is nothing that...

Phillip: [00:24:39] By the way, more [00:24:40] and moreare not code that's deployed. There are a lot of no-code tools for theenterprise that actually bring these things together now too.

Boris: [00:24:46] Exactly, exactly. And I think what youas a business then have to decide upon is, you know, back to the very, veryfirst point is what matters more to you because composable enterpriseessentially gives you a business agility, right? You [00:25:00] can build outthe different apps and different functions independently from each other. Youcan deploy them. You can have your dedicated team, dedicated product managers,and just all good. So the business agility goes up. But as you said, complexityalso goes up you and then you might need to solve things like, for example,unified [00:25:20] SLAs. You end up with an ecosystem of 15 different tools,but you as a customer and as an enterprise customer, you would transact hundredsof millions of dollars. So you still want to have one consistent SLA. You don'twant to have finger pointing. You don't want to talk to DSI about the customcode and to the commerce vendor about the commerce code. You just, you know,something doesn't work. [00:25:40] So you are losing this consistency in SLAs.You're losing maybe speed and efficiency on debugging, on supporting, onfinding, doing root cause analysis. This is something that you need to... It'snot impossible. So there are ways of how to solve it. But this is kind of thetradeoff that [00:26:00] you need to think about. And not do composablecommerce for composable commerce's sake because, you know, it sounds fancy. Sonow let's do... You know monolith sounds bad, so modular sounds good, so let'snow go all in the cloud because there is a price tag attached to it.

Phillip: [00:26:16] A surprising number of businesses havethese [00:26:20] legacy models for pricing and inventory that are things theyadopted because a prior business suite imposed it upon them. And as the worldevolves and as technology evolves, we have to come back to re-addressing someof those decisions around business [00:26:40] architecture and the reason whyit was that way to begin with. I mean, so much of the work I've done in theservices in the agency space has been trying to address these legacy businesspractices that now have to accommodate modern software. An argument forcomposable could be [00:27:00] that you don't necessarily have to do away withthe entirety of that old business suite. If there's one part of that that worksfor you, it can be durable in your organization while replacing the other partsthat need more modernization.

Boris: [00:27:12] Or temporarily. So this could also bethe fact that you try to... I mean, we all know these projects especially when[00:27:20] a business would re-platform. So a black and white binary decisionto you know change the entire stack is super, super risky. It takes a lot oftime, takes a lot of effort. There's a lot of expertise that is sitting in thebusiness, both on the business side of the business and on the tech side of thebusiness. So you know that you don't want to lose. Even [00:27:40] if overtime, you know, decisions stack up and many of the legacy decisions might notbe relevant anymore. Still, there are maybe some which are relevant. It alsogives you the ability to migrate in a step by step way based not just ontechnology, kind of on technology coolness, but [00:28:00] also on actualbusiness needs. And this is what I like the most that you can come now to acompany or to a customer saying, "Look, let's look into your data."Right? Or maybe they have done it already for you. "And let's see what isreally driving sales. What is really driving conversion? What is it holds youback?" "Your search is not good enough. Okay, then [00:28:20] let'smaybe start with replacing the search engine." Or "Hey, you need theability to use more payment methods." Or "Hey, your commerce engineitself, the commerce operating that you are using is maybe not goodenough." Let's plug this up, but your PIM is fine. Your catalog, you havesuper complex data. You spend like years to set it up. You have 150 trainedpeople who are doing nothing else than [00:28:40] managing content every day orthe same on the content side we see even more often. Why would you rip it outjust because you have pain somewhere else? So now these guys have to beretrained as well, which is a huge cost and risk to the business.

Phillip: [00:28:52] Yeah.

Boris: [00:28:53] And I think this gradual modernizationof technology is not a one-time thing. [00:29:00] You can modernize every twoor three years.

Phillip: [00:29:05] Thanks so much for listening toDecoded. You can find more episodes of this podcast and all Future Commercepodcast properties at FutureCommerce.fm. You can also subscribe to ournewsletter, which comes out three times a week at FutureCommerce.fm/Subscribe.[00:29:20] This special series of Future Commerce is brought to you by Spryker,the commerce platform to futureproof your business. Hey, it's a challenge rightnow in 2022. You have to be about more than just selling online. [00:29:40] Themarket is shifting and new technologies are changing the game every day. Andthat's why innovation and agility should be at the top of your list to be ableto stay competitive. And that's why the Spryker Excite Conference is soexciting. At the Spryker Excite Conference, you'll gain pioneering insight fromindustry leaders. You're going to [00:30:00] learn about how to win new andfuture commerce projects, and you'll be inspired by the amazing speaker lineupand fellow attendees. If you want to learn more and register for the event, goto Spryker.com/Future Commerce to learn more and register.  [00:30:20]And we'll see you in June inNashville at Spryker Excite.

‍