Six Scariest AEM Mistakes Your Team Can Make
AEM projects are usually large, take multiple months to complete, involve many people and often multiple departments. If you do not have a solid plan, experienced AEM experts and a good leader at the helm, expect scary things to happen.
Here are 6 horror scenes to avoid during AEM projects:
1. Forgetting about your authors
AEM is so powerful it gives you enough rope to hang your entire team with. AEM provides many components out of the box (OOTB) to help authors immediately begin creating content. However, if their efforts are not federated by AEM rules that are specific to your team, it is inevitable that productivity, consistency, reusability and governance will suffer. AX (Author Experience) is as important to analyze and design at the start of an AEM project as UX (User Experience).
2. Getting tunnel vision
It’s important with projects of this magnitude to have iterative releases that are tested by all parties involved. The worst thing you can do is wait until the end to realize that you missed that left turn in Albuquerque. Avoid that heart sinking feeling: deliver often, test often, gather feedback often, fail often and solidify your project often.
3. Overlooking out of the box features (OOTB)
Your first instinct may be to develop a feature (i.e: a component, a template, a workflow, an OSGI bundle) because the OOTB component doesn’t do one hundred percent exactly what you want it to. AEM comes with an exhaustive amount of OOTB components that deserve a chance. If they look twisted it’s probably for a reason. Take the time to understand them and weigh your options thoroughly before writing new code and completely busting your project budget and time estimates.
4. Putting all your eggs in the development basket; forget about operations
A common horror scene witnessed is when you get your operations team involved only at the very end of a project. Or worse yet: you throw the implementation at them and forget all about these DevOps New-Age ideas. Ignore deployment, monitoring, proper log management tools and other such commodities, worse yet don’t design for incremental updates and maintenance and watch your project transform into a Halloween monster that will give you and your team nightmares. Obviously, all of this can be avoided by properly addressing the right tasks in the right sequence and beginning with the end in mind.
5. Not understanding the underlying architecture of AEM
The JCR is an incredible mix of relational database features and hierarchical structure. Sling is a very innovative web framework. AEM adds its own layer of awesomeness to provide a great architecture for an enterprise content management system. Having a team that doesn't understand and properly appreciate the strength of the technology will only lead to frustration and potential catastrophe.
An easy fix to this problem is to make sure that your team lead has actual AEM experience. An alternative is to set your team up with an AEM environment where they can simulate an actual project with deliverables and testing.
6. Not using proper software engineering methodology in development
This recipe for disaster is easy: allow your team to write all code using CRX/DE, and to not use Maven, source control, continuous integration during the development process or to write unit tests. You might eventually complete the project but expect it to be something right out of a Tim Burton film.
AEM does not mandate the use of a particular toolkit or methodology to address these problems. However Adobe and the AEM community do offer tools and best practices to help any project team move in the right direction. Implementing these proven principles improves transparency, productivity, and teamwork and undoubtedly extends your project’s life span.