Service Management Functions

Infrastructure Engineering

Published: November 1, 2004

	Executive Summary
	Introduction
	Infrastructure Engineering Overview
	Processes and Activities
	Define the Infrastructure Environment
	Define Standards and Policies
	Apply Standards and Policies for Infrastructure Guidance
	Maintain Standards and Policies
	Roles and Responsibilities
	Relationship to Other Processes
	Key Performance Indicators
	Appendices

Executive Summary

The Infrastructure Engineering (IE) service management function (SMF) promotes the development and use of consistent, IT-wide standards and policies pertaining to infrastructure components and processes. Implementing this service management function will ultimately improve the operability of deployed releases by ensuring they are compatible with the existing infrastructure and services, as well as the changes planned for them. The IE SMF enhances IT’s ability to deliver services and functionality to meet business goals and objectives while reducing the likelihood of unrealized business value or failed project deployments.

The IE SMF describes processes to discover existing policies and standards within an IT organization, identify and fill gaps for desired standards (and policy coverage), drive consistency in standards-setting, and manage the suite of standards and policies through an established change management service function. By implementing Microsoft® Operations Framework (MOF) and service management best practices, including IE, organizations develop knowledge and skills in the management of their operations environment. This new knowledge can be used to optimize the performance of the infrastructure, ensuring that it meets the needs of the business now and in the future.

At a basic level, IE can use policies and standards as a passive touch point for change management processes in authorizing changes to the infrastructure. In a more mature situation, or where more control is required, IE can assume an active role. In association with engineering planning, change planning, and design/build efforts, IE regulates the use of approved standards in the development of specific and detailed technical plans to ensure consistency within the infrastructure design. As in all MOF SMF guides, this document offers guidance to fully implement standards and policies within an organization, but individual organizations may choose to implement the SMF to varying degrees, depending on the desired benefits and the resources available.

The extent to which an organization applies the Infrastructure Engineering SMF depends not only upon the selected scope of infrastructure to be regulated, but also on the nature of the changes being implemented. Some changes will require a full planning and developmental phase, including architectural design and sign-off. Other changes are minor and may be approved by the IE manager without further process requirements. In some cases—for example, the purchase of minor peripherals—the process may not require any intervention.

To learn more about MOF and how IE and other service management functions can help your organization, please visit http://www.microsoft.com/mof.

Top of page

Introduction

Document Purpose

The Infrastructure Engineering SMF assists in closely aligning MOF with ITIL guidance for the establishment of a centrally available standards and policies library. The need for such an effort is discussed in the ITIL document, “ICT Infrastructure Management,” published by the British Office of Government Commerce. This document describes, at a high level, the various aspects of the infrastructure for which design standards and policies should be devised. The MOF Infrastructure Engineering SMF provides significant process detail to implement common IT standards and policies within the IT infrastructure.

This guide provides detailed information about the Infrastructure Engineering SMF for organizations that have deployed, or are considering deploying, Microsoft technologies in a data center or other type of computing environment. This is one of the more than 20 SMFs defined and described in Microsoft Operations Framework (MOF). The guide assumes that the reader is familiar with the intent, background, and fundamental concepts of MOF as well as the Microsoft technologies discussed.

Audience

This document is written primarily for IT professionals and managers, including infrastructure engineers, systems engineers, architects, and others who wish to implement standardized practices and policies within their IT organization. The guidance provided in this document is intended to facilitate the development, application, and management of IT standards and policies in organizations of all sizes, but is aimed primarily at large organizations with complex IT organizations and multiple locations. Smaller organizations may realize the benefits of standardization as well, but may not require the detailed level of process outlined in this document to achieve a satisfactory set of standards and policies.

What’s New?

This IE SMF is one of the new SMFs added in MOF version 3.0. It has been added because of a demand from customers and partners alike for guidance on delivering a service management function to drive the consistent application of operations standards and policies throughout a project’s life cycle, from development to operation. This SMF guide uses feedback received from partners, customers, and internal Microsoft IT groups to develop and deliver a best-fit solution for implementing standards guidance throughout the infrastructure. It is a key SMF, and when used in conjunction with the Change Initiation Review Operations Management Review (OMR), which also changed in MOF 3.0, it ensures that the decisions and information pertaining to changes to the infrastructure are made using the right information at the right time.

Feedback

Please direct questions or comments about this SMF guide to msmfeed@microsoft.com.

Top of page

Infrastructure Engineering Overview

Goal and Objectives

Infrastructure Engineering (IE) is a new service management function (SMF) for MOF version 3.0. The IE SMF primarily coordinates the creation, management, and application of consistent IT standards and policies, which are then applied across the organization in the development, deployment, and operation of tools and services. Application of the standards and policies managed through the IE process becomes a fundamental part of the project planning process; compliance with these standards and policies is reviewed at key MOF milestones for the Optimizing and Changing Quadrants. (See Figure 1.)

Through implementation of the Infrastructure Engineering SMF, organizations will:

•	Develop standards, policies, benchmarks, and guidelines for managing the infrastructure now and in the future, maximizing availability, supportability, and operability.
•	Provide guidance and control to ensure that solutions are operable at the appropriate level and to optimize timing for new solution design and changes.
•	Ensure that the infrastructure in use, including the technology and common application portfolios (for example, standard desktops) align to the business strategy and direction.
•	Measurably improve their management of the infrastructure environment.
•	Provide for a means of verifying quality assurance (QA) for all infrastructure development at the planning and authorization stages.
•	Maintain a cost-aware approach to the selection of strategic technology solutions and reduce unnecessary costs. Figure 1. Relationship of Infrastructure Engineering SMF to other areas of MOF See full-sized image

Infrastructure Engineering will take the lead in identifying and normalizing existing standards and policies and determining the need for new ones. The IE SMF has responsibility for managing the development of standards and policies, typically through internal or external subject matter experts.

In some cases, the role of IE is a coordinating one—for example, the Capacity Management and Service Level Management SMFs are typically well-connected to business strategy and planning and how they relate to current and forecasted IT. These SMFs create standards and policies that address issues appropriate to their scope. The Infrastructure Engineering SMF will coordinate with these and other SMFs to ensure that the standards and policies they develop are consistent with those already established or planned for other categories. Once created, IE will take responsibility for managing these standards.

IE manages the resulting suite of standards and policies in concert with processes established by the Change Management and Configuration Management SMFs. This ensures that the standards and policies remain consistent and are changed only through a formalized process. Figure 2 illustrates this relationship.

Figure 2. Relationship of Infrastructure Engineering SMF with Change Management SMF and configuration management database (CMDB)
See full-sized image

In turn, to ensure that these standards are applied during the planning phases of IT operations and new projects, IE facilitates access to the new standards by publishing them to the configuration management database (CMDB), corporate intranet, and/or other publishing media. IE also ensures that proposed changes to the IT environment are in compliance with established standards and policies; this is accomplished through participation as a key stakeholder in the Change Initiation Review and Release Readiness Review OMRs, described later in this document.

Finally, the Infrastructure Engineering SMF provides guidance for applying the standards and policies across the organization. For example, the Service Level Management SMF may query the IE SMF when creating new service level agreements (SLAs) and operating level agreements (OLAs). Access to this information will ensure that the negotiated requirements can be met by the standards and policies for the infrastructure elements or service components involved.

Due to the need for input from subject matter experts across all the SMFs, the processes within infrastructure engineering are delegated and performed by various roles across the MOF Team Model role clusters; the specific coordination role for IE is carried out by the infrastructure engineering manager within the Infrastructure Role Cluster, which is examined in more depth in the Roles and Responsibilities section later in this document.

Scope

The Infrastructure Engineering SMF affects all standardized practices within an IT organization. These standards and policies may originate from any other SMF in any MOF process quadrant. The SMF is flexible in its scope, with the extent of IT standardization to be determined by the implementing organization.

Infrastructure engineering is not about control or micromanaging. It’s about defining common components that affect many groups and projects and facilitating the widespread application of these common components. To this end, controlling every single component within even a small infrastructure environment is impractical. Over and above the challenge of obtaining and collating all of the relevant information, the costs and resources involved in maintaining and updating the information would be prohibitive.

Therefore, choices must be made concerning the desired scope of infrastructure to be managed. This decision-making process requires that each category be evaluated for its direct relevance to meeting business needs, its dependencies on other categories, and the degree to which other categories depend on it. As with a CMDB, best practice calls for managing only those categories that:

•	Are necessary for the effective operation of the business.
•	Support the enablement and delivery of IT services.
•	Are common components across IT teams and projects that will save time and money if standardized for the whole.

These same criteria may be applied to creating standards or policies for the change or management of the infrastructure; centralized management of some infrastructure components is simply not practical or beneficial. Balancing this, it should be noted that the proliferation of multiple, seemingly inconsequential technologies—for example, remote management or scripting tools—can eventually amount to a significant operations management burden and cost. Furthermore, multiple technologies can impose additional security risks since additional network ports may need to be opened to accommodate them. In considering the scope within which to standardize, it is critical to consider these factors. Appendix A provides a list of typical IT infrastructure components to which standards and policies are applied. The decision to include a category within the IE scope should be reviewed at periodic intervals to ensure that resources are being allocated to useful activities.

Capabilities

An organization that implements this SMF should have the organizational capabilities in place to be able to complete and maintain the following:

•	Discover current standards and policies.
•	Define categories of standards, processes, and policies that align with their IT organizational structure.
•	Define an effective suite of standards, processes, and policies for common IT activities.
•	Implement and maintain a change management process.
•	Apply the standards and policies for design, development, and deployment tasks.

The breadth and depth of the standards and policies that are developed and applied may vary from organization to organization, depending upon the maturity level to which other MOF service management functions have been adopted.

Key Definitions

•

Change Initiation Review. The Change Initiation Review is the first milestone within the MOF Process Model and marks the beginning of an investment of resources from IT operations in instigating a change to the infrastructure. This review is held at the beginning of the change management process (closely synchronized with the Project Plan Approved MSF milestone) to evaluate the alignment of the requested change with IT policies or standards related to it. The guidance and infrastructure control processes managed by IE provide a key input to the Change Initiation Review as they ensure that any proposed change has utilized the policies and standards for the defined category to be changed.

•

Infrastructure category. A grouping of elements of the infrastructure with a commonality—for instance, hardware, desktop, network components, or buildings.

•

Infrastructure engineering manager. A specific role within the Infrastructure Role Cluster in the MOF Team Model. The individual responsible for the management, implementation, and review of the IE process. Coordinates and manages the relationships with those responsible for other SMFs and OMRs.

•

Infrastructure environment. The defined operational target for inclusion within the infrastructure engineering management process, which must be defined at the outset when implementing IE principles.

•

Policy. A defined process or set of procedures within a particular infrastructure category. For example, policies might be established for:

•	Managing the outsourcing of a service.
•	Hardware purchasing processes.
•	Managing change approvals.
•	Managing wireless security parameters.
•	Procuring a vendor.
•	Messaging security.
•	Guiding developers in procuring IT environmental requirements outside of established policies or standards.

The policies in place will ensure that the infrastructure complies with the overall strategy and accepted procedures of the organization.

•

Standard. A standard within this SMF is defined as a set of criteria or configurations applied within a category. Whereas policies are frequently processes applied to human activities, standards are frequently lists of requirements that apply to technologies. Examples of standards created for specific categories might include:

•	A network topology and layout standards.
•	A corporate standard for client or server configurations, specifications, and builds.
•	A standard architecture for test labs.

Standards may be prescribed, specific ways of working, or a set of specifications that describe a physical or virtual object, created to ensure a uniform approach to assist with control of the categories within the infrastructure. Note that both policies and standards may contain procedures; typically those defined within a standard are very prescriptive and focused on the completion of a well-defined task, as shown in the examples above. Appendix A provides a full listing of the standards and policies recommended by ITIL to provide guidance for infrastructure planning, engineering, and operations.

Top of page

Processes and Activities

Process Flow Summary

In implementing the Infrastructure Engineering SMF, a setup activity is initiated to define the scope of the infrastructure environment and to determine how best to manage it using defined policies and standards. Regulation of the infrastructure through the use of these standards can be as passive or active as the organization needs, although it is suggested that the use of established policies and standards be enforced at the Change Initiation Review, as a minimum. IE is not intended for use as a stand-alone SMF; it relies heavily on effective input and feedback from other SMFs, the business organization, the development teams, and the MOF Risk Management Discipline and Team Model role clusters to deliver maximum benefit to the organization.

A high-level view of the IE process is diagrammed in Figure 3. Note that the discovery and classification processes shown as setup activities may occur in parallel with the management activities illustrated in the lower half of the diagram.

Figure 3. A high-level view of the Infrastructure Engineering SMF
See full-sized image

The Infrastructure Engineering SMF is closely aligned with the Microsoft Solutions Framework (MSF) Planning Phase, as well as the MOF Change Initiation Review. Standards and policies that are derived in the top half of Figure 3 are applied within the production environment as part of operations, but are also applied to MSF projects for solution development and deployment.

Application of the IE standards and policies in MSF projects is initiated early in the project’s Envisioning Phase. Both MSF and MOF mandate that certain reviews take place throughout the course of a release’s (or project’s) evolution. As explained here, several of the MSF and MOF reviews synchronize closely within the release development timeline.

Project planning that occurs during the MSF Envisioning and Planning phases will incorporate IT policies and standards into the project requirements for development and deployment. Operations stakeholders first review these plans at the Change Initiation Review OMR, which occurs near the Project Plans Approved Milestone of the MSF Process Model. Compliance with standards and policies is again checked by operations stakeholders at the MOF Release Readiness Review, which is aligned with the MSF Release Readiness Approved Review. Both of these major milestones are significant checks against the possibility of releasing non-standard or incompatible changes into the production environment. These relationships are depicted in Figure 4.

Figure 4. Infrastructure Engineering SMF alignment with MOF and MSF processes (Note: MSF Scope Complete Milestone not shown)
See full-sized image

Process Flow Steps

The development and application of consistent IT policies and standards across an organization is accomplished through the following process, which is described in detail in subsequent sections.

Define the Infrastructure Environment

A clear and thorough definition of the infrastructure environment is key to its successful and subsequent management. This process provides guidance on how to define the environment and determine the desired scope of environmental components to be regulated, and examines how to categorize elements of the infrastructure into sensible groupings to allow effective utilization of standards and policies.

For example, the facilities manager within a particular organization may already have well-defined standards and policies in place for the acquisition of power and communications services for the data center. Although ITIL and MOF both have functions to regulate this, the organization may decide not to include this scope within the managed IT infrastructure as long as the IT management continues to communicate well with facilities management.

Collect and Define Policies and Standards

As previously stated, the use of policies and standards to control evolution of the infrastructure helps to maintain a stable and effectively aligned IT organization. This process provides guidance on collecting and documenting the policies and standards that exist across the infrastructure and defining new ones where necessary, looking in particular at key inputs that will ensure the best fit for the organization now and several years into the future.

Apply Policies and Standards for Infrastructure Guidance

The creation of policies and standards adds real value only if they are used effectively to provide guidance and control over the integrated infrastructure environment. This process examines how policies and standards should be applied in developing a new requirement or a change to the infrastructure. The process also describes an alternative for dealing with situations that fall outside the need for a standard or policy by taking a controlled approach to exceptions.

The IE SMF also facilitates the documentation and publication of standards and policies for easy accessibility within the organization. Templates and examples are provided in the appendices for guidance in developing an effective standard or policy. Publishing these through internal Web sites, knowledge bases, standardized queries to the CMDB, or other media minimizes the time that cross-operational teams or other users need to spend in researching the infrastructure engineering areas of their development or deployment projects or in writing specifications. For example, Microsoft publishes all of its financial and procurement standards and policies on a unified internal Web site.

Maintain Policies and Standards

Because the policies and standards are created across all the SMFs and MOF Team Model role clusters, it is important to ensure that they are maintained effectively and kept accessible to all potential users.

This section explains the management of changes, additions, and reviews of the standards and policies and how these maintenance activities map onto the processes defined by the Change Management SMF.

Top of page

Define the Infrastructure Environment

This section describes the process of defining the infrastructure environment. Managing the infrastructure can be carried out effectively only if you know what components you have and what you need to manage. This is particularly relevant to infrastructure engineering (IE) because the range of variables in IE is vast, and it is necessary to scope and define the area that the IE SMF applies to when implementing it. In varying sizes and types of organizations, the infrastructure may demand different levels of effort in management and control, and adequate scoping of these requirements beforehand will result in the successful management of the infrastructure in the future.

The overview of the process for defining the infrastructure environment is shown in Figure 5.

Figure 5. Process of defining the infrastructure environment

Document Infrastructure Environment

In order to collect a set of standards to use in managing the infrastructure environment, the infrastructure engineering manager must first determine the extent of the current infrastructure and identify its characteristics. The initial step upon implementation of the IE SMF is to complete a discovery exercise to determine exactly what infrastructure exists within the organization and what standards, processes, or policies are used (if any) to manage it. Initially, the scope of this effort might be restricted to the IT production environment only, but there might be circumstances where it is beneficial to apply standards, processes, and policies to other areas, such as development and test labs.

There are various starting points from which to begin discovering the infrastructure environment, and because every organization is different, the discovery methods to be used reflect this variety.

Locations

Few modern businesses are based in only one location. Even small- to medium-sized enterprises often use remote workers and spread their infrastructure over more than one site. It is essential to understand the variety and range of locations over which the infrastructure needs to be managed. One example of where to begin to define the scope of the IE SMF is to start first with the central data center environment and then extend the scope of IE control from there as the management of the infrastructure matures and benefits to the IE policies/activities are seen. Conversely, it might be decided to identify the full range of possible infrastructure locations first and then work within this range to define a smaller starting point. In any case, understanding the range of locations helps avoid costly remedial changes in the future due to ignorance of some planned change and allows for scaling up the scope of control when the use of the SMF matures.

The majority of organizations should have the details of the physical locations, installed technologies, and infrastructure components that they operate at hand. More difficult to define may be offshore or outsourced functionality or the use of remote workers. If there is a configuration management database (CMDB) within the organization, ideally it should contain information about assets in all locations.

Technologies

Another approach to investigating the infrastructure is to inventory the types of technology in use and the existing standards, policies, and processes used to manage it. For example, you will want to collect all available information about server hardware: brands, sku, suppliers, configuration, and procurement policies. Although you will perform a detailed classification of this information in a later step, to begin you should strive to obtain complete information about the technologies and processes in use in your infrastructure.

Within Microsoft, MSN has created categories and subcategories for a variety of technologies, as shown in Figure 6.

Figure 6. MSN categories for standards and policies
See full-sized image

When developing your own categories, you should consider including the following, as a minimum. The list below is not all-inclusive.

•	Data center hardware devices and configuration
•	Storage and backup devices and configuration
•	Core network infrastructure devices and configuration
•	Wireless or mobile connectivity devices and configuration
•	Desktops and mobile devices
•	Service provisioning software: Microsoft Exchange, SQL Server™, etc.
•	Standardized productivity software (corporate desktop)
•	Line-of-business software

Sources of Information

The discovery exercise should utilize information from many sources, some of which are suggested below, in order from most to least comprehensive. The objective of this exercise is to focus on information sources that will provide the greatest amount of information with the least amount of effort. If additional detail is required during the standards-setting phase of implementation, it is always possible to revisit the area. It is important to balance completeness of information with the reality that you will likely not require explicit standards and policies for relatively insignificant parts of the infrastructure, so plan your use of investigative resources wisely.

Service Catalog

The first step in the discovery process is to examine the service catalog that is maintained by the Service Level Management SMF. If this is present in the organization, it will contain a comprehensive list of the services delivered by the IT organization. This catalog will ideally list all the service components used to deliver the service and should document the extent of the infrastructure in use, as well as the criticality of the elements to the organization as a whole. The service catalog suggests logical infrastructure environment categories that relate infrastructure components by their importance to the business. For instance, the service catalog would specify the service level agreement for backups (including restore time, backup window, backup success rate, rotation, and retention policies). However, the underlying technology for performing these backups, including the storage media, backup devices, backup software, and agents, should all be strong candidates for standardization.

Configuration Management Database

After the service catalog, the configuration management database (CMDB), if present within the organization, is next in line to be queried for details about the IT infrastructure. An effective CMDB will have quality, current data. Keep in mind that the CMDB content is still only as complete as the individual organization’s level of configuration item (CI) recording. If the CMDB process is not mature, crucial information may be missing. For more information on CMDBs, visit the Configuration Management SMF guide at http://www.microsoft.com/mof.

Definitive Software Library

The definitive software library (DSL) should be consulted to obtain a definitive list of the software in use within the organization. Depending upon the operations maturity level of the organization, this list might not exist; if it does exist, it might not be fully inclusive of all products being used. Despite possible deficiencies, the DSL might be sufficiently complete to provide adequate information about key software usage.

Published Documents or Files

As a final step in the discovery process, the IE implementers should seek local documentation of various sorts. Various groups may document their infrastructure in Microsoft Word or Excel documents, or even on hardcopy forms. If this type of documentation is in use in the organization, it should provide information about the processes being used in the management and operation of the infrastructure. Document collections of this nature are unlikely to be centralized. More frequently, they exist locally, within departments or groups assigned to a specific function area or category. However, even these will provide some assistance in further scoping the infrastructure to be managed. These libraries should then be moved to corporate IE for wide access across the organization.

Contracts Database

If the organization has policies established for procurement or has implemented the Financial Management SMF, information should be available regarding the contracts currently in place. This information should be helpful, especially in reviewing purchased software and licensing, hardware products, outsourced facilities, and infrastructure—for example, power provision or ISPs, partners, and strategic relationships. As well as giving the current picture, details contained in a contracts database can be useful in scoping the extent of license agreements and partnerships by indicating length of tie-ins, renewal agreements, or expiration dates.

Once the information pertaining to the infrastructure has been gathered and there is confidence that the collected data is complete and accurate, you can begin categorizing the environment.

Create Guidance Categories

Categorization is the process of dividing the infrastructure into manageable and sensible sections. This is done to facilitate the development and management of similar standards and policies within a single group. In many cases, this is simply the recognition of existing categories or IT divisions. In others, it makes sense to split or merge existing divisions to accomplish the task. Categorization might occur along one of several different lines, each providing a different perspective of the IT environment. Examples include, but are not limited to:

•	Groupings based on table definitions and classifications within the CMDB.
•	Role cluster groupings assigned similar areas of responsibility for service functions.
•	SMFs responsible for coordinating the various areas of the infrastructure.

Keep in mind that this should be a simple process. The groups you create should be sensible and manageable groups of components, with commonality of purpose. In most organizations, the categories should become self-evident as you investigate the infrastructure.

Define the Scope of IE Guidance

In any organization, decisions must be made about which categories to manage and which to defer from standards compliance.

Categorizing and grouping similar infrastructure types, products, and services allows further refinement of the scope of the infrastructure being controlled. There are many examples; some will be specific to each organization. Several examples follow.

•

Data Center Standard Images. The data center environment is mission critical and highly dynamic. It is a corporate resource that depends upon the installation of consistently reliable components to achieve its mission; it is not an IT resource conducive to experimentation or incompatibilities. For these reasons, a key area for the implementation of standards is the data center hardware and server images. Although individual servers may be provisioned for a variety of server roles on a custom or semi-custom basis, it is important that the base servers be utterly reliable, with a well-tested and understood server image. The prudent IT organization will develop and maintain standards for the configuration of baseline servers in several roles, which may then be provisioned according to the service and service levels that have been negotiated.

•

Voice and Data Services. Many organizations outsource their communications services to a recognized supplier in that field rather than running it themselves across all their locations; in practice, national networks for telephony often rely on the use of commercial suppliers. The decision of whether to document standards for these services depends on the end use of the standards. For some organizations, this infrastructure element might be considered out of scope because it is provided externally and is supported by a contract and, ideally, an SLA. As long as the service is available when it is needed, no further management of the infrastructure that provides it may be required.

Conversely, for an organization that is actively expanding, it could be crucial to document standards for voice/data services for easy accessibility for future site development or to accommodate changes in vendors. There might be a need for scalability, however; and in some organizations where there is internal responsibility, there might be some input required for the way this infrastructure is managed and controlled up to the point where it is handed over to the external supplier.

•

New Technologies and Legacy Systems. As services become obsolete, they generally are phased out as new services are phased in. In some cases, however, legacy systems may remain for a period of time. This may occur because the solution works acceptably without the need to update it, because no update is available, or because it is not a critical function.

In contrast, organizations that rely upon implementing the latest technology in order to maintain a competitive advantage find it crucial to adopt cutting edge infrastructure components. This might also be done in phases to avoid large scale work disruptions or because only certain groups require the enhanced IT service or functionality.

Some organizations recognize the phased nature of infrastructure rollouts by managing standards throughout an established life cycle. For example, MSN, in managing its online operations, manages standards and policies for its mainstream operations by designating preliminary, current, and retiring versions of a standard. The MSN approach is further described in the following section.

Standards Life Cycle

Standards, or packages of standards, tend to follow a relatively predictable life cycle in most organizations.

The life cycle phases of a typical standard are as follows:

•	T0. The organization may propose a “preliminary standard” to govern the early adopters of newer and emerging technology, who will begin experimenting with and/or utilizing this newer “non-standard” technology. These early adopters will then typically contribute their knowledge and experiences into the standards development process.
•	T1. The organization formally proposes and ultimately approves a standard for the use of the new technology. Following the approval and publication of the new standard, the majority of other users will begin the process of becoming compliant with the new standard.
•	T2. Approximately 90 percent of the governed communities will have become compliant with the new standard. As the standard ages and technological developments continue, newer technologies will again begin to emerge by time phase.
•	T3. A new standards cycle must start again. At this point, compliance with the current standard will begin to erode as early adopters leave the current standard and begin to work with the emerging technology/standard.
•	T4. Is a representation of the mass adoption of new standards.

Figure 7, Typical life cycle of a standard, depicts one full life cycle of a standard from the early development of requirements of the standard through to the ultimate withdrawal/retirement of the standard.

Figure 7. Typical life cycle of a standard
See full-sized image

Standards Versioning

In order to manage the versioning of standards and the orderly transition through their overlapping life cycles the currently approved/active standard is given the designation of N. The newly emerging standard is designated N+1 and the standard immediately prior to N, the one that is being retired is designated N-1. Every standard during its life cycle will go through each of those phases/designations. The designations and descriptions of the N versioning model are as follows:

Table 1. Typical Standard Versioning Nomenclature

Version	Stage	Description
(N–1)	Trailing	The standard is still valid; however, not current, and will soon be retired.
(N)	On-boarders	The standard is current.
(N+1)	Innovators	The standard is valid; however, not current, but will become the next current.

This entire cycle iterates throughout the life of the standards process.

Figure 8. Standards life cycle iterations
See full-sized image

Table 2. User Adoption Through Standards Life Cycle

Cycle	Description
A – B	During time period A – B, Standard V.1 is the currently active standard and is designated N.
B – C	During time period B – C, Standard V.1 remains the currentlyactive standard and is still designated N. In addition, a new/revised standard (Standard V.2) has been proposed and is being tested/deployed by some organizations. The newer standard is the forerunner of Standard V.2 and is designated N+1.
C	At time point C, the proposed new standard (Standard V.2 becomes approved and is now the currently active standard. It is now designated N. In addition, the earlier standard is now being withdrawn and is no longer current. It is now designated N-1.
C – D	During time period C – D, most clients migrate to the new standard (Standard V.2) and some clients remain on the old standard (Standard V.1).
D – E	Most clients are now compliant with Standard V.2.
E – F	We now see a repeat of the cycle referenced in time period B – C.

Based upon the foregoing, the adoption and retirement of standards is shown to be a predictable, cyclic process. MSN applies this model in its standards deployment. This model provides for early communication of both client and operations standards requirements, predictably scheduled releases of “bundled” standards, and the opportunity for both advanced lab and pilot testing. All new MSN standards (bundles of standards) are released on a 4-month cycle basis.

This example illustrates the decisions to be made when considering which standards to document or manage and which to leave unmanaged. If an infrastructure component, service, or subsystem is not working effectively with other systems within the organization, then a new solution may be contemplated and a policy might be created for this transition. If it would not be cost effective or beneficial to manage and control these systems, then they should be considered as out of scope. However, as new standards are written, as shown in the MSN example, it may become more practical to manage a dynamic set of standards as the organization matures in this SMF.

Special Considerations

The organization may establish a policy that if a category is not included within the scope of controlled IE, that category must nevertheless have a clear relationship and review process with the IE SMF. In some cases, the points that interact with managed categories may be subject to IE control at—for instance, where a product is handed over to a third-party provider or where a new power requirement is made.

Summary

The following list summarizes the important points discussed in this section.

•	Document the details of your infrastructure, using available resources such as service catalog, CMDB, and other references.
•	Create categories to logically group the elements of the infrastructure environment that will require standards and policies. The categories should be devised to simplify the assignment of responsibilities to subject matter experts for subsequent development of standards and policies.
•	Scope the extent of the infrastructure that will be subject to guidance or regulation through the application of centralized standards and policies. Not all parts of the infrastructure will require such control.
•	Align categories and scope with existing processes within the organization for best efficiency. For instance, to achieve maximum benefit, the CMDB categories should align IE processes with existing service management processes in the organization.
•	Add the documented infrastructure environment to the CMDB as a configuration item.
•	Review the infrastructure environment categories and scope periodically to determine whether changes are necessary.

Top of page

Define Standards and Policies

This section describes how to best define the standards and policies to be employed within each category of the infrastructure. It is important to note that this iterative process (see Figure 9) is carried out for each of the categories defined in the infrastructure environment. It includes a discovery exercise to be carried out within the organization to determine the current status of standards and policies within each category and to find out if any activities within the category are currently regulated.

This exercise has as its goal the identification of three elements:

•	Existing standards and policies
•	Infrastructure changes currently underway (to which no standards yet apply)
•	Proposed changes being developed (to which no standards and policies yet apply)

The output from this exercise is used to decide the best-fit standards and policy solutions for the category. This decision-making process will involve all relevant parties who can contribute to the definition of new or modified standards or policies. The defined standards and policies are then documented and stored in the CMDB as configuration items.

Figure 9. Process flow for defining standards and policies in an infrastructure category
See full-sized image

Select the Infrastructure Category

To begin the standard and policy definition process, select one of the infrastructure categories. It may be useful to make this decision strategically since areas that have the most impact on the organization can assist in demonstrating the benefit of the IE SMF. Thus, you may wish to select categories for initial policy and standard definition where you expect to see the most benefit from the outset. For example, you may choose to develop a policy for the use of change management first since this affects all business and IT areas. In another organization, perhaps one experiencing rapid growth, it might be more important to develop standards for the corporate desktop configuration and deployment process.

As the definition process continues, subsequent categories may be selected by the IE manager based on other criteria— for instance, available resources, skills, impact, or cost. In any case, since business benefit is the overarching objective of service management, it would be sensible to base decisions on the realization of financial and business benefits.

Review Current Standards and Policies

Within a given category, the previous investigation process may have documented a variety of different standards and policies. Some of these may overlap or conflict; in other areas, the existing standards may leave gaps. The objective of this standards review is to develop a unified view of the existing infrastructure standards and compare it with the desired scope of standardization decided upon previously. In the process, the review group will apply input from the subject matter experts, representing the stakeholder groups, to make appropriate recommendations. The goal of this exercise is identify:

•	Obsolete standards to delete or update.
•	Conflicting standards subject to deletion or merger.
•	Out-of-scope standards to be eliminated from further consideration.
•	Gaps that require the development of new standards.

Review Proposed Changes for the Category

In the previous activity, you essentially developed a plan for consolidating and upgrading your existing IT standards and policies. Now it is recommended that you “future proof” this proposed effort by examining any changes currently in the pipeline, whether in development or underway elsewhere within the change management process.

New initiatives might indicate a move away from a certain technology solution or software product—for example, migrating to Microsoft Windows® XP or moving from Lotus Notes to Microsoft Outlook®. New projects might also be underway—for instance, to consolidate all desktop computers to a common build or to move to a new location that uses wireless technology.

The change management process, in conjunction with the CMDB, identifies all changes in the system for the category. It is also useful at this stage to judge whether these changes have been outstanding for a long time or are more recent because they might become useless if there is a decision made to use a specific policy or standard for the category. For instance, a change might have been requested, but not yet authorized, to implement a printing solution using a new version of a technology, but 90 percent of the organization is found through the discovery exercise to be using a different technology. This information might be sufficient to alter the change request to a pending status until the decision on the IE policy is made.

Another example might be the development of policies within service monitoring and control to monitor certain network functions and to write a detailed set of policies to do so, only to find that these would be quickly superseded by the installation of a new Management Pack for Microsoft Operations Manager (MOM). Future proofing allows you to avoid the wasted expense of developing standards and policies for infrastructure that is due for significant alteration, or even abandonment, in the near future. If you determine that a category is in the planning stages for migration to a new system soon, for example, you might elect to postpone further preparations to control that category.

The development life cycle will also be able to advise, through the change management process, of any changes to the infrastructure category that are in development, under research and vision scope, or due for imminent release. This information allows IE to build up a picture for the category on what is happening not only in the present, but what can be expected to happen in the short- to medium-term future. The more information available, the easier the decision should be for defining the best way to move forward. Approvals made as part of the change and development management processes should ensure that requested changes are cost justified and well documented before being authorized to continue.

Review Strategy and Planning for the Category

In addition to reviewing changes and development projects in progress, it is also useful to review strategy developments for the future. For instance, the business organization may have a strategy to outsource a telemarketing team within three years; this would affect the standards applied to long-term voice and data solutions. This strategy would obviate the need to update telephony solutions for this area of the environment. Similarly, a decision to move to a wireless technology, with an expected 40 percent increase in the number of telecommuting employees, would necessitate new requirements for the network category in the future and a corresponding reduction in investment in office-bound desktops in favor of mobile solutions.

A primary role of IT, and IE specifically, is to ensure that the IT infrastructure can enable business innovation and provide functionality to take advantage of market opportunities whenever possible. Tracking this type of strategic decision making requires that IE be recognized as a key stakeholder by the strategic business and IT decision makers in the organization. As the benefits of an effective IE process become apparent, it should be easy to gain the necessary buy-in from the senior level to share in this information.

Define Standards and Policies for the Category

Once there is an understanding of the existing, future, and strategic influences on the infrastructure category, it is then possible to define the standards and policies relating to that category.

Previous work has defined what standards and policies, if any, exist at present. It has also highlighted recognized conflicts and needed updates or deletions. Change records and development plans define the future for the category in the medium term, and the strategic plans for the business define the requirements for the category in the long term.

The standards and policies that are defined become the tools IE uses to progress from the current state to the desired state.

What Is a Standard?

A standard typically describes objects within categories. It is defined as something established by authority, as a model, example, or a rule for the infrastructure component or category. For instance, a standard for the change management category might be the minimum requirement documentation for an RFC, including the format in which it is submitted. A standard for vendor management could be a vendor contract template, and a standard for COTS software could define the minimum requirements for compatibility with other in-house products. Typical standards within an organization include the hardware specs and configuration for a data center server or desktop computer. An example of a server standard is supplied in Appendix F.

The standards for each category are likely to be more numerous than the policies for each category because they are more tactical. Standards are created with the current environment in mind and with an eye on the future. For instance, a standard requirement for a desktop build might take into account what is needed currently, but it might also include the capacity to integrate wireless technology if there is information from the strategic directions group that this is going to be developed in the future. Standards allow a structured and controlled approach to operating, changing, supporting, and optimizing the categories in the infrastructure environment.

What Is a Policy?

A policy differs from a standard in that it is a defined management course or method of action to guide and determine present and future decisions. It is created to embrace the general goals and acceptable procedures of an organization. A policy can be a corporate-wide one, such as, “No political e-mails will be sent using corporate resources,” or a department-specific one, such as, “All purchase orders for equipment over $20,000 must be approved by the general manager.”

Policies in IE, in simple terms, describe processes applied within categories. For instance, a policy for change management processes would describe how those processes are used in the organization; a policy on vendor management would define how vendor management processes are used in the organization; and a policy on commercial off-the-shelf (COTS) software would define how to use processes for COTS software in the organization. These policies are attached to the infrastructure categories that have been defined and act as the defined management actions for best practice control of the infrastructure environment. They are created in line with the requirements of the infrastructure now and in the future. Examples of typical policies are provided in Appendix D.

Defining the Best Standard

As described earlier, standards answer the following tactical questions for the infrastructure category: “What are the ways we want the category to operate in our infrastructure environment, and how can we ensure the functions in that category are managed and controlled as we expect them to be?”

Each category is likely to contain multiple standards at the outset, depending on its scope—for instance, security requires standards for dealing with security for users, data, network, infrastructure, specific solutions and services, and specific locations. Standards might already exist within SMFs or other functions already deployed in the organization. During the discovery phase, these standards will have been exposed; in this phase of the process, a decision is made for which, if any, standards or policies should be retained as-is or with modification. In some cases, similar standards from complementary organizations might be merged. In other cases, a particular location might require a separate standard that is applied locally, although these decisions should be based on careful analysis to ensure that a disparate standard won’t ultimately incur added expense and maintenance overhead. Table 3 shows some examples of standards that might be applied within categories associated with the MOF Infrastructure Role Cluster.

Table 3. Examples of Standards for Selected Infrastructure Categories

MOF Team Model Role Cluster	Infrastructure Categories	Standard Examples
Infrastructure	Workforce Management	Job descriptions and requirements for defined job categories Compensation model for system engineers
Infrastructure	Resource Planning	Acceptance testing reporting format
Infrastructure	Capacity Management	Default topology for capacity modeling MOM agent configurations to report performance metrics
Infrastructure	IT Service Continuity Management	Standard backup requirements for e-mail server Backup requirements for file servers Hardware specifications for backup tape drives

The discovery process might have identified a range of standards that all apply to the same category. In this case, it must be decided by input from the key stakeholders which are the best standards to apply for now and the future. The discovery exercise will also likely discover gaps where standards and policies do not currently exist but would be beneficial; these should typically be created by the subject matter experts in that field with input from other stakeholders, best practice advice, and the business strategy for use of that infrastructure category.

Microsoft IT and Standardized Server Platforms

In some cases, standards might not be applied as a set of specifications, but as a complete customer-oriented solution. For example, the Microsoft internal IT organization has adopted an effective approach to the standardization of data centers. Through a recent platform standards initiative, the IT group develops, tests, and delivers standardized Microsoft baseline server platforms called IPAKs (Microsoft IT Service Packs). These are created for Microsoft Windows Server™ 2003, as well as for SQL Server. IPAKs are issued every two quarters, and combine current version server software with all current hotfixes and patches. These configurations are thoroughly tested by the IT group and offer assured reliability to customers upon installation. For customers, this significantly reduces the complexity of installing patches on a regular basis.

Microsoft IT offers a sliding scale of support to internal Microsoft customers based upon the level to which the customer has adopted the IPAK standards. Between releases, Microsoft IT provides full support to customers running either of the two most recent IPAK releases. Older versions are supported on a “best-effort” basis.

Interim patches and fixes between IPAK releases are integrated into subsequent releases of the IPAK. Users may wait until a new IPAK release or may incorporate approved stand-alone patches into their own server. In either case, the IT group will provide full support to the extent of their service level agreement.

Whatever the situation, the standards are created with input from functional area subject matter experts, MOF Team Model role clusters, external benchmarks where appropriate, and business need and cost. No element of the infrastructure really stands alone; each standard must take into account the interacting infrastructures and the larger strategic picture. That is, all elements of the infrastructure link together effectively to support the business, complementing and enabling it.

Defining the Best Policy

As mentioned previously, there should be fewer policies than standards for a given category since policies tend to operate at a higher level than the more prescriptive-level standards. Occasionally, more than one policy for a given category may be necessary—for example, where multiple regions within an organization use different strategic partners for a product, there might be a policy for purchasing a product in each different region. Similarly, geographically separated branches may require different policies to accommodate variations in governmental regulations or operating requirements. However, since the goal is to create a consolidated and strategic set of solutions, too much variety in policies should not be encouraged since it might affect the potential cost savings and repeatability of a solution.

In defining the best policy for the organization, the following inputs should be considered:

•	Existing policy and documentation
•	New information that might become available through change management processes or development initiatives
•	Strategic information for the long-term plan
•	Information and recommendations from subject matter experts, internally and sometimes externally
•	Other SMFs or role clusters that might need to be informed

Through the consolidation and collation of all this information by the IE SMF, a best-fit policy can be created for control of the category or portions of the category. The best-fit solution needs to address:

•	Budget: Cost justification and approval.
•	Timescales: Present and future.
•	Potential risks and issues from choosing the policy.
•	Technology: Impacts on the targeted category and on other related technology within the infrastructure.
•	People: The skills and resources available to develop, implement, and support the defined policy; the buy-in needed to utilize the policy; the benefits to people of using the policy; and how people will react to the policy.
•	Process: The process or processes to which the policy applies and by which it interacts with other processes.

The decision-making process for defining the best policy can utilize any strategic decision-making tools and methods at the organization’s disposal. In most cases, individual standards or policies will be assigned to a subject matter expert, who is responsible for delivering a complete standard or policy to the IE manager, who then distributes it to stakeholders for feedback prior to final approval. Table 4 provides examples of some specific standards and policies that might be implemented within operations categories. Similar tables should be developed to plan the development of standards and policies in the other categories established for your organization.

Table 4. Examples of Policies for Selected Infrastructure Categories

MOF Team Model Role Cluster	Infrastructure Categories	Policy Examples
Operations	Network Administration	Announcements for scheduled system maintenance Non-business use of computers Assignment of IP addresses Troubleshooting procedures Network hardware procurement
Operations	Job Scheduling	Applying job scheduling
Operations	Storage Management	Storage device maintenance policies File name conventions

The level of effort applied in developing a policy will reflect the importance of its category. For example, a policy for a high-profile category, such as data integrity within a banking organization, will require a precise definition, might be very complex, and will require input from accountable parties throughout the organization. This might include input from legal departments on the official requirements and from technical staff on the capabilities of their components to deliver a secure solution. This policy will be a critical one for this organization. It must be carefully cost analyzed and evaluated to ensure consistency with future strategies, and it must be approved at a very senior level. Conversely, consider a policy related to the process for disposing of old toner cartridges: this is less likely to require the same sort of inputs but could still be cost effective for an organization if recycling opportunities and cost savings are explored. If the organization uses the best-fit solution, strategic input, and cost benefit for selection of the policies for each category, it should obtain the longest usability, highest supportability, easiest operability, and best functionality.

The creation and use of policies in the infrastructure environment will likely result in realizing at least some, if not all, of the following benefits:

•	More integrated strategic planning and reduction in piecemeal contracts.
•	Better decision making in the purchase of products with reasonable shelf lives.
•	Better value for money invested.
•	Better cost management through effective purchasing and use of strategic solution providers for enterprise-wide solutions.
•	Better retention of skilled staff, thereby reducing training and recruitment costs.
•	Improved consistency in making infrastructure choices. More appropriate usage of infrastructure resources.
•	Service improvement through integration of service management policies.
•	Higher confidence in supportability and operability.
•	Lower effort required in administration.
•	Simplified and repeatable deployments.
•	Better-integrated applications.

Publish Standards and Policies for the Category

The defined standards and policies are truly valuable for the organization only if they are accessible and easily understood. For this reason, attention should be paid to the most effective method for publishing and publicizing the standards and policies to the target audiences who need to be aware of them. A common means for publishing standards and policies is through a widely publicized internal Web site or knowledge base. To achieve maximum benefit from this type of distribution, it is important to consider that the potential audience includes non-technical business users and to present the Web content so that all users can easily understand it. An alternative to a Web site would be to publish the standards as content within an intranet-accessible knowledge base. In the case of MSN, an intranet site was built that not only publishes approved standards, but manages the change process for proposing, approving, and adopting new standards.

Other alternatives for publishing standards include CD/DVD or hardcopy distribution. For all distribution mechanisms, it is crucial to synchronize the published content with the most current version of standards and policies written to the CMDB. If direct links are not made to the CMDB to refresh the content on Web sites or knowledge bases, then a manual or semi-automated refresh must be scheduled on a regular basis: this could be weekly, monthly, or quarterly depending on the number of changes made.

By making all the standards and policies accessible to the entire organization, you create an open arena and minimize the risks often caused by lack of awareness of specific system requirements. You also make known the requirements for interfaces among other systems within the infrastructure. It is useful to note that misinformation is prevalent in organizations; these standards and policies represent correct information that people have been waiting to have made public. Once the standards and policies are published, they are likely to become widely used, thereby making future updates and contributions to change or adding standards and policies even more likely.

Add Standards and Policies to the CMDB

Once the standards and policies have been defined and accepted for publication, they should be added to the CMDB. This ensures that the documented standards and policies are under the same change control as any other configuration item; it also means they come under the standard review process for CIs.

The benefit of adding the standards and policies to the CMDB does not end with change control. It allows relationships to other standards and policies to be indicated and associated, and these links also can be applied to other CIs. This mitigates the risk of solitary action taking place, for instance, on a standard that could affect entire sections of infrastructure policy. This demonstrates further control of the infrastructure and shows the benefit of taking the full service management approach to the IT organization.

The CMDB is accessible in read-only format for most users (except for the configuration manager and administrator, who retain full privileges). If the CMDB is reportable and understandable by the business, it might not be necessary to maintain a published version of the standards and policies; instead, access to the CMDB can be given to all who need it. However, if the CMDB is complex in approach, the standards and policies content could be linked to published policy on an intranet or other easily accessible source. This would be of particular benefit to the business and facilities organizations as they might need a business-friendly, non-technical reference to the standards and policies to apply in managing business projects and facilities.

Summary

The following list summarizes the important points discussed in this section.

•	Prioritize the definition of standards and policies on the basis of greatest benefit to the organization. Early wins will help develop credibility.
•	Baseline the current infrastructure, including existing standards and policies, for future reference.
•	Review plans and strategies for future projects and initiatives to prevent rapid obsolescence of newly created standards and policies.
•	The complexity of standard and policy definitions correlates to their complexity and potential effect on the organization.
•	Rely on appropriate roles and SMEs in creating standards and policies.

Top of page

Apply Standards and Policies for Infrastructure Guidance

Ordinarily, proposed changes for development or deployment will fall within the norms of the established standards and policies; the process by which these are applied is described within this section. There are times, however, when a proposed change requires special considerations that will result in an exception to the established standards and policies. In addition to the normal process, this section also examines in more detail how these exceptions can occur and what actions can be taken by the infrastructure engineering manager to deal with them when they arise. Figure 10 illustrates the normal process for the application of policies and standards and shows where exceptions to the process branch into a separate task loop.

Figure 10. Utilizing policies and standards to control the infrastructure
See full-sized image

Propose Infrastructure Change

Proposed changes to the infrastructure may arise for a variety of reasons. Microsoft Solutions Framework (MSF) provides considerable detail about the envisioning process for new development and deployment projects. As the project plans begin to solidify, the team must consider what services and components of the infrastructure will be affected and identify the applicable categories of standards and policies that must be referenced.

For example, new projects and development initiatives will apply the standards and policies when reviewing their limitations and scope in the context of developing their new solutions. Facilities may want to check minimum power requirements or security policies for certain infrastructure categories. Any changes, additions, removals, or new developments and projects will need to utilize the standards and policies for the infrastructure category they will affect.

Proposed changes to the IT infrastructure follow a prescribed process in MOF, as described in the MOF Change Management SMF. As proposed changes progress through this process, they are guided by MSF principles for project management as well as MOF guidance to ensure they will be operable in the production environment. The MOF Change Initiation Review, a major MOF milestone, is the first scheduled review of proposed changes to ensure that they are in compliance with approved standards and policies. The Change Initiation Review is one of four Operations Management Reviews, which are described in more detail in the MOF Process Model white paper available at http://www.microsoft.com/mof.

Review Applicable Standards or Policies

When an infrastructure change is contemplated, the applicable policies or standards can be accessed from the CMDB, the IE manager or, more likely, through the published source (for instance, an intranet Web page). In some cases, the IE manager or a designated SME may provide assistance in applying the standard to a proposed change.

Is This an Exception to the Standard or Policy?

What is an exception? An exception is a process, event, or acquisition to which the established rules do not apply. These should rarely appear since the IE manager has ensured that there has been input from the change, development, and strategy groups during the process of defining the policies and standards, but there may be occasions when a genuine exception may occur, in which case it will follow the exception process illustrated in Figure 11.

Apply Standard or Policy to Change or Requirement

If the proposed infrastructure change is not an exception, the process continues with the incorporation of the specific standards into the requirements for the proposed change. Regardless of the nature of the change and its eventual application, it should be in compliance with the standards and policies established for that infrastructure category, exceptions notwithstanding.

Full Plan or High-Level Plan Required?

The extent to which policies and standards are included in a potential change depends entirely upon the nature of the change and its relevance to the scope of the regulated infrastructure. If it is a minor or standard change, then it may only need a sign-off within the change management process that affirms that the standards and policies have been used, similar to confirmation that the CMDB has been consulted to evaluate the impact of any proposed change. However, if it is a bigger change or development project, then standards or policies may contain specific design, build, or process elements that must be replicated within the project plans.

The results of the consultation will be that the change, addition, or development will in effect be planned according to the standards and policies in the IE SMF, although this checkpoint actually occurs outside of this SMF in the Change Initiation Review.

Exceptions to the Standards or Policies

As explained previously in this section, there are situations where established standards and policies may not directly apply. These are exceptions. Although an organization may maintain a set of standards or policies for a particular process or object, depending on the stage it occupies in the life cycle (as in the example of MSN with its set of standards for new, current, and departing technologies), sometimes an organization must also set up procedures for handling exceptions to the established standards and policies. Figure 11 describes a process flow that reflects best practices derived from the MSN process for dealing with exceptions.

Figure 11. The exception process
See full-sized image

Exception to Standard or Policy Arises

When an exception arises, it is a requirement that does not appear to fit within the rule specified in the existing policies and standards. Why the proposed change is an exception needs to be confirmed before action can be taken. As mentioned earlier, if the IE SMF is running effectively and there have been strong relationships built with the other SMFs and the business, development, and strategy groups for the organization, then exceptions should be rare. In some cases, exceptions may evolve into new policies or standards as the IT infrastructure progresses through its life cycle.

Is the Exception the Result of a New Strategy?

If this is a new strategic direction, it should have been revealed through the relationship between the IE manager and the associated business strategy group. However, there may be occasions when a change in strategy might not be identified before a change is needed.

For example, a merger or acquisition of another company or hostile takeover bid could affect the policies and standards and change the requirements. A political or legal issue could also result in an exception if the contents of the new regulation have not been disclosed before being promulgated. Economic and political changes external to the organization could change the policy—for instance, shifting exchange rates could affect outsourced offshore services or a volatile political climate could affect the import and export of products or services.

Confirm Strategy for Infrastructure Category and Validate

If the exception is proposed as a new strategy for the organization, this must be confirmed with board-level representatives, subject matter experts, and the relevant SMFs (if required) and validated as a genuine exception to the existing policies and standards. If it is not a valid exception when confirmed with the higher level, then it is returned to the initiator with the explanation as to why it has not been accepted as a strategy change. There may be other reasons why the exception should be accepted, but these must be resubmitted to the IE manager following rejection from the board.

Is It a Valid Exception on Other Grounds?

Even if the exception request is not the result of a new strategy direction, there may be other reasons for allowing it. For instance, a third-party vendor or outsource partner might go out of business, leaving a gap in the supported infrastructure that must be quickly dealt with to ensure service continuity. As with a new strategy, changes can occur outside the organization on a legal, social, political, or environmental basis that have not been foreseen and which can constitute a genuine reason to institute an exception to the infrastructure policies or procedures. Security could be impacted by a new virus, and patch software from a non-standard organization may mitigate the risk, for instance. As another example, if a desired new technology is released, it may be necessary to establish a new lab to work with it before existing standards may be modified to reflect necessary changes in architecture or hardware requirements. In this instance, new hardware requirements, outside of existing standards, may also require exceptions to purchase and vendor policies if the equipment is not available through established channels.

Is It Cost Justified?

Even if it is a new strategy or an emergency exception to the existing policies and standards, the exception must still be cost justified. The benefits of the exception being allowed to proceed must be higher than potential costs, not only to the budget but also in the potential risk to the infrastructure caused by moving outside established policies and standards. This cost justification is carried out as it was in the initial stages of defining the policies and standards, although it may be fast tracked if required, with key individuals reviewing the exception and using a quorum to authorize it.

Approve the Exception

If the proposed exception is cost justified and accepted by the key individuals in that infrastructure category, SMF, or role cluster, it may then be approved. The exception may still need budgetary sign-off at the board level to implement it, and it must now be determined if any existing policies or standards need updating to reflect the changes introduced by the exception. The exception should also be assigned an effective duration in order to establish how long it may be used and when it should be re-evaluated for consideration as a standard or for retirement. This process can be fast-tracked, but it is important to recognize that any inputs for an emergency exception are as important now as when creating the original standards and policies. Key individuals still must look at the exception requirement and evaluate how it fits in with the current infrastructure environment and how it will affect other future strategies, changes, and developments.

Effect on Other Standards or Policies

If a new policy of standard is developed as a result of the exception, it is necessary to use the CMDB to reference related standards or policies and other infrastructure categories that may be applicable to the excepted one. It is not a certainty that an exception will trigger an update to the standard or policy—the exception may be a one-off isolated occurrence. However, exceptions may eventually require applicable standards to be rewritten or policies to be reconsidered. For instance, a policy to use a certain vendor would change if trust in that vendor was lost or if the vendor became unable to ship products without incurring extra costs for a variety of local reasons.

Most influences by which exceptions arise are likely to be external to the organization; otherwise their underlying cause would have been detected within the review, change, development, and strategy relationships the IE manager has built up with other areas.

Publish Standard or Policy and Update CMDB

The updated standard or policy is published and the CMDB is updated with the new version, including any updates to other related infrastructure policies and standards that may have been instigated by the change. Changes to the CMDB must also follow established procedures.

Summary

The following list summarizes the important points discussed in this section.

•	Avoid exceptions where possible. Careful planning and execution of standard and policy settings should avoid the need for most exceptions.
•	Treat exceptions as changes. They must be approved and cataloged just as standards and policies.
•	Justify exceptions by cost and business value.
•	Examine the effect of exceptions on related standards and policies.

Top of page

Maintain Standards and Policies

The previous section described how standards and policies are applied to changes that occur within the IT environment. This section describes how the standards and policies themselves should be managed. Standards and policies are stored as configuration items (CIs) in the CMDB; as standard changes they will follow the change process used for other CMDB changes, as described in the MOF guidance for the Change Management and Configuration Management SMFs. However, the review process for the standards and policies is presented here with additional detail to assist in effective maintenance of the collected standards and policies.

The standards and policies for each of the infrastructure categories should be reviewed on a regular basis. Reviews may be driven by changes to the existing policies and standards typical to the daily evolution of an organization, but it is also important to review the standards and policies that have not been highlighted or questioned by other changes or development projects. The timeline for reviewing the categories is entirely up to each organization and can be carried out by the role cluster responsible for input to the policy or standard or by the area with the most commonality to the category for the standard. For example, security standards and policies would be reviewed by the Security Administration SMF and Security Role Cluster, service desk policy and standards by the Service Role Cluster and, more specifically, the Service Desk SMF.

The process for the review is detailed in Figure 12.

Figure 12. Maintaining standards and policies

Review Current Infrastructure Category Standard or Policy

It is useful to periodically review and report on the existing infrastructure categories, standards, and policies. If there are policies and standards that have been the subject of much change and many exceptions, it might be useful to re-evaluate if they are still relevant to the organization and, if not, where the shortcomings in the communication processes led to the mismatch. Similarly, there may be policies and standards that have not been accessed or utilized, which might indicate they are not adding real benefit through their inclusion in the IE control model. At this point, it is also useful to check compliance within the infrastructure with the published standards, using such tools as Microsoft Systems Management Server (SMS) 2003. A sudden decrease in compliance could reveal the adoption of a non-standard patch or perhaps implementation of a beta product prior to acceptance as a standard. Such reviews are useful as a “reality check” on the contents and can either be carried out on a scheduled basis or can be performed when deemed appropriate by the Team Model role clusters.

Review Development Projects and Changes for the Category

As the IE SMF evolves within an organization, so should the relationships with the IT development function, the project management function, and the Change Management SMF. Few surprises should arise as a result of milestone reviews for project development since all projects will be using existing policies and standards in order to work through the change approval process. It is worth noting, however, that if any surprises do occur in the pipeline of future changes and infrastructure development, this indicates that communication channels may need to be improved between those responsible. Action should be taken to address this as soon as possible, or the organization will not benefit from the integrated service management approach into which it has invested time and resources.

Review Strategy and Planning for the Category

As with the change and development relationship, there should be few surprises arising from strategic infrastructure planning if the IE manager has been successful in gaining senior and strategy group endorsement of the value of the IE SMF. If the IE processes are being perceived as valuable, the strategy planning group should not only be utilizing them, but demanding the creation of new policies and standards. The information held by the IE SMF can expose to strategists where corporate areas of potential reusability exist, where various skills reside in the organization, and what their current IT capabilities are. This can all be used to instigate cost-effective strategies for managing the infrastructure environment. It is important to remember that communication between the business strategists and the IE team should be two-way, providing information and guidance in both directions.

Are There Changes to Policies or Standards?

If there are changes to the standards or policies following the review, these changes should be initiated and directed through the change management process for CIs and the CMDB.

Update Changes to Standard or Policy for Category

Once the changes are authorized and planned, they can be deployed in line with the change management process and updated to the CMDB.

Update Status of Standard or Policy

The status of the CI for standards and policies should be updated in the CMDB. The suggested status for standards and policies changed as a result of the review process is Reviewed; it is also suggested that other status markers for standards and policies be used in line with those already used in the CMDB—for instance, Current, Retired, and Exception.

Publish Reviewed Standard or Policy and Add to CMDB

Ensure that any reviewed policy is republished and publicized to the Team Model role clusters and other audiences that may use it. If it is used regularly and has been altered, it is important to highlight the changes to the regular users to avoid any unintentional use of an old standard or policy.

Summary

The following list summarizes the important points discussed in this section.

•	Perform regular infrastructure reviews to ensure that standards and policies stay applicable.
•	Update standards and policies to keep pace with organizational requirements, applying change management.

Top of page

Roles and Responsibilities

This section looks at the various roles and responsibilities within the Infrastructure Engineering SMF. It is important to note that the roles here denote groups of tasks to be performed and do not necessarily correspond to organizational job titles or specific individuals. The majority of effort expended in establishing and managing standards and controlling their application across the infrastructure will be performed by the MOF Infrastructure Role Cluster, with the select use of virtual teams.

Infrastructure Engineering Manager

The IE manager has a coordinating role in the IE SMF, similar to that of the role of the change manager in the Change Management SMF. The role involves some technical decision making for approval and rejection of standards and policies, but in general the IE manager does not need to be technically cognizant of all areas of the infrastructure. Although IT infrastructure and engineering skills should be assumed qualifications for this role, the primary skill of the IE manager is the ability to extract the best information from the input groups, subject matter experts, Team Model role clusters, and business and strategy groups in order to come to agreement over a best-fit solution for the business.

In order to function effectively over such a wide array of groups and responsibilities, the IE manager role must be situated at the correct management level to be heard and respected within the organization—by the business and development organizations alike. Individuals filling this role need to have authority to reject non-standard infrastructure changes or development projects, or at least have a defined escalation path to senior IT executive committee members if they do not have the authority themselves.

Figure 13. MOF Team Model role clusters
See full-sized image

Infrastructure Role Cluster

The Infrastructure Role Cluster has the quality goal of “management of physical environments and infrastructure tools.”

The roles within this cluster can perform many of the tasks reviewed in this SMF guide. The policies or standards within a particular infrastructure category will typically be assigned to their corresponding area of responsibility. For example, the standards and policies created for storage elements of the infrastructure will be part of a storage category, and the responsibility for input, maintenance, and updating of the standards will be carried out by those actively involved in the Storage Management SMF and Operations Role Cluster.

Top of page

Relationship to Other Processes

This section examines the relationship between the Infrastructure Engineering SMF and the other SMFs in MOF.

Changing Quadrant

There are three SMFs in the Changing Quadrant; the IE SMF provides key input to all of them:

•	Change Management
•	Configuration Management
•	Release Management

It is useful here to review the diagram (Figure 14) used at the outset of this document to illustrate the relationship between the Changing Quadrant and IE. The IE SMF controls engineering activities within the infrastructure, the Change Management SMF manages the infrastructure environment, and the Configuration Management SMF documents the standards and policies in use.

Figure 14. Relationship of Infrastructure Engineering SMF with Change Management SMF and CMDB
See full-sized image

Change Management

The Change Management SMF has a close relationship with the IE SMF. The change authorization process described in the Change Management SMF has become formalized into the Change Initiation Review OMR in MOF version 3. This process, culminating in a formal review, requires that the initiator of a change complete the change request in accordance with the requirements for a change of that type and infrastructure category. For any change, the RFC should either apply the existing policies and standards for the change documentation submitted at the Change Initiation Review, or otherwise follow the exception process. Even exceptions must follow the change management process and as such have an important commonality with the Change Management SMF.

The change management process is, in itself, a policy. Changes to this policy must themselves go through change management. The Change Management SMF provides input to the IE SMF in terms of future changes that may be in development as these may affect the standards and policies being defined. In addition to this directly related input, the Change Management SMF itself will define specific policies and standards. The creation of these is formulated by the Change Management SMF, but agreement and administration and alignment of these to other SMFs is coordinated by the Infrastructure Engineering SMF.

Configuration Management

As shown in Figure 14 above, the Configuration Management SMF stores the IE standards and policies as CIs in the CMDB and ensures they are under the same level of control and change management as the other CIs. The CMDB is a key source of information to the IE SMF during the setup activities, and the two are used in conjunction in preparing RFCs for change authorization. The CMDB holds all the information on the infrastructure categories, the services delivered by them, and the scope of their individual service components, so it is a valuable source of information in defining the scope and extent of the infrastructure environment.

It also facilitates, through its relational capabilities, the mapping of relationships between infrastructure categories, policies, and standards.

Release Management

The Release Management SMF contributes its own standards and policies to infrastructure engineering information on, among other categories:

•	Release build requirements.
•	Release acceptance criteria.
•	Release planning.

Release Readiness Review

This review, the culmination of the change management process, applies infrastructure engineering standards and policies to confirm that current and appropriate policies and standards for build and standards for releases to different infrastructure categories have been used in the change and release development.

Operating Quadrant

There are seven SMFs in the Operating Quadrant; each is a valuable contributor to the standards and policies in the Infrastructure Engineering SMF. These SMFs all utilize standards and policies in their operation of the infrastructure environment to ensure it is operated in a controlled fashion. The Operating Quadrant SMFs are:

•	System Administration
•	Service Monitoring and Control
•	Network Administration
•	Directory Services Administration
•	Security Administration
•	Storage Management
•	Job Scheduling

System Administration

The System Administration SMF contributes to the Infrastructure Engineering SMF standards and policies pertaining to the day-to-day administrative services that support the infrastructure environment and business functionality. The System Administration SMF guides the other SMFs in the Operating Quadrant and, as such, has a coordinating role in the use of standards and policies throughout operations. While the Infrastructure Engineering SMF is largely responsible for ensuring that IT standards and policies are applied in the development of new additions or changes to the infrastructure, the System Administration SMF fulfills a similar role in applying these to daily operations.

The system administration manager plays a key role in defining how administration services are provided and executed within the scope of the infrastructure environment—for instance, defining if the standard is centralized administration, remote administration, delegated administration, or distributed administration.

The System Administration SMF also uses the documented policies and standards input from other SMFs, role clusters, and infrastructure categories to ensure the integration and effectiveness of their own system administration solutions.

Service Monitoring and Control

Through the use of processes and technology, the Service Monitoring and Control (SMC) SMF allows operations staff to observe the health of an IT service in real time. SMC creates and uses policies for monitoring the services available and ensures that it is monitoring those services within the infrastructure environment. This activity adds real value to the business function. The standards and policies used by SMC in its monitoring function include, among others:

•	Defined thresholds for services.
•	Escalation policies.
•	Response policies.

It also uses standards and policies related to other infrastructure categories to plan future SMC requirements, changes, and improvements.

Network Administration

The Network Administration SMF is responsible for the maintenance of the physical components that make up the organization’s network and as such is a key contributor to and user of the policies and standards of the Infrastructure Engineering SMF. The Network Administration SMF will contribute and coordinate input to policies for, as a minimum:

•	Network skills required.
•	Network management processes and procedures.
•	Network technology products and tools.
•	Approved network vendors and service providers.

It will also develop standards, with other SMFs (if necessary) for, among others:

•	Managing network faults.
•	Modification and expansion of the network.
•	Security of the network.

Directory Services Administration

The Directory Services Administration SMF is tasked with ensuring that data is accessible when it is needed by the authorized party. In this context, it is key for this SMF to use policies and standards, and it contributes to the definition of policies and standards in the areas of:

•	Directory standard types.
•	Network operating systems.
•	Special purpose directories.

As directory services deals with the day-to-day operation, maintenance, and support of the enterprise directory, it also provides input to and utilizes information from the Capacity Management SMF and other SMFs for standards and policies relating to other infrastructure categories.

Security Administration

The Security Administration SMF ensures a safe computing environment; policies and standards are key to its success in this endeavor. In defining a set of repeatable and strong security policies and standards for use across diff

Service Management Functions

Infrastructure Engineering

On This Page

Executive Summary

Introduction

Document Purpose

Audience

What’s New?

Feedback

Infrastructure Engineering Overview

Goal and Objectives

Scope

Capabilities

Key Definitions

Processes and Activities

Process Flow Summary

Process Flow Steps

Define the Infrastructure Environment

Collect and Define Policies and Standards

Apply Policies and Standards for Infrastructure Guidance

Maintain Policies and Standards

Define the Infrastructure Environment

Document Infrastructure Environment

Locations

Technologies

Sources of Information

Service Catalog

Configuration Management Database

Definitive Software Library

Published Documents or Files

Contracts Database

Create Guidance Categories

Define the Scope of IE Guidance

Standards Life Cycle

Standards Versioning

Special Considerations

Summary

Define Standards and Policies

Select the Infrastructure Category

Review Current Standards and Policies

Review Proposed Changes for the Category

Review Strategy and Planning for the Category

Define Standards and Policies for the Category

What Is a Standard?

What Is a Policy?

Defining the Best Standard

Microsoft IT and Standardized Server Platforms

Defining the Best Policy

Publish Standards and Policies for the Category

Add Standards and Policies to the CMDB

Summary

Apply Standards and Policies for Infrastructure Guidance

Propose Infrastructure Change

Review Applicable Standards or Policies

Is This an Exception to the Standard or Policy?

Apply Standard or Policy to Change or Requirement

Full Plan or High-Level Plan Required?

Exceptions to the Standards or Policies

Exception to Standard or Policy Arises

Is the Exception the Result of a New Strategy?

Confirm Strategy for Infrastructure Category and Validate

Is It a Valid Exception on Other Grounds?

Is It Cost Justified?

Approve the Exception

Effect on Other Standards or Policies

Publish Standard or Policy and Update CMDB

Summary

Maintain Standards and Policies

Review Current Infrastructure Category Standard or Policy

Review Development Projects and Changes for the Category

Review Strategy and Planning for the Category

Are There Changes to Policies or Standards?

Update Changes to Standard or Policy for Category

Update Status of Standard or Policy

Publish Reviewed Standard or Policy and Add to CMDB

Summary

Roles and Responsibilities

Infrastructure Engineering Manager

Infrastructure Role Cluster

Relationship to Other Processes