Building a Time Line

From the information you have gathered, you should build a preliminary time line. The following sections describes the steps to build a time line for a generic schedule of deployment.

Deployment Design

This phase of the time line is where the concepts, business needs, and user requirements are put in their proper context. A total view of the deployment takes shape. Components are described, technological requirements are defined, and a complete architecture is mapped out. Storyboarding login screens or creating data flow charts are two ways of initiating this design phase.

Proof-of-Concept

A proof-of-concept enables the design to be tested in a business environment. Organizations often have a test case database, a set of pre-configured test cases coupled with their expected results. The proof-of-concept can be applied to this test database, and, if all goes well, the documented results will be equivalent to the new results. A proof-of-concept aims to answer all question posed by the Deployment Design, proving that it meets all needs efficiently and with minimal risk.

It is generally fast allowing for ample time to refine the design based on a limited set of data. There are usually several rounds of proof-of-concept, followed by design refinement. The last round in the proof-of-concept should be integration of some internal applications. Integration of a corporation’s shared services often adheres to a standard model of sign-on by early adopters, followed by general participation and, lastly, the stragglers. Demonstrated success with early adopters makes it easier to use those applications as references for general adoption.

Early Adoption

Mission critical or revenue-building applications should not be chosen as your first application. A less risky strategy is to choose an important application that will not completely disrupt business operations if there are issues during roll-out. For example, a divisional portal serves as a natural staging ground for a single sign-on (SSO) roll out, rather than an accounting system at the close of a fiscal period.

Also, limit the number of applications roll-outs in the early phases so process flaws can be driven out, results demonstrated, and immediate success recognized. Minimizing organizational risk while maximizing visibility is the optimal roll-out strategy. This plan positions the deployment team with the appropriate product experience to take on critical applications.

General Participation

Although the deployment project begins with a single application, the requirements of other internal customers should be assessed at the same time so that a general purpose system can be built. The central IT group should be able to accommodate the diverse criteria and schedules of the satellite groups in order to provide service that is representative of the larger organization. Schedules must have sufficiently large windows, allowing the satellite groups time to build changes and upgrades into their application’s deployment and quality assurance (QA) cycle.

Production Environment

Following the proof-of-concept, the refined design can be replicated into a production environment. The purpose of a production environment is to demonstrate the function of the design in a non-artificial environment, ensuring its proper behavior. The environment is compared to the behavior as observed in the proof-of-concept, and as defined in the deployment design. It is also tested for stability.

An assessment is made and reports are generated. Early adoption applications go live in the production environment as they are ready. Incrementally phase new applications through the test phase and into production. Other applications are incrementally added to the production environment by working them through the proof-of-concept cycle as the early adopters have been.

Sample time lines are not available, because they vary based upon project complexity. However, this process typically takes place in a span of two to three months.

Deployment Road Map

Mapping out your Access Manager integration is imperative to ensuring its success. This process include collecting information concerning hardware, currently deployed applications, identity data, and access hierarchy. Access Manager deployment can be broken down into the following phases:

1. Identify business objectives such as:

   • Increase operational efficiency.

   • Assure data security.

   • Assure continued productivity by understanding the scope and relationships within the organization and analyzing the behavioral changes needed to support the business objectives.

2. Develop a high-level technology analysis and map it to the business objectives by listing technology services and tools needed to meet business objectives.

3. Define initiatives for each technology service such as:

   • Storing employee history and data accumulated through personalization.

   • Accomplishing password synchronization and identity administration through identity management.

   • Realizing enterprise security through the development of role strategies.

4. Prioritize initiatives based on items such as statistical accuracy, predictability, scope, cost, impact, complexity, behavior, infrastructure, benefit, support, and dependencies.