Sonja_Kotrotsos_Headshot.jpeg

Sonja Kotrotsos

Sonja heads up the EMEA Go-To-Market for Contentstack, with two decades of industry experience in the areas of marketing, business development and services. Sonja previously worked for traditional CMS vendors Bloomreach and SDL. Sonja is a mother of three and lives near Amsterdam, The Netherlands.

Posts by Sonja Kotrotsos

Jun 03, 2020

6 Ways to Identify Modern Enterprise Software

As digital business expands, so does the enterprise software market. The good news is that modern software options can support any digital experience you dream up. The bad news is that finding these tools can be like finding a needle in a marketing buzzword haystack. One term that is quickly becoming part of software design and marketing lingo is MACH (microservices, API-first, cloud-native, headless). MACH technologies are built from the ground up to be modular, pluggable, scalable, and to support a continuously evolving digital experience. Enterprises are eager to adopt these new principles. 80% of 2020 IT budgets have cloud applications as a top priority while legacy system integration was only a priority in 24%. Legacy vendors have noticed this trend, and many have tried to make “quick-fixes” when it comes to cloud and APIs, spinning their marketing message to match. When everyone is using the same language, it can be hard to determine which technology is the real deal. Here are six ways to look behind the marketing curtain and select the best modern tools for your experience. 1. No “All-in-One” Messaging Back when “digital business” meant merely having a website, it made sense for one platform to be able to support all of a company’s digital needs. As the scope of digital businesses expanded — from marketing to commerce to customer service and everything in between — so did the amount of functionality needed to manage it. Some larger platforms that would like to keep their business model of being the one-stop-shop for digital, have tried to add on more functionality to keep up. They build their product with the intention that customers will exclusively use the functionality in the platform, and don’t make it very easy to substitute with other tools. This means that if you choose a platform for its best features, you also get locked into the not-so-great ones. Digital Experience is too varied for any single vendor to master every part of it. As digital becomes a major way that businesses differentiate themselves, the chances of finding a single platform that aligns perfectly with every goal of an enterprise’s roadmap are slim. MACH tools address this issue. Built to integrate at a functionality level, they aim to be a part of a “composable enterprise” where a business has the freedom to assemble a toolkit that fits their unique needs. They support modern approaches to complex projects, such as hyper-personalization, that require data orchestration across multiple tools and teams. MACH vendors focus on proving the best solution for their digital experience domain and integrating easily with everyone else. What to look for: No “all-in-one” messaging that claims the platform can manage the entire digital experience. Documentation and guides on integrating with other tools, especially in the classes of technology most crucial to your ecosystem. The five factors listed below exist in technologies built to integrate from the ground up. 2. API-First, Not API-Added Across functionalities, over 80% of enterprise employees say that data integration is “critical” or “very important” to business. Even if the “all-in-one” platforms want to be the single source of experience functionality, they know they aren’t the only source of data to power that experience. Every enterprise software on the market will provide some sort of API to share data. However, there is a big difference between platforms that have added APIs to a monolithic codebase and ones that have been built with APIs from the ground up. APIs are often compared to Lego bricks, in that their standardized nature lets you click different applications to each other. Some platforms were originally built as full, monolithic boxes before APIs became a standard design practice. They have added APIs by gluing Lego bricks to the outside of this box, and wiring up the inside of the box to push and pull specific data through this brick. For some tools, like ERP and CRM, this push and pull of data is all that is needed. For customer experience tools, like content management and ecommerce, there needs to be more flexibility than a few specific Lego bricks can provide. MACH tools are built with APIs from the ground up, so that every functionality — across the management console, product UI, back-end, etc. — is accessible through an API. The entire solution is built with Lego bricks, and a business can organize these modular functionalities to fit unique plans, projects, and other digital experience tools. What to look for: There is documentation available for multiple APIs. There are no software add-ons or plugins; functionality is extended exclusively through APIs. A product history that has always been API-first. No announcements of “introducing APIs.” If specifically a headless technology, there should be no presentation layer available. A presentation layer that has been decoupled is a sign that the product has added APIs. 3. Everything as a Service The API-first design, combined with being cloud-native, allows MACH software to provide functionalities as a collection of microservices so each microservice can be individually tested, updated, deployed, and scaled. This is why most MACH software is available as Software-as-a-Service (SaaS). In this subscription licensing model, the vendor centrally hosts the application and provides access via the cloud. Resources, and the cost of those resources, can be easily scaled up and down as needed. Just as having an API doesn’t make you API-first, having a cloud offering doesn’t make you SaaS. As more businesses head towards cloud architecture, legacy software vendors are offering their software in the cloud as managed services. The vendor will take care of the hosting, but the software still requires custom installation and manual upgrades. SaaS, on the other hand, requires no installation. Because individual microservices can be upgraded and delivered instantly, updates are continuously delivered. There is no version 1, version 2, version 3, etc. of the software that requires re-installation — the software is a continuously evolving application that is automatically up to date. Some legacy vendors will say that managed services let you customize your platform, while SaaS is an off-the-shelf option. And, to be fair, the off-the-shelf standardization of the services is what allows SaaS products to upgrade automatically. However, customization shouldn’t be happening at a platform level anyways. Let’s take it back to the Lego example. For a managed service offering, the vendor will customize that monolithic box to push and pull the data you want through the glued-on Lego brick. A company pays a flat price for the whole box, regardless of how much of it they use. When the vendor updates their box, they will help rewire this new version of the box to make sure it works like the old one. It is customized, yes, but it requires custom work for each new version. The SaaS offering, on the other hand, is made up of Lego bricks that are standard for everyone. That standardization means that when a brick is updated, that update can be given to everyone, and that brick will be compatible in any previous scenario — no custom work required. Updates can be scaled, so customers get more of them. Companies are then free to assemble those bricks to meet custom goals and only pay for the bricks they use. What to look for: No software download required. A subscription model of payment based on resources or users. No licensing model based on versioning. Upgrades are rolling and automatic, there is no service cost or time estimated for version upgrades. 4. Supports Modular Implementation Due to all the above factors, MACH technologies offer businesses significant benefits. They let companies escape the re-platform cycle thanks to modular implementation. Legacy tools usually require a “big bang” launch. Going live with a new software means completing ripping out and untangling the dependencies of your old solution, re-mapping those to the new one, and ensuring the entire setup is perfectly in place before launching — or risk a cascade of errors. With MACH tools, the process is less “ripping” and more “clicking.” This is due to a few different reasons. First, because they aren’t meant to be “all-in-one” platforms, MACH tools make it easy to integrate with the investments you already have — including the platform they are set to replace. Teams can have access to new functionalities right away, while gradually weaning off of the legacy platform. Second, their decoupled services can be tested, updated, and deployed independently. Multiple teams can work in parallel, and changes can be made without the risk of cascading errors. Third, because of their independent nature, projects can go live one at a time. You can get a fully functioning project up and running in a few weeks, such as a new checkout or customer support process, and evolve your experience step by step. MACH tools are designed to evolve. To learn more, and for real examples of companies making the switch to MACH, check out the recently published ebook: Break the Replatform Cycle with MACH Enterprise Architecture. What to look for: It should be possible to use any functionality of the product on its own, without requiring the full kit and kaboodle to get started. Headless software. While not all MACH solutions are headless, it is a good indicator that the software has independent services. Reference customers who have had success with modular implementation. 5. Offers A Proof of Concept Always try before you buy. If a vendor claims their software provides agility and speed, but they are hesitant to demonstrate that with a proof of concept — that’s a red flag. Hacking your way past a vendor’s sales deck is the best way to see behind the marketing curtain. Choosing a real business case for this project lets you ensure that the solution fits into your ecosystem, and proves that the software holds up beyond the polished demo. It also gives you a chance to see if the vendor is the right match to partner with. MACH tools are a new venture for many companies, and it’s essential to have a vendor that you feel you can rely on to help you figure it out. What to look for: The APIs, documentation, and SDKs are easy to work with. The UI is easy for all relevant teams to adopt. The vendor’s customer service is helpful throughout the process. Emphasis on Partnership Digital is the new competitive battleground, which means companies need unique experiences that set them apart. This means that businesses need to choose a network of software providers that are willing to work with them on initiatives that haven’t been done before. Along with the support for new experiences, the SaaS model requires businesses to trust vendors to be transparent about day-to-day performance. With SaaS, enterprises are relying on vendors to be up to date with security, stability, and performance — and upfront about any issues that arise. On top of that, because there is no “all-in-one” platform market anymore, these vendors not only need to work well with you but with each other. Larger digital projects will require effort from multiple providers, and poor communication between parties can slow down efforts. When running the proof of concept, a kick-off meeting that includes your current key vendors can help determine if everyone is a good fit.  What to look for: Customer reviews on sites like G2, Capterra, Gartner, and Forrester. Recommendations from current vendors that you trust. Ask what recent feature has been added based on a customer suggestion, if they partner with customers on new initiatives they should have an answer. For a deeper look at the benefits of MACH tools and how real companies are making the switch to a MACH architecture, check out our ebook: Break the Replatform Cycle with MACH Enterprise Architecture. Ready to evaluate a vendor? Try these 30 RFP questions to ask your headless CMS candidates.

May 27, 2020

Ease the Pains of Legacy Tech One Step at a Time

Legacy technology, systems, and tools that require outdated methods are nearly impossible to avoid. Digital business is evolving so quickly that a technology purchased just a few years ago might already be considered “legacy.” It’s no surprise that 64% of IT leaders say a top factor in their budget is a need to upgrade outdated infrastructure. Legacy tools are not just frustrating to work with, they slow business down. In a 2019 survey, two-thirds of developers said that maintenance of a legacy system and technical debt hinder improved productivity. The catch-22 is that removing these legacy systems, and detangling the spider web of dependencies and customizations that have been built around them, can feel like even more effort than maintaining them. Of course, the custom workarounds needed to keep legacy tools running also add up, making the barrier to change larger. As Tom Morgan, Director of Digital at The Spectator, put it, “In terms of ability to innovate, everything had a cost associated with it, which put us off doing anything risky. That meant our technology was stagnating — as was our ability to serve customers.” Morgan and his team at The Spectator tackled this problem head-on by completely modernizing their architecture (full story in the newly published enterprise architecture ebook). Still, many enterprise companies need a way to embrace new tools without a significant infrastructure project. Businesses need a way to modernize their digital experience, safely step off legacy technologies over time, and create a framework that doesn’t require a “rip-and-replace” process to evolve in the future. The Emperor Has No APIs (but MACH Tools Do) Luckily, businesses looking for new solutions have a good pool to choose from because enterprise software is having a hot moment right now. The rise of customer expectations, the expectations of employees familiar with modern consumer technologies, and the rapid advancements in programming and cloud computing have led to advanced software designed for the speed, scale, and flexibility needed by today’s digital business. The need for software to help businesses grow quickly, exponentially, and in multiple ways — also known as being “future-proof” — has found its way into the messaging of many vendors. They know that if they aren’t omnichannel and integration friendly, their tool is obsolete. For some vendors, the solution was to “modernize” their existing software by wrapping it in APIs. But merely having an API doesn’t make a solution ready for modern business. If the software still requires manual updates, only integrates with a limited selection of other tools, or has a monolithic structure behind those APIs — there’s a good chance it’s a legacy tool in disguise. Enter MACH tools, a growing trend of software designed with the principles of microservices, API-first, cloud-native, and headless. These tools are API-first, not API-added. From the ground up, MACH technologies are built to be modular, pluggable, scalable, and support continuous development. Thanks to their modularity, MACH tools are a solution for enterprises that need to quickly alleviate the pains of an outdated experience while gradually stepping off legacy tools. Stop Vendor Lock-In It makes business sense for software vendors to have their customers (you) use their product for the majority of the digital experience. The more you rely on their software, the less likely you are to replace it. Back when “digital business” meant merely having a website, this also made sense for the enterprise - one vendor and one contract to cover all your digital needs. But as digital needs expanded and became unique to individual businesses, the “all-in-one” platform became more of a burden than a benefit. For example, say there is a platform that is top of the line in commerce, but the content and search capabilities are subpar. If their goal is to be your “core” platform, chances are they aren’t going to make it easy to integrate with other content and search tools. Choosing the platform for its best feature means being locked into its not so great ones. Designed with the understanding that an enterprise’s digital needs are too complex for a singular “all-in-one” platform, MACH tools support a composable enterprise, where businesses have the freedom to select, integrate, and replace any tool down to the level of individual functionality. For instance, while Contentstack’s full-text query search can work for smaller sites, it wouldn’t be the best option for sites with thousands of content items that need dynamic search. So Contentstack recommends integrating with leading search platforms and provides guides on how to do so. We focus on delivering the best-in-class headless CMS and integrating easily with everything else. This focus on integration helps alleviate a second way that businesses get locked in by software, when it’s not just features they are stuck with but the broader solution ecosystem. With their more monolithic architecture, legacy tools require custom code, plug-ins, or workarounds to support new initiatives. Over time this becomes a hairball architecture, with dependencies, created one at a time, sometimes by people who don’t work at the company anymore. Trying something new feels like it might trigger a domino effect of errors across these dependencies, and untangling the ball would take too much time. Your experience is locked into what is already there because innovation feels like too much time and risk. MACH technologies are relatively standardized. Every functionality is accessible through an API — so there are no plug-ins or workarounds needed. Additionally, their microservice design keeps functionalities tightly coupled to one another, so if there is an issue in one functionality, there is no risk of a cascade of errors. Another powerful functionality is using an event model that includes webhooks that enable intercepting events and taking custom actions. Adding new functionality, or trying new initiatives, can be done quickly with minimal risk. Overall, this makes MACH solutions less “sticky.” Meaning you keep them in your ecosystem as long as they are still the best fit, not because they are too hard to remove. End the Replatforming Cycle The modularity of MACH tools means that reorganizing your solution ecosystem is less “ripping” and more “clicking.” Simply put, these tools benefit from being designed after APIs and microservices became a widespread design practice instead of having to retrofit a monolithic codebase into a modular world. MACH technologies are API-first, not API-added. Because they are created from a foundation of microservices and exist natively in the cloud, these tools can be offered as Software-as-a-Service (SaaS). This means that you subscribe to only the resource you use and you can autoscale these resources up and down. Upgrades to the services happen automatically and continuously — no manual versioning is required. While upgrading to a new version may not be the same as replatforming, if the latest version of a software loses backward compatibility, it can require nearly as much effort. A services model also means that you can modularly implement MACH tools. Because MACH tools are composed of individual services, you can start on any corner of the experience with any MACH tool (even with specific functionalities) and be sure that as you expand the experience those services will be compatible with future additions and changes. As-a-service products let you break away from the “stop-rebuild-restart” pattern of monolithic tools. Step Off Gradually While the ease of upgrading architecture once MACH tools are in place is excellent, the first replatforming pain to tackle is how to remove the current legacy system without disrupting business. Because MACH solutions can be added service by service, businesses can start decoupling their architecture without entirely ripping out their legacy tools. Key functionalities can be up and running quickly, so teams can go ahead and start making improvements to the experience, and businesses can gradually untangle legacy dependencies one functionality at a time. In our latest ebook, we interviewed enterprise technology directors and solution consultants who moved from monolith to MACH. They shared advice on first steps, evaluating vendors, and what they learned about transitioning to a modern architecture. If you’re curious to learn more, we recommend reading: Break the Replatform Cycle with MACH Enterprise Architecture.