Opinions & Insights

4 ways to overcome pushback for composable architecture

Opinions & Insights

4 ways to overcome pushback for composable architecture

So you’re already familiar with the benefits of composable architecture and now you’re trying to bring it into your organization. Like most great things, they don’t come easy. You’ve tried to pitch the value head-on, but you’re met with objections at every turn. Persuading people to come along on your journey to composable isn’t easy when starting on your back foot. Here’s some practical advice on how to overcome pushback for composable architecture.

Why is there pushback for composable architecture?

For people unfamiliar with composable architecture, it may be perceived as a new and shiny toy. Unfortunately, not everyone has the same penchant for new and shiny toys—especially when they can appear expensive if misunderstood.

We asked our community what some of the leading reasons are for objecting to composable architecture. Here’s what developers had to say:

Devs who want to go composable at your company, but are getting pushback...what's the main thing you're hearing?
— Netlify (@Netlify) November 17, 2023

Though a small sample, sometimes you don’t need to yield an overwhelming response to recognize there’s a problem.

Composable architecture has an identity problem. It’s often misunderstood by nontechnical folks and that needs to change. In the rest of this article, we’ll uncover some common objections to moving to composable—including those above—and how you can overcome them.

Some common pushback for composable architecture includes:

Our monolith is fine
Composable is complex
A migration will be too time-consuming
We don’t want to undo the work we’ve already done

Let’s start with the most common.

1. Our monolith is fine

We should begin by stating that it’s quite possible your monolith is just fine. After all, they do serve some businesses well. But you should ask yourself—and stakeholders, like people you collaborate with—what makes our monolith fine? It may seem rudimentary, but begin with a simple diagram that lists what you like about your monolith and what you don’t.

There’s no need to complicate things—a sticky note works just fine for now. Ask yourself questions like:

How much time are we spending on maintenance?
How much do we spend on servers?
Could I (a developer) be working on more important projects?
Are requests bogging my team down?

The list goes on.

By asking yourself these questions you’ll be able to navigate the monolith-is-fine conversation much differently. And if the answers to these questions aren’t readily available, consider asking around for this info. Even better, form a cross-functional team of stakeholders. You’d be surprised how much weight it can carry.

In all, telling decision-makers that composable is cheaper likely won’t be very compelling. It’s also too abstract to think about if you don’t paint them the picture. Use these questions to build out an investment analysis. Show them what you could be saving long-term.

2. Composable is complex

Sure—many things are complex, but that doesn’t make them unworthy. Marketing teams run personalized, localized, complex campaigns. Sales teams perform complex multi-touch and -channel outreach. The difference is that these practices have become evangelized and widely accepted. How? An incremental approach.

Whether it’s building an inbound marketing strategy or developing an outreach strategy, you don’t need to do everything all at once. This is important to understand—especially when you’re trying to convince stakeholders that making the move to a composable architecture can be approached the same way.

Simply: you don’t have to rip and replace your monolith with a composable architecture. It can happen incrementally. Test one change at a time and react accordingly. Switch to headless and solve one business challenge at a time.

Remind stakeholders that if one piece isn’t working because your business goals change, a startup you wanted to rely on goes belly up, whatever the case you can swap that thing and move on.

Yes, implementing and succeeding with a composable architecture can be complex if you do it all at once, but with an incremental approach, you’ll gradually arrive at an end state with all the right-fit solutions you’ve hand-selected.

3. A migration will be too time-consuming

It will take time to fully migrate to a composable architecture. But it will also take time to maintain your current monolith—possibly more and more as time goes on. One way to think about this is by way of the strangler fig pattern:

“The pattern is an analogy for a type of plant that begins life as a vine growing alongside an older, established tree. As the vine grows, it spreads to completely consume and ultimately replace the host tree, leaving a new, strangler fig tree in its place.”

The same idea applies to migrating from a monolith to a headless composable architecture. Essentially, you can build out your front-facing UI (Netlify Core) and it can point to ~99% of your existing systems. (If you’re not following along, Netlify Connect handles this orchestration for you.) This way, you can move just one piece over at a time—like we mentioned earlier.

Here’s another way to think about it that might be easier for nontechnical folk to understand. If people are using a tool—say a CMS—that’s working for them, they don’t have to stop using it when you migrate to composable. They can continue using that solution while other areas of the business migrate to what works for them. Nonetheless, you’re still on the journey toward unification.

4. We don’t want to undo the work we’ve done

If you encounter this objection, well, you’re in for a philosophical discussion. We’d argue that you can’t measure the value of something by the cost you’ve already sunk into it. However, you should use it as an opportunity to do an analysis comparison. Think back to all of your previous steps and compare the world you’re creating to the world you’re living in now.

If we’ve learned nothing else, it’s that businesses have to keep pushing forward to remain relevant. For many organizations, especially those in fintech, ecommerce, and healthcare to name a few, this is the most progressive and strategic decision you can make from an architectural point of view.

In the end, while all the services you’ve hard-coded yourself might work now, as your business begins to scale, new problems will surface. With a monolith, you’re building a bigger and bigger code base that becomes more inflexible as time goes on. But with a composable architecture, you’re choosing the solutions you need when they’re solving a problem you have and no sooner.