40. Challenge Accepted. with Mihaela Mazzenga

Piotr Karwatka: [00:00:40] Hi there today. My guest is Mihaela Mazzenga, CTO of Sharper Image. We're about to talk about all things, MACH, microservices, API, first cloud native, and headless based on her firsthand experience with the rest of migration towards headless architecture. Hi, Mihaela, thanks for accepting my invitation. 

Mihaela Mazzenga: [00:01:02] You're welcome. Hi Piotr. Nice to talk with you today. 

Piotr Karwatka: [00:01:04] Awesome. Maybe let's start with a short intro. So if you can say something about yourself and your professional career. 

Mihaela Mazzenga: [00:01:12] Sure. So I'm really relatively new to commerce. I spent 15 years in Consumer Benefit Plans, such as Enrollment, Health, and Wellness early building teams and platforms from the ground up for wellness purposes.

So Learning Management, Health Assessments, Coaching Services integrating to wearable devices and health systems and AMRs, and really handled the team and the culture and the engineering and security. And just all end to end. So recently, about three and a half years ago, I moved over to commerce and the rest is history, as they say, right? I've moved over to the dark side at this point. 

Piotr Karwatka: [00:01:53] Gotcha. So. Relatively short in e-commerce. But doing a really huge project recently, I mean the migration of Sharper Image to MACH sounds like exciting. And I will ask you if you know a few things about it in a second, but first, could you give us a short intro about the company itself, because maybe not all listeners are close to what you guys are selling and how the business goes.

Mihaela Mazzenga: [00:02:20] So I think Sharper Image, at least in the United States, has a really long, rich history as a consumer product company. But the sharperimage.com of today was really reincarnated as digital only and digital first. So we primarily operate on digital though. Our catalog is a, you know, massive marketing channel that we still utilize today.

And that's maybe the older Sharper Image that people remember from the past, but it's tech oriented products it's lifestyle oriented products. And again, we sell primarily through sharper image.com, which started as a catalog based business. 

Piotr Karwatka: [00:02:58] Right. And then move online.

Mihaela Mazzenga: [00:03:02] Not just catalog, but physical stores. So back when, back when I was a child, I remember going to the Sharper Image store and sitting and playing with all the technology based products. And it was this neat place to go when you go shopping with your parents. 

Piotr Karwatka: [00:03:18] That sounds super interesting. When you joined the company, it was three and half years ago, right? How e-commerce was going. You know, technology wise, maybe like it was some, you know ready-made Leno box platform Monterey did, or maybe it was fully custom may give us some, some backup. 

Mihaela Mazzenga: [00:03:40] Right. So I think to no surprise, it was a fully boxed, suite monolith. And that was really different from the environment that I came from.

So the environment that I came from was really niche SAS. So everything was custom. Yeah. Yeah. Now that said I also came from a very composable world. So to the point that you didn't have to custom build something, you could utilize a SAS vendor which was also very prominent. The problem back then was that there just weren't very many satisfiers that you could actually utilize.

So coming over to Sharper Image, it was very much a monolith and MACH aside because we'll get into, I think how MACH really came, came to be within the sharper image. The goal was to move away and build something more flexible. I'm really leaning into my prior experience.

Piotr Karwatka: [00:04:40] What was the biggest problem with the platform? Like the lack of flexibility you just mentioned, or maybe high, you know, maintenance costs? What was the key, you know motivation. 

Mihaela Mazzenga: [00:04:55] Yeah. So you mentioned business, right? So there's business problems and then there's technical problems. And at the end of the day, I think scalability is number one on a technical basis.

If you need to run at any level of scale, the model at a certain point will no longer be able to facilitate the business, but on the business side, it was flexible. It was saying, well, we don't, if we don't like a feature within the suite, we want to be able to go with the best in breed vendor that can provide us the features that we want.

Piotr Karwatka: [00:05:30] And how did you approach the architecture? Because as you mentioned with this MACH based architecture, you can pick and choose whatever services you like best of breed products, but you need somehow to pick them actually. And how did you approach this problem assessing all those options you have on the market. 

Mihaela Mazzenga: [00:06:02] Yeah. So this is very different, I think, from what others have encountered in the past and how they procure software. And it's a lot of, you know, RFP and vendor management. And I think that the way that you get to that best is by forming a really clear statement. Of what you need out of it. And maybe not much more than that, because I think you can, you can be future forward, but you also have to keep tabs on what it is that you need to accomplish right now, especially if you're under some sort of time constraint. So building a really, really clear RFP and then.

Going out to the market and seeing which vendors I'll say vendors right now can truly align with you as a partner. Keep in mind that, right. These are likely going to be three-year contracts with each one of these vendors. And you may end up with five. Maybe you will, you'll end up with 10.

So it's a massive amount of vendor management. And I think being a true partner, Within that relationship is key. You want somebody where you know that regardless of what their support looks like, you can pick up the phone and if you have an issue, they're going to work together with you to figure that out.

So that was really key for me, while the process on top of just the tech itself, because there's, there's a lot of great options out there and, and of course, cost comes into that and cost should be one of the considerations. So I think you need to really narrow it down based on what your goals are.

And everybody's goals are going to be different. All the features they want are going to be different. I don't, I mean, it's nice to have a use case, or it's nice to have a ref, but it doesn't go very far to what you're going to need to do. 

Piotr Karwatka: [00:07:52] And in your case, what, you know, use cases or the business calls were the top three vendors that you went with? No, actually, you know you said that you need to set the top three goals, right? For example, we have really poor experience with our previous search engine. This is just an example, right? So what were yours? Three top three goals assessing the vendors, because the next question I will ask you is, well, what actually vendors that you decided on. 

Mihaela Mazzenga: [00:08:22] Okay. So number one was truly whether they could operate in a headless capacity and this is on the technical end. Because we knew that by going for a headless solution, we would be able to also accommodate the business goals through evaluating each vendor on, on a business level as well, whether the features match.

So one was, can you operate in headless? Number two, of course costs came into that. Right? So when you're moving from an enterprise model list, and now you're going to move to a very distributed space of many different vendors. I do think that you can get to the same cost or lower, but you have to be really intentional.

Isn't it? So, and those are right. It doesn't have to be one-to-one. Maybe you have business issues that you can solve by adding new vendors that have nothing to do with saying, we want to, we want to switch out the core. And I think those need to be slightly different initiatives.

And then I think that they were for us, certainly when it comes to, to the front end, And then in addition to the cost and the headless capacity, honestly and, and the MACH ideals of, of the open architecture or important then for scale. And I think it was really not very well understood when that was discussed with vendors.

Tell me what your infrastructure looks like. You know, are you really running on pure microservices? Is it really, you know, an API driven approach? And at one point I had somebody ask me, why does it matter? Because it matters. I need to know that for scalability purposes, now that we've combined five vendors together, I don't know what that's going to operate like in production yet.

Right. We're going through this for the first time now. And it's, it's really important that I know that you have these basics down. 

Piotr Karwatka: [00:10:25] That's interesting. And I think that this is one, the reason why MACH Alliance is here to stay with us for longer. I mean, I have this feeling that for the first time, somebody, you know, formulated the principles of the traditional MACH compatible architecture.

So that's really good. Very good. Okay. So you, you have those two goals? Yes. It sounds super clear. And, and, you know, it makes a lot of sense. But where have you landed with, with those goals in mind and we, which vendors these chairs. 

Mihaela Mazzenga: [00:11:02] So I won't give you the specific names, but I'll tell you the components that we ended up with.

So we ended up with a core commerce system that today operates the cart and the product information management. Primarily we ended up with a separate search system due to latency that we discovered after we started implementation. Okay. And then in addition to that, we also ended up with a custom react front end.

That is also powered back by a backend for front end and was, and that was honestly really critical to the scale that we ended up needing. I think what we learned through the process was that we probably introduced some latency. And the orchestration of so many different Avi's from different vendors and how those things operate together in the front end is really critical to the experience.

Now, we had made the decision that we wanted the backend for the front-end concept moving into the implementation and in hindsight, I think it was really, really critical to the overall success of  the project.

Piotr Karwatka: [00:12:17] You mean to have some kind of facilitation for the API calls to merge the data from different sources, something like this and maybe to ladder be casual or something.

Yeah. Okay. Okay. So you are losing cache as well for this proposal to lower the license. That's interesting. And there is no separate team, right? It's it the pin from the commerce platform that you use? Correct. Okay. That's cool. The next question I have on my list is what to do to build versus what to just buy.

And you actually answered this question already, because from what I understood is that you build this front end application. Right. And you said that it's custom react and just backend for front end probably is another thing you, you also built is there anything as you, as you feel that, you know, it's you know, adding value when you build it on your own, rather than just a taking from the market. So the back end for front end is from the market API gateway kind of, right?

Mihaela Mazzenga: Right, right. So here's the thing. I think it's hard to answer this question again because we had a very specific use case. And what I observed through the whole project was truly that, I mean, could easily go with an outsourced front end.

That one, I think, is really easy to plug and play. It's basically a non issue within the scope of the entire project that it's really order management. So forget about the post, the pre-order flow. It's all about poor post order and say that depending on where it is that you're facilitating fulfillment.

And post order and returns in order management. Maybe that's an art in an ERP already today, and you're at the point where your migration really consists of all fronts and technologies, right? So you're looking at the front end. Maybe you're looking at cashing and a backend for a front end, and you're looking at this entire API orchestration that is purely front end driven.

Well, in your case then maybe the front end is the new backend. What, where does the backend even belong in that case? If you need absolutely no custom coding. And that was a really interesting shift in realization that, you know, granted, we had some specific needs on LMS that we had to custom build.

But if that wasn't the case, if you're already integrated into a system that facilitates that for you this can really be a lightweight move. And I think the type of engineer that's required to do that type of implementation versus building your own microservice layer is really quite different. So I think. And what the team looks like. It's going to be so different for each brand and each entity. And it's going to come down to whether you still need to maintain custom development or not. 

Piotr Karwatka: [00:15:25] And your case, this OMS part was already here, or you build it from scratch. 

Mihaela Mazzenga: [00:15:31] Now that part we did have to build.

Piotr Karwatka: [00:15:33] Okay. Okay. To, to optimize the processes. 

Mihaela Mazzenga: [00:15:36] We didn't find a partner that was able to really facilitate all the features that we needed.

Piotr Karwatka: [00:15:42] Yeah. That's, that's super difficult, you know I'm consulting a project from the FMCG industry at the moment and they have the same, the same problem. Like if you compare all those, you know systems and the new other tools really. Good piece of software, but always there is some, but yeah, we can use it, but, oh, right. 

Mihaela Mazzenga: [00:16:06] And this was the most surprising part for me. Being new to commerce and kind of when I got here and I assess the technical landscape. I think that the way that MACH came into play and the visibility that the vendors have now, that's really relatively new. It wasn't quite like this three years ago and I was underwhelmed. At the maturity level at the time, because if you're building a, some sort of niche product, of course, it's underserved, you're going to need an internal team. You're going to need a custom team to do that work, but I'm sorry, you know, e-commerce isn't new.

And when I looked at how advanced the suites were and, and the features and how deep that they allowed you to go as an enterprise client, It just wasn't there. So I was, I was really surprised by that because you know, commerce is fairly well baked. The things that you need to do at the top rate have been in existence for a long time.

Of course, you need to get a package to a customer and that's a finite process and they might want to return that product. And it's a finite process. And it was really surprising what I found. 

Piotr Karwatka: [00:17:21] That's interesting. I also had some unpopular view on this last week I was. I was talking with some, some guy we are working in these e-commerce for 20 plus years. And he told me something like, you know, this all, you know, how does things, this, this looks really brilliant. Technically it's so cool, but it's a step back. And I was like, What do you mean step back? It's a huge step back because when you compare the feature set and the readiness you, you take this product and the readiness to the market, like how, how quickly you can deploy it, comparing to, I dunno, demand where are hybrids, whatever, like platform before a known before it was it's way longer, right?

Because you need to pick those elements, you need to integrate them. They don't worry, you know, together out of the box, probably it's going to change probably in the next couple of years, I suppose there are gonna be a lot of starters that integrate all those. Things like kind of Linux distributions, but for Mike products so that the boundary phase we're gonna, you know, catch up at some point. Now we have that bundling, but this, the bundling is, it's kind of the back. Do you agree that it's something you observe with, with no buildings, this product? I know this unpopular view, right? 

Mihaela Mazzenga: [00:18:50] So as a total, like, opinion I don't think it's a step back. I think that the, the preface of MACH, maybe, maybe 

Piotr Karwatka: [00:19:02] it is more like, you know, That's the step halfway through, you know?

Mihaela Mazzenga: [00:19:07] No. And, and I, and I agree on both ends. Yeah, I do agree on both ends. So I think that MACH, as a technology standard, I think is very well suited, right? The ability for us to distribute business functions. To the cloud that can be consumed by other organizations is absolutely the engineering. Okay. So we'll leave that on the table.

I think that that is, it should have been the future a long time ago and I'm happy to, I'm happy to see that it's here now, now. Yes. 

Piotr Karwatka: [00:19:45] It was the best architecture five years ago. And the next time, the best architecture is now, 

Mihaela Mazzenga: [00:19:51] You know, as well as I do, it takes a long time for things to mature in the market, regardless of how great the tech is.

Now yes, I do agree. I know that people are hesitant to couple. But there are certainly places where it makes sense. And there are certainly places where it brings a lot of pain. And if we look at, if we look at the cart and payment services and taxation, and now to, to rip those three things apart when they actually should have a relationship and it would be a lot easier if they had a relationship. I think it makes sense. So I'm not for recoupling everything. I think you have to really take a pragmatic approach to say, well, what makes sense? And also listen to all of the organizations that are trying to implement this and are implementing it. And it actually doesn't matter what you are.

I think if the masses are saying, okay, listen, Yeah, we're having a really hard time with these two things and we really wish they would be coupled together. I think we need to listen to that and take steps to mitigate it. 

Piotr Karwatka: [00:20:54] Absolutely. I agree with you. I think that the next step will be, you know, a kind of festival of tools integrating different mark products.

But as I kind of, you know, start accelerators kind of, you know, maybe not, not messing with accelerator because it's well known from the previous era where it meant, you know, HTML copied pace and change, not this kind of accelerator assignment, but when you have something that is it's letting you be quicker to the market, but still leveraging is architecture.

Because as I said, I think it's a must have. Maybe it's not the final word. Right? 

Mihaela Mazzenga: [00:21:35] Well, never. It's never the final word. Yeah.

(...)