Adobe Summit 2019 — my session summary

This year I was not able to attend the Adobe Summit in Las Vegas, but as many recordings are online available, I want to give you a short list of sessions I would have liked to attend.

Adobe Experience Manager Rock Star: The top tips are here” by Kaushal Mall and Darin Kuntze. Of course the most important session for the AEM community 🙂 Thanks to all presenters and congratulations to Marc!

Content strategy and architecture — The infrastructure behind the interface” by Elise Hahn. Elise highlights the importance of content architecture as part of the content strategy of an organization. Not a technical topic in the first place, but she points out that the content strategy always impacts the work of the engineering teams (even if you are not aware of it). Highly recommend content, also for technical folks.

Adobe Experience Manager Sites: Top Innovations” by Haresh Kumar & Cedric Hüsler. Cedric presents the top features of the new AEM 6.5 version. As usual a very informative and funny session, but not the usual “top 10 new features”. This year less seems to be more 🙂

Meet Dexter: The World-Clas Experience Manager Implementation of” by Audumber Ramesh, Lukas Ryf & Chris Millar. Chris shows how they removed the engineering group from the “we need a new component” discussions and let the design agencies directly talk to authors. As followup Chris also posted how they built their dialogs.

And of course there are lot of more gems in these sessions, but I did have not enough time to watch them all (yet). You can find all sessions at (use the search function at the bottom of the page).

“We have an urgent performance problem!”

“Customer situation is heating up because they have urgent performance problems in their production environment” … That’s something I heard quite often in my consulting career. And in many cases it was an outcry for help, because this problem did not turn out during tests, but most times in production environments.

I read once a nice quote: “Everyone has a performance test environment. But only a few have a production environment!” So true.

Is that really inevitable that performance issues occur? Given the number of cases I’ve seen, I am inclined to believe it. But it is not.

I think, that if all of a sudden a performance problem is put on priority 1, it has a history. If you are in a project team and one morning your project lead/PO tells you that the priorities have shifted, and that you need to push that little unknown item “Performance tuning” from the bottom of the backlog to the top of the list, you were aware of performance as topic. But other features were considered more important.

Or if your customer is starting to escalate with your account team that a really bad application (the one you developed for them) performance is affecting their business, then you often know, that this is not a new issue.

In both cases the priority of this problem just hit a certain level, that executives are getting concerned and start to escalate this topic, because it is hurting their and/or the company’s goals. Here you go, yesterday everything was fine, today it’s all screwed.

All of these problems have a history; performance problems rarely just rise out of nowhere, but they evolve under the radar of ignorance. As long as noone complains, who cares about performance? Features are more important. Until the complaints get loud enough they cannot be overheard anymore.

But when you get at the point where you need to care about performance, you are often in a very bad position. Because now you need information, tools and processes to improve that situation very fast. Because are in the focus everyone is looking to your problem (it’s yours!). “Deliver a fast improvement! Within this week!

But if you have never prepared for that situation, you lack all the necessary things for such an operation:

  • You don’t have KPIs to know what is “acceptable” performance. You just have everyone’s feeling “it’s slow!”
  • You don’t have the tools to measure the current performance. You just have logfiles (hopefully you have them …)
  • Is your system actually able to deliver that performance?
  • “Has anyone got the reports from the latest performance tests?”

That’s a hard situation and there is barely any other way than just to take a bunch of good people and start a surgery in production: Analyzing lot of data, making guesses, increasing logging, deploying hotfixes, and do all the things you already accumulated list on your list of “things which might improve performance” which you maintained over the last months.

But let’s be honest: This is chaos, unplanned, affecting a lot of other teams and people, and hurting careers. But does it really have to be that way?

No. Application performance is no magic, but must be managed. Performance should always be an important aspect in your project, and resources should be spent on it as you spend resources on testing. Otherwise performance is ignored 90% of the time, and in the remaining 10% you are escalating because of the lack of it.

Interview with Cedric Hüsler in the AEM podcast

Peter and Joey from the AEM podcast recently published their interview with Cedric Hüsler. Check out part 1, part 2 and part 3, there are a lot of interesting statements in there.

Cedric Hüsler is the director of product management for AEM for Adobe and a veteran in the WCM market. Although such a title sometimes suggests something different, Cedric is still very technical (at least sometimes he is, first-hand experience :-)) and this interview is a must-listen for all, which are interested in the ways AEM went and will go.

Thanks Peter and Joey for this podcast!

META: Being linked from Day

Today this blog was presented as link of the day on Thanks for the kudos 🙂

Welcome to all who read this blog for the first time. I’ve collected some experiences with Day CQ here and will share my experience and others thoughts furtheron. Don’t hesitate to comment or drop me an email if you have a question to an post.

Please note: I am not a developer, so I cannot help you with specific question to template programming. In that case you can contact one of the groups mentioned on the Day Developer website.