Glossary

Application Architecture Definition

The application architecture should clearly define the behavior of the proposed applications.

It is focused on:

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

Ensure that your team is made up of staff with the appropriate training. For project teams the recommendation is to have all the following:

Architecture Diagram

The architecture diagram is a graphical representation of the architecture. It includes representation of:

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

The Architecture Review Board is a cross-organizational body that:

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

Automation scripts and basic automated use cases:

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:

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

The automation of deployments ensures faster and consistent deployments. The Automation Strategy outlines the configuration of any such automation mechanisms; including:

Aware of Communication Plan

The entire project team and all stakeholders must confirm that they are aware of the:

Aware of Success Definitions and Criteria

The entire project team and all stakeholders must confirm that they are aware of the:

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

A full end-to-end test based on the Backup and Restore Concept.

Business Cases

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

The Business Analyst should confirm that they fully understand:

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

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

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

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

The Coding Guidelines define basic principles that the developers should adhere to when developing the solution. These can include, among others:

Communicate Operations Manual

Ensure that all appropriate persona/roles have received the Operations Manual.

Communicate Performance Test Report

Ensure that all appropriate persona/roles have received the Performance Test Report.

Communicate Release Notes

Ensure that all appropriate persona/roles have received the Release Notes.

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

Ensure that all appropriate persona/roles receive the training materials and user guides.

Compliance with Customer Security Requirements

Ensure that all the customer’s security requirements are in place.

Compliance with Security Concept

Ensure that the Security Concept is in place.

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

Details of the components and templates relationship concept.

Components Specification

Specification details for each of the components to be implemented.

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

Documentation of the proposed architecture of the content. The details should include, among others:

Content Validated for Migration

The legacy system content is reviewed and the selected content is validated for migration to the new solution.

Contract Draft

An initial draft of the legal contract.

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

Policies from the customer concerning:

Customer Coding Guidelines

Any guidelines/requirements from the customer on how development should be done.

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 policies and requirements on what should be monitored. These are in addition to any recommendations specified in the Monitoring Concept.

Customer Production Release Schedule

The schedule that is defined by the customer for releases to the production environments.

Customer Reporting Policies and Requirements

Any policies, or requirements, or both, that the customer has in regard to reporting. These can include:

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

The customer (business and IT) will have policies that define the required security levels for the solution. These can include:

Customer Specification Guidelines

Any guidelines the customer has that relate to the format, delivery, and sign-off of specifications.

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

Any customizations and/or applied hotfixes applied must be documented as they can affect future upgrades:

Daily User Acceptance Test Report

Reports or meetings resulting from the User Acceptance Testing (UAT). They should detail:

Default Security Enabled

Ensure that the default security settings for AEM have been enabled/implemented.

Deployment/Release Policies and Processes

Formalized policies covering both the deployment and releases of your project. These can include:

Deployment Cadence Established

Define the required frequency of deployments across environments.

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

Define which developer and/or role is executing IT (performance or other) and/or unit tests within the solution.

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

The Development Team should confirm that they fully understand:

Dialogs Specification

Details about the dialogs required for the solution.

Document Development Environment Setup

Documentation of the development environment.

Document Production Environment Setup

Documentation of the production environment.

Document Test Environment Setup

Documentation of the test environment.

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

Execution of the durability tests.

Error Handling Concept

Error handling refers to the anticipation, detection, and resolution of programming, application, and communication errors.

Error Handling Documentation

Detailed documentation of the proposed error handling, based on the Error Handling Concept.

Escalation Processes

Definition of all escalation processes. There will be separate processes for each project level:

Establish Regular Quality Review Sessions

Establish regular quality review meetings with the appropriate team members.

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

A diagram (or set of diagrams) of the existing systems and dependencies.

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:

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

Details of the Experience Design Requirements.

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

The definition of the fallback system:

Fallback System and Procedure Tested

End-to-end test of the fallback system.

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

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

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

Confirmation that the stakeholders fully accept the:

Go Live Schedule

Timeline and schedule for the activities required for:

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

Initial estimates of:

Hardware will be Available to Fulfill Requirements

Confirmation that all environments will have the minimum required hardware in place.

High-Level Requirements

Definition of the high-level requirements provides a generalized breakdown of requirements for the system, covering aspects such as:

Basic details about these functions are typically known, so this document should not be an estimate.

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

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.

Implementation Concept

The implementation concept provides the guiding principles for the entire implementation. It should consider:

This concept also outlines the frameworks, libraries, and other artifacts used in the solution.

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

Preliminary concepts for the designs of the experiences.

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

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

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

The selected tooling is fully integrated and access granted to all required roles.

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

An outline of tools that are used in the implementation; the tools should include:

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

An analysis, together with the resulting recommendations, defining what must be logged to monitor the solution:

Maintenance Tasks (AEM Specific) Tested and Enabled

Test and enable AEM maintenance tasks such as:

Migration Plan

Document the migration; including

Migration Strategy

A full description of the existing content, content architecture and formats mapped to the new solution. It should cover:

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 the solution’s use of the system CPU:

Monitoring - Disk I/O

Monitoring the solution’s disk input and output rates:

Monitoring - Disk Space

Monitoring the solution’s use of disk space:

You should monitor use by:

Monitoring - External Systems

Monitor any connections between the solution and external systems:

Monitoring - Network Bandwidth

Monitor the solution’s usage of the network bandwidth:

Monitoring - Requests

Monitor the requests made to the solution.

Monitoring - Security Points

Monitor at the defined security points.

Monitoring - System

Monitor the overall system; for example:

Monitoring - Threshold and Intervention

Monitoring of the solution’s defined threshold together with the implementation of intervention steps to reduce load.

Monitoring Concept

The monitoring concepts to be applied to your solution; incorporating:

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):

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

Define:

Operational Tasks Documentation

All operational tasks documented, with their frequency defined.

Operations Manual

Manual providing all the information required for the successful operations and maintenance of the solution:

Should also detail the implementation concepts for:

Package Prepared

Software package built and delivered ready for deployment.

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

All required criteria are passed.

Project Communication Plan

Define the communication plan for both business stakeholders and the project team.

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

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

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

The project scope document requires you to identify and document a list of:

It covers what must be achieved, together with the work that must be done, to deliver the project

Risk Mitigation Plan

The Risk Mitigation Plan includes the Risk Assessment. Together they cover:

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

Detailed specification of the concepts relating to roles and access rights required for the new application, including a high-level outline of:

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

A detailed specification based on the Roles and Rights Concept.

Security Architecture Recommendations

Recommendations related to security for the software and hardware architecture.

Security-Based Coding Guidelines

These guidelines define how the development coding should be done, based on security requirements such as:

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

Define and document details of the security configuration required for the application, architecture, and infrastructure.

Security Concept Draft

A high-level outline covering the security setup of the:

Security Issues Listed and Assessed

All security issues of the solution listed and assessed; including effort estimates.

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 the required support processes in place.

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 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.

Special Functionality Specification

Details of any special functionality that is considered outside the normal scope of development on the AEM platform.

Specification Guidelines

Any guidelines from the customer on how the specification should be done.

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

Internal staff that needs training so they can administer the solution.

Staff Selected for Author and End User Training

Internal staff that needs training so they can author on the solution.

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

Confirmation that all stakeholders outside the actual implementation team are aware of the:

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 reports are a key tool of communication. The format should be aligned with any reporting requirements from the customer.

Success Criteria and Definition

The customer, project sponsor, and project manager or consultant should specify:

These are used to ensure that the criteria for success are met:

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

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

An initial proposal and definition of the architecture for all environments of the solution.

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

A high-level outline of how to make the system architecture compliant with any security policies. This can cover:

System Risk Factors Identified and Verified

Any risk factors found in the risk assessment (or other reviews) are identified and assessed:

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

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

Alignment with the overall project and expectations, both internal to the project team and to the customer.

Technical Requirements

These requirements are specific to the technical implementation of services that support the solution.

Technical Risk Factors Verified

Identify and verify potential technical risks. Technical risks can include:

Technical Specification

The Technical Specification covers (among other information):

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 specific the detailed steps required to execute functional testing of the solution.

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

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

Reports detailing the results of testing; including:

It should be noted that:

Test Suite

Selection of the automation suite and tooling. These are used to automate tests, including those for use cases.

Test Tooling Suite Selected

Automation suite and tooling selected for use case automation and other test execution tasks.

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

These plans outline in greater detail the execution of tests for each phase of development and are based on the Testing Strategy.

Testing Scope

These requirements are specific to the technical implementation of services that support the solution.

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

Architectural and system level concept for the integration with third-party systems.

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

Concept for ensuring the security of any third-party integrations. Must be compliant with the appropriate security policies.

Third-Party System for Integration

Ensure that all third-party systems are available, with appropriate documentation, for integration implementation.

Third-Party Systems Access Enabled

Required access rights granted to the respective roles used with third-party systems.

Third-Party Testing Concept

Defines:

Threshold Definition

Defines the key values for monitoring points in the system.

For example:

Timeline and Milestones

This should define the project timelines and contractual milestones to be used for:

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

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

The appropriate persona should confirm that they fully understand:

URL Handling Concept

Your URL handling concept should cover AEM-specific URL functionalities including:

The concept should also cover:

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

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 provide information and assistance for the users of the solution:

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 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

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):