System Center management products, beginning with Operations Manager 2007, will make extensive use of software models for system health monitoring, configuration, and other purposes. These models, critical to Microsoft's Dynamic Systems Initiative (DSI), specify how to compare the actual attributes of system components against their desired attributes and fix differences. Although Microsoft has had success forming an industry group to standardize the language used to describe such models, it will have more difficulty getting the industry to agree on the next step: a common library of core models compatible with Microsoft's management software from which developers can create more sophisticated models.

The DSI Vision

The DSI is Microsoft's long-term plan to enable its vision of the so-called dynamic data center, in which the following occurs:

• Services and applications are decoupled from physical resources, allowing them to be run where they will use physical resources most efficiently, with optimum availability and performance, and without regard to specific makes and models of hardware
• Software automatically discovers hardware and software elements it needs to function and configures all required elements to comply with a configuration policy specified by the customer
• Software automatically senses when something goes wrong and either repairs itself or points IT personnel to the root cause and guides them toward the optimal solution.

To accomplish this vision on the Windows platform, Microsoft has outlined four prerequisites:

• Built-in Windows support for hardware virtualization, which will eventually allow applications to be moved from one physical server to another even while running
• System management products that work together to cover all aspects of the software life cycle, including capacity planning, change management, asset management, and health monitoring
• Hardware and OS and application software that have been purposely designed and instrumented for manageability
• Management models that contain the operational knowledge needed by the systems management infrastructure to manage all instances of hardware and software components in the data center.

While the first three points are fairly easy to understand, what exactly are management models?

Software Models Key to DSI

In the realm of software, most people interpret the word "model" to mean a software program that simulates a real-world process, such as a climate model or a macroeconomic model. However, when referring to the DSI, Microsoft is using a looser definition: "a simplified representation of something complex."

In the context of systems management, models are files that describe selected aspects of software or hardware elements at a level of detail sufficient for the management tasks for which the models were designed. Depending on the goals of the designer, these models can range from very simple to very complex. Each model describes a class of some type of managed component, which could be a hardware device, OS service, or application, or could be a composite entity involving multiple hardware devices, OS services, and applications.

A systems management model typically contains three types of information used to manage instances of a component:

• The component's expected attributes and behaviors, such as desired configuration settings, or target values for the status and performance data that have been exposed by the component's developer
• Where to read and how to interpret information revealing each component's actual attributes and behaviors
• How to restore deviations back to the expected attributes and behaviors.

Systems management models can contain any type of data, including parameters, scripts, and even text meant to be readable by humans. However, unlike computerized simulation models, the models themselves don't do anything; they are used in conjunction with management software that parses and uses the data in the model. It is the management software's job to test and detect the actual state of each component instance, compare the results against expected values contained in the model and, when needed, use instructions in the model to generate an alert or trigger some remedial or further diagnostic action.

Specific Types of Models

Three main management model types are or will be used by the following Microsoft products: Operations Manager 2007, System Center Essentials 2007, the upcoming Windows Server 2008 (code-named Longhorn), and two forthcoming Systems Center management products—Configuration Manager 2007 and Service Manager 2008. These model types are as follows:

Health models. These models specify how some element of a system ought to work when healthy, provide instructions on how to determine if the element is deviating from healthy behavior, and provide operational guidance and possibly automated recovery actions if the modeled element is unhealthy.

Configuration models. These models define how an element ought to be configured (based on criteria such as its role and relationships to other elements), describe how to determine an element's actual current configuration, and provide instructions for restoring it to the customer's desired configuration.

Discovery models. Discovery models define specific probing actions on devices—such as querying the Windows Management Instrumentation (WMI) repository, querying the Registry, or executing a script—that reveal whether the device is running an instance of the hardware or software component described by the model. Once an instance is discovered, management software can automatically apply the applicable health or configuration model to it.

Although Microsoft hasn't publicly said so, future versions of Capacity Planning Manager—a simulation tool that helps companies plan and optimize hardware resources by predicting performance bottlenecks and the effects of changes—might also use discovery models to automatically configure the baseline simulation scenario to reflect the customer's actual environment.

Other types of software models are possible. For example, Visual Studio 2005 Team Server introduced a design tool that generates dependency models for prospective applications. A dependency model can be compared with a manually specified logical data center environment model to see if the application's planned system requirements can be satisfied by the IT environment where it will be run. However, these models are used for communicating requirements between developers and system administrators during the planning and development phase rather than for managing operations.

Microsoft's Approach to Modeling

One could construct a monolithic model that described a specific implementation of a distributed application spanning multiple computers and networks, and that described all of the hardware, OS services, and auxiliary applications on which that application depended. However, this approach would not be very useful because it would take substantial effort to build, yet probably could not be reused in any other setting.

The key to practical models is to break them into standardized but extensible units. This approach allows larger models to be constructed from models describing a system's composite elements.

In Microsoft's approach to modeling, model designers build a particular model class or set of classes that define generic characteristics of the type of hardware or software component in question. These classes can be extended by other model designers to encapsulate additional information about the component. The management software then creates separate instances for each component it finds that matches the class. Those instances are managed using the model data.

However, for this approach to be successful, each component's model must use the same format and follow certain rules. Model developers need to record many types of operational knowledge in a form that can be read by the management software and that can be extended and customized without becoming unwieldy and impossible to maintain. These requirements and goals dictate a standardized model definition language and a standardized library of core models.

Modeling Languages and Libraries

Since 2003, Microsoft has been working to develop a new model definition language. Plain XML was a possible candidate, but the language for defining an XML document's structure—known as XML Schema—lacked certain capabilities needed by modelers. First, it's necessary to be able to break a model into multiple documents—for ease of maintenance and to have the capability of creating higher-level models from more primitive models, among other things. To make this possible, the language had to support references to elements in other model documents, which XML Schema cannot support. Second, XML Schema does not support certain types of arbitrary constraints on the structure and content of XML documents, which is important because modelers need to validate elements at a more granular level than XML Schema is capable of doing. For example, a model needs to be able to specify that an element tagged "IPv4 address" must have a value consisting of four one-byte numbers.

The solution was an extension to XML Schema that Microsoft originally called the System Definition Model (SDM). While initially a Microsoft-only effort, a larger working group—including BEA, BMC, Computer Associates, Cisco, Dell, EMC, Hewlett-Packard, IBM, Intel, and Sun—soon formed, and in Mar. 2007 a rework of Microsoft's latest version of SDM was submitted to the World Wide Web Consortium (W3C) for standardization under a new name: Service Modeling Language (SML) version 1.

Since SML is not specific to any single management product or vendor, it should lead to broad support and adoption from ISVs and IHVs.

Service Modeling Language

SML is an XML-based language for defining models of IT services and systems. An SML model is realized as a set of interrelated XML documents that describe a specific IT service or system. Note that SML does not define any particular management-specific modeling capabilities or even a particular schema; it merely defines the schema definition language. All this means is that once a model is created, the XML data in the model must validate against the SML-based schema declared in the model.

It is important to understand that SML alone does nothing to define higher-level entities, such as the concept of a process, computer, user, service, switch, or router, nor does it define any sort of layering structure (i.e., hardware, OS, middleware, applications), where elements in higher layers depend on elements in the layers beneath them. Although SML can be used to model these entities, they are not part of the SML specification.

For this reason, SML alone is not a practical starting point for most model builders. Rather, they need a set of common models (base classes) built with SML that they can extend and then combine into more sophisticated models. These common models are key to consistency, reusability, extensibility, and the ability to create composite models from component models.

Common Model Library

In Operations Manager (OM) 2007, Microsoft introduced a set of core model libraries (built on an earlier version of SDM rather than SML) containing base health, configuration, and discovery model classes for many standard types of entities (OS service, Web server, application, user, computer, switch, router, and many others) and defined the relationships of those entities with each other. In Configuration Manager (CM) 2007 (Systems Management Server 2003's successor), which is roughly six months behind OM 2007 in development, the base classes for its discovery and configuration models are built using SML 1.0.

Microsoft has defined four layers of entity types—hardware, OS and network, application hosts (middleware such as Internet Information Services [IIS] and SQL Server), and applications. Each layer can have dependencies on and constraints imposed by the layer beneath it.

As with the evolution of proprietary SDM to standardized SML, Microsoft is forming an industry working group to define a Common Model Library (CML) that will use an SML 1.0—based version of Microsoft's core model libraries as a starting point and drive the CML specification toward industry standardization.

Authoring a specific model for any given managed component begins by extending one or more core (and eventually CML) models. For example, models for Web servers such as IIS and Apache would be derived from the core Web server base class, and then extended to define characteristics unique to that particular Web server software.

But the extension and amalgamation of models doesn't stop here; IT organizations can take the models created by component vendors and use them to construct composite models that actually model their specific business applications or services.

Tougher Road Ahead

Although Microsoft's use of models for systems management is not new, no other vendor has tried to create industry standard models, and probably no other vendor, with the possible exception of IBM, has the influence and wherewithal to do so. Although it appears Microsoft and partners will be successful in getting SML ratified by the W3C, garnering consensus on the CML will be much tougher, since the CML is not as abstract as SML—it is much more concrete and specific to the actual designs of IT systems and system management products. Although Microsoft expects the other members of the SML working group to join the CML working group, as of May 2007 the constituent members had not been publicly announced.

In the meantime, as with SDM and SML, Microsoft is forging ahead with its own core library implementations in OM 2007 and CM 2007, which will mean that models developed for these products will undoubtedly have to be revised once a CML standard has been established. Microsoft believes that the differences will be small enough that this process will not be extraordinarily difficult, and much of it could be done with conversion tools.

Should the CML working group get bogged down or never get off the ground, Microsoft has been successful in garnering a sufficiently large customer base for its management products that it is likely to achieve some reasonable degree of success with CML on its own.

Unanswered Questions

The whole standardized management model approach still leaves behind many unanswered questions:

• How well will the current model framework be able to accommodate real-world scenarios?
• Even if the model framework is sufficiently powerful and expressive, will the models offered by Microsoft and third parties for their products be of sufficient quality?
• For ISVs, will models be like documentation—a checklist item where quick and cheap often trumps over quality?
• For corporate developers, will it be worth the effort to write models for code modules they write?

Getting Developer Buy-In

Microsoft can't do DSI alone; it will require an industrywide effort. Although Microsoft can build the virtualization capabilities and management products needed by DSI, designing software and hardware for manageability and building models requires commitment from Microsoft's partners and customers.

Although a systems management model can be built after hardware is designed or software is written, the person best suited to building a model is the developer of the component. Furthermore, models will be much more effective if the component is designed from the start to be managed according to a model. For example, in a "design for operations" approach (recommended in the DSI) the developer instruments his software to supply the data that will be needed by the discovery, configuration, and health models to compare the component's desired state and behavior against reality. The developer then builds the required management models himself.

However, although developers know best how their hardware or software ought to work, today they often have insufficient motivation or incentive to create models and instrument their code. Modeling and instrumentation impose significant cost and time penalties, so independent developers must be convinced that they will sell incrementally more product (or at least remain competitive) or improve customer satisfaction, while corporate developers must be convinced that operational cost savings will offset higher development costs and longer development cycles.

Getting developer buy-in would be easier if they knew that the models they create won't be bound to any specific management-software implementation. They would then have a larger pool of potential customers and greater independence from the whims of any one management software vendor.

Current development tools, such as Visual Studio 2005, aren't designed to automate instrumentation and modeling during product development, but eventually Microsoft plans to change that. Future versions of Visual Studio will give developers the tools to specify expected software functionality, behavior, instrumentation requirements, and data-center environment requirements before code is even written, and as code is written the development environment will automatically generate corresponding management models.

Resources

An in-depth analysis of OM 2007 can be found in "Operations Manager 2007 Explored".

Microsoft's System Definition Model white paper can be found at www.microsoft.com/business/dsi/sdmwp.mspx.

The SML specification is available at www.w3.org/Submission/2007/SUBM-sml-20070321 and more information can be obtained at serviceml.org.

A good Microsoft blog on SML can be found at blogs.technet.com/pratul.

Microsoft's DSI home page is at www.microsoft.com/business/dsi.