Back to podcasts

Bridging monolith and composable with automation, with Director of Engineering Keith Mazanec

April 9, 2023 / 13:40 / E27
Download
podcast-bg
Moving to composable technology almost never happens all at once. There is a transition period. How do you help teams make the most of the composable technology, while easing the transition between old and new? Keith Mazanec, Director of Software Engineering at Brad’s Deals shares how they used a composable content technology with automation capabilities (Contentstack) to create an easy transition that improved the lives of content editors straightaway - and created a better experience for everyone, customers included. Plus, hear about their favorite uses of Automation Hub to automate across the content lifecycle.

Timestamps:


1:05 The volume of content at Brad's Deals, and what that means for content editors
1:56 Why Brad's Deals looked for a new content management technology
2:27 An example of how automations helped reduce manual data entry for content editors
3:57 The custom dashboard Brad's Deals built for their editors
5:06 Example of automating a categorizing function to speed up content publishing process
6:03 Versioning and automating making changes to the content model
8:16 How Brad's Deals created continuity between their legacy technology and the new headless CMS
9:57 Automating throughout the content lifecycle across different content & marketing applications

[00:00:00] Jasmin: When you're moving to composable technology, you don't have to do it all at once. When Brad's Deals wanted to give their content creators a better way to work, they took small steps to bridge their old and their new technology. Along the way, they built in some pretty cool ways to automate their content lifecycle.

In today's episode of People Changing Enterprises, a deep dive into transformation through automation with head of engineering, Keith Mazanec. I'm your host, Jasmin Guthmann. Please enjoy this episode with Keith.

So let's talk about how you scaled your content operation inside Brad's Deals. Give me an idea of the volume of content that your teams have to manage on a regular basis.

[00:01:05] Keith: Today, our teams of editors typically publish one to 200 deals every day that they're finding in the market. And that involves all of the research, sourcing, finding, vetting of the deals. That's really one of the things that makes Brad's Deals special and unique, as it's all human-curated. Everything is vetted by a human. In addition to that, those are our core deals. We also have folks producing long-form content, and in our legacy systems, all different kinds of content were siloed. Our deal content and our long-form content were in completely different systems. And so it was difficult, if not impossible, for us to stitch them together. And that meant for any person on our editorial team, they were going into four or five different systems every day just to do their jobs. So the real big change here is moving to a unified platform where all of our content lives together. And then the second big thing is getting into a world where our editorial teams are spending less time on rote data entry and more time on the actual curation and recommendation of great deals that they're finding in the market.

What we wanted to do with this platform was really automate as much of the rote data entry as we possibly could. And so one of the things that we were super excited about is the automations feature in Contentstack, which made prototyping these things super easy. Probably about a year or so ago, I think, when we first started prototyping this, we wanted to be able to have our editorial teams input a product from a retailer that we work with, just the URL of where that product is. And in the legacy system, they would have to put in that URL, create a bunch of other tracking links, and manually enter images and things like pricing details and model numbers. All that type of stuff was just literally manual data entry. So now with the automations, we've been able to automate the importing of a lot of that information. So when someone puts in a product that they want to publish, it hits an automation, which then checks a couple of different data sources that we have for pulling in that product information and is gonna automatically fill that in along with images and whatnot for that editor. And all they have to do then is focus on, all right, what's the value here that I'm telling the consumer about? That's the part that's interesting to our readers, and that's the part that's the differentiator for our editors is what's their opinion and perspective on why is this a great deal? Why should you buy it now? We did not want to have to have them focused on the manual data entry of products and whatnot. There's a lot of opportunity for human error. So just having that ability to automate that was a huge unlock. And so in order to orchestrate all of this, we have the automations, of course, running in the background. Those are largely invisible to the editors. They spend their time in a custom dashboard widget that we built using the React SDK. And so they can sift through and see what they have published recently.

And then which of those things maybe have changed or maybe the deal has gone away? So one of the things about the consumer marketplace is things are changing all the time. In my early retail days, it was once a week at most when you'd have your sales, right? They came out in the newspaper on Sunday in a printed circular, and that was that.

And fast forward to today, sales can last minutes and they're at any time of day, all day. And so being able to keep up with the things that we're publishing about is really important to us, to make sure that we're providing real and valid information to our readers.

So being able to automate those kinds of things has been a huge unlock for us, and we believe will help our editorial teams accelerate and publish that much more content every day. In addition to those dashboard components, we've also built a lot of custom fields for our content types. One of the things that we do, of course, is we classify our content based on what kind of merchandise it is.

So is it apparel, is it shoes, is it bedding, etc.? And all that classification is based on this large and complex taxonomy that we have. And that was something that we were also able to tie into this automations feature as well. And a button that says, essentially, "Guess this merchandise type," because that's an area where if it's manually selected, the person might get it wrong, and it's also just yet another thing that they have to click. And so if we can make that be another thing that automatically fills in as soon as they put in an image or start to type a description about something. And that's another sort of win we were able to have. And again, it was about plugging in an existing system we already had that our data team, our data science team worked on and plugging that into a custom component in Contentstack was super easy. Another area is around versioning. So one of the challenging things with our legacy system is whenever we wanted to change the model, it was difficult to coordinate and orchestrate that change across our systems and across our different teams.

So today, when we want to make a change to our content model, it's very streamlined. We have a migration script that we write using the tooling that you all provide for us. And then run that against our different environments to get predictable results every time. And then all of that lives in version control because it's code.

And so we can see over time all the changes we're making. Then we can declare which version of the model each of those refers to, and if, let's say, a mobile client is consuming, when you publish an iOS or Android app, it might be out there on someone's device for a long time before it gets updated.

And so you can't just assume that, oh, we're gonna change which version of the API or which version of the content we're pointing to. And so being able to support older versions over a period of time is really key to be able to support some of those mobile clients that, again, not every user has auto-update turned on. Right? And so we have a content system that can support all of those different use cases today.

[00:07:23] Jasmin: Certainly, I love how it closes the loop on customer experience. You really have the customer at the heart of everything you do because you know, you could say, well, it's not my problem that you don't update your devices. No, you're taking the approach to say, Hey, you know, here's technology that enables us to create and provide a better customer experience. Let's use it to do just that. The one thing that I'm curious about after all you've said is it sounds like parts of your legacy technology and the new, quote-unquote, composable technology happily coexist. Can you tell us a little bit how you did that? What approach worked for you so we can give folks a silver lining on where to start.

[00:08:16] Keith: You have to begin with the end in mind and have an idea of where you want to go. And so for us, the end that we started with was the content model at a really high level. And that was sort of our driving force. And then from a technology perspective, even though we have this legacy system, I would say it's a service-oriented architecture, our legacy system.

And so we did have different, too many, but we did have different services that handled different parts of our stack. And so when we were looking at the future, we realized that, okay, a few of these things, the like applications, we can sunset those and we can build a bridge in between the old and the new, actually using some of the automation. Surprise, surprise. So for example, when the new content model doesn't quite fit our old system exactly, but in order to be able to run both at the same time and have that transition period happen for our web clients and mobile clients, we knew we needed to have our legacy APIs still function.

And so we were able to write a bridge essentially that uses automations to push new content back into the old system in a stripped-down form that's compatible with the old system's model. And that allows us to at least have continuity between the two systems and not have to do a single point in time, you know, July 1st, flip the switch, and it's old and new and that's it. We've been able to do this incrementally and iteratively rather than one giant sort of fell swoop. So that's been key. The other thing I would say is there's plenty of systems that we had already built that we are planning on keeping. A lot of the systems that deal with user personalization and profiles, and segmentation and some of the marketing automations that we have, a lot of those things are in good shape and are in great, a great spot for us.

And so it's how do we then integrate those existing tools that we're gonna keep with this new system as well? And again, thankfully, because everything speaks JSON APIs these days, it made that relatively straightforward. And again, through some of the things like automations that we talked about, we're also able to then get that entire, whatever events in the content lifecycle that we care about, we can pipe those into other systems. So for example, when we are building a process for our daily email that we send out to our readers to be published in the new system. We can have that be managed in the new system. And then when the content is ready, it can be published and that can trigger something over in our marketing system.

And so today, again, there's a whole sort of duct tape and bubblegum integration between our legacy publishing system and our marketing automation system, which I'm very excited to sunset. It's still functioning and operational today. We haven't fully cut over on that one yet, but that's an exciting project that, that I'm excited about as well because it allows us to reduce complexity. And I think that's the, the, the biggest thing that, that when, you know, two years ago when we were looking at our stack, we were looking at the content model we wanted it to be, we looked at all these applications. There's so many things we're maintaining that if we had dedicated teams, sure, maybe we could, you know, iterate on our own CMS and this one little feature. But we're not a CMS company. We're not, we're a publisher, and the market has changed drastically in the last decade as far as what's available in the market today. And so really we looked at, at choosing a vendor like Contentstack as a way to reduce complexity, in our stack by eliminating old services that, again, are hard to maintain, have security probably vulnerabilities and concerns of their own due to their age, are somewhat inflexible in their design.

And that's been a good journey for us. But again, we really had to begin with the end in mind. Where do we want to end up at the end of this journey? We knew we needed a new front-end web stack. We knew we needed to shift to a new CMS in order to support this new content model. And then we set off to do that.

And so really we looked at this as a, okay, how can we evolve our stack, simplify our legacy stack? Modernize the things that we're gonna keep and then integrate using essentially this event-driven system that we're getting out of Contentstack, with automations, to then coordinate activity between the old, the new, and the, and the, and the things that we're gonna keep.

So it's been a lot of fun, though. We've had a lot of fun doing it, I have to say.

[00:12:50] Jasmin: That is great and I think it shines through in everything that you do, and I love that it's such actionable advice. If you want to go composable, start with the end in mind and take small steps.

Thanks for listening to People Changing Enterprises. This show is brought to you by Contentstack, the leading composable digital experience platform for enterprises. Got a question or suggestion? Email us at podcast@contentstack.com. If you like the show, please leave us a rating or review on Apple Podcasts. We'll be back next week with a new episode, helping you make your mark.

Share on: