Glossary glossary
This glossary lists (alphabetically) details of all Deliverable documents from the Project Checklist.
Acceptance from Business Stakeholders acceptance-from-business-stakeholders
Acceptance from business stakeholders confirms that they, as key stakeholders, are aligned with the solution and have given their approval as to how the business requirements meet the business case.
Acceptance Tests acceptance-tests
Acceptance testing is performed when an application is ready for production. The tests are performed by a group representing the various types of end-user, using real-life scenarios.
Acceptance tests are used to confirm that the:
- Project fulfills the customer’s requirements.
- Solution is fit-for-purpose.
- Users accept the solution and can envisage working with it.
- Customer accepts the project.
The earlier you plan and design your acceptance tests, the easier the final deployment. They should be defined together with the customer and your Quality Assurance team.
Although you might not be able to define all details at the very start of the project, initial definitions should be discussed and agreed on. The acceptance tests will probably be based on the fundamental requirements (functional and performance).
Access to Test System Coordinated access-to-test-system-coordinated
Ensure that the required levels of system access have been granted to all roles.
Adobe Security Checklist adobe-security-checklist
The Adobe Security Checklist is the official checklist provided to ensure that Adobe Experience Manager (AEM) is secure at installation. It contains the security measures and verification steps that you must perform to ensure the integrity of your instance.
Adobe Support Portal Project Set Up adobe-support-portal-project-set-up
The Adobe Support Portal enables implementation partners and customers to set up the AEM implementation as a project in the Support Portal.
Details can be registered; for example, about the technologies and versions implemented. These provide transparency between the customer and Adobe.
AEM Administrator Training aem-administrator-training
Training for administrative staff of the solution. See the Adobe Training Services for more information.
AEM Author Training aem-author-training
Training for staff who will be producing (authoring) content for the solution. See the Adobe Training Services for more information.
AEM Certification Exam aem-certification-exam
Ensure that the appropriate personas are registered to take the relevant certification exams.
AEM Certified aem-certified
Ensure that the appropriate persona have passed the relevant certification exams.
AEM Technical Training aem-technical-training
Provide technical training for the appropriate persona; for example, developers, architects, engineers, and business practitioners.
Agreement on KPIs Defined as Goals for the Project agreement-on-kpis-defined-as-goals-for-the-project
Key Performance Indicators (KPIs) help an organization to define and measure progress toward organizational goals. Once an organization has analyzed its mission and defined its goals, it must measure progress toward those goals. KPIs provide a mechanism for measurement.
Align Business and Performance KPIs align-business-and-performance-kpis
Alignment of your business and performance Key Performance Indicators (KPIs) helps pull together all the involved people and processes from within the organization. This in turn helps reduce the amount of time and effort required to achieve business goals and fulfill the proposed purpose.
Alignment of Content Architecture with KPIs alignment-of-content-architecture-with-kpis
Ensure that the proposed content architecture is aligned with the relevant Key Performance Indicators (KPIs).
Alignment of the Customer Roadmap with Project Timeline alignment-of-the-customer-roadmap-with-project-timeline
The Customer Roadmap is composed of high-level milestones and business goals. The Project Timeline must adhere to and align with this strategy, so any potential risks and/or possible deviations must be highlighted and tracked.
Application Architecture Definition application-architecture-definition
The application architecture should clearly define the behavior of the proposed applications.
It is focused on:
- How they interact with each other and with users.
- The data to be consumed and produced by applications, rather than their internal structure.
Application Specific Maintenance Tasks Defined application-specific-maintenance-tasks-defined
Apart from standard Adobe Experience Manager (AEM) maintenance tasks, you must define any other operational tasks that must be run for the ongoing maintenance of the solution.
Appropriately Trained Staff appropriately-trained-staff
Ensure that your team is made up of staff with the appropriate training. For project teams the recommendation is to have all the following:
- at least one AEM certified Lead Developer
- at least one AEM certified Architect
- at least 75% of your developers AEM certified;
this allows the certified developers to mentor junior developers and ensures knowledge sharing and transparency
Architecture Diagram architecture-diagram
The architecture diagram is a graphical representation of the architecture. It includes representation of:
- the concepts
- their principles
- elements and components that are part of the architecture
Architecture Draft architecture-draft
This provides a high-level view of the system and solution architecture. At this stage it is a draft that will be reviewed and refined at later stages.
Architecture Review Board Sign Off architecture-review-board-sign-off
The Architecture Review Board is a cross-organizational body that:
- oversees the implementation of a coherent strategy
- ensures compliance in systems
The review board should be representative of all key stakeholders involved with the architecture. Typically they are composed of a group of executives responsible for the review and maintenance of the overall architecture.
Automated Test Suite Adapted for Real Content and Results Compared to KPIs automated-test-suite-adapted-for-real-content-and-results-compared-to-kpis
Automation scripts and basic automated use cases:
- adapted for production content
- checked against the KPIs
Automated Testing Strategy automated-testing-strategy
This strategy defines a framework for reusable automated scripts, together with the approach planned by the Quality Assurance (QA) team. It outlines the overall plan for automation testing to help ensure:
- a higher Return on Investment (ROI)
- more test coverage
- increased test reliability with quality repetition
Automated Testing Strategy Validated Against Realistic and Expected Load automated-testing-strategy-validated-against-realistic-and-expected-load
The Automated Testing Strategy must be validated and adjusted according to the content and expected load that will be on the solution.
Automation Strategy automation-strategy
The automation of deployments ensures faster and consistent deployments. The Automation Strategy outlines the configuration of any such automation mechanisms; including:
- frequency
- tooling to be used
- environments to be deployed to
Aware of Communication Plan aware-of-communication-plan
The entire project team and all stakeholders must confirm that they are aware of the:
- reporting structure
- cadence of reporting
- channels of communication
Aware of Success Definitions and Criteria aware-of-success-definitions-and-criteria
The entire project team and all stakeholders must confirm that they are aware of the:
- definitions of success
- criteria for success
Backup and Restore Concept backup-and-restore-concept
The Backup and Restore Concept outlines the technical functionality that will be implemented in the solution. It is required by the Company back up and restore policy.
Backup and Restore Tested backup-and-restore-tested
A full end-to-end test based on the Backup and Restore Concept.
Business Cases business-case-s
A business case document presents the arguments related to taking the action, taking alternative action (if available), or not taking any action. The arguments should be balanced, based on concrete facts (wherever possible/relevant) and highlight both the benefits and risks for all cases.
A business case document should be a clear definition of all options, concluding with a compelling argument for implementation of the proposed solution.
Business Analyst Understands Scope of Project and Expectations business-analyst-understands-scope-of-project-and-expectations
The Business Analyst should confirm that they fully understand:
- the scope of the project
- all customer expectations
- that this is the basis for all decisions made per persona, per phase in the project
Business KPIs business-kpis
Organizations use Key Performance Indicators (KPIs) to evaluate their success at reaching targets.
Business KPIs define measurable values that demonstrate how effectively a company is achieving key business objectives. It is important to choose KPIs appropriate to your business/scenario with clear definitions of what they are, how they are measured, how they are used, and by whom.
Business Requirements Documentation business-requirements-documentation
A business requirements document (BRD) details the business solution for a project, providing a clear specification of the customer’s business needs and expectations. The BRD also distinguishes between the business solution and the technical solution.
When examining the business solution the BRD should answer the question:
“What does the business want to do?”
Business Sign Off on any Required Adjustments to the Solution or Architecture Identified and Aligned Against ROI and KPI Expectations business-sign-off-on-any-required-adjustments-to-the-solution-or-architecture-identified-and-aligned-against-roi-and-kpi-expectations
The processes of risk assessment and penetration testing may produce issues and outcomes that must be addressed in the architecture or development of the solution.
Any adjustments resulting from these processes must be reviewed and approved by the business and gauged against the overall goals.
Caching Strategy caching-strategy
The Caching Strategy outlines what will be cached for the end user. It must be compliant with the Performance KPIs.
For examples, elements such as images, JavaScript, and other server files can be cached to improve the performance of a solution.
Coding Guidelines coding-guidelines
The Coding Guidelines define basic principles that the developers should adhere to when developing the solution. These can include, among others:
- naming conventions
- service usage
- library usage
Communicate Operations Manual communicate-operations-manual
Ensure that all appropriate persona/roles have received the Operations Manual.
Communicate Performance Test Report communicate-performance-test-report
Ensure that all appropriate persona/roles have received the Performance Test Report.
Communicate Release Notes communicate-release-notes
Ensure that all appropriate persona/roles have received the Release Notes.
Communicate Scope and Expectations to Team communicate-scope-and-expectations-to-team
Ensure that the project team is fully aware of, and aligned with, the project scope and expectations for delivery.
Communicate Training Materials and User Guides communicate-training-materials-and-user-guides
Ensure that all appropriate persona/roles receive the training materials and user guides.
Compliance with Customer Security Requirements compliance-with-customer-security-requirements
Ensure that all the customer’s security requirements are in place.
Compliance with Security Concept compliance-with-security-concept
Ensure that the Security Concept is in place.
Components and Templates Relationship Concept components-and-templates-relationship-concept
The outline of the templates and components that are used in the new application. Includes details such as inheritance rules, permissions, and relationships, among others.
Components and Templates Relationship Specification components-and-templates-relationship-specification
Details of the components and templates relationship concept.
Components Specification components-specification
Specification details for each of the components to be implemented.
Concept for Mock-ups of External Interfaces concept-for-mock-ups-of-external-interfaces
The concept of how to develop against and test any external interfaces that may not be open/available to the development or test environments.
Plan/implement mock-ups of these interfaces to ensure that testing is as close to production-like behavior as possible.
Content Architecture Document content-architecture-document
Documentation of the proposed architecture of the content. The details should include, among others:
- content tree
- tagging concepts
- strategies for the reuse of content
Content Validated for Migration content-validated-for-migration
The legacy system content is reviewed and the selected content is validated for migration to the new solution.
Contract Draft contract-draft
An initial draft of the legal contract.
Current Content Structure and Format current-content-structure-and-format
Documentation of the current content architecture and format. This is used to generate the future content architecture. It will also be used for the Migration Concept.
Customer Backup and Restore Policy customer-backup-and-restore-policy
Policies from the customer concerning:
- back up processes for both data and the solution
- storage of the backup
- confirmation that the backup is operating as expected
- restoration, if there is a failure
Customer Coding Guidelines customer-coding-guidelines
Any guidelines/requirements from the customer on how development should be done.
Customer Deployment/Release Policies customer-deployment-release-policies
Policies from the customer that define how and when deployments/releases can be made.
These often include timelines, scheduling, and sign-off requirements.
Customer Monitoring Policies or Requirements customer-monitoring-policies-or-requirements
Customer policies and requirements on what should be monitored. These are in addition to any recommendations specified in the Monitoring Concept.
Customer Production Release Schedule customer-production-release-schedule
The schedule that is defined by the customer for releases to the production environments.
Customer Reporting Policies and Requirements customer-reporting-policies-and-requirements
Any policies, or requirements, or both, that the customer has in regard to reporting. These can include:
- how often specific reports should be delivered
- the format for specific reports
- special requirements
Customer Roadmap customer-roadmap
Formulate a roadmap of the major milestones to be implemented, both technological and business. This roadmap is then communicated to the customer.
Customer Security Policies customer-security-policies
The customer (business and IT) will have policies that define the required security levels for the solution. These can include:
- Requirements for passing a risk assessment.
- Requirements for passing penetration tests.
- Any specific security requirements; such as escaping of all input fields, encryption usage (SSL), certificates, and authentication and sessioning.
Customer Specification Guidelines customer-specification-guidelines
Any guidelines the customer has that relate to the format, delivery, and sign-off of specifications.
Customer Test Reports customer-test-reports
Reports from the customer to the Quality Lead during the User Acceptance Test (UAT) period.
Customizations and Hotfixes that Affect Upgrades Documented customizations-and-hotfixes-that-affect-upgrades-documented
Any customizations and/or applied hotfixes applied must be documented as they can affect future upgrades:
-
AEM can be heavily customized to suit business needs. Any customizations that may impact upgrading must be fully documented. For example, any major changes to the user interface (UI) of AEM.
-
Any updates required for the current solution must be fully documented; these can include:
- cumulative fix packs (CFP)
- service packs (SP)
- hotfixes
- upgrades
Daily User Acceptance Test Report daily-user-acceptance-test-report
Reports or meetings resulting from the User Acceptance Testing (UAT). They should detail:
- the issues reported
- prioritization of these issues
Default Security Enabled default-security-enabled
Ensure that the default security settings for AEM have been enabled/implemented.
Deployment/Release Policies and Processes deployment-release-policies-and-processes
Formalized policies covering both the deployment and releases of your project. These can include:
- time for releases
- holiday planning
- frequency
- and can depend on the environment in question
Deployment Cadence Established deployment-cadence-established
Define the required frequency of deployments across environments.
Development Methodology development-methodology
A software development methodology involves breaking the entire process of software development work into distinct phases (or stages), each with distinct activities. The aim is to improve planning and management.
When defining the methodology, you should pre-define specific deliverables and artifacts that are created and completed by the project team to develop or maintain your application.
Development Role Definition development-role-definition
Define which developer and/or role is executing IT (performance or other) and/or unit tests within the solution.
Development Environment Ready development-environment-ready
Ensure that the development environment is configured with the integrated tooling required for the automation of deployments.
Development Team Understands Scope of Project and Expectations development-team-understands-scope-of-project-and-expectations
The Development Team should confirm that they fully understand:
- the scope of the project
- all customer expectations
- the basis for all decisions made per persona, per phase in the project
Dialogs Specification dialogs-specification
Details about the dialogs required for the solution.
Document Development Environment Setup document-development-environment-setup
Documentation of the development environment.
Document Production Environment Setup document-production-environment-setup
Documentation of the production environment.
Document Test Environment Setup document-test-environment-setup
Documentation of the test environment.
Durability Test durability-test
The Durability Test shows the performance of the solution under a specific load. The tests gauge how long the solution survives when submitted to the threshold load and at what performance levels.
Durability Test Executed durability-test-executed
Execution of the durability tests.
Error Handling Concept error-handling-concept
Error handling refers to the anticipation, detection, and resolution of programming, application, and communication errors.
Error Handling Documentation error-handling-documentation
Detailed documentation of the proposed error handling, based on the Error Handling Concept.
Escalation Processes escalation-processes
Definition of all escalation processes. There will be separate processes for each project level:
- Project team
- Customer
- Adobe
Establish Regular Quality Review Sessions establish-regular-quality-review-sessions
Establish regular quality review meetings with the appropriate team members.
Existing Permissions Structure existing-permissions-structure
Documentation of the existing set of permissions and groups defined for either the legacy solution or within the organization.
Existing Systems Map existing-systems-map
A diagram (or set of diagrams) of the existing systems and dependencies.
Expected Success Definitions and Criteria expected-success-definitions-and-criteria
The Project Sponsor collects the business expectations related to the success of the project. It is important to have the full set of expectations available at the start of a project as these should influence all decisions made throughout the implementation.
Expectations can include:
- specific KPIs, such as the percentage increase in pages served
- lower time for publishing content
- higher-level goals, such as an easy-to-use interface
Experience Designs Requirements experience-designs-requirements
Requirements for the entire experience of the solution. This covers factors such as personalization, cross device persistence, and user experience, among others.
Experience Specifications experience-specifications
Details of the Experience Design Requirements.
External System and User Dependencies/System Context external-system-and-user-dependencies-system-context
A diagram (or set of diagrams) outlining the full ecosystem of the solution. This should include elements such as the external integrations, interfaces, dependencies, and networks.
Fallback System and Procedure fallback-system-and-procedure
The definition of the fallback system:
- the business critical functionalities that must keep operating if there is a critical failure
- the processes required if there is fallback
Fallback System and Procedure Tested fallback-system-and-procedure-tested
End-to-end test of the fallback system.
Fallback System Sign Off from Business Stakeholders fallback-system-sign-off-from-business-stakeholders
Sign off, from the business stakeholders, that the fallback system and related procedures ensure the critical business functionalities.
Feasibility Confirmation on KPIs feasibility-confirmation-on-kpis
Results of a feasibility study for both AEM and the high-level solution design. These should be measured against the KPIs to ensure that these can be met.
Finalized Contract finalized-contract
A finalized and signed contract is needed before proceeding with the project. This is based on the Contract Draft.
Functionality of the Solution Accepted by Stakeholders functionality-of-the-solution-accepted-by-stakeholders
Confirmation that the stakeholders fully accept the:
- solution functionality
- any known issues in the solution
Go Live Schedule go-live-schedule
Timeline and schedule for the activities required for:
- preparation for go live
- the actual go live
Happy Paths Defined happy-paths-defined
A happy path is a default scenario featuring no exceptional or error conditions. It is composed of the sequence of activities executed when everything goes as expected.
Hardware Estimates hardware-estimates
Initial estimates of:
- the hardware needed for basic AEM installation
- any additional requirements, based on the high-level solution design
Hardware will be Available to Fulfill Requirements hardware-will-be-available-to-fulfill-requirements
Confirmation that all environments will have the minimum required hardware in place.
High-Level Requirements high-level-requirements
Definition of the high-level requirements provides a generalized breakdown of requirements for the system, covering aspects such as:
- Business processes
- Major system functions
Basic details about these functions are typically known, so this document should not be an estimate.
High-Level Solution Design high-level-solution-design
The high-level solution design explains the architecture that is used for developing the solution. The architecture diagram provides an overview of the entire system, identifying the main components that are developed for the product and their interfaces.
High-Level System Map high-level-system-map
This system map should provide a high-level diagram of the system. It differs from the Solution Context in that is it a generalized map of all systems involved, there are no interfaces on this diagram.
Historical Content Structure historical-content-structure
Definition of the content structure of the legacy system. This is used for reference and also when preparing the migration strategy.
Historical Performance and Historical Performance KPIs historical-performance-and-historical-performance-kpis
Collect and document performance statistics and performance KPIs from the legacy system. These are then used as a reference point and for benchmarking the new solution.
Identify Critical Key Solutions/Functionalities identify-critical-key-solutions-functionalities
A list of the business critical functionalities.
Implementation - Changes Based on Penetration Test Results implementation-changes-based-on-penetration-test-results
Implementation of all required changes (that have been signed off) to the solution based on the results of the penetration tests.
Implementation - Automated Testing Strategy implementation-automated-testing-strategy
Setup of the tooling and processes required to support automated testing.
Implementation - Automation Strategy implementation-automation-strategy
Setup of the tooling set and processes required to support automation.
Implementation - Content Architecture implementation-content-architecture
Implementation of the content architecture, tagging concepts and reuse of content.
Implementation - Experience Design implementation-experience-design
Implementation of the requirements to support the Experience Design.
Implementation - Fallback System and Procedures implementation-fallback-system-and-procedures
Implementation of the fallback system and related procedures.
Implementation - Integration implementation-integration
Implementation of integrations with all required external systems.
Implementation - Migration Strategy implementation-migration-strategy
Migration together with the validation of content and other artifacts for the new solution.
Implementation - Roles and Rights implementation-roles-and-rights
Implementation of roles and rights, users, and groups.
Implementation - Security Concept implementation-security-concept
Implementation of all security measures, including the AEM defaults.
Implementation - Security Software implementation-security-software
Implementation of software application security.
Implementation - System Architecture Security Concept implementation-system-architecture-security-concept
Implementation of the system security.
Implementation - URL Handling implementation-url-handling
Implementation of the URL handling concept.
Implementation - Workflows implementation-workflows
Implementation of the designed workflows.
Implementation Concept implementation-concept
The implementation concept provides the guiding principles for the entire implementation. It should consider:
- Operations
- Maintenance
- Compatibility
- Reusability
- Security
- Scalability
This concept also outlines the frameworks, libraries, and other artifacts used in the solution.
Inform Adobe Support About the Go Live Schedule inform-adobe-support-about-the-go-live-schedule
Contact Adobe Support to ensure that any support that is needed, can be enabled during the go live.
Initial Experience Designs initial-experience-designs
Preliminary concepts for the designs of the experiences.
Integration Testing integration-testing
Testing, and the resulting confirmation, of all integrations, both internal and external.
This should be automated and run frequently to ensure system stability.
Issue Tracking Process issue-tracking-process
Clear processes record all issues encountered and track ongoing activities with the aim of ensuring that all issues are addressed.
Issue Tracking System and Processes issue-tracking-system-and-processes
A tracking system, together with the required processes, to record all issues encountered and track ongoing activities with the aim of ensuring that all issues are addressed.
All project stakeholders should have access to facilitate transparency of the project status.
Examples include Atlassian JIRA and HP Quality Center.
Issue Tracking System Process is Set Up and Integrated issue-tracking-system-process-is-set-up-and-integrated
The selected tooling is fully integrated and access granted to all required roles.
Legacy System legacy-system
For your project the legacy system is the existing technology, computer system, or application program that will be replaced by the new solution.
Details of the legacy system should be collected so that you know what can be retired, when and the impact on any other systems.
List of Development Tools to be Used list-of-development-tools-to-be-used
An outline of tools that are used in the implementation; the tools should include:
- documentation tools
- issue tracking tools
- deployment tools
- build tools
List of Users that Require Access to Adobe Support Portal list-of-users-that-require-access-to-adobe-support-portal
A list of all users and roles that need access to the Adobe Support Portal.
The list is normally comprised of the Solution Architect and/or customer IT staff.
Log File Analysis log-file-analysis
An analysis, together with the resulting recommendations, defining what must be logged to monitor the solution:
- activities to be logged
- level of granularity
- information logged for each activity
Maintenance Tasks (AEM Specific) Tested and Enabled maintenance-tasks-aem-specific-tested-and-enabled
Test and enable AEM maintenance tasks such as:
- compaction
- system clean
- workflow purging
Migration Plan migration-plan
Document the migration; including
- timeline for the migration
- content maintenance plan, according to the migration strategy
Migration Strategy migration-strategy
A full description of the existing content, content architecture and formats mapped to the new solution. It should cover:
- technical details of automated migration if possible
- smoke tests to perform after migration, to validate the migrated content
It should also recommend how to keep the content up-to-date (or as up-to-date as possible) during the period between migration and the actual go live of the new system. This could mean a content freeze, double publishing, or the maintenance of an alpha system.
Monitoring - CPU monitoring-cpu
Monitoring the solution’s use of the system CPU:
- average
- peaks
Monitoring - Disk I/O monitoring-disk-i-o
Monitoring the solution’s disk input and output rates:
- average
- peaks
Monitoring - Disk Space monitoring-disk-space
Monitoring the solution’s use of disk space:
- average
- growth over time
You should monitor use by:
- the repository
- log files
Monitoring - External Systems monitoring-external-system-s
Monitor any connections between the solution and external systems:
- rate of traffic
- peaks
- stability
Monitoring - Network Bandwidth monitoring-network-bandwidth
Monitor the solution’s usage of the network bandwidth:
- average rate of traffic
- peaks
- stability
Monitoring - Requests monitoring-requests
Monitor the requests made to the solution.
Monitoring - Security Points monitoring-security-points
Monitor at the defined security points.
Monitoring - System monitoring-system
Monitor the overall system; for example:
- availability
- average performance
- performance peaks
- alerts
Monitoring - Threshold and Intervention monitoring-threshold-and-intervention
Monitoring of the solution’s defined threshold together with the implementation of intervention steps to reduce load.
Monitoring Concept monitoring-concept
The monitoring concepts to be applied to your solution; incorporating:
- AEM standard monitoring
- system monitoring
- customer-specific monitoring requirements
Monitoring Potential Weak Points monitoring-potential-weak-points
Specific points that could be susceptible to failure, should be identified and defined. Any monitoring tasks related to these should also be defined.
Examples include (among others):
- key workflows
- transactions processing
- integration points
Monitoring Policy Communicated to System Engineer monitoring-policy-communicated-to-system-engineer
Ensure that the system engineers and operations staff know and understand any monitoring policies.
Monitoring Reports - Structure in Place monitoring-reports-structure-in-place
Define:
- when monitoring reports should be generated
- who they should be delivered to
Operational Tasks Documentation operational-tasks-documentation
All operational tasks documented, with their frequency defined.
Operations Manual operations-manual
Manual providing all the information required for the successful operations and maintenance of the solution:
- all operational tasks
- key contacts
- deployment plans
- pre-/post- deployment checklists
- any other critical tasks
Should also detail the implementation concepts for:
- meeting the performance KPIs
- scaling the solution to continue to meet those KPIs
Package Prepared package-prepared
Software package built and delivered ready for deployment.
Penetration Tests penetration-tests
A penetration test (informally known as a pen test) is an attack on a computer system that looks for security weaknesses, potentially gaining access to the computer’s features and data.
Penetration Tests - Passed penetration-tests-passed
All required criteria are passed.
Penetration Tests - Results penetration-tests-results
Reports created for the business explaining the penetration test results.
Performance and Scalability Concept performance-and-scalability-concept
Conceptual document about how to ensure that your implementation meets the performance KPIs, and how to scale the solution so that it continues to meet those KPIs.
Performance Benchmark performance-benchmark
The Performance Benchmark is used to define performance testing, durability testing, and monitoring. It does this by assessing the performance characteristics of the solution and system hardware.
Performance KPIs performance-kpis
These define the Key Performance Indicators (KPIs) required to measure performance of the system. Some examples include page load time, server response time, and database query performance.
Performance Tests - Report performance-tests-report
Reports created for the business, detailing the results of the performance tests.
Performance Tests - Results Match Performance KPIs performance-tests-results-match-performance-kpis
The results must match the defined KPIs and expectations for performance.
Persona-Based Testing Concept persona-based-testing-concept
Persona-based testing is a method based on the different personas outlined in the Experience Designs. It also tests the accounts and their related permissions levels.
This is often used in User Acceptance Testing (UAT).
POC Tested and Verified against Requirement Documentation poc-tested-and-verified-against-requirement-documentation
The Proof of Concept (POC) is gauged against the requirements to ensure that both are aligned.
Post-Deployment Checklist post-deployment-checklist
A checklist to define the series of checks and tasks to perform after each deployment.
Pre-Deployment Checklist pre-deployment-checklist
A checklist to define the series of checks and tasks to perform before each deployment.
Production Environment Baseline Performance Tests production-environment-baseline-performance-tests
It is usual to run a baseline test on a standard installation of AEM. This is then used as a benchmark to test the implementation and hardware against.
Production Environment Ready production-environment-ready
Confirm that the production environment is ready, with automated deployments in place.
Production Sign Off from Business Stakeholders production-sign-off-from-business-stakeholders
Before Go Live onto the production environment, Production Sign-off (PSO) must be granted. This is the result of a review of the release that will go into production, together with any known issues. Sign-off is given as part of the Go Live schedule.
Production Sign Off Process and Policy production-sign-off-process-and-policy
The policy and process required to obtain the Production Sign off before moving the package to the production environment.
Project Communication Plan project-communication-plan
Define the communication plan for both business stakeholders and the project team.
Project Efforts - Final Estimates project-efforts-final-estimates
The initial estimates were high level and made according to the high-level requirements for the implementation.
These are now reviewed, refined, and expanded to provide the final estimates. Estimates should be delivered by each appropriate project lead, including project management, consulting, architecture, testing, and development.
These estimates are used for resourcing and budgeting.
Project Efforts - Initial Estimates project-efforts-initial-estimates
Initial estimates are high level and made according to the high-level requirements for the implementation. This will be reviewed and refined at later stages.
Project Organization project-organization
The required documentation to outline the organization and reporting structure of the project and team.
Often takes the form, or includes, a chart to present a visual overview of timelines and responsibilities. There are many tools available to help with this.
Project Scope Document project-scope-document
The project scope document requires you to identify and document a list of:
- Specific project goals
- Deliverables
- Features
- Functions
- Tasks
- Deadlines
- Planned effort
It covers what must be achieved, together with the work that must be done, to deliver the project
Project Status Reports Within a Defined Cadence project-status-reports-within-a-defined-cadence
Project status reports delivered according to the agreed schedule and with the required format.
Proof of Concept (POC) proof-of-concept-poc
The Proof of Concept (POC) implements a limited range of functions for the solution.
It should aim to demonstrate the feasibility of the solution, verify that it can fulfill the required purpose and prove that there is the potential of it being used.
Purge Rules purge-rules
AEM maintains multiple versions of assets and content. Purge rules are designed and configured to periodically remove the older versions to maintain repository health and size.
Quality Report Format and Cadence quality-report-format-and-cadence
Define the required content and format of the quality report, together with how frequently it must be delivered.
Release Coordinated release-coordinated
The project manager coordinates all roles required for the release to production.
Release Notes release-notes
Release notes are part of the documentation for the release. The release notes should cover:
- prerequisites
- requirements included
- issues solved
- known issues in the release
It is used with the Runbook to execute pre- and post installation steps and checks.
Release Running on Production Environment release-running-on-production-environment
Final release running and active in production.
Relevant Contract Terms relevant-contract-terms
Highlight specific contract terms that are relevant to the implementation of the project; such as contractual milestones, invoice periods, or staff requirements.
Reporting Cadence reporting-cadence
Together with the customer, define the frequency of reports delivered to them.
Repository Optimization repository-optimization
Data is never overwritten in a tar file, the disk usage increases even when only updating existing data.
To counteract the ever increasing size of the repository, an optimization strategy is put in place to remove obsolete data.
Request for Setting Up Project Section in Adobe Support Portal request-for-setting-up-project-section-in-adobe-support-portal
The official request to set up your project in the Adobe Support Portal.
Requirements Documentation requirements-documentation
This set of documentation covers the functional and non-functional requirements, together with the efforts estimated.
Resources Available to Support Go Live resources-available-to-support-go-live
Ensure that all the roles required for go live are staffed and available.
Risk Assessment risk-assessment
The Risk Assessment is run by the customer’s IT department, or Security department, or both.
It assesses the technical and business risks of the project. The assessment is required for the solution to ensure compliance with security policies.
Risk Mitigation Plan risk-mitigation-plan
The Risk Mitigation Plan includes the Risk Assessment. Together they cover:
- identified risks
- possible solutions to those risks should they arise in the implementation
ROI Expectations roi-expectations
Define the Return on Investment (ROI) expectations that are attached to the solution.
They aim to indicate the efficiency of the solution in economic terms by defining the benefits/profits expected in relation to the estimated investment.
Roles and Rights Concept roles-and-rights-concept
Detailed specification of the concepts relating to roles and access rights required for the new application, including a high-level outline of:
- roles
- groups
- users
- permissions
- and user management and provisioning
Roles and Rights Concept Meets Security Guidelines roles-and-rights-concept-meets-security-guidelines
Review of the Roles and Rights concept to ensure that it meets the security policies.
Roles and Rights Specification roles-and-rights-specification
A detailed specification based on the Roles and Rights Concept.
Security Architecture Recommendations security-architecture-recommendations
Recommendations related to security for the software and hardware architecture.
Security-Based Coding Guidelines security-based-coding-guidelines
These guidelines define how the development coding should be done, based on security requirements such as:
- naming conventions
- libraries
- guidelines for frameworks
- API usage
Security Checklist security-checklist
Project-specific checklist of items, based on the Security Concept together with any additional policies required to ensure compliance of the solution.
Often this is also included as part of the post-deployment steps in the runbook.
Security Concept security-concept
Define and document details of the security configuration required for the application, architecture, and infrastructure.
Security Concept Draft security-concept-draft
A high-level outline covering the security setup of the:
- application
- architecture
- infrastructure
Security Issues Listed and Assessed security-issues-listed-and-assessed
All security issues of the solution listed and assessed; including effort estimates.
Security Sign Off from Business Stakeholders security-sign-off-from-business-stakeholders
Sign off from the stakeholders to ensure that the security implementation is compliant with policies and expectations.
Set up Support Processes set-up-support-processes
Set the required support processes in place.
SLAs for Third-Party Systems slas-for-third-party-systems
Ensure that Service Level Agreements (SLAs) are available and communicated to both the development and operations teams for use during implementation and support.
Smoke Test Concept smoke-test-concept
Smoke tests consist of a set of defined steps that test the key functionalities of the solution to ensure basic operations and functionality of the solution.
They are executed, on any environment, after installation or deployment.
Smoke Tests Executed for System Validation smoke-tests-executed-for-system-validation
Smoke Tests should be run on all systems to ensure correct operation of the solution’s basic functionality on installation or deployment to any environment.
Software Architecture Strategy software-architecture-strategy
The high-level strategy for the software architecture; including services, servlets, frameworks, and other implementation decisions.
Solution Review Board Established and Meeting Cadence Set solution-review-board-established-and-meeting-cadence-set
The Solution Review Board is comprised of customer stakeholders.
The board holds regular meetings to review the currently scoped requirements and relevant specifications on an ongoing basis. The aim is to ensure alignment with the success definition and criteria and also provide input into the development of the requirements.
Solution Runbook solution-runbook
Installation instructions for the solution, together with basic operational tasks to be executed on installation.
Solution Sign Off and Acceptance Process solution-sign-off-and-acceptance-process
The sign-off and acceptance process outlines the criteria that must be fulfilled before the solution can be released into a productive environment.
It can also serve as a contractual milestone.
Special Functionality Concept special-functionality-concept
The initial concept for any special functionality that is considered outside the normal scope of development on the AEM platform.
Special Functionality Specification special-functionality-specification
Details of any special functionality that is considered outside the normal scope of development on the AEM platform.
Specification Guidelines specification-guidelines
Any guidelines from the customer on how the specification should be done.
Specification Review and Approval Process Defined and Communicated specification-review-and-approval-process-defined-and-communicated
A clear process for the customer sign-off of specifications should be put in place. This process ensures clarity and firmness of scope for the requirements.
Staff Selected for AEM Administrator Training staff-selected-for-aem-administrator-training
Internal staff that needs training so they can administer the solution.
Staff Selected for Author and End User Training staff-selected-for-author-and-end-user-training
Internal staff that needs training so they can author on the solution.
Stakeholders stakeholders
Stakeholders are the key persons and/or roles that have a significant interest in the project. Some will be contributing towards the project budget.
The stakeholders can be internal and/or external.
Stakeholders are Aware of Success Definitions and Criteria stakeholders-are-aware-of-success-definitions-and-criteria
Confirmation that all stakeholders outside the actual implementation team are aware of the:
- definitions of success
- criteria for success
Stakeholders Understand Project and Expectations stakeholders-understand-project-and-expectations
Confirmation that all stakeholders outside the actual implementation team are in alignment with the overall project and expectations, both internal to the project team and to the customer.
Status Report Format Definition status-report-format-definition
Status reports are a key tool of communication. The format should be aligned with any reporting requirements from the customer.
Success Criteria and Definition success-criteria-and-definition
The customer, project sponsor, and project manager or consultant should specify:
- What defines a successful outcome for the project?
- The specific criteria required to meet that definition of success.
These are used to ensure that the criteria for success are met:
- As the basis for KPIs.
- When making decisions throughout the implementation.
Support in Validation of Reported Issues support-in-validation-of-reported-issues
Part of the Quality Lead’s responsibilities is to ensure that there are resources available to support any user when testing. For example, to help the user when testing, when reporting issues and to help validate the issues against the test environment.
Support Processes and Access to Adobe Support Portal support-processes-and-access-to-adobe-support-portal
Access to the Adobe Support Portal is crucial for submitting tickets about any product-based issues that may arise during implementation.
Access should be allocated to key members of the team.
System Architecture Definition system-architecture-definition
An initial proposal and definition of the architecture for all environments of the solution.
System Architecture Documentation system-architecture-documentation
A document detailing the system architecture; including interfaces, network location, and integrations for all environments, among other information.
System Architecture Security Concept system-architecture-security-concept
A high-level outline of how to make the system architecture compliant with any security policies. This can cover:
- firewalls and firewall rules
- security zones
- local and general traffic managers
- web servers
- proxies and reverse proxies
System Risk Factors Identified and Verified system-risk-factors-identified-and-verified
Any risk factors found in the risk assessment (or other reviews) are identified and assessed:
- the level of risk implied in each one
- together with the estimated effort for any changes to the implementation that are required to address them.
Team is Aware of Success Definitions and Criteria team-is-aware-of-success-definitions-and-criteria
Confirmation that the entire team is aware of the success definitions and criteria.
Team is Aware of the Communication Plan team-is-aware-of-the-communication-plan
Confirmation that all members of the team are aware of who should be communicating with the customer, together with details of how and when.
Team Understands Project and Expectations team-understands-project-and-expectations
Alignment with the overall project and expectations, both internal to the project team and to the customer.
Technical Requirements technical-requirements
These requirements are specific to the technical implementation of services that support the solution.
Technical Risk Factors Verified technical-risk-factors-verified
Identify and verify potential technical risks. Technical risks can include:
- cross site scripting
- end user facing input fields
- infrastructure
- technology age
- number of integrations
- and dependencies
Technical Specification technical-specification
The Technical Specification covers (among other information):
- interfaces
- configurations
- APIs
- services that support the requirements of the solution
Template Specification template-specification
The specifications for the required templates. These should cover details including parsys, blueprint and inheritance mapping, among others.
The specifications are based on the Business Requirements and Experience Requirements.
Test Cases test-cases
Test Cases specific the detailed steps required to execute functional testing of the solution.
Test Content test-content
The test content should be as close to production content as possible. It must be of a wide enough selection to allow for testing all scenarios.
Test Environment Ready test-environment-ready
Ensure that the test environment is ready, with automated deployments in place to ensure that all release candidate code is up-to-date for testing.
Test Reports test-reports
Reports detailing the results of testing; including:
- defects raised
- status of test cases executed
- other quality-related topics
It should be noted that:
- Any testing team should be allowed to remain neutral and deliver the testing results.
- It is the responsibility of the Project Manager to assess any implications of the results and decide on appropriate action.
Test Suite test-suite
Selection of the automation suite and tooling. These are used to automate tests, including those for use cases.
Test Tooling Suite Selected test-tooling-suite-selected
Automation suite and tooling selected for use case automation and other test execution tasks.
Testing Concept testing-concept
The Testing Concept is the high-level outline of testing for the project; including, QA, UAT, performance, security, and integration testing.
Testing Plans testing-plans
These plans outline in greater detail the execution of tests for each phase of development and are based on the Testing Strategy.
Testing Scope testing-scope
These requirements are specific to the technical implementation of services that support the solution.
Testing Strategy testing-strategy
The testing strategy outlines the high-level strategy for quality assurance and user acceptance testing. This includes timelines, reporting cadence, and execution.
Third-Party Integration Concept third-party-integration-concept
Architectural and system level concept for the integration with third-party systems.
Third-Party Integration Specification third-party-integration-specification
Details of the requirements (both functional and non-functional) for the supported functionality and integration of the third-party systems.
Third-Party Security Concept third-party-security-concept
Concept for ensuring the security of any third-party integrations. Must be compliant with the appropriate security policies.
Third-Party System for Integration third-party-system-for-integration
Ensure that all third-party systems are available, with appropriate documentation, for integration implementation.
Third-Party Systems Access Enabled third-party-systems-access-enabled
Required access rights granted to the respective roles used with third-party systems.
Third-Party Testing Concept third-party-testing-concept
Defines:
- use cases for testing the integrations
- functionality related to any third-party application
Threshold Definition threshold-definition
Defines the key values for monitoring points in the system.
For example:
- how many kilobytes (KB) of unsent logs generate a warning on the principal server instance
- the number of milliseconds of average delay per transaction that are tolerated before a warning is generated on the principal server
Timeline and Milestones timeline-and-milestones
This should define the project timelines and contractual milestones to be used for:
- Invoicing.
- Alignment against the success definitions, success criteria, and the KPIs.
Total Project Efforts total-project-efforts
All effort estimates, from each of the leads on the project, should be consolidated; including, overhead, development, system engineering, architectural, and testing efforts.
If there is a support level included in the agreement, support and operations efforts should also be included.
Training Materials training-materials
Materials to be used in training sessions. The materials should be created specifically for the solution and designed to be used with the User Guides.
Understands Scope of Project and Expectations understands-scope-of-project-and-expectations
The appropriate persona should confirm that they fully understand:
- the scope of the project
- all customer expectations
- that this is the basis for all decisions made per persona, per phase in the project
URL Handling Concept url-handling-concept
Your URL handling concept should cover AEM-specific URL functionalities including:
- vanity URLs
- link externalizing
- error pages
- mapping
The concept should also cover:
- any rewrite rules
- virtual hosts on the web server
- SEO considerations, such as robots.txt
- a site map
Use Cases use-cases
A use case is the list of actions or event steps needed to achieve a goal. Typically they define the interactions between a role and the solution. The role can be a user or an external system.
Use Cases Converted into Test Scenarios use-cases-converted-into-test-scenarios
Test scenarios are based on the technical and business use cases. They are used to test that the solution behavior is as expected.
User Guides user-guides
User Guides provide information and assistance for the users of the solution:
- authors
- power users
- administrators
Validated Budget Plan validated-budget-plan
The budget plan must be reviewed and validated by all stakeholders. They must check details such as invoicing, amounts, and methods/timing of budget reporting.
White Box Test Results white-box-test-results
White box testing is a method that tests the internal structures or workings of an application, as opposed to its functionality. White box testing can be applied at the unit, integration, and system levels of the software testing process.
Workflow Specifications workflow-specifications
Based on the Workflows Concept, these specifications should define, in detail, the steps that create the full workflow.
The specification of each workflow should include (at a minimum):
- use case
- roles
- steps
- outcomes
- error handling
Workflows Concept workflows-concept
Workflows let you automate AEM activities. The Workflows Concept outlines:
- the processes that need automation
- the services and roles in AEM that will be affected