Document Your Business Goals

Applies To: Windows Server 2003 with SP1

Previous Sections in This Guide

• Overview for Identifying Your Identity Integration Project

• Define the Project Structure

• Start the Solution Proposal

Correctly identifying the business goals that you want to achieve is essential for the success of your MIIS 2003 deployment project. The MSF approach to achieving business goals helps you overcome problems that get in the way of project success and take advantage of opportunities so that you can gain a competitive edge. A project team needs to clearly articulate the problems and opportunities, and understand the direction in which the business must move in order to reach its business goals.

While you write your vision statement, identify, clarify, and refine your business goals. These goals help form the vision and provide needed input to identify project scope. Prioritize your goals so that you can design and deploy by using an iterative approach. In this manner, you can take advantage of the MIIS 2003 features that are relevant to your scenarios and develop a working solution.

The two main components of articulating, refining, and subsequently documenting your business goals are the following:

• Gather all the requirements from the major stakeholders.

• Identify the high-level requirements of a project to meet your specified business goals.

Gathering Stakeholder Requirements

As you define and understand the business goals that direct your MIIS 2003 design and deployment, you can begin to identify the key stakeholders in the project. These stakeholders will be asked to sign off on the solution proposal and for some, the dataflow design. Gathering stakeholder requirements at an early stage permits smooth development of the solution proposal. Consider these stakeholders:

• The executive sponsor of the project.

• The data source stewards and data owners.

• The IT department, which includes capacity planning, hardware purchasing, and others.

• The security architect.

• The testing organization.

• IT support services, such as development and help desk.

Identifying the Needs of Your Business

Whereas a business goal may be broad or overarching in scope, the process of identifying business requirements points out specific objectives that you need to accomplish. For an identity management solution, fulfilling these objectives affects your IT organization (development, testing, and operations), security management, help desk organization, regulatory polices, and end user experience.

Identifying your business requirements starts with identifying the real-world objects that might be involved in any possible identity management scenarios. Real-world objects, such as employees, facilities, or hardware, are usually represented in data repositories as objects. The business requirements, however, address the real-world objects and the actions that use these objects are typically enforced through policies.

Figure 6 shows how you might start to diagram a basic system dataflow that focuses on business requirements of the staff member. In the first pass, the diagram need only list the data sources and those attributes of interest that pertain to contact information for a staff member. The contact information is listed on the diagram as real-world attributes.

Identifying Business Policies

Business policies are the guidelines or governance of the organization. Because identity information is critical to how a business conducts its operations, you need to research and then document all the policies that affect the real-world identity objects that you might use in your solution. Record these policies in the solution proposal.

In the example scenario that is used throughout this collection, the business requirement might be to allow employees (including management) the ability to access the most recent phone contact information. The policy for publicizing this type of information is:

• Specific department phone numbers are only published internally.

• Employee home phone numbers are only exposed to the employee and their immediate manager.

• Mobile phone numbers, which are issued to the sales staff, are accessible to outside customers by department only.

The design and planning tasks for deploying MIIS 2003 use these policies to perform the correct synchronization process for the associated attributes of each real-world identity object.

Figure 7 shows the same example scenario diagram with policies listed for each connected data source and for the staff member. The project team has the responsibility to discover and articulate these business policies so that the designers and planners can configure MIIS 2003 to conform. In some cases, MIIS 2003 might not be able to enforce a policy, in which case, your design should include other enforcement means.

Defining the High-Level Requirements

After you identify your stakeholder requirements and business policies, begin considering the high-level requirements of the MIIS 2003 deployment. Your basic requirements might be strictly internal to the organization, such as security, cost, availability of personnel, and deployment timing and sequence. Basic requirements might also be related to external forces, such as company merges or partnerships.

The process to define your basic requirements begins with defining a set of functional requirements and features that should be considered for the identity integration or management project. It focuses on the business requirements you defined in the preceding step. After you define the set of potential business requirements, the project team narrows the list to the essential requirements, postponing those of secondary importance until a later time.

Typically, high-level requirements for an MIIS 2003 deployment involve the following elements:

• Data availability

• Data security

• Data integrity

In the example scenario, business policies dictate that only human resources — and no other process — can control the update of the HR database. This policy translates into a data security requirement that states human resources data is read-only to all departments except human resources. However, because the home phone numbers in this scenario change more often than human resources personnel want to update their database, this project requires that the current home phone number must be available within 72 hours of a change. Where the home phone number can be accessed is an issue for the designers.

Versioned Releases

MSF advocates the use of versioned releases in defining project scope. Versioned releases help the project team respond to ongoing changes in scope, schedule, and project risk. If time, budget, or resource constraints prevent deployment of the entire vision at a specified date, the team may decide to implement the project in phases. A phased approach is especially useful when the time to deploy is critical.

Versioned releases often involve trade-offs in features in favor of an early release of a stable solution that greatly increases the business success. They also provide an opportunity for making changes in response to feedback from earlier releases.

Defining User Profiles

It is the responsibility of the project team to define user profiles in order to predict user behavior. The prediction is achieved by identifying users’ needs and requirements for the solution: you identify what they are doing that the solution will facilitate.

Business requirements develop out of organizational needs. Those user needs are addressed as you design and plan for the implementation of your identity management solution by using MIIS 2003. Most are identified when you write the business goals and business requirements, but listing them in the solution proposal allows you to evaluate each individually.

An effective way to do this is to create profiles that include these activities for different categories of users, usually grouped by their functional areas. Users are often from both the IT and business areas of the organization. Business users might include accounting, procurement, and warehouse operations. IT users could include help desk operations and database administration.

For an MIIS 2003 deployment, consider these user groups and identify how a new method of identity management would affect each. Remember, as with the other tasks in these early planning phases, this is an iterative task. As you develop your solutions for your planned scenarios, return to this list and update it accordingly:

• End users. How will each group update and access their information?

• System administrators. How easily will IT administrators adapt to new requirements, such as increases to system availability by users or processes, or security enhancements. What kind of MIIS 2003 training will they need?

• IT department. Do the requirements for any current data sources need changing?

• Help desk. How will the solution fit into help desk current processes and will it affect their ability to achieve their goals?

• MIIS 2003 operators. What kind of training is required to perform the daily administrative and operational tasks for MIIS 2003?

Identifying the System or Process State That You Want

The final step in the process to identify business requirements is to define how you want your identity management system to function when it is fully deployed. Using the high-level requirements and the usage scenarios, complete a high-level system diagram of each scenario. Identify the possible real-world objects and associated data sources with their known restrictions. At this point in the design, without understanding all the details think of MIIS 2003 as a means that can solve your identity integration problems. As you move through the subsequent design phases, you can update these scenario diagrams with the necessary synchronization details.

For example, Figure 8 shows one possible integration scenario for the example scenario. The vision statement is clearly stated so that only the relevant objects and attributes are addressed (not all are listed on this example). In addition, the business policies are closely related to the vision of the project. Relevant objects are listed for each data source and for the key attributes required for this scenario.

Use this type of diagram to design your specific scenarios, noting which data source is affected, where the data needs to flow, how often this needs to occur, and similar details. In this example, there are six scenarios that can be considered for a staff member:

• A staff member is hired.

• An existing staff member changes contact information.

• A staff member leaves the company voluntarily.

• A staff member leaves the company involuntarily.

• A contracted labor resource becomes a staff member.

• A human resource does not fit into the staff member or contracted labor category but requires contact information.

Next

• Document Your Business Goals

See Also

Concepts

Initiating Your Identity Integration Project
Define the Project Structure
Start the Solution Proposal
Document Your Business Goals
Assess Your Current IT Infrastructure
Create the Project Vision and Define Scope
Assess Risks for an MIIS 2003 Project