Got data? Where? Understanding how Registry Services helps you manage the whereabouts of your data
John_Kogel 270005XG54 Visits (1273)
Good data about services is essential to making decisions. How can I find it when I need it?
Making decisions about opportunities as well as problems and new challenges requires information. In many cases, that information needs to be available in real time and in context to the business.
For example, before I patch a server, it is essential to understand what applications are running on that server and what time is best to apply a patch. It is necessary to know the current patch level as well as any recent, pending issues or incidents for that server. It is important to know if the server is close to the end of its lifecycle and who owns it for a quick review and notification.
Finding this information rapidly can be daunting. In many cases, the information will be stored or behind multiple products. In last month’s blog I talked about the value of “linked data” and how important it is to use internet based standards to access data. In addition, providing a standard like Open Services Lifecycle Collaboration, or OSLC, is an approach to ensuring the data is open and supports standardized interfaces. Given that, as a program or a user, I still need a way to effectively locate the interfaces in the system. Due to configuration changes which take place frequently, this operation should be dynamic. I need to know I am getting the latest most updated data on the system.
In Jazz for Service Management or JazzSM, we developed a set of registry services just for that purpose. JazzSM is a place to find open standardized interfaces for many different services or products with a simple query. There are actually two registries in JazzSM. The first is something we call the provider registry which is where services register and is easily found by consumers. The second is what we call the resource registry. Think of the resource registry as an index into the world of data and how it is related to that index. For instance, a resource might be identified by a serial number, hostname, or asset tag. Consumers of this information issue a search for a resource where one or more URL’s are returned pointing to services that have data about that resource. The consumer or the application now has access to the open APIs for quick access about that particular resource.
Continuing with the scenario we started with, a request could be made to tell me everything there is to know about server “123”. Depending on the services registered, you would be able to get relevant information about server “123”; information like utilization and performance trends from your monitoring product, as well as lifecycle status and owner(s) from your asset management product. You might be able to visualize the current patch level as well software levels from your patch and configuration tools. All of this information returned in real time will help in making better decisions about what actions to take.
Does this sound like it has value and something you can use with your service management portfolio?
To learn more about Jazz for Service Management join the grou