August 06, 2018
Introduction - efficiency vs. flexibility dilemma in global platforms
When investing in Marketing automation tools such as Adobe Experience Manager, the basic purpose behind this investment is faster delivery of more content at a lower operational cost. The latter goal can be achieved by reusing content artefacts or by process automation, and - for companies dealing with multiple brands - using all these clever mechanisms for all internal clients (tenants) on a single hosted platform. On the other hand, "reuse" means reduced flexibility in the visual and functional design of the pre-given artefacts. Imagine you are in the role of a product manager selling a unique product. You certainly want a unique representation and not a standard website assembled with an inflexible catalogue of components. The importance of this "local adaptation requirements" depends, amongst other things, on...:
a) ...the product type: luxury goods or vehicles in particular should consider local culture, wording, visuals...
b) ...the governance style within the company which can be something between the two extremes of a "dictator approach" and an "anarchistic approach" as depicted below.
Centrally governed processes (Dictator Approach)
Headquarters is in charge of providing and managing everything ñ even at a local level.
Virtual / international governed processes (Democratic Approach)
A board of international participants oversees the management/
budget of services in question.
Local governed processes (Anarchistic Approach)
Those responsible for the act on their own without any company
oversight or central guidance
It is not the intention here to judge the value of centrally versus locally governed processes. Each may be the best fit depending on the company model, staff mind and the type of products. And please note that this categorisation can vary from service to service within a single company. E.g. "Security Management" can be efficiently handled centrally, whereas "Project Management" services may be rendered locally so as to work efficiently with local suppliers.
In either case, a global multitenant platform should respect the company's governance setup and not vice versa.
Now, what is the position of Adobe AEM with respect to multitenancy? Is this product so flexible that it can efficiently support all governance variants and allow sufficient flexibility for the marketeers? And can it really industrialize IT processes and keep the efforts manageable in a multi brand / multi language setup?
Promises are made by Adobe, but as always, you should countercheck sales statements and you probably will find during your research an Adobe article like this:
This Adobe technical article already indicates that there are some governance-limiting constraints if you want to use the platform in a multitenant mode.
We thought that it might be a good idea to put more light on this topic and discuss how an international, multi-brand company might cope with the task of converting a localized product page from a centrally managed white-label blueprint to a local brand content page.
First of all, a disappointing message: "The one and only Setup" does not exist. Each company is unique and the degree of flexibility differs. So you have to continue reading.
"Agency-Cut" vs. "Supplier-Cut"
If a company has the need for product localization with local development partners in a centralized IT management structure, the first question which comes up is to what extent this local partner can contribute via a shared platform. Based upon my past experiences I would categorize this in two ways, as depicted here:
External partner uses an existing component/template catalogue and customises it with modified CSS/HTML for localisation. Quite often the embedded CSS overloading mechanism allows one to change the look with preconfigured color and font schemes.
External partner is allowed to create and deploy additional components/templates within the constraints outlined below. These artefacts may later be considered for addition to the catalogue or remain only for project-specific development.
Modifying the CSS in a complex web stack such as Adobe AEM requires an understanding of what can be changed and what cannot. These constraints, accompanied by best practices, should be provided to external suppliers before they create any HTML/CSS packages. I will not go into any detail here regarding these guidelines, but instead of provide some food for thought for a more industrialized approach that allows editors to choose from different colour schemes, icons and logos in order to reskin the provided white-label templates.
Now, we just need to find a catchy name for this tool so that the marketing people believe that it's something really cool. How about we name it, "Light Theme Editor".
All other development, e.g. email connector services and general templating, can be centralised.
With Adobe AEM version 6.4 Theming of visual artefacts is possible by configuration of the related CSS files for each component and view - as demonstrated on the Adobe London Summit 2018.
To conclude, "Agency-Cut" is a model that is found mainly in centrally governed platforms. A Light Theme Editor approach allows further industrialization of the localization procedure.
Things get more complex if an external partner can contribute his own project-specific components, templates or OSGi services. Obviously, this development must conform to the overall platform coding guidelines. To avoid conflicts with other external partners or even the platform owner - who is in charge of the centralized catalogue - you should consider a far more sophisticated approach, which will be discussed in Part II.