Microsoft Frameworks Integrated GlossaryThe Microsoft Integrated Glossary contains terms for: MSF - Microsoft Solutions Framework MOF - Microsoft Operations Framework MSPMO - Project Management Office
See change advisory board.
Preliminary or proposed, before being baselined or finalized, as in candidate components, services, objects, or technologies.
candidate project list
Compiled during the planning phase of the enterprise architecture, when determining which IT projects to undertake requires complex trade-offs in uncertain situations. The candidate project list helps IT planners to balance business needs and goals against technological possibilities and risks and prioritize projects for a versioned release of the enterprise architecture.
A MOF service management function in the optimizing quadrant. The process of describing, managing, directing, and proactively maintaining the capacity of information and supplied services in accordance with agreed quality performance levels and processing capacity at reasonable cost.
Note The IT Infrastructure Library (ITIL) also uses this term to connote a similar meaning and process. MOF uses the underlying ITIL characterization as a foundation and then extends it by incorporating partner experience and Microsoft-specific features. For the specific ITIL definition, please consult the ITIL glossary, located at the time of publication at the ITIL Web site.
The process of forecasting system and environment utilization and workloads and then developing plans to ensure that the system and environment will be able to support anticipated performance demands.
Classification of a group of configuration items, change documents, or problems.
See Central Computer and Telecommunications Agency.
Central Computer and Telecommunications Agency
A United Kingdom government executive agency chartered with development of best practice advice and guidance on the use of information technology in service management and operations.
The addition, modification, or removal of approved, supported, or baselined hardware, network, software, application, environment, system, desktop build, or associated documentation.
change advisory board
A group of people representing service delivery and support functions who are responsible for assessing, planning, and authorizing changes to the IT environment. This board is a key component of a formal change management process and is likely to be made up of representatives from all areas within IT and representatives from business units.
Principles and processes that facilitate the management of change without compromising the quality or integrity of an IT project or solution, through structured procedures for submitting, approving, implementing, and reviewing change requests.
Auditable information records that describe what was done, when it was done, by whom, and why.
A log of requests for change raised during a project, showing information on each change, its evaluation, what decisions have been made, and its current status, such as raised, reviewed, approved, implemented, or closed.
A MOF service management function in the changing quadrant. It employs the practice of administering changes with the help of tested methods and techniques in order to avoid new errors and minimize the impact, if any, on the agreed IT service levels in accordance with service level agreements.
A record containing details of which configuration items are affected by an authorized change (planned or implemented), and how.
The first quadrant in the MOF process model where a new release is prepared and then released into production. The changing quadrant starts with a release approved review to determine if the release is ready for implementation in the target environment and culminates in the release readiness review in which the release is assessed for effective implementation.
Examples of changing quadrant activities include:
- Verifying the readiness of the release.
- Verifying the release functionality in the physical environment.
- Verifying the preparedness of the operations staff and processes.
- Creating and following through on the installation plan.
- Creating a contingency plan.
- Analyzing potential impacts on other systems.
See configuration item.
The lowest level at which identifiable items can still be uniquely distinguished.
Expressing the value of items by placing them in a certain order on the basis of category, impact, and urgency. Also, the process of formally grouping configuration items by type (for example, software, hardware, documentation, environment, application). Classification can be used to support decisions based on priorities.
Synonym for MSF product manager within an engagement.
The combination of software, hardware, and network components in which one or more clients (computers) request services from one or more servers (computers) and through which the computer network functions for the user as one computer.
When the customer is satisfied that an incident has been resolved.
See configuration management database.
Assessing code to improve its quality and the capabilities of the development team.
The relationship among different internal elements of an object.
A formal plan, usually a document, for how a project team will handle communications within the team and between the team and external entities.
A unit of application logic that delivers a set of specified services that can be accessed only through a published interface or interface contract.
The predefined part of a component that allows a component user to access component functions exposed at that predefined part.
Component Object Model (COM)
A language-independent, system-level object model that provides a standard way for components and applications to interoperate.
A component distribution map that indicates the location of components and their services in relation to the network topology.
A major stage in the design process, through which the project team translates the business requirements into a common language to be shared by users and developers, and describes the feature set and/or usage scenarios that the solution must encompass.
conceptual design baseline
The culmination of the research, analysis, and optimization steps of conceptual design.
A component of encryption. Confidentiality mechanisms ensure that only authorized people can see data stored on or traveling across the network.
Configuration of a product or system established at a specific point in time, which captures both the structure and details of that product or system and enables that product or system to be rebuilt later.
Activities that control changes to configuration items. They include evaluation, coordination, approval, or rejection of changes.
Documents that define requirements, system design, build, production, and verification for a configuration item.
A component of the IT environment (or infrastructure) that may impact the service level agreement if changed. A configuration item (CI) can be either a physical or a logical object and can be composed of other configuration items. CIs may vary widely in complexity, size, and type, from an entire system (including all hardware, software, and documentation) to a single software module or a minor hardware component.
A MOF service management function in the changing quadrant. It employs the process of identifying and defining configuration items in a system, recording and reporting the status of configuration items and requests for change, and verifying the completeness and correctness of configuration items.
configuration management database
A database that contains all relevant details of each configuration item (CI) and details of the important relationships between CIs. The database can include ID code, copy and serial number, category, status, version, model, location, responsibility, historical information about the item, and so on. The level of detail employed in this depends either on the aims or on the degree to which information is to be available.
configuration management plan
A document setting out the organization and procedures for the configuration management of a specific product, project, system, support group, or service.
A hierarchy of all the configuration items that make up a configuration.
When everyone on the team supports the teams decision without feeling they are compromising any important needs or values.
One of three key concepts in the Microsoft approach to managing project trade offs. In the trade-off matrix, constraining costs and resources requires a not-to-exceed strategy.
A nonfunctional requirement that places a limit or dictates a limited range of possibilities. For example, an infrastructure constraint.
An information source for scenarios. It provides background or a frame of reference.
A plan for addressing recognized risks that may arise during the course of a project. For development projects, the plan may, for instance, reallocate resources or drop features to react to an unanticipated change in schedule. For operations, a contingency plan provides details for an alternative system or manner of conducting business during an IT crisis.
Uninterrupted consistency and persistence of processes and the certainty that the processes will continue in operation. See also service continuity management.
A coherent whole characterized as a sequence or progression of elements. Hence, the design continuum describes a progression of design elements: in conceptual design, the scenarios; in logical design, the services and objects, high-level user interface, and logical database; in physical design, the components, user interface, and physical database.
The process of comparing actual performance with planned performance, analyzing variances, evaluating possible alternatives, and taking appropriate corrective action as needed.
One of the four strategies designed to extricate an organization from the IT abyss. Organizations in the IT abyss attempt to get all IT under control by setting funding targets for future application and infrastructure spending.
Addressing the results of risk tracking and the process as a whole.
Components of the solution that are deployed at a central location, rather than at individual sites.
core team organized interim milestone
The point during the envisioning phase at which the core project team has been formed and is ready to move the project forward.
core technology deployed interim milestone
The point during the deploying phase at which the team has deployed the selected technology at the central, or core, location(s).
A technological or procedural response to address a single point of failure or other threat to the availability of an IT service. Two examples are the use of redundant power supplies and the implementation of a proven database backup procedure.
The relationship of an object to other objects.
Used primarily during the developing phase, it attempts to thoroughly test every feature of the product and the code base of the product.
The series of activities that determines the duration of a project. It is the longest continuous chain of linked activities through a project schedule; a chain of activities to which no slack or float time is assigned. Delays in any of the linked activities will delay the entire project.
critical success factors
Activities, tasks, technology, funding, and milestone requirements that must be accomplished before an organization can reach its long-term goals and objectives. Similar to dependencies.
current state assessment
An assessment of the actual present-day status of the organization's business processes, applications, information stores, and technological support made during the planning phase of the enterprise architecture.
The recipient of a service (or product).
A best practice or principle of a successful team. It means committing to understanding and solving the business problem, focusing on the alignment of business and technology, and involving the customer throughout the process.