For executives
For digital leaders
For developers
Recommended for you
3 ways tech and business teams can help each other through a transformation
Not all great tech transformations are brought to the table by a developer, engineer, CTO or other technical person. We see great projects kick off because someone in marketing, sales or customer success raises the flag for change. Sometimes business people can see opportunities that aren’t as plain to the tech teams.That’s what happened when Booking.com decided to transition off its old systems to a headless CMS. Juliette Olah, senior manager of Editorial, realized that her teams had produced thousands of pieces of content over the years — but the capabilities of their current technology significantly limited the value that content produced in their local markets and possibilities for the future.Listening to her “People Changing Enterprises” episodes, I admired the way Juliette united Booking.com’s product and editorial teams from the beginning to pull off their transformation. Business and tech can either be each other’s biggest advocates or frustrating roadblocks.To avoid the latter, these are three examples of how tech and business teams can support each other throughout a transformation.Thoroughly debrief at the onsetAt the beginning of every project, we encourage organizations to sit down with their cross-functional teams and level set. Business and tech have their own KPIs and goals to achieve. In a project that bridges the two, there should be a frank discussion, ending in clear, written requirements of process and goals for both sides.Once Juliette realized a tech transformation was the answer to the editorial team’s needs, she became the living bridge between the editorial and product teams. Sitting down with tech stakeholders, they talked through what Juliette called a “comprehensive 360 view of the benefits to the technical side of the platform”:The editorial team’s strategy and the justification behind the new technologyReal-life examples of what execution would look likeThe business value of a central headless CMS would bring to each local marketOpportunities they were currently missing out on because of their current toolBecause she had clearly done her homework and demonstrated the need on both sides, the product team was eager to get started.Partner up to find and test new toolsFinding and testing new tools is an easy way for business and tech teams to partner effectively. When the new CMS was in place, the teams at Booking.com partnered to try out the new tool to make sure it worked for both sides.At Contentstack, once a new solution is initially developed, we pull in our business partners for User Acceptance Testing. They can test, catch bugs, or point out which workflows function trickier than anticipated — versus the tech teams doing it all themselves.Additionally, when you’re on the hunt for new tools, tag a business partner in for their opinion. From a different mindset, they might be able to raise questions or point out benefits you didn’t consider. Work together to phase out what isn’t neededA transition to composable is the perfect time to evaluate what tools you’re bringing into the new environment — and which ones you should retire. This is another area that tech and business teams should work together.A few years ago, we bought an analytics tool for the organization to use on their reports. It was low-cost and met some of our needs upfront, so we decided to take a chance on it. Six months down the road, we were spending a huge amount of time trying to force the tool to work. When a business person came to me and admitted the tool wasn’t helping their team meet their objectives, we decided to look into something else. On a composable project, it’s not always clear on the back end if a tool is working for teams as they need. That’s where our business partners come in. It’s a partnership.Babe Ruth once said, "The way a team plays as a whole determines its success. You may have the greatest bunch of individual stars in the world, but if they don’t play together, the club won’t be worth a dime."It’s easy for business and tech teams to work in silos, but working together produces more value. Especially in a tech transformation, the two teams are different sides of one coin. Find ways to bridge the gap and you’ll see much more value in your resulting tech stack.
Moving from monolith to composable with ASICS' Mindy Montgomery
Mindy Montgomery, Sr. Technical Product Manager at ASICS, describes the brand's journey from monolithic technology to a composable customer experience ecosystem. She describes how their eCommerce, omnichannel, and partnerships brand experiences are underpinned by composable technology, and how all of that stems from their brand mission - "A sound mind in a sound body".Learn about:- The ASICS vision for the truly omnichannel customer experience - How the company moved from a Salesforce monolithic platform to a composable stack- What Mindy has learned about how to run RFPs quickly, efficiently, and effectivelyTimestamps: 1:01 The ASICS omnichannel vision2:30 The company's journey to eCommerce and composable technology3:57 The brand promise that is driving technological strategy at ASICS4:39 The composable model supporting future brand extensions inside the ecosystem platform6:33 Moving off the monolith 8:11 What's next in eCommerce for the brand10:09 Tips for surviving the RFP process13:06 Trust your internal knowledge - and instincts when it comes to vendor conversations
Drive Seamless Digital Customer
Experiences with Composable UX
Disjointed customer experiences are a widespread marketing pain point. Delivering seamless digital user experiences across the touchpoints of the customer journey is tough, and a traditional channel mentality won’t get you there.
Read the reportExecutives
Leverage composable tech to drive business forward
De-risking your transition to composable
Everyone has a different journey to composable. Some companies adopt it quickly; some take several months. Some are eager; some are skeptical. But nearly all are concerned about risk during the transition. That’s not surprising — any good business leader considers all the risks at hand when making a big move. Levi Strauss & Co certainly did, and they weren’t shy about discussing it on our “People Changing Enterprises” podcast. I was a fan of the openness from Zach Crittendon, a software architect, as he broke down Levi’s approach to transitioning from their monolith environment to a composable architecture.Since risk is on everyone’s minds, I wanted to share my perspective on how to minimize risk when making the move to composable.Get everyone on boardChoosing to make the switch from monolith to composable doesn’t happen overnight. It also can’t be accomplished alone. You need a team. If critical stakeholders like finance and procurement are not on board at the start, it can cause problems and increase risk in the future. Finance might question the higher upfront costs because the business is adopting several best-of-breed tools with built-in benefits like scalability and extensibility. Procurement is going to look at the different vendors to manage and balk.Demonstrate the business case for why this move is important:To finance: “The market is ever-changing and we need to pivot quickly when required. Our current environment doesn’t allow us to do that. Composable is much less risk, time and cost than our current environment in the long run.”To procurement: “I know you want to consolidate vendors, but our current tools aren’t working for the business. There’s no solution in the composable world where we just buy everything as one.” (If Contentstack is your composable partner, I would recommend telling them about Care Without Compromise™, the industry’s only cross-vendor support program).It’s a slow process, but worth it. There’s much less uncertainty and chance that risk might be incurred in the future from internal conflicts.Make a plan and take it in phasesOnce you have everyone on board, your next move to decrease risk is to make a plan. I recommend pacing the transition in phases so it’s not so overwhelming or too fast.I like how Zach said it: “I think the choice of the word ‘composable’ is really meaningful in the sense that it’s like a musical composition. It’s a series of notes and chords that come together into bars and movements. Eventually, you have an entire piece.”The terms “come together” and “eventually” are important in Zach’s quote. Levi’s didn’t adopt composable all at once. In fact, they started with just four modules. Eventually, they were able to create cool content experiences that they had been dreaming about for a long time — but it wasn’t what they started with. They started with a plan and phase one.However, remember this: Plans change.I love this quote from President Eisenhower surfaced by a previous “People Changing Enterprises" guest: “In preparing for battle I have always found that plans are useless, but planning is indispensable.”I wouldn’t say having a roadmap for your transition to composable is useless, but I would advise you to be open to change as circumstances evolve. It’s the act of planning for the future that will de-risk your transition most, rather than the plan itself. Balance the present and the futureConsider the balance between the capabilities you need now and what you’ll need down the road.One of the benefits of composable architecture is the flexibility it provides. If you build something into your initial stack that you want to remove later, it is much easier than in a monolithic environment. Conversely, if you leave something out that you discover a need for, you can easily integrate that into your stack. Balancing the present and the future also means you have a long-term vision of what you want to do but start with a very clear and provable business case. For Levi’s, their first phase in the composable transition was proving Contentstack would excel with one use case: the homepage. While the homepage ran through the headless CMS, the rest of the website remained on the monolith. It was like a small trial run: Once they proved the business case for composable, they moved on to phase two. They replaced their old environment and created a simple version of the website in a smaller market (for them, it was Eastern Europe). The third, and last, phase was taking the lessons learned from phases one and two to fully replace the entire website.Trust your instinctsThe term digital transformation – along with all the moving parts and plans it brings – can be intimidating. So, here’s my biggest advice in this process: as a business leader at the head of the charge, trust your gut. I got this advice from Dheeraj Pandey, founder and CEO of Nutanix and someone I respect, who said that gut feeling comes from experience. You may not have walked through a digital transformation project before, or it might have looked very different in the past. But experience forms the foundation of your gut instinct.If something seems like a risk, consider it. Check with your colleagues and trust their gut instinct, too. Remember this transition to composable is a less risky approach than staying with your old tools and technologies. Any good tech leader knows you’ll never fully de-risk your transition to composable. But with a thorough approach, an understanding of where you want to go, and an experienced partner to offer expertise, you can pave a path to less risk and more flexibility for the future.
How to avoid the pitfalls of a composable architecture
Digital content management is in a state of perpetual evolution. Consumers have come to expect robust, seamless digital experiences when interacting with brands, and organizations that fail to meet those expectations can quickly find themselves left behind.It’s tempting to think the solution is to build a digital experience that satisfies the expectations of today’s consumer; unfortunately, it’s not that simple. Every day brings new channels and new competitors, and the digital experiences consumers want today might not look anything like the one they want tomorrow.A composable architecture gives businesses the speed, flexibility and scalability they need to deliver digital experiences that meet the expectations of current and future customers. However, there are complexities in the implementation process that enterprises need to be prepared for in order to ensure a seamless transition to composable architecture.What is a composable architecture?Content management systems traditionally have relied on monolithic architecture: an all-in-one system in which the front-end and back-end layers are handled by a single codebase. That approach served us well for decades; that is, until 2014, when mobile internet usage supplanted desktop usage. Since then, consumers have grown to expect a seamless omnichannel experience that a traditional monolithic CMS was never designed to deliver. “There are a lot more requirements on the customer [or] end user side,” said Jeff Baher, head of product marketing at Contentstack. “Content that once resided solely on a website is now in a lot of different places.”Monolithic architecture offers a suite of functions that can be managed from one codebase, which makes for a fairly simple implementation process. But what happens when an organization’s needs surpass the capabilities of a legacy CMS?“Can any one single vendor get their arms around it and solve for all that?” Baher asked. The answer is increasingly no. Enterprises are instead often forced to rely on clunky plug-ins to deliver the functionality they need, and with each new plug-in, the site gets a little slower — and the digital experience suffers as a result.Organizations that wish to avoid plug-ins can update their CMS, but that’s a time-consuming and expensive process. With monolithic architecture, even minor front-end changes can require significant updates to back-end code. And, of course, that process inevitably needs to be repeated every time consumer expectations change or new channels emerge.A composable architecture breaks down the large and complex functions found in monolithic solutions into smaller, more manageable pieces. An application programming interface (API) acts as the go-between for these smaller pieces, allowing them to communicate and transfer information more efficiently. In a composable CMS, the front-end and back-end layers are decoupled, so changes can be made to the front end independent of back-end functions.The result is the same functionality found in monolithic architecture, only more efficient, more flexible and with more freedom to build a customized or modular solution to meet an organization’s specific needs — once the new architecture is up and running, that is.Common pitfalls of implementing a composable architectureA composable architecture allows organizations to build rich, omnichannel digital experiences on their own terms, free from any of the limitations imposed by monolithic architecture. But, a wider range of possibilities also means more potential challenges.What goes where, who’s on first?A monolithic architecture has a variety of inherent shortcomings, but monolithic solutions do offer a clear benefit: simplicity. Although notoriously difficult to update, legacy architecture is fairly easy to implement, which may be attractive to some organizations depending on their needs. And since monolithic solutions are typically created and sold by one vendor, organizations benefit from a one-stop point of contact for any issues that may arise. A composable solution brings together capabilities of different vendors, Baher said. This is undoubtedly a positive in terms of flexibility and freedom, but if one element doesn’t work as intended, it can affect the entire digital experience. With a monolithic solution, the vendor handles the process of identifying and fixing the problem, but with composable, the organization has to manage the diagnostic process. On top of that, if the issue is being caused by two elements from two different vendors; which vendor is responsible for the fix?The ‘kitchen sink' problemThe main selling point of a composable architecture is its flexibility; there are few limits on what your organization can do with a composable solution. But just because you can do something doesn’t necessarily mean you should. A composable architecture is “similar to Lego pieces, allowing you to build a lot of different things,” Baher said. “But that’s also the challenge: What do you build? How do you do it?”Assembling, or integrating, the available pieces is only half the battle. The other half is making sure each component selected is necessary to create the digital experience you have in mind. Remember, there’s “must-have” functionality and there’s “nice-to-have” functionality — and the more you have of the latter, the less time your IT team has to focus on the former.Disconnects between teamsAs the old saying goes, “a camel is a horse designed by a committee.” The flexibility of a composable architecture is useless if nobody can agree on the best way to use it. In organizations accustomed to monolithic architecture, it’s not uncommon for siloed teams or departments to form and operate independently of one another.Under these conditions, each team may develop their own idea of what “best” means in terms of functionality, user experience and so on, which can make for a rocky transition to a composable architecture. In order to overcome this challenge, and to maximize content re-use, organizations need to break down those silos by clearly defining cross-team goals and making sure departments work collaboratively to achieve them. If not, the digital experience you deliver to consumers is likely to resemble a camel.The people problemUltimately, an organization’s ability to successfully implement a composable architecture rests largely on its people for it’s not only a technology shift, it’s also a mindset shift. With a monolithic CMS, all the features are included in the software, but a composable solution is essentially a blank canvas — and it’s up to your people to think through and feel comfortable and confident with how to fill it in. Eliminating disconnects between teams is a key part of success in this regard, but organizations also need to have the right frame of mind and right resources on the technical side to build everything out.Overcome the pitfalls and go composable with confidenceMoving to composable architecture is more complex than many organizations realize initially, but the pitfalls are all surmountable. The following considerations are the key ingredients for success, according to Baher:Choose the right component technologies.Select vendors who view going composable as a partnership, not a dealership.Invest in automation technology to simplify integrations and automate routine tasks.Seek expertise and support to help you along the way.Run the numbers and a proper ROI analysis.Learn moreWatch this episode of "Contentstack LIVE!" to learn strategies for implementing composable technologies from Auden Hinton, director of digital experience at Contentstack.Schedule a free demo to see how Contentstack’s headless content management platform and industry-leading, cross-vendor support can help your organization make the transition to a composable architecture today.
Enterprise MACHified
The MACH Alliance supports companies who want to take advantage of the most innovative and flexible enterprise technologies available — and to break the release cycle. Read the most recent research report.
DownloadDigital leaders
Learn how to deliver better digital experiences, faster
Earning authority: How a team of copywriters changed an airline
Icelandair's content (all of it - from flight destinations to marketing campaigns) was scattered across business teams and third-party agencies. Then this power trio took the reins and brought the process in-house, under control, and to a level of efficiency that allowed them to stay operational through all the chaos during Covid shutdowns and beyond. In the process they became the brand's "content center of excellence". In this episode, Icelandair's Óskar Völundarson, Edvardas Paskevicius, and Hallur Þór Halldórsson dive deep into their content process - so if your organization's content is a bit chaotic, this is a great listen. Or, if you are part of any team that could use some quality control, organization, process and structure, check out this episode to learn how to take the reins and become the managing authority of excellence yourself. Timestamps:01:18 What is the job of content at Icelandair?02:02 The content team as intermediaries02:39 "Before": What was the content landscape before Óskar and Edvardas joined the company?04:23 "During": What transformed in the business, the culture, and the team, to allow change to take place?06:06 "After": What does the content Center of Excellence look like today?07:22 Troubleshooting: What Óskar and Edvardas do when something goes wrong in the content process09:42 How can someone create their own Center of Excellence inside their organization?10:19 Example of a well-oiled content excellence process11:43 How the team ensures clear lines of communication12:30 How to create, or earn, the authority to become arbiters of excellence
4 questions for e-commerce brands considering composable
There’s a lot of confusion in the market when it comes to composable architectures. A company says one thing and their competitor says something different — all the while, the people who hunger for change inside complex organizations struggle.We see this in potential e-commerce customers all the time, knowing they need a change but not really understanding what composable can do for them. Emma Sleep, one of the fastest-growing D2C sleep brands in the world, was one of those organizations.Andreas Westendörpf, chief technology officer of Emma Sleep, talked about why they chose composable and what it did for them on the latest “People Changing Enterprises” podcast. Hearing him speak about the differences between traditional environments and composable inspired me to create this litmus test. Ideally, this will help provide clarity for e-commerce organizations wondering if composable is the right move for them.Are you aiming to grow quickly?For organizations trying to scale quickly, traditional CMS and legacy systems are far more complicated than composable architectures. They are less flexible and take more developer intervention to launch new markets, products, and content. Composable wasn’t in Andreas’ original plans. But when Emma Sleep introduced their ambitious growth goals, they were operating from a highly customized legacy system. Doubling business every one or two years in vastly different markets would be difficult, frustrating and extremely error-prone with these technologies. They also wouldn’t be able to support personalized content for each market — what works for European audiences doesn’t work for Asia or Latin America. If you are a scaling organization, you need composable. Other options are too rudimentary and inflexible for you. You will have to manipulate and create custom code to force things to work, which is not only a huge risk — as it will most likely break often — but inefficient when efficiency is required.Are you outsourcing the problem to the vendor?Andreas made a good point in the podcast. E-commerce was one of the first ways to make money on the internet, which is why many platforms still follow the architectural design principles of the ’90s and early 2000s when they were founded. While that’s changing, it’s happening slowly. In the meantime, e-commerce organizations are struggling with monolithic technology.The common solution is outsourcing your development to the same vendor you’re struggling with — a tricky catch-22. The problem doesn’t change. Instead, it comes with long consulting timelines and following industry “best practices” that actually aren’t best, like planning out your project five years in advance (more on that to come).Composable solves two problems at once: providing a more flexible, agile technology stack and by bringing control back in-house.Do you need to make room for innovation?I recently read a great piece that nails down what innovation really is: riding a wave. Mary Kay Ash didn’t invent cosmetics; she rode the direct-sales wave. Henry Ford didn’t invent the automobile; he rode the assembly line wave. Steve Jobs didn’t invent computers; he rode the digital wave. So on and so forth.Here’s what I’m trying to get at: Are you equipped to ride the wave?E-commerce brands must ride the wave more than most. They ride the waves of public opinion, of social media, of what customers need when they need it. But the thing about waves is they disappear quickly. If you don’t catch it, you sink. E-commerce organizations don’t have the luxury of submitting a developer ticket or a feature request and waiting around for six months until the request becomes a reality; the wave could be gone by then. Yet that’s often what happens with legacy technology — so many missed opportunities.In the podcast, Andreas expresses his desire to experiment quickly and figure out what works versus what doesn’t. In a composable architecture, their team can integrate up-and-coming tools like ChatGPT for use pretty quickly. Emma Sleep also tests new platforms for new markets beforehand and implements them when ready. That was not possible for them in their previous environment.Do you need to transform quickly?“The five-year plan is dead.”That might be my favorite quote from a “People Changing Enterprises” podcast so far, and Andreas is absolutely right. Why stretch your timelines out that long, especially when you can reap value much earlier?Andreas added: “Don't plan for a five-year project. If you are trying to implement within a five-year timeframe, things change too much. So plan for two years. Two years is a good time horizon. If two years becomes two and a half, fair enough. But you need to somehow have the most critical work done at the end of two years, like 90%.”Enterprises choose to make the transition from monolith to composable in different ways, but one thing all successful transformations have in common is that they don’t push it too far down the road.The litmus test is done. If you answered “yes” to most — or all — of these questions, then it’s time to talk with us about moving from monolith to composable. Here’s the good news: When you choose to make the transition to composable, you’re future-proofing your organization. According to Andreas, “it’s the last replatform you’re going to need.”
4 ways your teams can benefit from a composable DXP
Whether you’re a company leader, developer or a creative director, chances are that you understand the importance of having good content on your website and other communication channels that your organization leverages. If you’re like most mid-sized to large companies, you have a complex mix of content that’s used for diverse purposes: marketing and promotions, internal communications and investor relations, delivering personalized customer experiences, engaging potential customers and more.Traditionally, having relevant omnichannel content has been disjointed, time-consuming, difficult to manage, slow and inefficient. Compounding these issues is the accompanying frustration from developers who are leaned on to edit code when any little thing needs to change, and from marketers who can’t get updates made fast enough.Fortunately, there’s a much easier and streamlined way to manage and publish content these days with digital experience platforms (DXPs) built with composable architecture and headless content management systems (CMSes). An increasing number of organizations are transitioning to this type of system for benefits including agility, speed and scalability. Last year, Gartner predicted that more than half of mainstream organizations would invest in composable applications by 2023.Before delving into the benefits of composable, let’s first take a look at what a DXP built on a composable architecture actually is.What is composable architecture?Composable architecture is a way of separating the front-end (what you see on the display) and the back-end code (development) of a website, making development faster and easier. This separation means the front and back end can be developed independently of each other, making deployments simpler and more efficient.A composable architecture typically has a headless CMS at its core. This type of CMS provides an application programming interface or API that the front-end code can call to fetch data from the back end. What kind of tools or APIs are used in a composable DXP?In addition to the headless CMS, which is the central hub of the composable DXP, this type of platform will include a wide variety of microservice-based APIs based on what your organization needs. The beauty is that you can pick and choose the best options in each of these areas below in addition to others without being locked to a specific vendor:E-commerceAsset managementCustomer managementOmnichannel managementMarketing automation and analyticsContent workflowsCustomer engagementAI toolsIn a nutshell, composability means you have the freedom and flexibility to create a unique DXP that’s tailored specifically to your organization’s needs by choosing the right microservices. You might think of these microservices as being an arsenal of tools that can help you elevate your organization above the competition.If the idea of switching from a traditional, monolithic platform to a composable DXP seems daunting at first, keep in mind that the transition doesn’t have to take place all at once. Instead, it can take place one piece (or API) at the time as you add different products and services to the headless CMS. Compatibility enables this kind of targeted transition because each component or API works independently of every other component. As you might imagine, this has many advantages. One of the biggest is that a failure in one component doesn’t bring down the whole system.A composable DXP provides many significant benefits for your organization’s executive, creative and technology teams. Here are four key features of composable DXP and how each team benefits.Very little to no coding neededWith a composable DXP, most changes don’t require the technical knowledge of a developer. Here’s how this benefits teams at every level of your organization.Executive teamsWhen marketing and technology teams can focus on what they do best, there should be less friction between the two. This reduces frustration levels and makes for happier employees, helping you retain your best workers.Creative teams Composability will empower marketing teams to create, change and publish content without having to have any technical expertise. Content is easy to access in one central location. Marketing teams will no longer have to create tickets and wait for developers to get around to their requests. Instead they’ll create campaigns and push a variety of content types to multiple platforms and channels with greater speed and efficiency.Technology teamsThe time developers typically spend making everyday fixes and working with code to launch new campaigns will be freed up so that they can focus more time on creating user-friendly digital experiences for customers.ScalabilityDo you plan on adding e-commerce down the road? Want to add a mobile channel? Want your website to have chat functionality? It’s very easy to add new apps and services to your websites and other channels with a composable DXP. Executive teamsThe business can more easily expand its product and service offerings without having to worry about downtime for websites and other channels. You can focus on growing the business with confidence that your content management system has the agility to keep up. Creative teamsAs new marketing automation and tools become available, it will be simple to add these to your API mix.Technology teamsIt will be easier for IT to scale apps because services can be deployed independently. Tech can focus on one type of digital service, while others continue to work as normal. There’s no need for rushed overnight deployments or site downtime to release new functionality.SpeedComposability improves speed in several different ways, including speed of publishing content, speed of implementing campaigns and speed of reaching business goals.Executive teamsBusiness goals can be fulfilled faster, whether you aspire to expand into a new region or roll out new products and services. What better way to stay a step ahead of the competition?Creative teamsMarketing leaders will be empowered to launch campaigns and publish content much faster. Again, there’s no waiting on IT to make changes. They can also push content to multiple sites without having to totally recreate content from scratch. Composability makes it easier to create a content block for one site, and then quickly push that content to other sites and channels.Technology teamsSlow implementations become a thing of the past, as IT teams focus their efforts on targeted API functionality, rather than being bogged down with tickets for minor edits and updates.Improved customer experiencesWhen relying on a composable DXP, delivering content that’s personalized and relevant becomes the status quo instead of the exception, boosting customer satisfaction. Executive teamsThe business can expect to reap the rewards of improved customer experiences. A current Forrester Total Economic Impact (TEI) study demonstrates an ROI of 295% with a composable architecture.Creative teamsMarketers will no longer be hindered by the rigidity of a monolithic CMS. Instead, they will have unlimited access to all the tools they need for success with the freedom to expand their toolkit any time they choose.Technology teams With less time spent on repetitive requests, the IT staff can put its expertise to work in key areas which will have the biggest impact on customer satisfaction.FAQsAs a recap and to answer additional questions you may have, here are a few frequently asked questions about composable DXPs.Am I tied to one vendor that determines what solutions I can use?No, a composable DXP gives you the freedom to choose the best solutions, regardless of vendor.How do I know all the components that I want in my composable DXP will work together?Composable providers understand the importance of their solutions being able to integrate with other APIs and have worked to address this issue. Composable providers ensure their solutions can seamlessly enable multiple APIs to work together by making them easy to plug in with software developer kits (SDKs) or one-click connections.What if I want to keep tools on my current websites that are working?With a composable DXP, an organization can choose the best options and even keep using some of the existing solutions that are already working. You are no longer locked into using just the services and apps that your vendor or platform supports.What is the first step in transitioning to a composable DXP?Begin by thinking about the apps and services you would want to have in your DXP if the options were limitless and then write them down. Be sure to get input from executive, creative and IT teams before searching for products and scheduling demos.Learn moreLearn more about composable DXPs in our guide, “What is a DXP? Understanding digital experience platforms.”Schedule a free demo to see how Contentstack’s composable digital experience platform can benefit executive, creative and technology teams at your organization.
Adopt a Modern Digital-first Marketing Strategy
Content is consumed everywhere by everyone all at once. If only we lived in a multiverse, where multiple versions of your marketing team could crank out personalized omnichannel content at the speed your customers demand. Watch this webinar to learn how a composable DXP gives your teams the (multiversal) powers and tools they need to create the content you need to get the results you want.
Developers
Learn how to build better digital experiences
3 ways tech and business teams can help each other through a transformation
Not all great tech transformations are brought to the table by a developer, engineer, CTO or other technical person. We see great projects kick off because someone in marketing, sales or customer success raises the flag for change. Sometimes business people can see opportunities that aren’t as plain to the tech teams.That’s what happened when Booking.com decided to transition off its old systems to a headless CMS. Juliette Olah, senior manager of Editorial, realized that her teams had produced thousands of pieces of content over the years — but the capabilities of their current technology significantly limited the value that content produced in their local markets and possibilities for the future.Listening to her “People Changing Enterprises” episodes, I admired the way Juliette united Booking.com’s product and editorial teams from the beginning to pull off their transformation. Business and tech can either be each other’s biggest advocates or frustrating roadblocks.To avoid the latter, these are three examples of how tech and business teams can support each other throughout a transformation.Thoroughly debrief at the onsetAt the beginning of every project, we encourage organizations to sit down with their cross-functional teams and level set. Business and tech have their own KPIs and goals to achieve. In a project that bridges the two, there should be a frank discussion, ending in clear, written requirements of process and goals for both sides.Once Juliette realized a tech transformation was the answer to the editorial team’s needs, she became the living bridge between the editorial and product teams. Sitting down with tech stakeholders, they talked through what Juliette called a “comprehensive 360 view of the benefits to the technical side of the platform”:The editorial team’s strategy and the justification behind the new technologyReal-life examples of what execution would look likeThe business value of a central headless CMS would bring to each local marketOpportunities they were currently missing out on because of their current toolBecause she had clearly done her homework and demonstrated the need on both sides, the product team was eager to get started.Partner up to find and test new toolsFinding and testing new tools is an easy way for business and tech teams to partner effectively. When the new CMS was in place, the teams at Booking.com partnered to try out the new tool to make sure it worked for both sides.At Contentstack, once a new solution is initially developed, we pull in our business partners for User Acceptance Testing. They can test, catch bugs, or point out which workflows function trickier than anticipated — versus the tech teams doing it all themselves.Additionally, when you’re on the hunt for new tools, tag a business partner in for their opinion. From a different mindset, they might be able to raise questions or point out benefits you didn’t consider. Work together to phase out what isn’t neededA transition to composable is the perfect time to evaluate what tools you’re bringing into the new environment — and which ones you should retire. This is another area that tech and business teams should work together.A few years ago, we bought an analytics tool for the organization to use on their reports. It was low-cost and met some of our needs upfront, so we decided to take a chance on it. Six months down the road, we were spending a huge amount of time trying to force the tool to work. When a business person came to me and admitted the tool wasn’t helping their team meet their objectives, we decided to look into something else. On a composable project, it’s not always clear on the back end if a tool is working for teams as they need. That’s where our business partners come in. It’s a partnership.Babe Ruth once said, "The way a team plays as a whole determines its success. You may have the greatest bunch of individual stars in the world, but if they don’t play together, the club won’t be worth a dime."It’s easy for business and tech teams to work in silos, but working together produces more value. Especially in a tech transformation, the two teams are different sides of one coin. Find ways to bridge the gap and you’ll see much more value in your resulting tech stack.
From legacy systems to microservices: Transforming auth architecture
Contentstack receives billions of API requests daily, and every request must be validated to be a valid Contentstack identity. It is a common industry practice to achieve this using some sort of “identity token" for every request. Imagine having multiple types of identity tokens, such as session tokens, OAuth tokens, delivery tokens, management tokens, etc. The problem of securing billions of API requests daily can be challenging. We decided to address this by spinning up a new team that handles the complex problems of user authentication and authorization in a token-agnostic platform.Our transition journey Contentstack started as an API-first headless CMS platform that allowed content managers to create and manage content while simultaneously and independently enabling developers to use Contentstack's delivery API to pull that content and render it to create websites and applications. This means that Contentstack’s traffic increases proportionately to the traffic received by our customers' websites and applications.With increased traffic and usage, we catered to various new use cases by developing new features. These features were powered by a set of microservices, each catering to a particular feature domain and needing support for processing multiple identity tokens that had roles and permissions associated with them. The whole system had turned out to be quite complex, and performing auth had become a great challenge. This prompted us to redesign our auth architecture, which addressed the issues of being a token-agnostic and low-latency platform.Read on to learn more about this journey and how we have been able to:Transition from a monolith to a low latency microservices-based auth (authentication plus authorization) and rate-limiting architecture.Set up centralized authentication for multiple (any domain) microservices that are part of the same Kubernetes cluster.Set up decentralized and self-serviced, policy-based authorization for internal services and teams.Increasing feature sets increased domain microservices, which increased the complexity of performing auth.Monolithic auth architectureMonolithic architectures can be difficult to maintain, scale and deploy. In a monolithic architecture, user authentication and authorization are typically tightly coupled with the application code, making it difficult to implement and maintain robust security measures. Monolithic architectures often rely on a single authentication and authorization mechanism for the entire application, which can limit the flexibility of the system to accommodate different types of users or access levels.Performing auth in a typical monolithic architecture.In monolithic architectures, the steps involved in auth are the following:Users use their credentials at the client to generate a session token or use an existing identity token to generate other identity tokens.Users then use the generated identity token to perform a business operation by making a request to the application server.Once a request is received at the application server, the authentication middleware authenticates the token and forwards the request to the business module.The business module performs the business operation based on the authorization rules applied to the user identity.Problems with monolithic auth architecture:Authentication and authorization logic is mixed with the business logic.Changing the way an identity performs an operation on a resource involves a change in the associated auth-related logic.Each domain individually implements the authorization logic, causing a difference in implementation.Since authorization logic is deeply nested in business logic, we lack visibility into authorization rules applied to a resource.Shipping of new authorization logic requires a fresh deployment of the application image.New microservices require knowledge of various identity tokens and resource authorization rules to be applied.Microservices auth architectureMicroservices offer a more flexible, modular approach that allows for easier maintenance, scalability and deployment. With microservices, each service can be developed, deployed and scaled independently, allowing for faster time-to-market, improved fault tolerance, and better alignment with modern development practices. Additionally, microservices offer more efficient use of resources and better support for diverse technology stacks.AuthenticationWhy centralized authentication?Centralized authentication is a security model in which a central authority manages authentication, such as a server or service, rather than it being distributed across multiple systems or applications. There are several reasons why centralized authentication is commonly used and considered advantageous, including increased security, simplified management, improved user experience and lower costs. While there are some drawbacks to centralized authentication, such as the increased risk of a single point of failure and increased complexity in managing the central authority, the benefits often outweigh the risks. Centralized authentication and rate-limiting at the edge of the service mesh.The steps involved in the centralized authentication process are the following:Any incoming request to the Kubernetes cluster first lands at the Istio ingress gateway.The request containing the identity token is proxied to a central authentication gRPC service with the help of envoyproxy's external authorization filter.The central authentication service queries Redis with the identity token and metadata associated with the request.Redis responds with the identity associated with the token and the current rate-limit count based on the request metadata.The central authentication service responds to Istio with either of the following:Authenticated response with user context attached to the request in the form of request headersUnauthenticated responseRatelimit exceeded responseAn authenticated request containing the user context is then forwarded to the upstream service.Advantages over the monolithic architecture:Easier to onboard newer microservices to central authentication service by using label based istio-injection.All requests are authenticated and rate-limited at the edge of the service mesh, ensuring that each request entering the cluster is always rate-limited and authenticated.The request forwarded to the upstream microservice has user identity context attached to it in the request headers, which can be further used for applying authorization rules.Keeping centralized authentication eliminates the problem of multiple mutations performed by the upstream microservices on the identity of the token.Authorization Centralized authorizationWe tried a model where along with authentication and rate limiting, we also added authorization as a responsibility of the central authentication and rate limiting service. The service would first identify the incoming request’s identity from the token and apply rate limiting based on the request metadata. Once the user identity is known, authorization rules could be applied to the user’s identity, thereby performing the entire Auth at the edge of the service mesh. Problems with this model are the following:This model could only perform basic authorization at the edge based on the request metadata provided, such as validating organizations, stacks, etc. However, it could not perform fine-grained authorization, such as finding out which content types the logged-in user had access to.For RBAC, each domain has its roles and permissions associated with it; performing authorization for such requests requires knowledge of the upstream domain and leads to the addition of domain-specific logic in the centrally managed domain-agnostic platform.With newer domain microservice additions, this again would lead to the problem of lacking visibility into authorization rules applied to a resource.Distributed authorization with central authorization serviceWe then tried implementing a model where we distributed authorization to the upstream microservices where each upstream microservice makes a call to a central authorization service. The authorization service has access to all the roles and permissions of different domains and was able to give appropriate authorization results. Authorization could now be performed from the upstream service’s business module by making a network request using Kubernetes cluster networking to avoid making a call over the internet.Problems with this model are the following:The central authorization service becomes a single point of failure.Any change in the API contract defined by the central authorization service requires all the upstream services to abide by it and makes shipping these changes independently a complex task.Performing authorization adds a network hop, thereby increasing the latency.Distributed authorization with the sidecar patternLearning from the previously discussed disadvantages, we wanted to build a model that had authorization distributed, low latency and made shipping authorization logic an independent activity. ArchitectureThe architecture involves the following components:Auth sidecarCentral policy serviceAuth SDKArchitecture for authorizing an authenticated request with the sidecar pattern.Auth sidecarThe auth sidecar is a gRPC service that gets injected along with the microservice’s application container in the same Kubernetes pod. Let’s understand how this architecture helped us tackle the previously mentioned problems.Single point of failure: The auth sidecar service runs with the application container in the same pod, and any case of failure is only limited to the current pod. Restarting the pod gives us a fresh set of application and auth sidecar containers.Independent delivery: Since the auth sidecar service container is shipped along with the application container, the application service can decide which version of the sidecar image to use, thereby making the delivery of newer versions of the authorization sidecar independent.Low latency: There is no network hop involved in making a gRPC call to the auth sidecar running in the same pod. This helps the application to get the authorization result with very low latency (in a few milliseconds).Updating authorization logic: The auth sidecar periodically downloads fresh policy bundles; any time there is a change in policy bundle coming from the central policy service, the auth sidecar updates its local policy cache with the new bundle.This way, updating authorization logic does not involve a fresh deployment/restart of the application container.Components involved in auth sidecar Responsibilities of the components involved in the authorization sidecar.Aggregator: The responsibility of the aggregator is to fetch authorization-related data for the current identity based on the metadata provided by the application service in the gRPC call. It then aggregates it to be evaluated against the authorization policy.OPA Engine: We use OPA (Open Policy Agent) to periodically download fresh policies and evaluate the policy path mentioned in the gRPC call against the aggregated data.Central policy serviceThe central policy service is a repository of policy bundles (*.rego files) which are independently managed by the domain microservices. The maintainers of the domain microservices create these policies for various resources that need authorization. Since these policies only involve rules, it greatly increases the visibility of authorization rules being applied to a particular resource.Auth SDKThe auth-sdk is an internal library that we developed that helps the developers of upstream microservices to easily communicate with different auth components. It can do the following:Extract user identity and other useful information attached in the request headers by the central authentication serviceDiscover various auth components and streamline communicating with themExpose different helper methods to perform any auth-related activity on behalf of the application serviceRedesigned (new) architecture:Tracing the request lifecycle in our redesigned auth architecture.ConclusionMicroservices-based architectures can help address some of these challenges of monolithic architecture by separating user authentication and authorization into individual services, which can be developed, deployed and maintained independently. This approach can provide greater flexibility, scalability and security for user authentication and authorization.However, it's important to note that transitioning to a microservices-based architecture can also come with some challenges, such as increased complexity and a need for more advanced DevOps practices. Proper planning, implementation and ongoing maintenance are crucial to ensuring a successful transition.
What developers should know about composable DXPs
As enterprises strive to create a unified digital experience for their customers, it is essential to understand the fundamentals of composable DXPs. This blog post will explain what these platforms are, how they work, and how they can help create an effective customer experience. What is a composable DXP? A composable DXP (digital experience platform) is a technology stack that supports the development and deployment of applications across various channels such as web, mobile, voice assistants, wearables and more. It consists of different components such as content management systems (CMSes), microservices architecture, APIs, analytics tools, customer data platforms (CDPs), marketing automation tools and more. These components work together to enable developers to rapidly build and deploy applications with minimum effort. How does it work?The key to making a composable DXP successful is having the right components in place. Components of a composable DXP include:A CMS that is the foundation for managing content across multiple channels APIs that provide access to data stored in other systems such as databases or cloud services. Microservices architecture that helps break down large applications into smaller services that can be deployed independently. Analytics tools that allow developers to gain insights into user behaviorMarketing automation tools help automate tasks such as sending emails or messages on social media platformsA customer data platform to store customer data securely and easily access it when neededBenefits of adopting a composable DXPUsing a composable DXP has several benefits for developers including:Increased agility: With a composable DXP in place, developers can quickly build apps without spending time on coding from scratch or integrating multiple technologies together. This increases agility by allowing them to respond quickly to market needs or changes in customer preferences. Scalability: Composable DXPs are highly scalable so they can handle large amounts of traffic without compromising performance or reliability.Cost savings: Using a single platform reduces costs by eliminating the need for multiple technologies and license fees associated with them. Challenges for developersIntegrating multiple components One of the biggest challenges with composing a DXP is integrating all the different components together in a way that works seamlessly with each other. This requires extensive knowledge of web technologies, coding best practices, and design principles. It also requires developers to have an understanding of how different software interacts with each other and how they can be integrated into a single platform. Additionally, if there are any compatibility issues between two components or systems, then the developer will need to find a workaround or replace one component with another. Maintaining quality standards Another challenge that developers face when implementing a composable DXP is maintaining quality standards throughout the process. Since they are dealing with multiple pieces of software that may come from various sources, it’s important to ensure that all components meet certain quality standards before they can be used in production. This means making sure that all code is up-to-date and bug-free; all third-party APIs are secure; and all data sources have been tested for accuracy and completeness before being integrated into the platform. Testing for performance issues Finally, when creating a composable DXP, developers must also test for potential performance issues. As more components are added to the platform, there is an increased likelihood that some parts may not perform as expected due to memory usage or runtime errors. Therefore, it’s important for developers to thoroughly test their composable DXP before launching it in production to ensure its stability and eliminate any potential issues from arising later on down the line. ConclusionImplementing a composable DXP offers many advantages over traditional monolithic applications but comes with its own set of challenges. Developers must make sure each component functions properly and meets quality standards before being implemented into the system. They must also test their platform for potential performance issues before launch. You can overcome these challenges by carefully planning your architecture and understanding how each component integrates with one another so you can create an effective solution for your customers’ needs.Learn moreLearn more about going composable in our guide, “How to go composable in 6 steps.”Schedule a free demo to see how Contentstack's composable content experience platform can help your organization benefit from the flexibility and scalability of a composable DXP.