My colleague Jan Exner initiated a “no custom code challenge” for the Analytics area earlier this year; and in the followup of this the people of 33sticks posted a good summary why it would be much better if you could avoid any custom code in the analytics world.
I am wondering if this holds true for AEM systems as well. On the one hand side customization is required. For example you need to style the components according to the requirements and styleguides. But on the other hand siede, excessive customization (overlays and adaptions/changes to ootb functionality) leads to maintenance and upgrade issues. But maybe we should not use the term “customization” anymore in the AEM world, but choose a more appropriate one, maybe “application development on AEM”, because that’s what we do in reality quite often.
And the application development part is the one which makes software expensive. It requires design, architecture, implementors, tests, automated tests, deployments. It requires management and comes with risk. The more application development we have, the higher the risk and the costs.
If you were able to avoid any application development in an AEM project, and just live with the core components components and brand them accordingly, that would be great. We would only focus on style and branding of the components, no need to Java developers and code deployments. Just pure frontend, and a clever use of the out-of-the-box tools AEM offers you.
I am truly convinced that you can build a standard marketing site (multi-site, multi-language, integrated translation etc) with this approach. It requires dicussion with the business and more important, you as a developer or architect need to urge yourself not write any code.
Of course, it’s probably getting a very basic site, but it can serve 2 purposes:
- We identify what should really be part of AEM (which is something we can and should add asap)
- We challenge ourselves to think in much simple structures and less customizations. I always wonder how easy the statement “then let’s overlay it” comes out of the mouth of an AEM consultant in a discussion, and I am no exception to this.
Yes, can we join Jan’s initiative. With AEM it’s definitely harder to achieve this than with other solutions of the Adobe Experience Cloud, but it’s doable. And honestly, we should accept such challenges more often. Even if we eventually fail.
But the learning is immense.
Things on a content management system 
Instead of ‘customize’, I like to refer to ‘extend’… AEM is a base-platform that needs to be ‘extended’ to meet business needs/requirements. I do think that use of core components, now, gets us ‘closer’ to an OOB implementation – with the added task of setting up the clientlibs (css/js). But, every client’s needs are so diverse, especially with the world ever moving towards more and more SPAs. I always advice customers, if you truly need to CUSTOMIZE some part of AEM, be aware that future upgrades could become (more) painful. Excellent blog posting. –Todd
The question is always the “if you truely need to customize”. While there are cases where it’s really obvious that such an extension is required, there are others, where we often agree too early to customize. And it’s to easy to put the burden of the decision and the impact to the customer. Often we as implementers are convinced that a requirement is silly or if it’s considered from a different angle, can be fulfilled much easier. But we go the easy way, take the money and customize.