Developing

Article
03/05/2008

During the Developing Phase, the feature team uses the data gathered and analyzed during planning to establish a viable set of operational processes that are applicable to the BDD project. Then it creates a training program to facilitate the adoption of these processes by the operations staff.

The roles and responsibilities listed below are those of the MOF Team Model. For detailed information about the MOF Team Model, refer to the MOF white paper, “MOF Team Model for Operations,” available at https://www.microsoft.com/technet/itsolutions/cits/mo/mof/moftml.mspx.

Roles and Responsibilities

During the Developing Phase, the team members are primarily concerned with using the operations assessment data to choose appropriate operational practices and with building a training program to enable production staff to implement them. Table 4 describes the roles and responsibilities of each role cluster during this phase.

Table 4. Roles and Responsibilities During the Developing Phase

Role cluster	Involvement in evaluating operations process activities
Infrastructure	Provides technical expertise, including advice and guidance on how to identify and manage the relationship between configuration items
Operations	Provides input into operational configuration items
Partner	Provides partner/third-party input, particularly for cases in which the partner manages configuration items
Release	Manages and owns the identification of configuration item processes Coordinates with the Deployment feature team to ensure that co-dependencies between new processes and tools and deployment plans are accommodated
Security	Provides input into security configuration items and security issues with this task
Support	Provides input into support configuration items Provides direct support for this task

Establishing Processes and Tools

Investigation and analysis of the current state of the IT organization are the key tasks the Operations Readiness feature team performs during the Planning Phase of the BDD 2007 project. As the project moves into the Developing Phase, the team coordinates with the customer stakeholders to determine priorities in mitigating any operational deficiencies found before the pilot and subsequent deployment.

As discussed earlier, more than 20 MOF SMFs have been identified that address key aspects of operating and managing an IT environment. Although MOF recommendations prescribe that all these SMFs should be implemented, this may not be possible in the short term to meet the operational objectives of a deployment project. This section provides guidance on the most significant operational processes that should be either in place or implemented.

The SMFs that are important when deploying and maintaining the post-deployment health of the deployed environment are:

Change Management.
Configuration Management.
Release Management.
Service Continuity Management.
Security Management.
Service Desk.

Note that these processes should be in place for each workstation role identified in prior investigation. Particularly in organizations with distributed IT operations, it is crucial that all workstation roles be managed in a consistent manner. Those involved in the assessment activities conducted in the previous phase should also be familiar with these processes to direct their investigations appropriately.

Change Management

During the pilot and following deployment, the IT organization should implement several key change management processes. Change management enables the IT managers to control the stability of the IT environment, preventing the introduction of unauthorized or ill-conceived changes that may have harmful effects on the environment. For additional information, review the Change Management SMF. The recommended change management processes include:

Change request procedures. Each change request should follow a standard format, which must be defined and implemented.
Change classification. Requested changes will be categorized by urgency and potential effect on infrastructure. This classification will affect the timing and strategy of implementation.
Change authorization. Requested changes will be reviewed and authorized or denied by a change manager and/or a CAB. The CAB consists of IT and business representatives appointed by IT management.
Change development. The change and its deployment strategy will be planned and developed with reviews at key interim milestones.
Change release. The release and deployment of the change into the production environment will be defined.
Change review. A post-implementation process review will be conducted to determine whether the change has achieved the goals that were established for it. At this review, a decision will be made to either keep the change in effect or back it out.

Configuration Management

Configuration management , in general terms, is a set of processes intended to identify and track each of the component parts of an IT infrastructure and its relationship with the other parts of the infrastructure. This includes hardware, operating systems, application software, and other related components.

The configuration management processes that are recommended for implementation include:

Establishing configuration items.
Assessing configuration items.
Changing configuration items.
Reviewing configuration items.

Each of these processes is described below. For a detailed discussion of the Configuration Management SMF, refer to the Configuration Management SMF at https://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfcfgmg.mspx.
Establishing configuration items. Document the identity of each workstation that the pilot and the desktop deployment will affect. Workstations are defined as the combination of any desktop computer—with its operating system and applications—that is connected to and uses the network. The proper understanding and documentation of relationships between IT components make it possible to perform detailed impact analysis on a proposed change.
Assessing configuration items. After the configuration item data for each workstation is collected, it is entered into a tracking system, typically the CMDB. The CMDB enables other SMFs to access the data they require to implement their functions. For example, change management uses the relationships defined within the CMDB to determine the effect of a change on other components within the IT environment, and problem management uses the CMDB as a resource to identify which configuration items are the root cause of incidents.
Changing configuration items. As Release Management begins to make changes to IT components, corresponding updates must be made to the CMDB, because without accurate and up-to-date information, the value of configuration management is lost. This process should be done automatically, wherever possible. The amount of information and the frequency of change make manual data entry impractical for all but the smallest organizations.
Reviewing configuration items. The accuracy of the information stored in the CMDB is crucial to the success of Change Management and other SMFs. Establish a review process that ensures that the database accurately reflects the production IT environment.

Release Management

Release management encompasses the decision-making, planning, testing, and eventual rollout of a change. In the case of BDD 2007, release management constitutes the primary interface between the existing IT Operations organization and the desktop deployment project team. In reality, the Deployment feature team is actually an extension of the IT Release Management SMF into the development process.

Subsequent to the approval of a change in the Change Management SMF by the CAB, the release transitions through several steps as it moves toward and through rollout. Those steps include:

Release planning. During release planning, an assigned release manager determines which changes must be made to the production environment to implement the BDD 2007 project. Having established what must be done, the release manager can then decide how those changes should be released into the production environment. After the release manager has defined the contents of a release, he or she can formulate and build a release plan that lists the tasks and activities required to deploy the release into the production environment.
Release building. During this task, members of the Release Management Role Cluster begin to develop the processes, tools, and technologies required to deploy the release into the production environment. Collaboration among all the BDD 2007 feature teams will be essential in this process.
Acceptance testing. Testing of the planned release ensures that releases will not adversely affect the production environment. Although testing in a simulated production environment provides the Release Management Role Cluster with some confidence in the release, it does not guarantee that the release will perform well in production, where conditions may be significantly different. In some cases, it may be necessary to conduct several controlled tests in production to confirm that the release meets expectations.
Release readiness review. The release readiness review is the final management checkpoint and approval step before the Release Management Role Cluster begins detailed rollout planning and preparations. The release readiness review ensures the readiness of the release for deployment and produces a decision about whether to deploy the release. The review considers the operability and supportability of the release itself as well as the readiness of the target production environment to support and operate the deployed release. If the decision is to deploy the release, the release moves to rollout planning and preparations; otherwise, the deployment is postponed until the necessary improvements take place or it is canceled.
Rollout planning. Rollout planning is where the strategy for the rollout itself is created. This step includes a review of the rollout by the release manager. The release manager must review the rollout order to determine whether it is still aligned with business requirements and priorities. If there is a pressing need for the release in Finance, for example, it may be preferable to change the rollout order so that the release is deployed to the Finance department before Sales and Marketing. After the release manager has confirmed the rollout order, the task of building detailed rollout plans to deploy the release into production can begin.
Rollout preparation. Before the actual rollout, preparations must be made in the production (or pilot) environment to accept the deployment. The tasks and activities required to achieve this step often include communicating information about the release to users and other personnel, training help desk and technical support staff, and making backups of critical IT components.
Rollout. Rollout, the process of moving BDD 2007 into the production environment, depends on the type and nature of the release and on the selected release mechanism. In all cases, however, the release manager should be provided with status reports and, where appropriate, tools and technologies that will enable him or her to track and monitor the progress of deployment. As changes are made to IT components during deployment, corresponding changes must be made to the configuration items and relationships that model them in the CMDB. If the release fails to meet expectations or if serious problems are encountered during deployment, the Operations Readiness feature team may require problem management to identify and diagnose the root cause of the problem. If a suitable fix or workaround can be found, the team should document this and create an RFC to deploy it into the production environment. If not, it may be appropriate to use the rollback procedures to remove the release from that environment.

For a detailed discussion of the Release Management SMF process, see the MOF Release Management SMF at https://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfrelmg.mspx.

Service Continuity Management

The Service Continuity Management SMF is concerned with managing risks to ensure that an organization’s IT infrastructure can continue to provide services in the event of an unlikely or unanticipated event. This function is accomplished through a process that analyzes business processes, their effect on the organization, and the IT infrastructure vulnerabilities that these processes face from a myriad of possible risks. Each phase has tasks and deliverables associated with it that assist in determining cost-effective solutions. The deliverables must be maintained as active documents and updated as needed. In the context of the BDD 2007 project, the focus of this SMF will be to ensure service if the deployment fails in some way, thereby allowing the IT environment to recover to a stable, usable state. The process consists of four steps:

Acquiring service-level requirements. Service continuity management starts by carefully agreeing to availability targets with the customer and determining the cost of downtime or unavailability of the IT service in question so that a realistic IT budget can be established. It is also important that the negotiation includes realistic expectations of reduced system availability while the contingency plan is in place. In the case of the BDD 2007 project, this negotiation is confined to service availability during the duration of the deployment itself. For a full-scale MOF implementation of the SMF, this negotiation would cover 24-hour-a-day operations for the length of a long-term agreement.

This process involves an element of education and negotiation on both sides (the customer and the IT organization). The customer must understand how to define and articulate its availability requirements. The IT organization must understand the functions that make up the overall IT service and which functions are most important.
Proposing contingent solutions. Service continuity management ensures that the service is available in the event of a service disruption, regardless of the cause of the disruption (for example, disaster, component failure, virus attack). During desktop deployment, the Deployment feature team must develop strategies for maintaining service in the event of a failure caused by the deployment itself. Service continuance typically involves two separate but equal functions: failover and restoration.
Formalizing operating level agreements. When IT and the customer agree on a cost-effective contingency solution, the agreement needs to be formalized in a document called an operating level agreement (OLA). The OLA serves as one of the building blocks for the SLA between IT and the customer. The SLA is a formal, legal document between IT and its customer. For a single, limited-duration event, such as the desktop deployment project, the stakeholders must consider the level of formality required to guarantee appropriate levels of service availability.
Formalizing the contingency plan. The contingency plan should be a prescriptive guide that IT personnel can use to failover and recover the service in the event of a significant event. This document must include information about escalation and notification procedures, startup and shutdown procedures, communication methods, and status-reporting requirements.

Although the extent of a full implementation of the Service Continuity Management SMF is beyond the scope of a BDD 2007 project, there is considerable similarity in the tasks that must be accomplished.

Security Management

Security Management SMFs can affect an entire information system, including interactions with many of the other SMFs. In fact, security management acts as an umbrella process in the Operating Quadrant of the MOF Process Model. Every other process must conform to the guidelines security management sets forth. The main processes encompassed by the Security Management SMF are:

Identification.
Authentication.
Access control.
Confidentiality.
Public key encryption and Public Key Infrastructure (PKI).
Virtual Private Networks (VPNs).
Integrity.
Nonrepudiation.
Auditing.

Because security is embedded at the core of most IT operations, BDD 2007 has incorporated a feature team that is focused on the security issues of planning, developing, and deploying the solution. See the Security Feature Team Guide for additional details about implementing security SMFs. Also included in the Security Feature Team Guide is an overview of the methodology used for ensuring the deployed operating system and any installed software applications are kept up-to-date with security-related updates.

Service Desk

Service desk operating processes are extremely important, particularly after the migration to an updated IT environment that includes new hardware, operating system, and productivity applications. Most IT operations organizations maintain some form of the Service Desk SMF, which can form the basis for service management of the new client computer.

A complete description of the Service Desk SMF is provided in the MOF Service Desk SMF document at https://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfsvcdk.mspx, but some of the key objectives that should be accomplished in preparing the service desk to handle client computer service requests include:

Supporting the upgraded environment across business, technology, and process boundaries.
Providing a single and central point of contact between users and the IT department.
Providing an interface for users to other SMFs, such as Change Management, Problem Management, Configuration Management, and Release Management.
Identifying additional business opportunities for the desktop deployment project.

Developing a Training Program

To ensure a smooth transition from a successful deployment to an efficient operations environment, the desktop deployment team should develop a training program for IT operations staff. MSF, through its Readiness Management Discipline, defines a rigorous readiness management process to help organizations prepare for change. By applying appropriate components of this process, the Deployment feature team can build a targeted training program to meet the requirements of the overall project scope.

Through MSF, the process to manage readiness for change comprises four steps: define, assess, change, and evaluate.

Define

Key to a successful training program is a clear and concise definition of the specific items that must be taught. For some projects, this goal might require considerable research. For the desktop deployment project, the key IT Operations items are relatively well defined: They are the limited set of SMFs described in the previous sections. The IT organization personnel who will manage the deployed desktop must be familiar with the SMFs that will allow them to make necessary changes, ensure availability and security, provide support, and execute the other functions required to maintain organizational productivity. For each of the SMFs described, the feature team must list in detail each of the specific processes, procedures, and tasks that must be accomplished. The published SMFs will provide specific references in this task.

Also included in the definition process is an analysis of the required levels of proficiency for each of the learning units. For example, for a service desk technician, there may be little need for an expert knowledge of system architecture. Proper determination of the depth of knowledge required will be crucial in scoping and developing the training program.

Assess

Having defined the training requirements, the team must assess the current state of readiness in the host IT organization. An organization with well-established IT management processes may require very little training to bring its members to the desired levels of proficiency. Conversely, an organization with few standardized processes may require a focused effort to bring its members to the desired level.

Assessment activities may take a variety of forms. Typically, the team will use some combination of surveys and interviews to obtain the required information. The team can most efficiently accomplish this effort during the operations assessment, described in the “Planning” section of this guide. Assessing which SMFs the organization has implemented and its proficiency in doing so is relatively straightforward.

Change

This step of the readiness process includes development and presentation of the training program. The training team evaluates the results of the assessment program and performs a gap analysis to determine where gaps in knowledge, skills, and proficiency exist, prioritizes them, and selects appropriate training or other approaches (such as outsourcing) to address them. During this process, the team will also establish a method to track the progress of the training program. This is of particular importance in cases in which it may be impractical to provide centralized training to the required IT staff, because the deployment is occurring in diverse geographic areas or to diverse user workgroups.

The feature team may develop this learning program entirely, but it is more practical to make use of existing Microsoft courseware, including the MOF Essentials course at https://www.microsoft.com/learning/syllabi/en-us/1737bfinal.mspx and the MOF Changing Quadrant course at https://www.microsoft.com/learning/syllabi/en-us/1787Afinal.mspx. In addition to these courses, the training team may also develop shorter workshops or presentations to address specific organizational needs or issues.

Evaluate

After implementing the training program, the training team will evaluate the program’s efficacy. This evaluation will typically take the form of a readiness review.

This evaluation step could be the end of the readiness management process. But because learning is an ongoing process, evaluation is typically viewed as the beginning of an iterative process. Some of the elements of the readiness review are:

Reviewing results. A real-world test of the training’s success is the effectiveness of individuals back on the job. One of the activities during the change step is identifying the most effective approach to the transfer of knowledge. A suggested approach is to follow traditional training delivery, such as instructor-led and self-study, with on-the-job mentoring or coaching. The individuals’ activities in this phase may include some introspection and self-assessment to determine whether the learning was effective before putting those new competencies to work. Individuals may also decide it is a good time to become certified, because they have done the learning, performed the key tasks, and assimilated the knowledge.
Managing knowledge. A natural side effect of training individuals is that the knowledge they acquire becomes intellectual capital that they can then pass on throughout the organization. As individuals complete learning plans and apply what they learn on the job, they use key learning that their training provided. Sharing this information with others throughout the organization enhances the collective knowledge and fosters a learning community. One objective of the Readiness Management Discipline is to encourage development of a knowledge management system to better enable the sharing and transfer of proven practices and lessons learned as well as to create a skills baseline of the knowledge contained within the organization.

Milestone: Operations Readiness Scope Complete

Table 5 shows all deliverables and their descriptions that should be completed at the conclusion of this phase.

Milestones are synchronization points for the overall solution. For more information, see the Plan, Build, and Deploy Guide.

Table 5. Deliverables

Deliverable ID	Description
Operations Processes	Operations processes are updated, supported by the relevant tools, and integrated into the operations management architecture and operations environment.
Trained Operations Personnel	Operations personnel have been trained to a sufficient level that they can support and manage the new desktop environment.