Why Successful Adobe Experience Manager MVPs Become Long Term Failures
When purchasing a CMS Solution such as Adobe Experience Manager (AEM), oftentimes the initial costs of licensing and migration drive business stakeholders to seek the lowest time and cost minimum viable product (MVP) solution to go live. However, that approach can leave a business with a shiny solution on Day 1 that is not ready for Day 2, requiring the business to choose between overhauling the solution or enduring higher maintenance costs for the life of the platform.
A well-implemented CMS from both a business strategy and technical perspective is evidenced by tangible metrics, over time. Costs for migrating new sites to the platform decrease site to site. Author engagement and design flexibility within the platform continually increase. And these results are underpinned by only nominal increases in ongoing platform maintenance costs. That’s the picture of success, so when this picture doesn’t materialize we naturally must seek why. Sometimes the issue lies in a lack of a business strategy to leverage a CMS well across business units and brands. But other times the problem lies in a short-sighted technical MVP implementation, imperceptible to business stakeholders until the solution looks to grow.
Poor long-term CMS implementations occur when a myopic focus on driving down the cost of initial implementation leads to an oversimplification that doesn’t create a solid foundation for the future. MVPs in and of themselves are of course not a bad thing—quite the opposite. However, when an MVP does not set the right patterns for expansion to a mature solution, those technical debts get paid every single day the platform exists, far eclipsing any "savings" that were realized in the initial implementation. Business stakeholders know that something isn’t quite right, but because the problems live at the technical foundation no one can quite put their finger on it.
Let’s paint a picture of what this would look like on a home construction project. Consider a roofing job where you’re tasked with reshingling a single-story garage and then a two-story house. You decide the prudent way to go about this is to first reshingle the garage as the MVP, and once that is successfully completed apply the same solution to the house.
The first thing you need to accomplish the MVP is a reliable way to get up and down from the garage roof, so you’re going to need a ladder. Thus you are presented with two options—you can purchase either a 10-foot straight ladder for $200 or a 20-foot extension ladder for $300. To keep costs low on your MVP you decide that the prudent purchase is the $200 straight ladder that is clearly sufficient.
A few days later, however, feeling quite self-congratulatory on a low-cost completion of your MVP (the garage roof) you look to the two-story house and ask, "How am I going to get up there?" Not only is your 10-foot straight ladder insufficient for the task, but you also can’t even spend an incremental $200 on a second one to accomplish the goal—the straight ladder solution simply doesn’t work for the expanded use case. Whereas an investment of $300 in the 20-foot extension ladder upfront would have been a fine solution for both phases of the job, you’re now spending $500 and are left with an extra ladder in your garage gathering dust until the end of time.
Maybe this example seems a bit too obvious—no one would be so short-sighted as to buy the straight ladder knowing about the looming two-story house project. But this type of thing happens all the time in software projects, particularly CMS implementations, where the methods of implementation are obscured from the business stakeholders buying the solutions and oftentimes the platform evolves to satisfy use cases that weren’t even conceived at the time of purchase. Below are some of the costly pitfalls we see that turn “successful” AEM MVPs into long-term failures.
Pitfall #1: Dumbing Down the Platform Versus Enabling Developers
There has been a push in the industry for "low code" and even "no code" solutions that promise an extremely low-cost website implementation. Making these solutions particularly enticing is the fact they are often discussed in the context of an MVP, a time where a business has just made a significant monetary investment in platform licensing and is looking for ways to keep additional costs low. AEM has joined the party with its "quick sites" solution. Quick sites promise the ability to create an AEM site without the need for true AEM developers, relying on one or two commonly skilled front-end developers to brand a set of authorable components.
Solutions like quick sites for AEM are not without value, but their goal isn’t long-term success as an enterprise platform serving flexible experiences across multiple brands and BU’s in a maintainable system. On the contrary, "quick sites" is best for exactly what its name states—quick sites. When those solutions need to be elevated to the next level with business-specific experiences and functionality, a "true" AEM codebase is still required and leaves you managing multiple codebases and disparate implementation patterns. Adding to these challenges, by leaving the AEM-isms out of development upfront, the platform is now a scary black box when anything goes wrong.
As with any technical framework, not just AEM, optimal code patterns for modularization, reuse, and maintainability require an intimate understanding of the platform and its tenets. If you’re going to drive differentiated value from a best-of-class tool like AEM, don’t fall into this pitfall believing you can do so without engaging professionals that are experts in the tool.
Pitfall #2: Over-simplified Component Library
Another MVP solution often pursued is one consisting of only "out-of-the-box" components, often referred to in AEM as the "WCM Core" components. The idea is that by leveraging a handful of atomic, granular components on top of AEM’s rich authoring, templating, and layout capabilities, an MVP site can be created on top of a best practice foundation that requires minimal development support. This is another attempt at a low/no code solution, and a pitfall that is extremely alluring when watching a professional AEM salesperson whip together a page that looks like your legacy website in a matter of minutes without writing a single line of code.
What’s not often discussed in the sales process is what represents a good CMS experience for your authors—one that they will enjoy using on a daily basis. The capabilities of the AEM authoring interface in the hands of a power user are truly awe-inspiring. But are all your author's power users? And even if they are, do they really want to create a responsive grid by tediously sizing component after component in desktop, resizing the interface to tablet, specifying which components to fold to the next line, and then repeating the process one more time in mobile? Or would they rather leverage a Grid component that handles that tedium both reliably and automatically? Atomic components and layout capabilities are invaluable for one-off, bespoke experiences that no one had preconceived when developing the platform, but when every page and experience requires that level of authoring effort and expertise your content managers will quickly become frustrated.
Beyond the immediate authoring frustrations, an even bigger travesty of the over-simplified component library awaits well hidden in these solutions. The issue shows up months or years after implementation when your designers wish to rebrand the site and find out they can’t. Take the example of an "Our Leadership" section of the site that shows a headshot, name, title, and short bio for each member of your senior leadership team. Using a bit of layout magic in the AEM editor interface, each "Leader Tile" can be created as a combination of generic Image, Headline, and Text components, thus alleviating your dev team from creating an actual Leader Tile component. However, when your designers come back with a modernized design for each Leader Tile where the headshots scroll into view from the side and the names are written in a custom font, not only can your authors not affect the change, but neither can your developers (without significant rework). Since there is no true Leader Tile component, just generic Image, Headline, and Text, there’s nothing for developers to key off of to make these changes with updated styles.
WCM Core components are a great starting point, and are the base of what we do with Activate. But don’t be tempted into a solution that leans too heavily on granular out-of-the-box components as a full solution.
Pitfall #3: Short-Sighted Feature Implementation
It always amazes me how architects and developers dote on their MVP technical implementation that is oh so clean, maintainable, and highly performant. The dirty secret is that every MVP, regardless of technology, can say these things. By design, an MVP has a small feature set, serves limited traffic, and solves no difficult problems...yet.
We see this pitfall manifest itself in AEM projects in some common ways, though the reality is that there are infinite software shortcuts that lead down this path.
One such shortcut is creating an initial site in a way that doesn’t readily support multi-site, so that code (server logic, markup, styles, and JavaScript) cannot fully be shared across multiple sites without any rewrites. Coding for multi-site must be deliberate, and failing to do so on-site #1 makes site #2 a combination endeavor of write and rewrite.
Another area we see teams shortcut best practices is creating components without sling models, particularly simple display-only components developed by front-end developers. Though the website looks the same to the end-user, skipping these foundational constructs for a subset of components introduces disparate implementation patterns in your codebase and reduces overall platform support for content reuse and sharing for omnichannel experiences.
MVP solutions can also get away with poor caching strategies and implementations. A common situation where this flies under the radar is when an MVP doesn’t yet include an authenticated experience where content is gated by user permission. Automated capacity scaling of systems like AEM as a Cloud Service is generally an amazing benefit to customers, but they can also mask caching problems of MVPs until mature features are added, and a surge of site traffic that simply can’t be handled by scaling results in an untimely site failure.
The many pitfalls of short-sighted feature implementation are proactively avoided by a tech team that is deeply knowledgeable about AEM infrastructure and has built enterprise-level platforms for numerous different clients and use cases. Years of experience are nice to have, but the breadth of experience is what is critical to avoid these pitfalls.
Pitfall #4: Technical Library Dependencies
Even experienced AEM architects will often fail to see the pitfall of technical library dependencies until they experience the problems for themselves. Luckily (or perhaps unluckily) for us, we’ve built enough AEM platforms to have experienced the associated challenges first-hand, arming us with the insight to help you steer clear of this pitfall on your project.
From a business perspective, it is important to understand that a dependency "library" (not to be confused with an accelerator such as Bounteous’ Activate, where you own the code) will always come with a measure of "lock-in." If you’re using Adobe’s WCM Core component library, you are beholden to the updates made in the library whether you agree to them or not. And though Adobe goes to great lengths to make updates backward compatible, there’s always a risk of updates unexpectedly causing issues in production.
If you’re using a third-party partner library, the risks are even higher. With a third-party library, you’re beholden to that partner for any support and feature changes. This can be a real problem as the AEM platform evolves over time if your relationship with the partner isn’t perpetual.
Beyond the concerns of lock-in, your development team is also constrained by libraries. Though libraries like WCM Core do their best to provide options for overriding portions of the experience and functionality with business-specifics, inevitably some overrides are simply not possible and require the team to choose between reimplementing/duplicating an entire feature or constraining the business to the opinion of the library.
In other cases where overrides are possible, technical limitations in how overrides are enabled result in brittle half-versions of components that are highly susceptible to breakage in the future. The extension patterns all sound very good on paper or in a classroom, but experience on real projects shatters the rose-colored glasses at a point when it’s too late.
Your safest bet when developing an AEM component library is to own your code—all of it.
Avoid the Pitfalls
If you’re implementing a few microsites or landing pages on AEM, really any approach that gets you there quickest will do. But if you’re leveraging AEM for mature web properties critical to the long term success of your business, and expect the platform to evolve with your business for years to come, be sure you do it right by avoiding these pitfalls that will otherwise plague your system for as long as it exists.
