AEM Development Workflow - Part 1 (Introduction)

if you have followed my blogs recently, you would know that i have debated the development workflow for a cms based application being developed on top of adobe aem. if you missed those posts you can read here and here . to summarize and set context

the challenge we have seen is too much time spent to integrate the html/js/css being delivered by the site developers into the aem’s components and templates. and the solution that seems to be cropping up is not to fix the process but to pick technologies that change the workflow fundamentally. more specifically, i have seen some suggestions that try to solve many other things and lose sight of this simplest of the problems.

technology should really be an enabler and in this case if there is a technology that can enable us to do something better and faster why not. i am thinking through is if there is a universal solution to this problem and can we apply this solution pattern or technology to all solutions cms or not; aem or tridion, etc.; or does there needs to be a more scientific way of arriving at the solution.

referring to a few of the slides from adobe’s presentation presentation here ; i want to highlight two specific slides (merged here into one) where the problem now stands in how the components get build and how much time it takes (the problem itself). if you have read the entire presentation, you would already know that adobe’s answer to fixing the problem is sightly .

what i want to do here is to compare 3 workflows and see what each one has to offer and what’s the best possible way to remove this inefficiency or improve productivity.

1. follow the current set of technologies jsp-java but change the way of working aka different set of tools, trainings and processes
2. use sightly ~ the new templating language pushed by aem
3. use other templating languages like handlebars or angular which are more platform agnostic and goes beyond just cms and aem (old school application development also fits)

there will be a set of posts in coming week as we go through each of those 3 ways of writing the application. for the sake of this exercise, i am going to take on one of the most common components ever used in the cms world – the carousel. for each of these activities i will elaborate upon the steps which entail to reach from a design to end product aka – final working part for a consumer. the solution will be built in adobe aem (not going to touch any other set of cms tools for now; maybe later). for me to be objectively look at the end results, i will use the following parameters for comparison in the methods:

1. level of effort (loe) spent by a site developer in converting the design into a working front-end code
2. loe spent by a aem developer to take up the front-end code and convert it into a cq component
3. loe spent in any sort of integrations and bug fixes between the two paradigms

as we progress, i will post sample code, screenshots of what i am trying to do. i will also publish a product (code, configuration, content) that you should be able to run on an instance of aem if you have access to one handy. i will also publish the tools i would use along the way – including instructions or setting it up on your boxes. if you like this subscribe to this url and you can directly see posts only applicable to this topic.

next > finding the problem