Concept and Planning

Once the concept phase has been authorized you can analyze the fundamental issues for the prospective project:

Content and Applications - New or Upgrade?

You will also need to make decisions on two fundamental issues:

Content Input - Import or Upgrade?


  • A major consideration is whether you want to:

    • Upgrade the content of an existing installation. See Upgrading to CQ5 for more information.

      Do not underestimate the effort required for this. Although efficient it can still represent a significant task for your planning.

    • Generate new content; either by importing from a prepared file (e.g. XML), or inputting all content with CQ.

  • Applications - Upgrade, Refactor or Embed?
  • As with content, you will need to decide how to handle existing applications. Here you can either:

    • Upgrade them to the new installation. See Upgrading to CQ5 for more information.

    • Refactor them, by rewriting them completely.

    • Embed them by running CQ4 within CQ5.

  • Setting Target Metrics

    Metrics are used to define quantitative measurements for the quality of your website - they are basically a definition of the performance goals that you want to achieve.

    Many metrics can be defined, but often cover your goals for performance and concurrency. In particular, factors which can be difficult to quantify, and are often prone to emotional assessment:

    • our website is much too slow today - when does slow qualify?

    • everything grinds to a halt when my colleague logs in - how many concurrent users can the system support?

    • when I search, the system grinds to a halt - which sort of search requests are impacting the system?

    • it takes ages to download the file - what are acceptable download times (under normal network conditions)?

    Target Metrics are defined at the start of a project to:

    • indicate the expected dimensions of the website you will offer

    • indicate the minimum quality which you want to achieve

    • define how these factors will actually be measured

    During development of the project they can be updated and tuned as appropriate. After the project has been successfully implemented, they can be used to help you control your installation and monitor / maintain the required levels of service for ongoing operation.

    As always care must be taken when defining the target metrics:

    • if set too high they may be completely unattainable

    • if set too low fluctuations may not be highlighted

    • to ensure that they can be repeatedly and consistently measured

    • to provide a balance across the different factors being measured

    • certain metrics will relate to a test environment, but some should reflect real-life scenarios as they must be measurable, and reproducible, on your production website

    • prioritize the metrics according to their significance to the website

    • limit the metrics to a set that can be realistically monitored

    When used properly these metrics can provide a useful tool; when used irresponsibly they can be a time-wasting distraction. As always, you need to understand what you are measuring, how you are measuring it and why.


    This section will deal with the basic principles and issues to be considered. Each installation is different, so the actual values to be measured will differ.

    Everything rests on your Project Design

    All metrics to be measured will, in some way, be affected by the design of your project. Conversely, many issues will be best solved by design changes.

    Therefore, you should define your target metrics before your design has been finally decided. This allows you to optimize your design based on these factors. Once your project has been developed, it will be difficult to make any changes to the basic design principles.

    When you create the structure for the website, follow the recommended structure for CQ5 websites. Make sure you understand the following issues and/or principles:

    • How to structure website content.

    • How templates and components work.

    • How caching works.

    • The impacts of personalized content.

    • How the search function works.

    • How you can use CSS and related technologies to create compact, non-redundant HTML code.

    If you feel that your design does not follow the guidelines, or if you are unsure about some of the implications, clarify these issues before you start either the programming phase or filling in the content.


    To define or assess the infrastructure it will help to define target values such as:

    • visitors/day; both average and peak

    • hits/day; both average and peak

    • number of web-pages being made available

    • volume of web-content

    Depending on your situation, and the strategic significance of the website this will help you to assess, or choose, your infrastructure:

    • number of servers

    • number of CQ5 instances (author and publish)



    Your website will be made available to a number of users. Often more than you used when testing, but also fluctuating and difficult to predict. Your website will need to be designed for an average number of concurrent users who can work without noticing a negative performance impact.

    Concurrency on author and publish environments

    Targets for the number of concurrent users, are dependent on the environment type:

    Author Environment

  • Usually the number of concurrent users can be accurately estimated. You will know how many authors you have in total, though (probably) not all will be active at the same time.

  • Publish Environment
  • This is more difficult to predict, so you must select a target value. Again this should be based on experience of your current website together with realistic expectations of your new website.

    Special events (e.g. when you publish new, very popular content) may exceed expectations - or even capabilities (as sometimes reported in the press when tickets for certain events are made available for sale).

  • Again the request.log can be used to make concurrency tests; see Performance Optimization for more details.

    Capacity and Volume

    Before discussing the metrics, a quick definition of the 2 terms:


  • the amount of output that is processed and delivered by the system.

  • Capacity
  • the system’s ability to deliver the volume.


    At each step, capacity and volume are measured differently, as shown in the table below. For best performance, make sure that the capacity matches the volume at each step, and that both capacity and volume are shared across all steps. For example, you may be able to compute the navigation on the client computer, or put it in the cache, instead of computing it on the server for every request.

    Capacity and Volume

    What / Where  Capacity  Volume
    Client Computational power of the user’s computer. Complexity of the page layout.
    Network Network bandwidth. Size of the page (code, images and so on).
    Dispatcher cache Server memory of the Web server (main memory and hard drive). Web server (main memory and hard drive). Number and size of the cached pages.
    Output cache Server memory of the Communiqué server (main memory and hard drive). Number and size of the pages in the output cache, the number of dependencies per page. The dispatcher cache lowers this volume.
    Web Server Computational power of the Web server. Amount of requests. Caching lowers this volume.
    Template Computational power of the Web server. Complexity of the templates.
    Repository Performance of the repository. Number of pages loaded from the repository.

    Other Metrics

    The preceding sections detail the main metrics to be defined.

    Depending on your specific requirements it might be useful for you to define additional metrics, either in isolation, or taking the above classifications into account.

    However, it is preferable to have a small set of accurate, core metrics that function easily and reliably, rather than try to measure and define every aspect of your website. By its sheer nature, your website will start to change and evolve as soon as it is handed over to your users.

    Acceptance Tests

    Acceptance Tests are used to confirm that the:

    • Project fulfills the customer's requirements.

    • Customer accepts the project.

    The earlier you plan and design your acceptance tests, the easier the final deployment will be. 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 fundamental requirements (functional and performance) of the system.

    Organizing your Project

    As with any project it is critical to establish ground-rules as soon as possible. These include:


  • These should be clearly defined and made known to everyone involved in the project. In addition, it is advisable to highlight:

    • Decision Makers

    • Points of Contact

  • Responsibilities
  • For each role a clear definition of the responsibilities related to your project helps prevent confusion.

  • Involvement
  • By involving interested parties as soon as possible you can encourage them to become stakeholders in the project, thus increasing their commitment to its success.

    On the customer side this includes the authors - who will have to work with the system on a day to day basis.

    Within your own project team this will also include the people responsible for quality assurance. The more they understand the customer's requirements the better they can plan the tests.

  • Paths of Communication
  • Although these should not be formalized excessively, specific definitions should ensure that the key people are always informed and therefore kept up-to-date. Specific attention should be made to communication with external parties.

  • Processes
  • The processes to be defined will depend upon your individual project. Again try to keep these simple, with consideration for:

    • Defining processes (and paths of communication) for interacting with any third-parties; e.g. design agencies and third-party software suppliers amongst others.

    • Often the customer will have their own Project Management and Reporting procedures and tools.

  • Tracking Tools
  • There are many tools available for tracking information on bugs, tasks, and other aspects of your project - see Overview of Potential_Tools for more details.

    The key point to note here is to keep only one copy of the information and share the information (and therefore access to the tool being used). This will ease maintenance and help prevent discrepancies.

  • Scope
  • Clearly define what is to be covered by the project at various levels:

    • the individual releases (if an iterative release process is used, and regardless of whether they are delivered to customers or your internal test team).

    • the CQ5 project.

    • the entire project; including any third-party software, their impact on testing, organizational issues and many others.

    For certain aspects it can also be useful to state what is not within the scope of the project. This can help prevent confusion and incorrect assumptions, though it should be limited to essential issues.

  • Reporting
  • Clearly define what information you will report, in what form, how often and to whom.

  • Terminology
  • Define any abbreviations and/or customer-specific terminology to be used.

  • Assumptions
  • Define any assumptions being made.

  • This information can be defined within a Project Handbook; the use of a Wiki can also help ensure that ongoing changes are handled efficiently.

    Wherever these are defined, the key factors are that:

    • Information is defined and maintained

    • Information is clearly communicated to all of the relevant people involved. Although standard Project Management practice, it cannot be repeated often enough that clear role definition and good communication can make, or break, a project.

    • Only one version is kept of any information being tracked; e.g. bug tracking, issue tracking, etc.

    Project Phases

    The following diagram offers an example overview of milestones and phases involved when implementing a CQ5 project. The actual model you select to work with will depend on factors such as the project concept, budget and timelines amongst others.


    The time scales are theoretical.

    Example of Milestones and Phases

    Examples of Milestones and Phases


    Split the project-launch into Soft Launch (reduced availability) and Hard Launch (full availability) to allow for tuning, optimization and user training under realistic conditions on the production environment.

    For each phase of the project:

    • Concept and Planning

    • Development

    • Testing

    • Content generation and/or migration

    • Training

    • Knowledge Transfer to support team

    • Deployment

    • Acceptance tests and sign-off

    • Post-deployment

    • Project Management

    you need to assess the possible tasks, then list those actually needed for your project. This list can then be used within your project plan or as a detailed checklist when monitoring progress.

    See Example_Tasks for examples of possible tasks which you may need to perform (or assess) during the life-cycle of your project. These tables are meant as quick-reference and to act as a springboard, they do not (cannot) offer a completely comprehensive list of all possible tasks. Your list of actual tasks will vary with each project.

    Estimating Time and Effort

    Dependent on your resulting task list you can then make initial estimates of time and effort for (high-level) task definitions. These should include an indication of who (customer or partner) will do what and when.

    The following list shows standard approximations and inter-relationships of effort involved, and therefore costs:

     Phase Effort 

    A rough estimation of 2 - 4 hours for each component node will cover all development requirements.

    Note: These can only be used for initial estimates. An experienced CQ5 developer must make the detailed analysis.

    Developer Testing 15% of Development
    Follow-up 10% of Development
    Documentation 15% of Development
    JavaDoc Documentation 10% of Development
    Bug-fixing 15% of Development
    Project Management 20% of project costs for ongoing Project Management and Governance

    Detailed planning can then relate available or required resources to deadlines and costs.

    Any questions?
    Find tips, tricks, and solutions to common issues in our support community: