AEM: Are you Coding when you should be Configuring?

Photo by Jeremy Bishop on Unsplash

There is an interesting assumption that people make when thinking about development for Adobe Experience Manager: you have to be a good coder in order for it to be done right. While you need to know how to code, that isn’t where the bulk of AEM work is performed. The real expertise in working with AEM is to understand how to properly configure it. The subtle intricacies of the software make it so you can just use simple HTML, CSS, and Javascript. It’s not that complex to use whatever coding process you want. Where it gets hard is understanding how to use AEM to accomplish your business objectives. Or better yet, knowing how the infrastructure works so that you know why your code or website is failing.

So when we talk about being an AEM implementation specialist, what we are really saying is that we understand Adobe Experience Manager’s toolset so well that we can pull the right levers, spin the right dials, and press the right buttons to accomplish the desired effect.

There are plenty of wrong ways to code for AEM (or any platform for that matter) but for the most part, the issue is tweaking tools and knowing where to put your code. “This system” likes it to be done in “this way”. With Adobe Experience Manager occasionally you will need to write some custom Java code. A given in any AEM implementation is that there will be some specific requirement that can’t be accomplished through the normal out of the box components, and you will need to create something completely new from scratch; just plan for it. Or, certainly there are going to be times where the business goal requires heavy coding — for example, we spent a month upgrading a client’s Classic UI component dialogs to 6.4’s Touch UI dialogs, which involved changing to Granite UI dialogs away from custom ExtJS code. But every developer should always practice proper coding standards. Those exist regardless of the system you are working with.

Don’t Reinvent the Wheel

Or maybe said a more relevant way, “don’t reinvent the really complex tool that already exists inside AEM”. Once I worked with a developer who wanted to create his own system for tagging pages of content. I pointed out that it might be easier, and less time consuming, to just use AEM’s built-in Tag Manager system. After more discussion than I would have thought necessary, it was agreed that we would use the native AEM Tag Manager. Don’t overdevelop your solution.

“But I don’t like the tool AEM comes with.” That’s actually a valid concern. There may be some truly awful tools that you have to work with (ie: AEM’s vanity URL support). But is it worth building a completely new thing that no one other than you can support as new versions of AEM come out? And do you really think that you are going to build something better? Using the built-in tool is almost always better than just rewriting it.

You don’t need to rebuild these items, you just need to calibrate these tools so that they do what you want them to.

If I was going to try and be catchy, I might try to give you the “top 5 things that your implementation partner should know how to configure in AEM”, but that wouldn’t be accurate (though if I were these would be at the top of my list: /etc/map rules, dispatcher configs, replication, workflows, and general systems maintenance tasks). No two AEM projects are done the same way. Instead, I would say that your AEM implementation partner, or your own internal team, should know about, and know how to make, all the necessary configurations. They should know how to configure the tools of AEM to accomplish your business requirements.

We do. We’re Hoodoo.