Vaatate praegu abisisu järgmise versiooni jaoks::

Best practices for project delivery

The following checklists guide you, through all phases of the project lifecycle, to a successful project delivery. They are intended as a set of best practices for project delivery. To deliver high quality services, you need to complete all items in the checklists, preferably in order.

The checklists contain Input elements and Output elements. There is no 1:1 correlation between inputs and outputs; for example, a collection of several inputs can result in one output.

Laadi alla

Laadi alla


The preparation of your project requires a collection of requirements, a roadmap and other up-front work which should result in:


Input Output
Customer roadmap
  High level solution design  
Scope document   Architecture draft  
Return On Investment (ROI) expectations   Hardware estimates  
Initial experience designs requirements   Performance KPIs  
Business requirements documentation   Project efforts  
Technical requirements documentation    


Key Performance Indicators (KPIs) are:

  • Number of parallel authors and users (concurrency)
  • Response times
  • Number of assets per day (average and peak)
  • Number of page modifications per day (average and peak)


Input Output
Scope document   Validated budget plan  
High level solution design    
Hardware estimates    
Project efforts    
Requirements documentation    


The planning of your project must start with a good understanding of the project by everyone involved. You also need to have a sound knowledge of the risks your project will be exposed to, and a plan on how you will communicate throughout. This will provide a sound basis for the start of your project. Completing these 4 checklists will help you cover the main points:


Input Output
Customer overall project roadmap   Performance KPIs document  
Project scope definition   Project management understands the scope of the project and the expectations  
ROI expectations    
Initial experience designs    
Business and technical requirements documentation    
High level solution design    
Architecture draft    
Hardware estimates    
Historical performance KPIs and expectations    
Relevant contract terms    


The project management team needs to have a clear understanding of:

  • the throughput for the site
  • the numbers of visitors including peak times (for example events iDay, Superbowl and so on)
  • the page render times millisecond granularity, including third party integrations
  • the asset delivery 
  • the caching strategy

Risk Assessment

Input Output
Identify critical key solutions and functionalities   Technical risk factors are known and understood  
Customer roadmap  project timeline   Adjustment of the scope and features required  
Technical and Business Risk Assessment   Results and business decision proposal  
Proof of concept (POC), design and implementation   Technical risk factors verified  
Test and verify POC against Requirement Documentation    


The identification of solutions that can be a potential risk (for example MSM, Commerce integration, and so on) is important. The result will be the basis for reporting into the business whether the full requirements can be implemented or even whether other concepts need to be adapted. In case the solution concept is fraught with risks, the business requires a decision template on how to deal with those key requirements.


Input Output
Definition of internal and external Stakeholders   Issue tracking process is set up and integrated  
Issue Tracking System and processes from involved parties   Project status reports within a defined cadence  
Status Report format definition    
Reporting Cadence    


Input Output
Customer roadmap   Project team understands project and expectations  
Project scope document   Hardware will be available to fulfill requirements  
ROI expectations   Agreement on KPIs, defined as goals for project  
Initial experience designs   Project team is aware of the communication plan  
Requirements documentation    
High level solution design    
Architecture draft    
Hardware estimates    
Performance KPIs    
Timeline and milestones    
Project organization and communication    


For more information about kick-off requirements, see also:

Preparing for Development

Before the actual development, there are several prerequisites to ensure that your team is ready to go for it:

Development Team Certification

Input Output
AEM technical trainings   Staff trained  
AEM certification   Certified AEM Component Developers (75%)  
  AEM Lead Developer Certified (minimum of 1)  
  AEM Architect Certified (minimum of 1)  


For AEM trainings and certifications, see:

Content Architecture

Input Output
Initial experience designs   Content architecture definition  
Requirements documentation   Feasability confirmation on KPIs  
High level solution design    
Architecture draft    
KPIs definition    


This checklist should result in a definition of:

  • Basic structures (content, assets, campaigns, etc.)
  • Multi site and multi language structures (MSM, Translation, etc.)
  • Supportive content (tags, ...)
  • Cached versus uncached content

System Architecture

Input Output
Requirements documentation   System architecture definition  
High level solution design   Run baseline tests on an out-of-the-box installation of AEM, using preferred automation testing suite, confirm deviation to plan and adjust.  
Architecture draft   How KPIs for performance and scalability can be met?  
Hardware estimates    
KPIs definition    
Sign off with lead developer checklist    
Performance and scalability concept    


This checklist should cover:

  • Hardware Sizing Guidelines
  • Required environments (dev, stage, prod, other?)
  • Servers and processes for each environment
  • Maintenance activities (Datastore GC, TarPM Opt, ...)
  • Matching KPI's from Sales Handover
  • Dispatcher caching 
  • Clustering Publish/Authorshare 
  • Most important: Performance for the client-side (JS minify, concat, css sprites, total number of http request, and so on)

Application Architecture

Input Output
Requirements documentation   Run baseline tests on an out-of-the-box installation of AEM, using preferred automation testing suite, confirm deviation to plan and adjust  
High level solution design   List of components and templates to be developed, dialog definition, together with important properties (name and type) for all of these  
Architecture draft   Implementation concept for specific (large) modules of AEM when used  
Hardware estimates    
KPIs document    
Component and template concept    
Special functionality concept    


This checklist should cover:

  • Basic code structure for project
  • Code artifacts (bundles, packages, ...)
  • Templates/components breakdowns and their relations
  • Required customizations (high level, specific overlays later)
  • Design of general workflows that the solution must support (content creation, approval, publishing, transformations, imports, exports, ...)
  • Special attention on complex modules, such as MSM, Commerce, third party integration

System Integration

Input Output
Third party integration requirements   Technical concept for third party integration  
Service level agreements defined and in sync with the platform   Support process and emergency plan  


This checklist should cover:

  • Technical concept on how the third party system will be integrated (offline/online, client-side/browser-side)
  • Fail-over handling when third party system is down 

Test Concept

Input Output
Initial experience designs   Test concept documentation  
Requirements documentation   Test plan  
High level solution design   Customized Tough Day, covering customer use cases  
Transform performance KPIs into Tough Day   Formalized acceptance tests  
Use cases / customer stories   User stories, dissected into click paths, to generate executable test cases  


Tests automated with, for example, Selenium or AEM Developer mode.

Support Setup

Input Output
Setup support processes (Partners/Customers/Adobe)   Staff understands the support processes from Adobe  
List of users require access to Adobe Support Portal   Staff has sufficient permission in Support portals  
Definition of escalation process   Staff understands escalation processes  
Request for setting up project section in Adobe Support Portal   Project setup in Adobe Support Portal  


See the Adobe Support Portal.

Only trained developers are allowed read/write access.


Successful development is crucial to your project. The first step towards this involves completing the following checklists:

Development Environment

Input Output
List of standard development tools to be used in the project   Development environment set up  
High level solution design
  Development system ready  
Architecture draft    


A typical environment consists in an issue tracking system, an IDE (such as Eclipse), Maven, Jenkins (for continuous integration), GIT/SVN, Archiva/Nexus.

Test System

Input Output
High level solution design   Test system ready  
Architecture draft    


The test system must:
  • be ready for development releases and nightly builds
  • preferably have similar sizing as the production system for performance tests

Production System

Input Output
System architecture definition   Production system ready  
Run Tough Day test on final production setup   Baseline performance verfied with Tough Day Test  
Disk performance test   Disk performance (DiskBenchmark) result with a valid pattern  


To help you achieve this checklist, see:

Integration Test

Input Output
Integration test setup   Automated deployment process  
Role Definition for IT and/or Unit Tests    


This checklist should cover:

  • Automated process to move application from dev to test to prod (and content the other direction)
  • Definition on which level developer should test (i.e. IT, Unit)


Input Output
Document customizations which affects upgrades, hotfixes   Operations manual (user guide)  
Document operational tasks    
Release notes    


The operations manual must contain:

  • Information about changes that may affect installed systems and content
  • Information about customizations and overlays that may affect upgrades, hotfixes, etc.
  • Information about operations related tasks (configuration, etc.)

Performance and Testing

Good performance is also key to a successful project:

(End-) User Acceptance Test

Input Output
Release running on production   Functionality of the application is accepted by stakeholders  
Acceptance test   Formalized checklist for customer handover; ideally automated and run on a nightly basis on snapshot, yielding results, sent to project manager and development team  


Final check for functional/workflow issues. It has to be verified with every development sprint.

Performance and Load-Test

Input Output
Performance KPIs   Tough Day or equivalent test suite results, must be passed  
Use cases definitions   Validated test script against realistic and expected load  
Real content for testing   Customized Tough Day or equivalent test suite adapted to real content and result comparison to OOTB test run  
Full loaded test suite   Automated, or run manually on a regular basis  
  70% of the requests for pages respond in less than 100ms  
  No pages respond slower than 1 second.  
  Acceptance from business stakeholders  


For more information about performance tests, see:


Having both trained users and a high level of security is mandatory to be able to go live safely:


Input Output
AEM Admin Training   Trained system administrators  
Standard author training   Trained authors/users  
If required: specific training material for application and/or site   End users trained  


See Adobe AEM Training to find the trainings in the course catalog.

Penetration Test

Input Output
Security checklist   Security test report  
    Signed from system owner  


Input Output
List of security issues   Security issues fixed  
Security checklist   Security enabled  
Penetration test   Penetration test passed  
Fallback system   System and process available for switching back  
Fallback procedure tested   Fallback Procedures passed testing  
Go-live schedule   Adobe Support is informed about the go-live schedule  


You need to define roles (such as author, contributor, administrator) with specific permissions for your users. It is also mandatory to maintain and monitor your system as the project proceeds and to be able to backup and restore in case of emergency:


Input Output
Permission concept (list of roles, groups)   Permissions meet security guidelines  


  • List of roles (i.e. groups) with read/write access definitions for each. 
  • Privileges like replicate defined. 
  • For users with minimal privileges, workflows should be defined. 
  • Users in the editor group should not have admin rights nor be part of the administrators group.

For more information, read User Administration and Security.

Maintenance and Monitoring

Input Output
Disk space monitoring   System monitoring enabled  
CPU monitoring   Threshold and interventation enabled  
Disk I/O monitoring   External system monitoring enabled  
Network bandwith monitoring    
DataStore garbage collection enabled and tested    
Repository optimization    
External system monitoring    
Request monitoring    


See also Monitoring and Maintenance for more information.

Backup and Restoration

Input Output
Backup of author and publish instances   Recovery plan and procedures documented  
Restoration tested and documented    
Cluster: steps for cloning were tested and are documented    


In an emergency situation, a full rollback/restoration must be available to secure the production use of AEM.