--
Lately we’ve seen many SIs and agencies embrace the publication and marketing of “Accelerators”. Often these are reusable front-end solutions or ready made integration components that integrate SaaS services for you, so that these don’t have to be developed in your project.
While this is a good initiative, we feel that it is often too much focused on creating quick wins and used as a commercial lever, rather than focusing on building sustainable MACH implementations for clients, that last long and are easy and fast to operate.
In this article we explain how Accelerators could be part of the wider practise of “platform engineering” at SIs and how an internal platform can truly accelerate client implementations on the longer term, while injecting culture in the process.
It sounds good right? Ready-made components that speed up the implementation of your MACH replatforming project. Don’t get me wrong; this is a great idea. The current age of cloud computing and stable APIs, allows for far better reusability of components than before. Building everything from scratch for each new project is simply not that smart anymore.
As a boutique SI ourselves, we’ve been doing this for many years; even before MACH or Composable were a thing. The biggest reason for us to pursue this, was to improve quality and deliver value sooner to our clients. And our laziness has something to do with it, but that’s food for another blog post.
Accelerators are usually created when new projects are executed for clients. These often result in reusable software that is not tied to a specific client or project. UX and layout are often similar across sites and the same can be said for back-end components such as integrations with SaaS systems, i.e. a PIM or a payment provider, or core components such as a GraphQL gateway. These are often quite generic in nature and can therefore easily be reused for future projects — when built well with proper isolation and the right techniques like scalable design systems and to some degree a microservices architecture.
What’s wrong with that, then?
Well, in itself nothing at all! It is just that this is only part of the story and is an opportunistic approach to reusability. The problem is that it is an ‘end result’ and might not provide you with the right environment to be successful in the future. It is the F1 car without the pit crew and factory team at home. Worst case, an Accelerator is implemented by a team that doesn’t know anything about it and it crashes into the wall in the first lap.
Let’s take a step back and look at what we want to achieve with a replatforming project.
Time-to-market of an MVP is definitely shortened by the use of an accelerator. After the launch it really starts. You want to keep that fast pace! The new platform should be able to deal with quickly changing business demands. And that is when things like proper architecture and engineering practices start to count: when making changes takes ages and operating the platform in production is a big effort, questions will be raised quickly.
You want a platform that is lightweight and automated as much as possible, so that it can be changed and operated with speed and efficiency by your teams. And this is incredibly difficult with distributed MACH systems.
You don’t achieve that with just accelerators. In fact, relying solely on accelerators might even give you the opposite!
This is about culture.
How does culture get me a lightweight and automated platform, I hear you ask? Let me explain.
Being an agency we work for a lot of different companies, with similar projects and use cases that we implement for them. And being good engineers, we try to see the similarities between those projects, so that we don’t reinvent the wheel whenever a new project or client comes across, and rather leverage our experience.
With the goal of making our own lives easier and providing more value to our clients, over the years we’ve built a large library of open source tools, SDKs and accelerators for MACH, that help us build our projects faster, with higher quality, and set up the project for a lightweight and easy to change future.
Examples of these are numerous Terraform providers for MACH platforms (i.e. commercetools, Amplience and Storyblok) as well as our MACH composer framework, several platform SDKs and libraries to interact with them or improve our own way of working. And using those tools we’ve created accelerators that implement complete B2C front-ends, GraphQL Federation and several back-end integrations with external systems. Ready made software components that provide UIs, integrations and core infrastructure components for MACH architectures.
An area that has had special attention is developer experience: CI/CD, automation and developer productivity in general has been setup carefully, to make it easy for teams to quickly make changes to the project they are working on.
Furthermore, we’ve created blueprints and best practice architecture designs that can basically be applied to any use case we throw at it; it is all standardised.
All of this results in a lot of consistency across the board: all of our projects share the same frameworks, tools, architectures, ideas, ways of working and approach to deploying and integration. When you look at them through your eyelashes, the implementations are more or less the same and use the same underlaying toolchain. Regardless of the underlying Cloud or SaaS platforms they use and in which client environment they are deployed, which often come with their own policies and guardrails that you should be flexible towards.
This results in a lot of benefits when it comes to operating the platform, making changes, baseline security hardening, sharing knowledge about the platform and the overall quality and stability of the platform. Not to mention maintainability, long term support, broad knowledge base and quickly being able to start up new projects.
As you can see, this is much more than simply having a couple of components available as a starting point. This is a platform that provides an end-to-end approach to building MACH systems, including the end-user facing building blocks such as a UI, that accelerate the build, and primarily has all infrastructure in place to actually work on a MACH platform productively, as an engineering team.
The real acceleration is brought by the well-balanced integrated set of tools and methods, created and continuously refined over the course of many years of building cloud native and composable architectures. This absolutely includes the heavy use of accelerators — but much more than that as you can see.
According to Gartner, Platform engineering is an emerging technology approach that can accelerate the delivery of applications and the pace at which they produce business value.
Which is kind of an abstract definition, but describes the business goal pretty well.
The CNCF uses this definition by Evan Bottcher for “Platform”:
A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination.
In other words; the cloud native toolchain, including ‘templates’ that makes your teams productive. Making sure that they don’t have to invent the wheel themselves all the time, but can focus on the parts that are actually distinctive.
With that in mind, you could consider the combination of our tools, standards, accelerators, knowledge and ways of working for building MACH architectures, the “Platform” that we build as Lab Digital.
Our clients are “consumers” of that platform, when they let us build a project for them. It is the product we deliver, built by an autonomous delivery team that uses our past experience, practises, tools and building blocks, as a foundation.
When combined with a product mindset, you can reason about this ecosystem as a tangible product (“Platform as a Product”), that evolves over time. All of the projects and products we build contribute to this platform on a daily basis in some shape or form, creating value for all of the consumers of the platform.
We believe that this is how an SI and specifically an SI in the MACH space, should operate. In an ideal world, its knowledge and expertise should grow over time and with every client interaction it has, flowing back to the internal platform that comprises all of this. This will create a flywheel that makes the SI continuously better at building MACH systems, and prevents reinventing the wheel across clients and projects. Creating value for the customer as well as the SI, and the developers that work there.
This sounds logical right? However in practice, we see a lot of “copy pasting” out there, lacking a long term vision. Agencies and SIs that build completely bespoke solutions for their clients and follow different paths for individual projects. This results in solving problems over and over again, whilst there are ample opportunities for reusability and building reusable solutions. And we’re not even talking about open sourcing certain reusable components, yet.
We try to do this differently. We see all of our projects as instances delivered from our internal platform and see developments in these projects as “extensions” to our platform. It is our internal standard that continuously evolves and is used for every client.
That means when new services need to be supported, recently Storyblok and commerce Layer for example, we take a “platform first” approach by implementing support in our platform tools (integration in the Accelerator through GraphQL, creating a Terraform provider and implementing a MACH composer plugin) first, as the first step in the project implementation.
Secondly, we try to keep existing instances of the platform up to date with new developments we do across our projects, where it makes sense. Examples are the implementation of upgrades to newer versions of MACH composer and Terraform providers, or replacing our GraphQL code generation and Gateways with newer versions that we’ve created.
By keeping this system “tight”, we ensure that we keep our distributed engineering roughly in the same direction, while still allowing for full autonomy of the team; the benefits of following the platform are simply too big to ignore. Or at least, we like to think so.
So yes, we are absolutely believers in “accelerators” for MACH replatforming projects. They play a big role in our projects and we invest in them heavily. In fact, we think they are essential to be successful for any agency in MACH; also looking at the increasingly complex future. Developing our standardised accelerators as a base helps reduce said complexity and increase predictability of delivery.
But in our view, the real acceleration comes from the entire platform approach, which accelerators are part of, and at some point might may even become obsolete or outdated. Contrary to the platform and its methods, which should support iteration and even replacement of those accelerators over time. The platform provides the right environment for a MACH architecture to be created in.
For getting started with this practise, I recommend diving in to the Platforms Whitepaper, published by the CNCF. It contains a clear and concise explanation and definition of what Platform Engineering is and isn’t, whom it’s for and what problems it aims to solve. And it contains ample examples and suggestions for getting started with it.
In the end, this is about getting more value and keeping the system simple and sustainable for longer; allowing to focus on creating differentiating features and projects, rather than maintenance.
The foundation of the software you are receiving, is the result of many years and iterations of R&D, testing and production hardening of MACH systems, resulting in a sound and stable architecture to build upon. This value is unlocked through building on top of it and using it’s methodology and tools in your replatforming project.
But it is more then that: implied in the platform engineering method, is making sure that the MACH platform has been designed to sustain and evolve over time, with the ability to be updated and upgraded whenever new developments are done in the platform behind it, benefiting from platform-wide efforts. So as a client, you benefit from all the work we do in the MACH domain!
And most importantly, we believe that following a platform engineering approach with an SI, will teach your organisation about platform engineering and injects this methodology for your own environment, improving software engineering maturity and culture in the process, ultimately making it possible for you to maintain and develop your platform, or parts of that, yourself.
In our view, SIs and Agencies should follow an holistic approach to building composable architectures, deeply embedded in their company and engineering culture. Implementations should be a product of their knowledge in both tangible and intangible form that continuously improves over time. And ideally, they should share their methods and tools where they can in the open, where of course the “crown jewels” could remain proprietary.
We think the current influx of Accelerators has its purpose and is great for getting the conversation around reusability and not starting from scratch. But we also see a lot of marketing & commercial driven efforts that do not have an holistic approach and are simply a “quick win” at the start, but introduces risks in the longer term in terms of platform sustainability.
As an industry, both the MACH ecosystem and SIs and agencies in general, we should be looking at the practise of platform engineering, which takes a product driven approach to engineering organisations and enables delivery teams to deliver higher quality faster and more autonomous, while reaping the benefits of cloud native, DevOps and reusable software. This allows us to build more sustainable MACH platforms for our clients at a faster pace and with higher quality.
At Lab Digital this approach has been running through our veins since our inception in 2015, well before MACH, Composable or Platform Engineering were a thing and Cloud Native was just getting started. It is the secret sauce that powers our company and has resulted in many developments from us in the space, which are largely open source. And more importantly; it has resulted in a lot of value delivered to client projects based on that foundation.
We’re think following this approach is a great step for any SI or Agency, especially in the MACH space, where complexity is something that actively needs to be tamed (also at the industry level) in order to reap the benefits on the longer term. Having a solid approach will help greatly with this and we encourage anyone in the industry to have a closer look at it!
The following resources are a great starting point to read in to the practise of platform engineering, including our views on how to apply this with MACH.
The (work-in-progress) maturity matrix for Platforms, by the CNCF
“What I Talk About When I Talk About Platforms” https://martinfowler.com/articles/talk-about-platforms.html
https://internaldeveloperplatform.org/ — Everything the WWW has around Internal Developer Platforms in one curated space.
Our introductory post about MACH composer, which encapsulates many parts of our platform (except for the crown jewels ;-))
Happy (re)platforming!