Moving Toward the Future: Dynamic Systems Initiative

Knowledge is a key component for systems management. This includes knowledge of the deployed systems, knowledge of the environment in which they operate, knowledge of a designer's intent for those systems, and knowledge of IT policies. Specifically, knowledge may include the following:

• Developer constraints on settings of a component, including constraints on related systems that the component is hosted on or communicates with

• IT policy that further constrains settings or deployments

• Installation directives that describe how a system is to be installed

• Health models that describe system states and the events or behavioral symptoms that indicate state transitions

• Monitoring rules, ranging from polling frequency to event filtering and forwarding to diagnostic or corrective action in response to problems

• Schemas for instrumentation, settings, events, and actions

• Service-level agreements that define performance and availability

• Transaction flows and costs of processing steps for performance analysis

• Reports

As IT organizations have become more geographically dispersed and individual roles more specialized, IT professionals tend to operate in silos focused on their area of specialization. This makes it increasingly difficult to communicate relevant system knowledge across the IT lifecycle. As a result, organizations find it very difficult to collaborate across roles, promote continuous improvement of a system's design and operation, and conduct typical management tasks such as deployment, updating, and patching.

The silos that form across IT organizations interact with an application or system at some point during its lifecycle. However, each silo possesses its own pocket of system-relevant knowledge that does not get communicated effectively to the rest of the organization.

Software models can be used to capture system-relevant knowledge and facilitate the communication and collaboration around this knowledge that is required to improve the efficiency of the entire IT development, deployment, and support lifecycle. A software model provides a level of abstraction for administrators similar to what a blueprint provides to an architect or a prototype provides to a product designer. But for a dynamic and distributed software environment, a static model or blueprint is insufficient. The model must be a living organism and should evolve throughout the life of a system. Having the right tools for systems management can help to keep these models current and enable users to have dynamic views of the system model based on an underlying operational system.

When a system is developed, basic rules and configurations are defined. As the system is deployed, the details of its configuration, environmental constraints, and requirements are added. As operational best practices are developed or enhanced, they can be incorporated into the model as well, providing a feedback loop between the operations staff and the model. In the end, the model becomes a live, dynamic blueprint that captures knowledge about a complete distributed system in terms of its structure, behavior, and characteristics. The following benefits can be gained as a result of these models:

• The system model captures the entire system's composition in terms of all interrelated software and hardware components.

• The system model captures knowledge as prescriptive configurations and best practices, allowing the effects of changes to the system to be tested before the changes are implemented.

• Tools that take advantage of the system model can capture and track the configuration state so that administrators do not need to maintain it in their heads. The software maintains the desired state so that humans do not need to.

• Administrators do not need to operate directly on real-world systems but rather can model changes before committing to them. In this way, "what if" scenarios can be tried without impact to a business.

• The system model becomes the point of coordination and consistency across administrators who have separate but interdependent responsibilities.

The modeling system becomes the integrated platform for design and development tools that enable the authoring of system models. It also becomes the platform for operational management and policy-driven tools used for capacity planning, deployment, configuration update, inventory control, and so on.

In Microsoft's initial implementation of the Dynamic Systems Initiative, the System Definition Model (SDM) is a foundational component of dynamic systems. SDM is a model that is used to create definitions of distributed systems. In this context, a distributed system is a set of related software and hardware resources working together to accomplish a common function. Multi-tier applications, Web Services, Internet web sites supporting e-commerce, and enterprise data centers are examples of systems. Using SDM, businesses can create a live blueprint of their systems. This blueprint can be created and manipulated with various software tools and is used to define system elements and capture data pertinent to development, deployment, and operations so that the data becomes relevant across the entire IT lifecycle.

Today, an SDM can be defined using tools available with Visual Studio 2005. Going forward, SDM will be the basis for design of system models, used to deploy systems based on the model defined and will be kept up-to-date by an SDM service that dynamically modifies the SDM to reflect the current state of operations. While the SDM will be incorporated into the Microsoft management solutions, third parties will also be able to develop solutions based on the SDM to extend the capabilities of these models and the tools that consume or produce them.

Several key capabilities of IT organizations and IT systems become possible when software models are used to capture all relevant system knowledge. Through the DSI efforts and SDM, Microsoft aims to enable innovation in its products and from its partners in four areas: Design for Operations, System-Level Management, Policy-Driven Operations, and Hardware Abstraction.

Design for Operations

When creating mission-critical software, software architects often find themselves communicating with their counterparts who specify data center and infrastructure architecture. In the process of delivering a solution, an application's logical design is often found to be at odds with the actual capabilities of the deployment environment. Typically, this communication breakdown results in lost productivity as developers and operations managers reconcile an application's capabilities with a data center's realities.

With new model-based development tools, such as Visual Studio Team System, these differences are mitigated by offering a logical infrastructure designer that will enable operations managers to specify their deployment environment and architects to verify that their application will work within the specified deployment constraints. These tools use software models to capture the knowledge of a designer's intent, knowledge of an operational environment, and knowledge of IT governing policies to ensure IT systems are designed with operations and manageability in mind from the start. The models described can be built using Visual Studio 2005 and then consumed by Microsoft management tools and any other third-party tools that are built to consume the models, which are based on an open specification.

System-Level Management

Models can capture the entire structure of an application, including all the underlying and interrelated software and hardware resources. Management tools, such as future versions of MOM, will use those models to provide a system-level view of the health and performance of that application, enabling administrators to understand the impact of changes or errors in the system and to manage the application more effectively.

This system-wide view will enable future versions of management tools, such as MOM, to perform robust health monitoring and problem solving, as well as end-to-end performance and service-level management.

Policy-Driven Operations

Models can also capture policies tied to IT and corporate governance, such as Sarbanes-Oxley compliance or basic security standards and operating system versioning. Management tools, such as future versions of Microsoft SMS, will use these models for desired-state management.

By comparing the model of the real-world state with the model of the compliance definition, management tools can make systems compliant before allowing them access to corporate resources.

Hardware Abstraction

Software models can capture an entire system's composition in terms of all interrelated software and hardware components. As a result, a system will contain a specific description of the hardware requirements of the environment into which it will be deployed.

This knowledge will enable new resource management technologies, such as Microsoft Virtual Server, to interpret these hardware requirements and to be used by management tools to ease the initial provisioning, ongoing change, or removal of hardware from an application based on changing business needs.