某些 Creative Cloud 应用程序、服务和功能在中国不可用。
You're viewing help content for version:
- 6.4
- 6.3
- Older Versions
Managing a project to implement Adobe Experience Manager (AEM) requires planning and understanding to ensure you are aware of the issues and (related) decisions that you need to make (both before and while implementing your project).
To help you, the best practices consist of:
- An interactive checklist that allows you to track and monitor your progress with these best practices.
- Defines inputs and deliverables according to phase, milestone and persona.
- Provides automated overviews (quality, health and completeness) to indicate progress and project-health.
- Documentation, based directly on the checklist, that details the:
- Project Heartbeat analysis.
- Status by Role overview.
- Phases and Milestones.
- Key Persona and their involvement at every (relevant) stage.
- A Glossary of the Required Documents and Deliverables.
- Further reference material to provide more details on specific areas.
The Project Heartbeat worksheet provides a graphical overview of critical metrics for your project:
- Phase Quality
- Indicates the quality of the Required Documents and Deliverables across the project.
- Phase Health
- A high level status indicator for your project; useful to highlight areas that may be at risk.
- Phase Completeness
- At any point in time during the project this indicates how much has already been completed for each phase of your project.
The Status by Role worksheet shows detailed breakdown of Health, Quality and Completeness by Phase and Persona.
The project plan is broken down into distinct (high level) phases.
Each phase contains its own milestones. For each persona (or role), the relevant milestones are listed, together with the documents that are required to produce the defined deliverables.
Note:
There is not a direct 1:1 relationship between the individual required documents and deliverables.
Preparation of your project forms the basis of the entire project. You need to define key requirements together with clear goals and expectations for the:
- Business Rationale
- The fundamental reasons and justification for undertaking the project.
- Scope and Schedule
- A basic scope, and rough schedule should be made available to define what is required, and within which time frame; if it helps clarify the situation, you can also define what lies outside the scope.
How you prepare, plan and run your project and implement your solution will be affected by the restrictions you are operating under e.g. fixed budget, fixed timeline, quantity of content, quality required.
As always, adjusting any of the factors will impact the others. For example reducing the time, but requiring the same level of quality will probably increase the price while reducing the quantity of content you can cater for. Budget is often a key factor so such relationships cannot be forgotten.
-
In this phase you need to validate and confirm the goals for the project; for example:
- What do you want to achieve/provide?
- Who will benefit?
- What is the scope?
- If it helps clarify the situation, you can also define what lies outside the scope.
- How will you define success?
- How will you measure success?
- What are the requirements, business and technical?
- Are there legacy systems to be replaced and if so, is there data to be migrated?
- Who will be involved?
- How will you measure progress?
- How often will you review progress during the life of the project?
-
Budget
Before you start any project you need a reliable, realistic estimation of what it will cost to implement:
- Use information from the validation milestone as a basis for the estimates.
- Be realistic in your estimates.
- Consider and respect any client guidelines, processes or restrictions that the client may be subject to.
- Consider contingency and review processes should a review, or refinement, of the budget is required at a later stage.
- Remember that costs come in many forms; purchases, use of resources and fees amongst others.
Planning your project consolidates the preparation. Here you need to start converting the goals and expectations into a well-defined roadmap consisting of concrete tasks, bound by clear communication, with stringent reviews to measure progress.
-
To avoid unpleasant surprises, use risk assessment to identify and quantify any potential risks together with their impact and probability.
This should be done early in the project life cycle to ensure that any vunerabilities are identified and evaluated. Based on the findings you can report to your stakeholders on whether the full requirements can be implemented and, if necessary, whether it is possible to plan for appropriate actions to be taken and tracked.
-
The Kick Off meeting is used to raise awareness that the project is starting. It is a good opportunity to:
- Invite all interested parties (or at least group-representatives).
- Present key facts about the project.
- Answer questions.
- Ensure that everyone has the same knowledge base.
- Get commitment from everyone who will be involved - this will have to be earned.
- By involving prime players (including prospective authors) at the very start of the project, you increase your chances of getting their commitment to the project.
Planning the development is key to ensure that your project is built on a solid design by a team that has the required knowledge.
-
The content architecture defines and describes the future architecture of the content; including:
- The content tree; including assets
- Basic structures; including campaigns, etc.
- Multi site and multi language structures (MSM, Translation, etc.)
- Supportive content (including tags and tagging concepts)
- Caching and content reuse strategies
-
The system architecture defines the conceptual view of your system; including (amongst other information):
- System structure for all required environments
- Sub-systems
- Third party systems
- Interfaces; hardware, software and human interaction
- Servers for each environment; see the Technical Requirements and Hardware Sizing Guidelines
- Processes for each environment; for example, deployment and maintenance requirements
- Maintenance activities (Datastore GC, TarPM optimization, etc.)
- Dispatcher caching
- Clustering Publish/Authorshare
- Performance for the client-side (JS minify, concat, css sprites, total number of http requests, and others)
-
The application architecture defines and describes the behavior of the proposed applications.
It is focused on:
- How they will interact with each other and with users.
- The data to be consumed and produced by applications, rather than their internal structure.
The definitions should cover:
- Basic code structure for the project
- Code artifacts (bundles, packages, etc.)
- Breakdowns of the templates/components and their relationships
- High level details of required customizations (specific overlays will follow later)
- Design of workflows required by the solution (for example, content creation, approval, publishing, transformations, imports, exports, etc.)
- Special consideration for any complex modules, such as MSM, Commerce, third party integration
-
System integration requires you to plan (then implement):
- How all the sub-systems and solution integrations will be brought together to operate as one coherent system
- How any third party systems will be integrated; together with any special considerations, such as offline/online, client-side/browser-side or fallover handling when a third party system is down
-
Before starting development you should draw up an in-depth and comprehensive concept of all testing requirements for your project.
This should include (amongst others):
- Details of all tests to be performed
- Preparation of any content required for those tests
- Information of any test tools to be used
- High level indication of who will be involved in testing; especially groups outside the QA team
- Details of test automation; for example, with Selenium or AEM Developer mode
-
Prior to development all support processes, required to deploy, release, test and report issues, should be set in place.
See also the Adobe Support Portal.
On a similar basis the operations must be properly planned to ensure you have the environments that you require - for all stages of the project life cycle. You also need the appropriate processes for maintaining them.
-
You need to plan and then implement a Roles and Rights Concept for all users/groups that will use the solution.
For example:
- A list of roles (i.e. groups) with read/write access definitions for each
- Definition of the use of privileges that impact the publish environment; for example, replicate
- 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, see User Administration and Security.
-
Monitoring and maintenance are key aspects of ensuring the smooth operation of your solution once it goes live. For this you need to define:
- What needs monitoring
- Maintenance tasks; both regular and for special cases
See also Monitoring and Maintenance for more information.
-
Plan and document your development environment, including:
- Architecture
- Development tools
- A typical environment consists of:
- an issue tracking system; such as Jira
- an IDE; such as Eclipse
- a build management tool; such as Maven
- a tool for continuous integration; such as Jenkins
- a tool for version control; such as GIT/SVN
- a build artifact repository manager; such as Archiva/Nexus
- A typical environment consists of:
- Third party software integration/dependencies
- Solution integration/dependencies
- Deployment cadence
-
Plan and document your production environment, including:
- Architecture
- Deployment cadence
- Third party software integration/dependencies
- Security setup
- Baseline performance verified by running the Tough Day tests on the production setup
- Requirements for performance tests; see Best Practices for Quality Assurance
-
Plan, document and test all aspects of the system and solution integration, including:
- An automated testing strategy
- Automated processes to move applications from development to test, then production
- Automated processes to move content from production to test and development
Once the new application is available it will need to undergo stringent testing, both for functionality and performance.
Note:
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.
-
User acceptance testing (UAT) is crucial to ensure that:
- The solution fulfills the user/customer requirements
- The customer/users accept the solution (function, design and performance)
-
Performance and load tests are used to ensure that the solution meets the required performance levels, at average and peak loads.
Note:
This process will have to be continued during normal use of AEM, but these initial stages are the most crucial.
Rollout of your new application needs careful planning to ensure a smooth Go Live. This includes confirming a high level of security, training all prospective users and making multiple dry-runs to confirm that all issues have been dealt with.
-
Ensure that all involved staff have been trained.
See Adobe Experience Manager in the course catalog.
-
To ensure the security of your solution, perform specific penetration tests, together with a wider range of security tests.
See the Security Checklist for more details.
You want your Go Live to be as smooth as possible. Again the final steps need planning for clean execution.
The checklists are designed by persona. These are the roles with significant involved in the project life cycle.
There are also some other persona that are involved in specific tasks.
The project sponsor is:
- Responsible for providing/presenting the business case for the project.
- Key to shaping and defining the scope of the project; including:
- the definition of, and criteria for, success
- the main KPIs
- Provide the main milestones based on the client roadmap.
The project manager is:
- Responsible for the overall delivery of the project based on the requirements (e.g. scope, KPIs, success criteria and definition) provided by the project sponsor.
- Responsible for defining the budget and resourcing the project based on that budget.
- The main point of communication for all persona involved in the project.
The solution architect:
- Is responsible for the high-level design of the solution and system.
- Helps define the implementation strategy for AEM. For example, whether to implement a clustered installation, or a cold standby, or when a content delivery network (CDN) is needed.
- Also define the AEM solution architecture based on the client requirements. This can include the concept for user roles (with related rights), the relationship between templates and components, or when to use multi site management.
The business analyst:
- Is primarily responsible for gathering and analyzing the high-level requirements, then transforming these into specifications:
- for the project manager to use when planning the development
- for the development team to work from during design and development.
- Works closely with the client to analyse the requirements. They match these against:
- The definition of success.
- The criteria for success.
- KPIs (both business and performance based).
The development lead:
- Is responsible for the technical delivery of the project.
- Is responsible for selecting a development methodology that is compliant with client requirements.
- Draws up the development strategy:
- ensuring that it is aligned with the business and performance KPIs
- taking into account the success criteria and definition
- Works closely with the architect (especially when drawing up the development strategy for AEM) to define aspects such as the relationship between templates and components, the integration strategy for third party applications and any specialized functionality.
The quality lead:
- Is responsible for the quality of the delivery; ensuring that it meets the criteria for success and any KPIs defined by the client.
- Defines the quality metrics, aligns with all stakeholders, draws up the testing plans and ensures that they are executed.
- Creates and delivers reports to project stakeholders.
The system engineer:
- Is responsible for overseeing the project infrastructure.
- Is responsible for:
- the setup of internal development and test environments
- for matching those systems to the client systems
- Provides hardware recommendations, monitor the various implementations and provide operations support both prior to go live and afterwards.
The security lead:
- Is responsible for the overall security concept of the solution, ensuring that it is aligned with any requirements and policies from the client.
- Delivers a security concept, security operations and recommendations for any hardware based security concepts; such as zones and firewalls.
- Stakeholders
- People (often from the business) who have an interest (stake) in the success of the project. They often contribute to the budget.
- Legal
- Legal advice is required when negotiating contracts.
- Trainers
- Depending on the scale and nature of the project, specialized trainers can be used to develop and present training sessions for the relevant groups.
- Technical Writers
- Depending on the scale and nature of the project, specialized technical writers can be used to write guidelines and manuals for specific groups; e.g. a Maintenance manual for system administrators or a User Guide for the authors.
- System Administrators
- Responsible for the ongoing operation of the system.
- Authors and End Users
- The people who will use the system to create and maintain your website content.
The checklists cover the Required Documents and Deliverables for each milestone.
- There is no 1:1 relationship between these; for example, a group of required documents can result in a single deliverable.
- A deliverable from one persona can be a required document for another persona during the same milestone.
The Required Documents are needed by the appropriate persona when producing their deliverables.
For each Required Document the persona should indicate:
- Y/N: whether it has been received.
- 1-3: an indication of the quality of the received document.
For each milestone the appropriate persona are responsible for delivering specific documents and therefore realizing their responsibilities for a specific milestone.
For each Deliverable the persona must indicate:
- Y/N: whether it has been completed.
Deliverables are often used as Required Documents for either the current or a later milestone.