A Crash Course for Composable - Introduction
Welcome to a new series on Sitecore Spark: A Crash Course for Composable. With composable DXP (digital experience platform) being a thing in the martech space, I've set out on a journey to modernize my developer skills. I've traditionally been a backend developer (heavily focused on MVC), but with headless and composable solution architecture quickly about to become the norm, I've begun to explore newer technologies and architectures - specifically Next.js, React, and modern JavaScript (ES6+).
With so much catch up to do, I'm dedicating the remainder of 2021 to help my fellow Sitecore backend developers modernize their skills for the composable future. This series will cover the following high-level topics:
- JavaScript Modernization - getting up to speed with ES5, ES6, and beyond
- Why Choose React? - an overview of the React library
- Getting Started with React - succinct introductions to React concepts with real code
- How to Lose Your Head and Stay Composed - all the ways backend devs can get started with headless architecture
You'll notice a focus on JavaScript and React - this isn't meant to imply that frontend technologies are the way of the future - but they are a major part of it. By better understanding frontend technologies, all developers can have intelligent conversations around headless and composable architectures.
What is Composable?
Digital marketing platforms have traditionally been built, marketed, and sold as monolithic platforms that attempt to provide every feature, service, and option that digital marketers may need. While an all-in-one platform has advantages (one price, one codebase, one support call, simpified training, etc.), the reality is that most monolithic DXP platforms are rarely utilized over more-optimized invidual services and solutions (such as Google Analytics or Hubspot).
Composable DXP simply breaks each piece of the digital marketing platform into modules that allow end-users to mix-and-match functionality. One product handles content management, another handles DAM, another covers analytics, etc.
This implies cost, training, and usability advantages - end-users can use the tools they are immediately familiar with while bringing in new pieces to learn one at a time. Unfortunately this adds potential complexity to the implementation; making different systems work together means additional effort for development teams. This will be partly addressed by headless concepts and API standardization, allowing developers to connect disparate systems to function together intelligently.
Stay tuned for part one: JavaScript Modernization - The Basics in the coming weeks.
Do you have questions, comments, or corrections for this post? Find me on Twitter: @BrandonMBruno