IT Operations Benefits
[This is prerelease documentation and is subject to change in future releases. Blank topics are included as placeholders.]
The code name “Oslo” repository enables IT to more efficiently organize data about server environments, applications, and related processes. The following list describes the type of IT operational data that can be stored in the “Oslo” repository and the benefits of using the “Oslo” repository as a central store for this data. In each case, the potential improvements include higher efficiency, greater accuracy, and increased discoverability of existing enterprise data.
The types of IT operational data that can be stored in the “Oslo” repository include the following:
Configuration data.
Application and performance logs.
Operational procedures and scripts.
Business processes.
Service directories.
Configuration Data
Enterprises often struggle to understand configuration data across large numbers of machines. This is especially true when that configuration information includes data about the operating system and applications running on those machines. To obtain this information, operations staff must look at multiple locations on each machine, such as the Windows registry, application-specific databases, and other configuration files.
The “Oslo” repository can store all types of machine and application configuration data. When consistently updated, this configuration data is a catalog of the current state of all monitored machines and applications in the environment. The “Oslo” repository is a SQL Server 2008 database, so discovering and using this configuration data is straightforward for both ad-hoc queries as well as custom applications.
For example, consider the need to distribute a software patch to only specific machines that match a target configuration. An IT professional could manually run an “Oslo” repository query to find the machines that match the desired configuration. Or a custom management application could programmatically query the same information to automate the task of targeting the correct machines and deploying the software patch.
Storing configuration data in the “Oslo” repository also assists with evaluating and maintaining compliance standards. Organizations can query the configuration data in the “Oslo” repository to:
Compare the configuration of machines against a vendor’s recommendation.
Verify the configuration of machines against custom baselines.
Remediate noncompliance through management events and custom update utilities.
Application and Performance Logs
Organizations often store application logs and general performance logs for the servers that host those applications. Sometimes it is difficult to correlate multiple logs or to associate events with a particular application component. Procedures for storing and finding these logs are also inconsistent.
The “Oslo” repository organizations to store this monitoring data alongside the applications that also reside in the “Oslo” repository. This provides a richer experience for analyzing the performance data. Recorded events can be associated with the specific application component that caused the events. Development teams also have an easier experience in using the data to improve future development decisions. For example, a developer might have a new Web part to add to a page on a corporate Web portal. He or she decides to run “Oslo” repository queries to look at the Web traffic that is directed at the target page. If the page receives 60% of the total traffic, the developer can use a better-performing Web part or place the Web part on a linked page. In this way, the “Oslo” repository helps users and tools to isolate current application issues and also prevent future issues by understanding the impact of a potential change.
Operational Procedures and Scripts
Organizations often have application-specific or machine-specific operational procedures and scripts. However, these procedures and scripts are sometimes stored in a separate location from their associated applications or servers. They might also be used to meet a Service Level Agreement (SLA), but that SLA can be located in yet another location. As a result, these procedures and scripts become hard to manage and discover.
The “Oslo” repository provides a more effective solution for storing operational procedures and scripts. The “Oslo” repository already contains models for applications and machines. Operations staff can store procedures and scripts in the “Oslo” repository database in the same logical area with these models and their related documents, such as business processes and SLAs. In this way, these procedures and scripts are much more easily discoverable and their location in the “Oslo” repository provides better context for understanding their purpose. They can also be versioned, backed up, and managed with other “Oslo” repository data.
Business Processes
Business processes often define best practices within an organization. The challenge is to document these business processes and publish them to the rest of the enterprise for reuse and modification.
Analysts can document existing business processes with “Oslo” repository-based modeling tools, such as Microsoft code name “Quadrant”. By storing the processes in the “Oslo” repository, other analysts in different parts of the organization can discover these processes. Using “Oslo” repository tools, they can either copy or version the business processes to adapt them to their specific needs.
Service Directories
Current technologies for service discovery, such as UDDI, are oriented to connecting to known services. However, users searching for a reusable service might need more details to determine whether an existing service meets their requirements.
The “Oslo” repository provides a central storage location for services. It is a searchable directory for these services, and it can include extensive service details. This includes details on SLAs, policies, and components associated with the service. Through queries or “Oslo” repository-based service reports, developers are better able to find reusable services. Developers also have more information for evaluating the potential usefulness of the discovered services.