25 Terms Required to Work at commercetools
Kelly Goetsch
Chief Strategy Officer at commercetools / MACH Alliance Co-founder / 4x O'Reilly Author
We at commercetools are not just “another commerce platform.” We invented headless commerce back in 2013 and have created the entire category which we now lead .
When your mission is "to challenge and change the world of ecommerce," and you succeed, there's a pretty big chance that the vocabulary you use becomes commonplace inside the company and out in the general market. Headless, MACH, unopinionated, portfolio, commodity, etc are all terms we invented or were first in applying to commerce. In the past year alone, we’ve had 300 new employees join us and many are completely confused by all of these new terms.
This article is for new employees and anyone else interested in the vocabulary we've built up at commercetools over the years.
For each of 25 terms, I will offer a short description, a graphic where it makes sense, and links to further reading material.
1) Microservices
Small, cross-functional teams of roughly 5-9 individuals who build a small standalone application that does one thing (inventory, pricing, wish lists, etc) and only one thing. Each microservice should be able to be built and released on its own, and only the microservice has access to its data. Microservices must expose APIs and share data with other applications via events.
Further reading:
2) APIs
Some data (like a product) or functionality (like add to cart) exposed over an HTTP endpoint. APIs are an abstraction that separate the producer (like commercetools) from the consumer (our customers). APIs should have a service level agreement (SLA) that offers guarantees on performance and availability. Once exposed, an API can be called by any frontend (web, mobile, AR, VR, etc) or other backend application. Our customers’ goal is to build a catalog of these APIs, some from us, some from other 3rd party vendors, and some from the APIs exposed by custom microservices
Further reading:?
3) Cloud Native / Multi-tenant SaaS
Software that is provided as a service, where the consumer of the software doesn’t have to deal with hosting, scaling, securing, or managing in any way the software. The vendor shouldn’t have to provision any hardware when a new customer signs up. Ideally, customers are able to create self-service trials on their own. Think Gmail (a SaaS service) vs Microsoft Exchange (hosted for a specific customer or run on premises)
Further reading:
4) Headless
A fundamentally new approach to commerce that Dirk Hoerig invented in 2013 . Rather than having the “head” (historically web pages) embedded as an inseparable part of the commerce platform, headless commerce allows all data and functionality to be exposed as APIs and then be consumed by multiple heads. Headless represents a fundamental separation of concerns between frontends and backend, thus allowing the backend and frontend(s) to be worked on and released independently of each other
Further reading:?
5) MACH
Acronym created by our own Margaret Rea for a commercetools marketing campaign in 2019 . Microservices, APIs, Cloud Native Multi-tenant SaaS, and Headless. See each of the previous four terms. MACH is how we build our service internally.
Further reading:
6) MACH Alliance
A non-profit founded in 2020 by commercetools, Contentstack, Amplience, EPAM and Valtech to:?
The MACH Alliance now has 66 member companies including Amazon Web Services, Deloitte, Netlify, Sapient, Capgemini, Talon.One and many more.?
Further reading:?
7) Composable Commerce
Gartner coined this term and defines it as "An architectural approach to digital commerce whereby applications are constructed with packaged business capabilities (PBCs)." PBCs are the next term I define. Basically this is Gartner's business user term term for mixing and matching best of breed functions from different vendors. The term is applied to how these PBCs are consumed, rather than a vendor-centric view of how these PBCs are architected behind the scenes.
Headless commerce as a term is more loose, more commerce-focused, and more technical. Composable Commerce is what we most often say externally when we talk about what we do. MACH is how Composable Commerce vendors build and offer their services.
Further reading:
8) Packaged Business Capabilities (PBCs)
A Gartner term for "non-technical business users view of the business capabilities." They further define PBCs as "Independently deployable capabilities that include self-contained business data, logic and processes to perform a business function. These interact with other applications via APIs and event channels.?" These capabilities (product information, product discovery, or payments) from potentially different vendors, and each vendor exclusively owns its data. Think of a PBC as the business user term for a set of APIs that provide a specific function. Each capability is likely to (but not required to) map back to a microservice behind the scenes. PBCs are building blocks for composable commerce in Gartner's terminology. They can also be seen as mapping back roughly to a MACH-based microservice.
Further reading:
8) Modular Commerce
Gartner defines modular commerce as "Modular commerce takes API-based (headless) commerce further by breaking down the functional modules in the core commerce platform to improve flexibility and agility. In this approach, functional modules are often separate business capabilities, have their own APIs and data model, and can be independently deployed." Legacy commerce platforms can be headless, but with a monolith behind the scenes. Modular commerce refers to a single "platform" being decomposed into individually deployable PBCs, each with their own datasource and each able to be deployed independently.
Confused about Composable vs. PBCs vs. Modular? I am too. Yes there are differences between the three, but I (and we at commercetools) tend to think of MACH as the "how we provide our service" and Composable Commerce as how our customers consume our services. Modular is a pretty new term that hasn't really caught on yet.
Further reading:
9) Frontend-as-a-Service (FEaaS):?
An opinionated framework that allows business users to build and deploy various front-ends. Frontastic (now commercetools Frontend ), Vue Storefront , and Shogun are all examples of these products. These products can also optionally render and deliver the frontends. Frontends-as-a-Service are far easier to use than legacy Digital Experience Platforms (DXPs) and DIY-based approaches using off the shelf open source.
All of these frontends work with any commerce back-end.
Further reading:?
10) Opinionated
Software that is extremely prescriptive about how it is consumed, customized and extended. Some of our competitors require you to use a specific programming language, specific flavors of that programming language, require the extension of specific classes or implementations of specific interfaces. The platform has an opinion about how you do everything. Our competitors are for the most part quite opinionated, which limits the people who can work with their platform.
Further reading:?
11) Unopinionated
The exact opposite as opinionated. From day one commercetools has been built to be as unopinionated as possible. We expose data and functionality via:
Customizations and extensions are all performed in the serverless framework of your choice, in the programming language of your choice.?
This allows anyone to work with our software, rather than only experts trained in a proprietary, opinionated platform.?You just need to know how to use events, functions, and APIs which are taught at any programming boot camp.
Further reading:
12) Digital Experience Composition
A new term coined for the "neck" of headless commerce. Gartner defines it as "API connectivity to headless services like CMS, search or commerce." This is a brand new term, first introduced in the 2022 Gartner Hype Cycle for Digital Commerce , but is important because it gives a name to a category of software that has been rapidly emerging but has lacked a name. Vendors like Occtoo , Uniform , and builder.io make Composable Commerce much easier for business users to consume through their products.
Further reading:
13) Suite
A collection of applications (usually platforms) that are bought up by a single vendor and then offered as a pre-integrated, pre-packaged stack of software. Oracle had a classic suite when it bought ATG for eCommerce, Endeca for search and experience management, FatWire for content management, and BigMachines for CPQ. Those products are essentially “welded” together and in most cases must be purchased, released and upgraded as an atomic unit. This leads to monthly or quarterly “big bang”-style releases. SAP, Salesforce, and Adobe also have suites to varying degrees.?
Further reading:
14) Portfolio
A collection of independently consumable APIs, offered by a single vendor, backed by microservices. Each product in the portfolio is market leading (vs. just thrown in with the suite), able to be sold independently, has its own dev team and roadmap, is able to be released independently
commercetools is proudly a portfolio company.
Further reading:
15) Platform
The term for an old-school opinionated application that offers "everything in a box." We at commercetools are re-branding away from that term. Platforms were great 20 years ago when brands were first getting online. But not anymore.
Further reading:?
16) Commodity
Commerce APIs are a commodity - in the best possible way. Software is commoditized when it meets the following criteria:
Commerce very much meets that criteria. We at commercetools are proudly a commodity. We're no different from a load balancer, DNS, or any other piece of commoditized plumbing that makes the internet work. A shopping cart is boring, hard to build, and offers relatively little differentiation. We take do those things really well, allowing our customers to focus on the things that offer true differentiation, like frontends, loyalty, and personalization.
Further reading:
17) In the Cloud (vs On the Cloud)
Most of our competitors use the cloud for compute hosting only. That’s called “on” the cloud, whereby developers have no access to the underlying cloud. It’s impossible to access events, functions, native cloud services, or anything else that makes cloud so special. We are “in” the cloud, whereby we are a first class citizen of cloud as if Google, Microsoft or Amazon had built their own commerce APIs in their respective clouds.?See events and functions terms below.
Further reading:
18) Legacy
Any commerce solution that's not MACH is branded as "legacy" in commercetools. Anything non-MACH has become so technically obsolete that it needs to be replaced. Many of those first wave platforms from the 1990’s are still out there being repackaged but they’re still fundamentally out of date. Problems with legacy?include:
Further reading:
19) GraphQL
A query language for your APIs that Facebook open sourced in 2015. It has since become the de-facto means of accessing data and functionality. With GraphQL, the client (typically a frontend) constructs a single query for all the data it needs. A query will look something like the following:
That is sent over to the GraphQL server, which then calls all of the relevant commercetools APIs and responds with a single concise JSON document with all of the required data.
We at commercetools were first to market with GraphQL support, have the most coverage of any vendor in the space, co-organize GraphQL Conf (the world’s largest GraphQL conference), and one of our developers built Sangria, which powers Twitter and the New York Times.?
Further reading:
20) Monolith
An application that’s built, deployed and managed as a single atomic unit. See legacy above. The direct opposite of microservices (see above). When one part of the codebase is touched, the entire rest of the codebase has to be re-tested and re-deployed. Most of our competitors are monolithic, even if they expose APIs.?
Further reading:?
21) Eventing
An event is a simple message that's published to a queue. We support AWS SNS, AWS SQS, AWS EventBridge, GCP Pub/Sub, Azure Service Bus and Kafka. When an order is placed, a product is updated, or any other action is performed, we'll throw an event containing that information. Those events can then be used anywhere across the cloud they're published to. You can execute serverless functions in response to the events, ingest those events into other cloud services, or send them to other systems.
Further reading:
22) Functions / Serverless
A function is a small snippet of code that's triggered in response to an event, or during an API call. See the above term on "Eventing." Through our subscriptions functionality, we post an event to the queue of customers' choice. Functions can then be executed in response to those events.
In the above example, this simple function listens for an order event and executes the following (psudo)code in response:
You can choose any programing language you want.
Through a patented bit of commercetools functionality called extensions , functions can be called in real-time to perform actions like checking inventory in real-time or checking loyalty point balances.
Further reading:
23) “We don’t do that”
A term you’ll often hear at commercetools, especially when speaking to external audiences. Our product is very focused on doing a handful of things (order capture, frontend, etc) exceptionally well rather than trying to do a lot of things (OMS, CMS, CPQ, etc) poorly. We believe that our deep specialization is what makes us unique.
Further reading:
24) Strangler pattern
Coined by Martin Fowler in an iconic 2004 blog post , this widely followed pattern is used as guide to incrementally move from a traditional monolithic commerce platform to commercetools.?Fowler starts his blog post as follows:
One of the natural wonders of this area are the huge strangler figs. They seed in the upper branches of a tree and gradually work their way down the tree until they root in the soil. Over many years they grow into fantastic and beautiful shapes, meanwhile strangling and killing the tree that was their host. This metaphor struck me as a way of describing a way of doing a rewrite of an important system.
Since the vast majority of our customers are coming from some legacy system, and nobody has the risk appetite for a "big bang"-style replacement, this has proven to be the best approach. Hundreds of our customers have successfully used this pattern to move to us.
Further reading:?
25) Jamstack
An acronym coined by Netlify that stands for:
Jamstack is the pre-rendering and serving of content from a headless CMS or usually a Content Delivery Network (CDN). Product detail pages, static home pages, and similar content is pre-rendered and served directly from a CDN, requiring zero calls to back-end infrastructure to render. This improves performance and security.
Any calls for dynamic data (real-time pricing, real-time inventory, etc) or to access functionality (add to cart, etc) then require a call to the back-end. But for the vast majority of page views, the content can be pre-rendered and served directly from the edge.
Further reading:
Additional Resources
I hope you found these resources helpful. I'd also suggest you follow the CommerceTomorrow podcast , which I co-host with Dirk Hoerig and our well-read tech blog . Finally, follow me on LinkedIn for my mostly unfiltered commentary on our fast-moving market.
Partnerships Manager at Talon.One
1 年Very helpful and relevant, thanks for sharing! Kelly Goetsch
Thank you Kelly Goetsch! ??A common language is really crucial and this was exactly as short and snappy as I needed. Will use it as reference next time I need to be just as crisp in the future ??
AI Engineer, Product Manager, Founder, Inventor
2 年Congrats, Kelly Goetsch, it's awesome to see the growth!
SDR Team Lead @ Talon.One - Loyalty | Promotions | Rewards Programs
2 年Andrew I. ??