This page provides further details to elaborate on and/or augment the documents and principles covered by the Managing Projects - Best Practices Checklist.
The lists in this sub-section are not exhaustive, but intended as an introduction.
When implementing AEM (particularly for the first time) you will need to review the capabilites and workflows of AEM to be sure of which areas you want/need.
Consider the features of AEM that you will be using, and the impact on your design; for example:
In addition check the Release Notes, for the various versions of AEM, to see when any new features were added.
AEM can be integrated with other Adobe products and/or third party services. These can increase the power and functionality at your disposal.
See Solutions Integration for full information.
A major consideration is whether you want to either:
When moving from a previous version to the current version there are two options:
As with any project it is critical to establish ground-rules as soon as possible. These include:
These points are generic, the Best Practices Checklist deals with specifics in relation to AEM.
These should be clearly defined and made known to everyone involved in the project. In addition, it is advisable to highlight:
By involving interested parties as soon as possible you can encourage them to become stakeholders in the project, thus increasing their commitment to its success.
Paths of Communication
The processes to be defined will depend upon your individual project. Again try to keep these simple, with consideration for:
There are many tools available for tracking information on bugs, tasks, and other aspects of your project - see Overview of Potential Tools for more details.
Clearly define what is to be covered by the project at various levels:
Clearly define what information you will report, in what form, how often and to whom.
This information can be defined within a Project Handbook; the use of a Wiki can also help ensure that ongoing changes are handled efficiently. Wherever these are defined, the key factors are that:
Organizations use Key Performance Indicators (KPIs) to evaluate their success at reaching targets. These indicators are measurable values that can be used to demonstrate how effectively specific objectives are being met.
These indicators can be:
Some, but not all, indicators can be based on the target metrics that you identify and define.
Metrics are used to define quantitative measurements for the quality of your website - they are basically a definition of the performance goals that you want to achieve and can be used to define your KPIs (Key Performance Indicators).
Many metrics can be defined, but often the ones you define cover your goals for performance and concurrency. In particular, factors which can be difficult to quantify, and are often prone to emotional assessment:
“our website is much too slow today” - when does slow qualify?
“everything grinds to a halt when my colleague logs in” - how many concurrent users can the system support?
"when I search, the system grinds to a halt " - which sort of search requests are impacting the system?
“it takes ages to download the file” - what are acceptable download times (under normal network conditions)?
Target Metrics are defined at the start of a project to:
As always care must be taken when defining the target metrics:
During development of the project they can be updated and tuned as appropriate. After the project has been successfully implemented, they can be used to help you control your installation and monitor/maintain the required levels of service for ongoing operation.
When used properly these metrics can provide a useful tool; when used irresponsibly they can be a time-wasting distraction. As always, you need to understand what you are measuring, how you are measuring it and why.
This section will deal with the basic principles and issues to be considered. Each installation is different, so the actual values to be measured will differ.
All metrics to be measured will, in some way, be affected by the design of your project. Conversely, many issues will be best solved by design changes.
Therefore, you should define your target metrics before deciding on your design. This allows you to optimize your design based on these factors. Once your project has been developed, it will be difficult to make any changes to the basic design principles.
When you create the structure for the website, follow the recommended structure for AEM websites. Make sure you understand the following issues and/or principles:
If you feel that your design does not follow the guidelines, or if you are unsure about some of the implications, clarify these issues before you start either the programming phase or filling in the content.
To define or assess the infrastructure it will help to define target values such as:
Depending on your situation, and the strategic significance of the website, this will help you to assess and choose your infrastructure:
There are several performance factors which can be evaluated:
response times for individual pages, taking into account:
response times for search requests
This section can be read in conjunction with Performance Optimization that expands the technical details of actually measuring the performance.
A key issue is the time your website takes to respond to visitor requests.
Although this value will vary for each request, an average target value can be defined. Once this value is proven to be both achievable and maintainable, it can be used to monitor the performance of the website and indicate the development of potential problems
Differing targets on author and publish environments
The response times you will be aiming for will be different on the author and publish environments, reflecting the target audience:
This environment is used by authors entering, and updating content, so it must:
This environment contains content which you make available to your users:
speed is still vital, but is often slower than an author environment
additional performance enhancing mechanisms are often applied:
So how can you decide on achievable (average) response times? This is often a matter of experience:
However, (under controlled circumstances) the following guidelines can be applied:
The above numbers assume the following conditions:
There are several mechanisms you can use to monitor the response times:
Monitoring response times with the AEM request.log
A good starting point for performance analysis is the request log. Amongst other information, you can use this to see the response times of individual requests. See Performance Optimization for more details.
Monitoring response times with HTML comments
*HTML comments* can be used to include response time information within the source of each page:
</body> </html>v <-- Page took 58 milliseconds to be rendered by the server --> Response times for search requests
Search requests can have a significant impact on your website, in terms of both the:
Response time of the actual search
Impact on general performance
Setting targets for search requests is, again, a matter of experience depending on:
These should be planned and integrated from the very start of your project. Mechanisms available for monitoring include:
Monitoring search response times with the AEM request.log
Again the request.log can be used to monitor the response times for search requests; see Performance Optimization for more details.
Programmed mechanisms for measuring search response times
To customize the information you collect about search requests, and their performance, it is recommended to include information collection in your project source code; see Performance Optimization for more details.
Your website will be made available to a number of users/visitors, on both the author and publish environments. The numbers are often more than you used when testing, but also fluctuating and difficult to predict. Your website will need to be designed for an average number of concurrent users/visitors without noticing a negative performance impact. Again the
request.log can be used to make concurrency tests; see Performance Optimization for more details.
Targets for the number of concurrent users, are dependent on the environment type:
Before discussing the related metrics, a quick definition of the terms:
Capacity and Volume
|What / Where||Capacity||Volume|
|Client||Computational power of the user’s computer.||Complexity of the page layout.|
|Network||Network bandwidth.||Size of the page (code, images and so on).|
|Dispatcher cache||Server memory of the Web server (main memory and hard drive).||Web server (main memory and hard drive). Number and size of the cached pages.|
|Output cache||Server memory of the AEM server (main memory and hard drive).||Number and size of the pages in the output cache, the number of dependencies per page. The dispatcher cache lowers this volume.|
|Web Server||Computational power of the Web server.||Amount of requests. Caching lowers this volume.|
|Template||Computational power of the Web server.||Complexity of the templates.|
|Repository||Performance of the repository.||Number of pages loaded from the repository.|
The preceding sections detail the main metrics to be defined.
Depending on your specific requirements it might be useful for you to define additional metrics, either in isolation, or taking the above classifications into account.
However, it is preferable to have a small set of accurate, core metrics that function easily and reliably, rather than try to measure and define every aspect of your website. By its sheer nature, your website will start to change and evolve as soon as it is handed over to your users.
Security is crucial and an ever-increasing challenge. It must be considered and planned from the earliest stages of your project.
The Security Checklist details steps that you should take to ensure that your AEM installation is secure when deployed. Other security aspects are covered under Security (when developing) and User Administration and Security.
For a new implementation of a standard AEM project you will need to consider tasks such as:
For all aspects it is recommended to use an iterative approach:
Split the project-launch into Soft Launch(s) (reduced availability, multiple iterations) and Hard Launch (full availability - Live) to allow for tuning, optimization and user training under realistic conditions on the production environment.
See the Project Checklist for examples of tasks which you should perform (or assess) during the life-cycle of your project.
Some points to note for each category are:
Define the base architecture first.
Use several iterations (sprints) for development:
Plan for the eventuality of an update of the available AEM version during the project.
Plan for tests and optimization during sprints.
Plan for stabilization and optimization phases.
Create a log of items to be planned for further releases.
Plan for partner involvement and handover.
Define the base architecture first:
Use several iterations; for the first sprint and initial configuration prepare:
Plan for several load tests.
Plan for tests and optimization during sprints.
Plan for a stabilization and optimization phase.
Deploy to the production environment as early as possible (let the operations team setup the system to gain experience).
Use named users and defined roles as early as possible.
Plan for training (for example, administrator training).
Plan for handover to operations.
Dependent on your resulting task list you can then make initial estimates of time and effort for (high-level) task definitions. These should include an indication of who (customer or partner) will do what and when.
The following list shows standard approximations and inter-relationships of effort involved, and therefore costs:
These figures can only be used for initial estimates. An experienced AEM developer must make the detailed analysis.
|Development||A rough estimation of 2 - 4 hours for each component node will cover all development requirements.|
|Developer Testing||15% of Development|
|Follow-up||10% of Development|
|Documentation||15% of Development|
|JavaDoc Documentation||10% of Development|
|Bug-fixing||15% of Development|
|Project Management||20% of project costs for ongoing Project Management and Governance|
Detailed planning can then relate available or required resources to deadlines and costs.
The reference architecture is given to provide a template solution for the AEM architecture. The reference architecture addresses problems commonly encountered for enterprise systems including scaling, reliability and security.
The following site metrics should be defined:
|Number of Internet sites|
|Number of intranet sites|
|Number of code bases (e.g. if Internet and intranet differ)|
|Number of individual pages|
|Number of site visits / day|
|Number of page views / day|
|Volume (in GB) of data transfer / day|
|Number of concurrent users (Closed User Group)|
|Number of concurrent visitors (publish)|
|Number of concurrent authors|
|Number of registered authors|
|Number of page activations / working day|
|Number of page activations during deployment|
The following list is provided to inform you of tools that can be used. It is intended as an introduction, not an extensive recommendation list, and should certainly not deter you from using any other tools which you prefer.
AEM itself provides a range of mechanisms to help you monitor, test, investigate and debug your application; including:
|Selenium||Selenium is an Open Source test tool. The tests run direct in the browser - emulating how your users work.|
|Microsoft Project||A commonly used project management tool.|
|Jira||Jira is an Open Source tool for tracking and managing details of your software bugs. Workflows can be imposed onto the bug details as required.|
|Git||Git is a revision control software.|
Eclipse is an Open Source IDE, composed of various projects. These are focused on building an open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software across the lifecycle.
See How to Develop AEM Projects Using Eclipse for more information.
A professional (and therefore liable to licensing costs) IDE offering a comprehensive range of features.
See How to Develop AEM Projects using IntelliJ IDEA for more information.
|Maven||Maven is a software project management and comprehension tool which can manage a project's build process (software and documentation).|
In addition, the following sections are of particular interest:
Adobe provides further Best Practices for all phases and audiences: