The Business Impact of Composable Architectures

Phil Hawksworth

I'm very excited that we're going to invite Joe Sisman to join us now. We really wanted to make sure we got a chance to talk to Joe at this conference. He can't be here, but he's going to join us remotely. So, first of all, we're going to have some words from Joe, and then we'll have a conversation between Joe and Matt right here on the stage, technology allowing. But of course, we can make this happen.

First things first, this is the point that I nervously ask, "Joe, Joe, can I... I feel like I'm doing a seance. Joe, can you hear me? Joe, are you there?"

Joe Cicman

I am here.

Phil Hawksworth

Hey, wonderful. Okay, well, we'll see Joe. There he is. Fantastic. Welcome, Joe. We're so delighted you could be here and joining us in this form. We really wanted to hear from you. Folks in the room may already know Joe Cicman has a long history of Enterprise architecture, Enterprise engineering, and is now Principal Analyst at Forrester. So, he has incredible insights and thoughts on the composable future that we might encounter. So, I will step out of the way. I will let Joe take the stage and lead us through some of his thoughts. And then Matt will return to the stage, and the 2 of them can have a bit of a further conversation. So, please make him incredibly welcome. It's Joe Cicman, everyone.

Joe Cicman

Hi, everyone. Yeah, my name is Joe Cicman, and I'm coming to you over Starlink because I did not want to miss the opportunity to talk to you about bridging composable architectures into the Enterprise for your digital products and experiences. So, I'm an analyst at Forrester Research, and I spend my days researching the technology that enterprises use to build digital experiences for their customers. I use that insight from the research I do to advise tech leaders in those enterprises. Now, some days I'm advising Chief Digital Officers, other days I advise Enterprise Architects, and still other days I advise CMOs or Directors of Sales Operations. So, I work with many types of leaders, and too often it feels like those leaders are all speaking about the tech using different languages. So, what I do is I bridge the conceptual gap. I use metaphors, I use familiar analogies, and I use value language. So, it's a little bit like a Rosetta Stone. It helps people get on the same page so that they can work in alignment. And I'm going to talk to you about composable the way I talk to my clients about composable. I'm going to raise the altitude a bit, so let's get going.

You know, that saying, "Ah, now that's music to my ears." When you deliver value to your customers, it's a perfect harmony. They're happy, they pay you, and then you're happy. It's how capitalism is supposed to work. But the trick is to do that at internet scale, actually at cloud scale. See, a long time ago, in a dev shop far, far away, the technology for making music wasn't adaptive. Music was written with ink on paper. You needed trained musicians to play it. Producing it was expensive, and too few people could enjoy it. Music can change a person's perspective, and a person's perspective can change the world for the better. But prior to 1770, music was not only hard to write, it was hard to play.

But then someone invented a hardware solution that made playing music less hard, and finally, more customers than ever could afford to hear automated music experiences. Now, this scaled the delivery of music, and it thus democratized it. The ad was great too, clean lines, authoritative font. And after its launch in 1770, the music box was sharing space with the pocket watch. And it wasn't until 1810 that wrist watches were invented, and it wasn't until the movie "Pulp Fiction" came out in 1994 that people knew how important wristwatches were to families. The comic relief aside, my point is that the architecture of music experiences meant that music wasn't easy to iterate. Making a change was economically infeasible for the most part, and any music that got created and compiled into a music box remained the same for a very long time.

The era of musical experiences was partly automated and scalable, but it wasn't adaptive. Now, I'm telling you this because the internet predated the cloud, and there's still a lot of pre-cloud era digital experience tech running in enterprises to this very day. With pre-cloud architecture, deploying changes remains economically infeasible for the most part. Cloud-native architecture is designed for activity and for scale. Okay, now flash to the present. Composability is a software architecture based on cloud-native principles, and it dramatically alters the economics of delivering value to your customers, no matter what business you're in. It enables you to change quickly and economically as your understanding of your customers’ preferences change.

How did cloud-native architecture get invented in the first place? Well, it started with the pressure to innovate at cloud scale. That pressure, on the shoulders of really people with the right incentives, yielded composable architectures. Today, composability is changing the form factor of enterprise tech for delivering customer experiences. Traditional enterprise IT is clunky, it's rigid, it's expensive. Developers have to work in ways that practically feel like writing music by hand with ink on paper. Now, there's still a lot of technology executives who are dealing with the challenge of managing pre-cloud era tech. In fact, Forrester's 2023 survey indicates that 58% of global enterprises are in a traditional IT state of maturity.

But there's a force at play that's changing the expectation that enterprises have of their web technology. It's this idea of consumerization of enterprise software, and that expectation is driving the adoption of composable architectures in the enterprise. The payoff of composability is lowering the cost of change, and when that happens, enterprises can iterate more. And when they iterate more, they can innovate more. They apply that adaptive technology strategy. They compose their digital systems so that they can recompose them, as and when they need to in order to keep up with the changing demands of their customers. Adaptivity is one element that enables enterprises to keep up with the ever-changing demands of their customers, but it's not the technology on its own that knows what the customer wants. Your people have to do that work by working in alignment and by putting the customer at the center of everything they do.

Through our research, Forrester has discovered and described what we call the customer-obsessed operating model. Customer obsession, that's putting the customer at the center of your leadership strategy and operations, enables your company to sense and respond to market circumstances. And that specific blend of leadership strategy and operations characteristics enables any enterprise to be customer-led, insights-driven, fast, and connected. And we've expressed this as a maturity model that has 5 stages. Enterprises at the highest level of maturity, the truly customer-obsessed enterprises, grew at 5 and a half times faster than their less mature peers who are in a state that we call customer-naive. We do this survey every year; we measure the year over year revenue growth at enterprises around the world. Last year, that number was 1.6.

In today's uncertain macro environment, the success chasm is widening between businesses that are customer-obsessed and those that are not. So, how many enterprises across the globe are customer-obsessed? We measured 6% of global enterprises are in a state of being customer-obsessed. And when we look at European businesses, they're pretty much in alignment with that global number. But what about other industries? Well, healthcare lags their peers by one basis point. Healthcare is notably less customer-oriented than the global benchmark. What about retail? Well, retail also lags their global peers at being customer-obsessed, but they're ahead of their global peers at that customer-committed stage. Outsized revenue growth is the power of a customer-obsessed operating model in your enterprise.

And we just saw 3 benchmarks of the distribution of that maturity across sectors. Now, the customer-obsessed operating model is how you orient your business around your customer. And then when you combine that with the right technology strategy, what Forrester calls a future-fit technology strategy, what results is you having new ways of working and new ways that customers can engage with you. 3 core drivers, platforms, practices, and partners give rise to 3 crucial capabilities: the ability to be adaptive, that's the ability to change when you spot an opportunity; the ability to be resilient, that's the ability to change when something exogenous, like a pandemic happens; and the ability to be creative, which you can think of as your ability to be resourceful even without being full of resources.

And again, this comes to life in your business as new ways of working and new ways that customers can engage with you. So, to recap, composable software is a key ingredient that makes your technology strategy adaptive. A future-fit technology strategy uses adaptivity to enable customer obsession. And customer obsession correlates with outsized revenue growth, 5 and a half times faster growth than businesses in a lower state of maturity. So, that's the perspective I give my clients to help them connect the dots between their pursuit of customer-obsessed growth and composable architectures.

And so now, Matt and I are going to have a chat about how to connect even more of those dots.

Thank you.

Matt Biilmann

Thanks so much, Joe. That was amazing. When you think about all these different roles and stakeholders that you generally interact with, what are the differences in their perspectives on composability as you talk through the space with them?

Joe Cicman

I'll start by saying when I work with clients that come to me with problems, I come across largely misperceptions and missteps. It's kind of like how a doctor usually only sees the patients when they have pain, not when they show up to brag. So, what I end up doing is working to recalibrate those perspectives when I work with my clients. So, I'll give you a couple. On the tech leader side, I will often hear things like, "Oh, hey, I thought composable would make things simple, but my velocity is slowing down." But they're looking at it from a perspective that doesn't include a view on using a platform product team. When you miss that out, then the result is they've got feature devs that have the burden of figuring things out, like how to do identity.

Now, on the marketing side, I would hear, "Okay, well, my devs are happy, but now I just took a step back 5 years because I don't have a WYSIWYG editor and preview it anymore." And sometimes from the enterprise architects, I hear, "Hey, my legacy vendor is telling me they're composable. I just have to upgrade. How on earth is that even possible?"

So, when I get those perspectives, what I then do as an analyst is I get the leaders aligned and working together to create, think of it like a pipeline, if you will, that starts with the CX team studying customers, creating journey maps that call out the digital interactions that benefit those customers and have value to the firm. And then they kind of stack rank those by business impact. And then they build a two-stage roadmap where we call out how to build quickly and realize the impact and then rebuild to harmonize that capability across the rest of the enterprise's digital experience platform. So, you can do that centrally, or you can do that locally, or you can do that in a federated structure. And it all depends on how your brands are organized.

Matt Biilmann

Yeah, sometimes, there's this weird chain between architects, developers, and marketers, where each of them make choices that are really important to their role, right? Like, so as an architect, you have to really think about the longevity of your choice, long-term evolution and those pieces. You have to think about governance and control and oversight. And depending on how an architect solves that, they can really make life miserable for the developers that have to work within this system that's suddenly stuck in some legacy stack or can't move or can't do anything. Hopefully, we hope that if they choose our approach, they can make life for those developers amazing. They can give them flexibility, the ability to pick up any modern technology, the ability to move fast, the ability to focus on creating value instead of operating pipelines and maintaining stuff.

But as developers try to solve for those points of their flexibility and their ability to use the newest tools and build the newest things, they have the ability to really make life miserable for the marketer or the business stakeholders that now fall into this ticket vortex where everything they want to do is like asking the developers, and they'll tell you, "Maybe we'll look at it in our next sprint. Maybe we won't." And hopefully, we can give them a platform where we can get the developers to solve for their concerns but also make the next step in the chain awesome. When we talk to a lot of these large Enterprises, they might often look at this very fast moving web space and what you can build there and feel like they are not really able to get there and that they're lagging behind and that they're kind of in a different world.

And I think when we talk to a lot of these stakeholders at the large companies, I often ask them, "How often does your team ship changes to production for your core web properties?" And often the answers I get typically span from the very best case, something like once a week, very regularly. There's a bi-weekly release window. Sometimes I hear once a month, and it's not even uncommon to hear every quarter we have this big release window when changes go up, everybody has to queue around it and get their things in or lose out. And so, that leads to very heavy QA processes. And at a point, I asked one of our data analysts to just look at how often do our enterprise customers actually ship changes to production because we run that whole release pipeline, right, from checking of content or checking of code or anything to the changes going live. And we can see if it's on a Deploy Preview, or staging, or in an actual production release. And when we filtered out the big outliers that are maybe doing automated publishing all the time, 3,000 times a day or something, when we filtered out those outliers, the average was 140 times a week. And I think that's what this approach can help with. When you can actually decouple the web experience, the actual experience you're building from your core business infrastructure layer, from all the legacy systems that you have sitting internally, from the systems that require data migration and security reviews and so on, then you can get to that pace. Often, the large companies barely believe that it's doable. We have so many proof points and we've really worked on this platform to make it a change you can start without re-architecting everything. You can start in a small place and get to that point. But I think, as we see this pressure from generative AI and from whole new UI experiences, if you want to be one of the companies that can stand out digitally in that environment, going from that maybe once every 2 week release cycle to 140 times a week is really going from being an aspiration to becoming absolutely necessary.

When you talk to the companies that you've seen go through this journey and go composable, what is your key takeaway on which ones do it successfully, and which struggle, in which cases is it a failure?

Joe Cicman

I think for a lot of years, enterprises were buying big monolithic systems with all the processes worked out behind the scenes by the vendor. But when you go composable, you are the architect of your own digital experience platform. So, you have to approach it with the discipline of a software company that's delivering the platform. You have to deliver that platform like it's the product your business uses to create all its experiences. When I've studied companies that have done it well, I found that the tech leaders speak the same language as their stakeholders. They get their stakeholders to speak the same language to get to the root of the problem. They lay out the chain of dependencies to get to the goal, incrementally bringing them into place. They establish a global platform product management team, charter a global product platform development team, and reshape the digital product development team to use the platform. They also consider delivering a second prescriptive stack option for technical projects.

Matt Biilmann

That makes a lot of sense. We've really architected our platform with this in mind. A key concern for us is that our platform is not a big monolithic platform. We're clear about the core web architecture that will be similar across different journeys, and we offer components that change over time. We identify what won't change, what stays stable while everything else evolves.

Before we wrap up, what's your main advice to our audience on connecting all these dots?

Joe Cicman

When you go home, start talking to your colleagues in different functions, speak in their value language. Business is about people and understanding how improving customer life translates into them spending more time and money with you, driving demands on your digital capabilities, which in turn drives demands on technology. Connect those dots, and you'll make the right decisions. Thank you.