Past few years, I have been working with my team to build our own CMS for marketing content or SEO content, an audacious goal given that we were already using AEM, an enterprise level CMS with great integration with Adobe marketing cloud. In these blog post I will walk through mental model and architecture of how we went about building it.
In building any new product which is not part of your core business and for which good solution already exist, first question you gotta ask yourself or answer to others WHY BUILD ? or WHY NOT JUST BUY ?
I have seen multiple frameworks to help you decide which path to take (build vs buy), in our case since we were already using AEM we already knew some pain point (see below) with framework that help us make decision. When your company is very engineering driven and have frameworks, platform and system in place that very few has.Our criteria of justifying to leadership came down to 4 things,
Is this problem unique to you: In this case NO. CMS is not a unique problem, many company has CMS needs for different use case and there is plethora of solution that exist for those use cases.
Is this part of your core business: YES and NO, Core CMS feature it self is not part of Core business, Company is not going to build and sell enterprise level CMS. However there are certain product which uses subset of CMS features (we will get to that later)
Does this need white glove support: If you buy you definitely need white glove support, specially with AEM getting support is harder, hiring someone who knows AEM or really good at it is even harder. And even if you hire them it hard to have a career path for them in other part of company. We struggled with hiring and retaining AEM talent.
Integration: This was BIG one, if most of your app are custom integrating with third party solution is harder, all the way from using Data (Internal data), Infrastructure (using physical or virtual hardware running in same network), CI/CD (all the way from code hosting to canary testing to prod deployment), Accessibility, Security, Designs (align with visual design of rest of company and keeping system up to date) etc. We continuously struggled with integrating AEM with company stack, processes and infrastructure.
After using AEM for years we stack rank these criteria against our future need and decided to build our own CMS.
Well so far so good, but how would you go about justifying this to leadership and most important executing it. I have seen many companies trying it and not succeeding so it was big risk. In section two I will try to cover steps we took to go from justification to POC [Episode 2 - Proof of Concept]
AEM pain points:
- Not a true Microservice: Given that how author, publish and communication between two (through replication) works, I don't think it is true microservice. It is really hard to scale AEM horizontally (both author and publish)
- Technology & Ramp up: Now this could be debatable but I think AEM tech stack is not widely used teach stack, for example app request processing (sling), Sightly (Templating language), Event handling (OSGI or sling events), Data replication (Proprietary), persistence (Tar), Apart from backend being in Java none of the other technologies are widely used and hence hard to find generalist and hard to ramp someone on this product.
- High reliant on dispatcher: Effective caching is still not a solved problem and AEM rely a lot on effective caching at dispatcher to do app level scaling. We could not scale system if you are service dynamic data.
- Automation: AEM deployment pipeline is tightly coupled, there are only few options you have to extend it, it makes it hard to integrate it with existing systems.
- Code management: Fact that actual code (front end) and bundles lives where content also lives do not provide good isolations and hard to do code management (versioning etc) and plug in in to existing deployment pipeline.
- Upgrade: Not sure how many of you faced this but upgrading AEM systems are not easy and takes a lot of resources. Engineers end of spending more time on upgrade than developing features.
