As discussed in Chapter 1, knowledge of systems and processes 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. A systems administrator can benefit from the following types of knowledge:
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
As IT organizations have become more geographically dispersed and individual roles more specialized, IT roles tend to operate in silos, making it increasingly difficult to communicate relevant system knowledge across the IT lifecycle. Consequently, 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 this system-relevant knowledge and facilitate the communication and collaboration of this knowledge, which is required to improve the efficiency of the entire IT life cycle. 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.
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. 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, Microsoft aims to enable innovation in its products and from its partners in a number of major areas.
When creating mission-critical software, application architects often find themselves communicating with their counterparts who specify data center 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, Microsoft mitigates these differences by offering a logical infrastructure designer that enables 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.
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.
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.
Software models can capture an entire system's composition in terms of all interrelated software and hardware components. As a result, a system contains a specific description of the hardware requirements of the environment into which it will be deployed. This knowledge enables 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.
The software models in use today vary in complexity and capacity in terms of the types of knowledge they capture and how thoroughly they can describe the various aspects of a system. The MOM management packs are an example of one kind of model used today.
Starting with the work that Microsoft is doing in Visual Studio 2005 Team System, Microsoft and partner modeling efforts will focus on SDM as the core modeling technology. Much richer than today's modeling languages, SDM is a language, or metamodel, designed for capturing models of complex, distributed systems.