The Expanding Universe of Software Development

These days I often think about the expanding universe when I see what's going on in software development. It keeps expanding like the universe. Software development didn't really start as the universe started from the Big Bang. Rather it started quietly in a single system but the distributed nature of software architecture made it possible to expand. What we could do before with only in a monolithic system, can be done today in distributed systems over the internet or we say cloud these days. For example, a few years back it was difficult to bring multiple systems over the Internet under the same Identity Provider. That is not the case anymore. Today, we can use OAuth2 and OpenId Connect to create Single Sign On (SSO) for multiple systems.

I had the opportunity to work on many Digital Experience and e-commerce projects for many years. It's interesting to see how software systems are evolving where some systems are shrinking and other more specialized systems are forming. This year itself I worked on four CMS systems (Optimizely, Sitecore, Sanity, and ContentFul), two eCommerce (Optimizely Configured Commerce, Sitecore OrderCloud), and many system integrations associated with that. Let's dive into the discussion of changes happening in system development.

Content Management System (CMS)

It is pretty clear by now that all future CMS will be headless. To stay relevant in the cloud-based distributed architecture a CMS has to work as a headless service. A headless CMS is more than just database schemas exposed through APIs. Besides content modeling and storing content, a CMS enables users to manage content publishing through workflow, content control through content locking, multi-language content generation, content generation through generative API, preview content generation, and many more things that are focused on content only. It is clear that future CMS will be specialized in managing content.

E-Commerce

E-commerce systems ventured into the headless category before CMS. Most of the e-commerce platforms are Headless API First may or may not be SaaS. To be part of the composable architecture it's important to be Headless but not necessarily it has to be a SaaS platform. There are certain advantages if a platform is SaaS, for example, core platform feature implementation is more seamless than a non-SaaS platform but customizing the platform is sometimes challenging. Many Headless e-commerce platforms today originated from monolithic e-commerce platforms and architectural patterns used in the monolithic time still drive some way after moving to SaaS. In a pure Saas platform, you will be using Webhook, Middleware, Events, etc. to customize the platform features where the custom codes are deployed and hosted in a different environment and don't mix up with the platform code. That may not be the case for platforms that originated from a monolithic architecture because the patterns for customizing code in those platforms are ingrained in the code. I work with Optimizely Configured Commerce. It is a platform that originated from monolithic architecture. It is Headless and SaaS but we need to deploy code to the SaaS system when we want to customize. Whereas, Sitecore OrderCloud was started as SaaS and follows the patterns that don't require us to deploy code in the OrderCloud environment for customization. This discussion is not to say one platform is better than the other. It's just that the architectures are different.

E-commerce platforms itself is breaking up into special services. Thing that was a core part of an e-commerce platform are becoming specialized services. Who thought checkout would be a specialized service? Optimizely Commerce is now integrated with Bolt Checkout that eliminates fraud, improves conversions, creates royalty, and embeds checkout everywhere (QR Code, Social, Email, etc.). Similarly many e-commerce features like Payment, Promotion, Pricing, Search, Product Recommendation, etc. today are expanding as services.

Frontend As a Service (FEaaS)

The scene for Frontend Development exploded last decade with the advancement of browser technologies and the invention of frontend frameworks React, Angular, Vue, and meta frameworks like Next.Js. It helped to decouple the frontend from server-side services and today frontend is offered as a service hosted independent of server-side services like headless CMS or e-commerce. There are companies like Uniform and Builder.io that let you build components and pages in your language of choice and host them. You can connect your frontend to any headless CMS or e-commerce either through their connector or build your own. The frontend used to be part of CMS and used for visual editing. Today we are seeing it is separated from CMS so much so that major CMS products are building their own FEaaS tools. Examples of that are Sitecore Component Builder and Optimizely just announced their release of Visual Builder as part of their SaaS core offerings.

The CMS product company Sanity took a different approach than building Visual Builder. They are building a standard specification called Content Source Maps. The idea is to include the metadata of the origin of the field, document, and dataset with the content so that when users want to change the content they can be sent to the origin of the data. This approach is more generic than just building Visual Builder because in this way multiple data sources can be connected. Here is a nice video from Sanity showing how using Content Source Maps and Vercel Preview Build someone can accomplish visual content editing.

Search

The Public facing search is probably the earliest in service-based architecture. Google search, even before that Yahoo search was available to everyone for searching internet content. Both Google and Microsoft provided their search solutions to corporations. Although the website crawler based search is useful it doesn't solve all search problems. Specialized indexing of data is needed when it comes to supporting data retrieval that is not just web pages. Every e-commerce platform needs to provide support for product search. In CMS platforms content search enables content authors to find content easily. The real breakthrough came when the open-source Apache Lucene and Solr was released in early 2000 and Elasticsearch was released in 2010. Many platforms have used these open-source search technologies to satisfy the search requirements of the platform. Later many companies created search services based on these search technologies. Some popular services are Algolia, Relflektion (aka. Sitecore search), SearchStax, Search & Navigation by Optimizely.

Things got interesting when personalization was mixed with search. Originally search relevance ranking was based on the keywords and weight of the fields, but with personalization included it means relevance can differ from person to person. Today specialized search services collect visitors' data to render personalized search results.

To make it easier to render the results search services also include frontend widgets and javascript-based SDK. This reduces the work for developers significantly. We can drop a search bar on the webpage header that will take inputs from users and render search autocomplete and predictive results and use the facet widgets on the search result page to narrow down the search further.

Every specialized search service comes with an admin portal to manage search-related administrations. You can add multiple websites for search crawler to crawl, manage field boosting, add synonyms or words to ignore, create facets, etc. Also, the search admin provides the analytics data that you can see to understand website users' search behavior.

Product Recommendations

In e-commerce systems, product search is essential for users to find the product they are looking for. Search can also help sellers to upsell and cross-sell products. Product recommendations help users discover products based on search, product browsing, or previous purchases. Most online retailers today use product recommendations for better conversion. There are different approaches to using machine learning algorithms to discover products that users possibly will like. Effective approaches are Collaborative Filtering where the user's product browsing behavior is compared with other users with the same behavior and discover products that other users liked. Collaborative Filtering also uses item-to-item comparison to discover products. Another approach is to use Content-Based Filtering. If the users are reading certain content the related products can be offered to them. Some system uses Hybrid Filtering where both content and users' preferences are looked at. The modern Product Recommendation systems come with widgets to recommend products. Familiar widgets are Frequently Purchased Together, Related Products, etc.

Experimentation

Experimentation is a way to understand user's preferences from sample data. In the world of web applications users are randomly presented with two or more scenarios and collect the data to see which scenario is most popular. The experimentation services use statistical methods that calculate the winner of an experiment with certain statistical confidence (probability like 95% cases the selection of winner makes sense). If more than two scenarios are included it is called multivariate testing.

Many popular Experimentation as a service are available in the market. Sitecore offers Personalize for Experimentation and Personalization. Optimizely offers Optimizely Web Experimentation Experimentation and Personalization. There are two ways to integrate a website with an Experimentation platform, 1) including a Javascript beacon and 2) using APIs. Using the Javascript beacon is the easiest way to collect data from users' browsing activities. If it requires to collect and personalize for more complex functionalities API methods should be used. All experimentation platform provides access to data analytics through data visualization.

Personalization

Personalization involves bringing together multiple services to provide a personalized experience to users. It can include Experimentation, Product Recommendation, Content Recommendation, Search, Email Campaigning, and more. Personalization also depends on collecting customers' data and using the data in recommendation engines to provide tailor-made personalized experiences. Most Digital Experience platforms today make use of customer data. Optimizely Data Platform (ODP) is integrated with many of its products and independently available as a service. Sitecore offers Customer Data Platform (CDP) formerly known as Boxever.

Integration

Integration is an essential part of composable architecture. All services discussed above are in some way integrated to create an overall experience for users. But integration as a service like a SaaS platform is a fairly new entry in the composable world often mentioned as iPaaS (Integration Platform as a Service). Integration as a special platform used to be proprietary middleware services are opening up to be available as services and provide a more low-code/no-code way to connect with a variety of services. Some notable names are Workato, Boomi, TIBCO, Mulesoft, Azure Logic App, etc. Many companies are adding their integration into these platforms to be readily used by other platforms. Sitecore has created an ecosystem called Sitecore Connect to make it easy for customers to integrate with Sitecore products and to add custom integration for Sitecore implementations. Sitecore built Sitecore Connect on Workato. Hence all Workato integrations are available to use as well as Sitecore integrations.

Security & Identity

In composable service-based architecture securing multiple services is complex and critical. Thankfully recent development of security protocols OAuth2 and OpenId Connect helped companies to create services that can be used to implement Single Sign On (SSO). Some notable services are Okta, Auth0, Google Firebase, Azure AD, etc. Sometimes in the composable system, there are needs to integrate with legacy systems and may require using SAML. Authentication and authorization shouldn't be the only things to consider when securing systems built with composable services. We should be mindful of keeping track of the audit trail in case of vulnerability arises.

Another aspect of security is compliance. SOC (Service Organization Control) is the most important compliance framework for service-based composable architecture. SOC compliance ensures that the customer data stored by SaaS services are protected. Other specialized compliance apply for specific domains. For example, services need to be HIPPA compliant if it is used for Healthcare implementation. E-commerce application that uses credit card needs to be PCI compliant. There are service-based payment platforms such as Spreedly, TokenEx that are specialized in handling payments and PCI compliant.

Generative AI

The latest addition to composable services is Gen AI. The release of ChatGPT showed the power of Gen AI. There is a surge of interest to include Gen AI in Digital Experience Solution. In the last year or so all CMS platforms integrated Gen AI to help generate content in the platform. Sitecore released the ChatGPT integration with XM Cloud CMS that enables marketers to rapidly create content for various user segments with the help of Gen AI. Optimizely recently announced Optimizely One an Operating System designed for marketers and Opal the embedded AI across the entire marketing lifecycle. Opal includes Gen AI powered by ChatGPT as well as Machine Learning for Content Recommendation, Product Recommendation, Content tagging, and more. Sanity released Sanity AI Assist an assistant for Content Authors powered by ChatGPT. In the coming future, we expect to see integration with Gen AI for audio and visual asset generation.

Challenges

Like monolithic architecture composable architecture has its challenges.

System Reliability: A composable architecture comprises many service-based systems that run independently. More services mean more failure points. A monolithic architecture provides a common interface for finding issues using logs. Since these systems are run by separate entities it is challenging to troubleshoot the issues.

Security Concerns: As with any system, introducing more components and connections increases the potential attack surface. Ensuring each module is secure and that there are no vulnerabilities introduced during integration can be challenging.

360 Degree View: In composable architecture separate systems collect customer data. It's difficult to consolidate the data from different systems and form a 360 degree view of users' interaction with the system.

Standardization: Composable systems built from different vendors use different architectures to build the services. Integrating services from different vendors can be challenging due to the use of different technologies and standards.

Ownership: The services in a composable system owned by different vendors require customers to work with multiple vendors can create challenges when there is a problem with one or more systems.

Cost: The licensing or the subscription of SaaS-based systems involves dealing with multiple vendors and can be complicated to manage the cost of the overall system. In a monolithic system the cost the constant for a period. In a SaaS system where cost is calculated based on transactions, it is difficult to predict the overall cost of the system, and sometimes cost can be surprisingly high if the system is not implemented properly.