I’m not talking only about getting rid of nasty .jsp’s with a bunch of scriptlets inside. They did much more in the last few years. The product is getting better and better, the clients are getting more and more capabilities.
But what happens with Developers? Do we still need them? How did that role changed in the past few years? And how will it look in the future?
Not so long ago, there was no Adobe Managed Service and everything was hosted on-prem. What is more, there were no editable templates, no mechanisms of reusing content like Content/Experience Fragments and even no Core Components!
Typically, almost all the components were developed from scratch, the code was deployed manually, all the tests were custom, etc. Every single company was following its own best practices and development cycle process.
Building a site was quite a complex task that required producing boiler-plate code.
There was quite a lot on the developer’s shoulders that time!
Then Adobe introduced a few improvements…
In the last few years, Adobe introduced many interesting features that significantly influenced the developer’s life. To mention a few:
- Editable templates, Content Fragments / Experience Fragments
- Core Components
- Cloud Manager + Quality Gates
- AEM as a Cloud Service
So what exactly has changed for the Developers?
Now, many simple projects can be “composed” from the existing pieces (e.g., Core Components that cover a large number of business cases) and actually the only customizations that have to be made are:
- Custom styling + JS implementation
- The Dispatcher configuration
- Widely understood “configuration” (e.g., policies)
Hold on, so I don’t need to create custom components but how do I deploy my application?
Cloud Manager sounds like a good option. It will not only take care of the deployment but will also handle performance and security testing.
Does it mean that nobody needs an AEM Developer 🙁 ?
Well… not really 🙂 There’s still quite a lot to be developed: in some of the organizations, Cloud Manager might not be enough to cover all the specific security, testing or procedural requirements. Thus, it usually becomes a step of the already existing CI/CD process. Someone has to find the mutual ground for those two worlds. Typically, that would be a developer’s work.
Also, local and dev environments are usually not kept in the Cloud, so someone has to manage them. What would either be DevOps or the Developer’s role?
Not to mention: customizations to be made within the components, workflows, a backend, integrations, and so on, so on…
What happened to the Authors?
Authors or actually Super Authors are more and more important in my opinion. They can take care of things that previously were reserved to developers only. Which is good, because developers can focus on coding customizations rather than producing boilerplate code or configuration. Authors can do things faster without a need for the deployment of any code.
AEM is changing and the team roles require optimization. Developers are equally important as before, now thanks to Adobe they can focus on the development instead of composition and configuration.
So how should the perfect AEM Team structure be?
I think that currently, the well-balanced AEM team could look as follows:
- AEM Architect designing the solution
- AEM Super Authors working on Editable Templates, Sites Composition, Policies, etc.
- AEM developers developing custom components & features
- Frontend Engineers that style the whole solution
- DevOps working on CI/CD and the Dispatcher configuration
- QA Engineer working on the quality of the system
I asked fellows from Antologic to read and comment on my article before I publish it. The only comment I got was: why don’t you mention full-stack developers? The reason being, I have never met a person that was good at both: backend and frontend. It’s always a compromise between these two and having dedicated people is (in my opinion) much more efficient. Having said that, it might only be me who never met a real full-stack. What is your opinion?