Freitag, 28. August 2020

Mini Series IBM Agile Service Manager – part three: pants down

Within this final part of our mini-series on #IBM Agile Service Manager, we’ll have a closer look on some use cases covered by it. The most common one that I – or more likely everyone within IT – is facing, are very heterogeneous management systems, all having their own idea of presenting data northbound-wise. Grant it, we’re lucky to live in the age of ReST APIs, so at least access - in most cases - is the same. As I briefly talked about ASM’s architecture within the first post of this series, I mentioned the observers, which primarily collect data. Next to plenty of out-of-the-box integrations, there is a ReST observer, publishing an endpoint to receive entities, relations or a status. Having this kind of generic southbound interface, you can basically bring any data into ASM. This is great for our customers: They are no longer tied to any rigid interfaces resulting in a superior overview! Speaking of which, visualizations are highly customizable, making them very intuitive. Not only by adding a custom icon, but also by changing the shape of a resource, giving it a human readable label (e.g. by using tags if we’re talking cloud-based infrastructure which usually gets a UID-like name) or by coloring the line based on the relation’s type. So we have whatever data in the system, put some lip stick on its visualization, but what else? Well, there is the history functionality, which I already captioned as the killer feature: Nowadays, infrastructure is so volatile, that it could look completely different compared to a minute ago. Using ASM’s timeline functionality, we have a clear picture at any given time. This is very helpful to reduce the mean time to identify and mean time to know. However, you still need to know what you’re looking for, unless you leverage ASM’s topology templates: Image you could define a topology – via UI – by its characteristics, like an element of type server has a connected to relation to another element of type switch, which again connects to something like a router. Once you defined such a topology template, which might also contain logical connections, ASM will search thru its whole topology, creating tiny slices of views for you. So instead of searching for a specific resource, you now got a service-oriented view on your topology. Great feature. 

With this post, our mini-series on ASM ends. We hope you enjoined reading and in case you wanne dig deeper into ASM, feel free to get in touch with us!