What do you do anyway? Part 1: Delivering Experiences with AEM By Hoodoo

So what do we, at Hoodoo Digital, do? I’ll answer that question over the next three articles as I cover: how we Deliver Experiences with AEM, our AEM Connectors, and our AEM Cloud DevOps Platform. Let’s start with how we deliver experiences with AEM.

There are a lot of companies out there now that can assist you in your Adobe Experience Manager implementation. Hoodoo Digital understands AEM at a basic and fundamental level because we have been working with it for so long and we employ experts and content leaders in the field. We have a team of people who have been working with it for the last 8 years. Since before Adobe was actually using it. Let’s talk first about Kem Elbrader & Andy Wakefield’s history with it.

Back in 2010 Kem and Andy were asked to review a content management system for Omniture, a client at the time. The CMS in question was CQ, the forerunner to what would become known as Adobe Experience Manager. Having been a heavy Java developer, and being familiar with the Java Content Repository (JCR) — a foundation to the CQ system — Kem managed to get a copy of the CMS and reported his findings to the customer that this indeed would be a good tool to build website functionality with. And so Kem led the task to migrate Omniture’s websites over to CQ. Because of their success, eventually Adobe contracted with Kem and Andy’s employer to build some of their own web properties on CQ; Adobe Acrobat’s website and their internal Sales Collateral Portal (a type of asset share site). And from there the flood gates opened as more and more properties within Adobe needed help migrating to AEM, and because of that experience other organizations came to him for help.

One of our team members, Tyler Maynard, is the leading authority on Pluralsight Adobe Experience Manager courses. He has authored 5 courses that have over 10,000 hours of viewership, and growing steadily, with more videos slated before the end of the year. When developers need to learn how to use AEM, Tyler is leading the way.

Also, not to toot my own horn too much, but I have also been creating and sharing helpful developer information since 2013, through my work on AEM Podcast, one of the original and foremost independent sources of AEM development content, as the Editor in Chief and main writer. And additionally now on the the site AEMHQ.com where I serve as its Editor, to produce even more content geared at building the AEM Developer knowledge base.

Our understanding and long exposure to AEM is what makes us so good. But our history is not the only way to find success. We are constantly trying to find a fresh approach.

While the basic implementation or augmentation project is certainly well within our wheelhouse, and something we do for customers that need it, we do things a little differently. Our focus for AEM implementations has been on: Running Lean, Creating Connectors, Design Systems and Toolkits, and Our AEM Cloud DevOps platform. Let’s talk about each one briefly.

Many other organizations will build a lot of redundant layers and personnel into the project, thus ramping up the FTE count and, consequently, the budget. We would prefer to simplify and work smarter. AEM is already expensive enough, and you don’t need an over bloated approach. As Uncle Scrooge would say, “Work smarter, not harder”. Instead of inserting layers between you and the developer, there is direct access, ownership, and accountability. We ensure a high level of competence and maturity in our AEM Architects and Developers, and because of that you don’t need full time babysitters herding the team along. That isn’t to say that, in certain situations, TPM’s, BA’s, and Account team members aren’t useful, only that they shouldn’t be viewed as essential to a project’s success. Stay lean for as long as you can.

A major headache in enterprise web development ends up being third party integrations with other marketing tools. Building templates, components, and authoring controls in AEM is actually pretty straightforward, if you have a basic self-contained website. But what enterprise does? There is always some system that needs to be integrated into AEM because it is a critical tool that has been around in the organization for years and years. So rather than rebuild the same solution with a third party product time after time, let’s partner with these organizations and make products that can be enhanced and iterated over time with those companies that use them to improve their utilization. These products are what we call Connectors. This product reuse is one of our long term goals, as it helps to make the product: be more useful, last a long time (reducing TCO), and become more maintainable. We’ll discuss our specific Connectors in more depth in another article.

There is a significant challenge when writing components for Adobe Experience Manager; frustration, felt by both the Author and the Designer. The frustration from the Author happens because the development on the newly designed component is slow, requiring them to wait a long time before they get their tool. The frustration from the Designers happens because new designs can’t be accommodated with existing components and there is push back from the development team. The solution is the Hoodoo AEM system design approach. Our goal is to enable rapid introduction of new experiences while minimizing additional component development effort by allowing the front end developer to work in their own development structure, keeping them out of AEM specific areas.

“How can we make DevOps easier?” Knowing that DevOps is a major pain point for organizations prompted us to ask this question and find a solution to it. We took some inspiration from what Gitlab was doing with Auto-DevOps. Our solution was to create AEM Cloud. Instead of having individual environments running 24/7 (Dev, Test, Stage, and Prod) that need continued and ongoing maintenance, as well as a bill of running costs, you instead only run your Production environment and then spin up other environments on demand to do your QA and UAT, or other needed testing and review. The savings alone in your hosting costs should make this worthwhile, but the added savings from not needing to run constant patches, garbage collection, and other forms of maintenance make it even sweeter. We built AEM Cloud on Kubernetes, which allows developers to spin up their needed environment by running a simple command using Docker images that we already have built, based on all the various Versions, Service Packs, Cumulative Fix Packs, and Hotfixes. We will discuss AEM Cloud in more depth in another article.

We think that our approach to AEM development and our expertise really set us apart from the rest of the AEM implementation competition. Join us for part 2 of our article series where we will focus on our AEM Connectors.