I had a systems management discussion this morning that reminded me about tags in the BMC product I used to work on, BMC Performance Manager. Over a year ago, around April 2005, I started posting the idea for using tags in that product on my internal BMC blog and, eventually, put together and gave a presentation on it. Another team, who worked on the UI framework, took up the task and tags were shipped in the version of BPM at the time.
Why Tags in Systems Management?
The idea was to allow users of the system to tag "managed objects" that BPM monitored (devices, applications, and parameters). Additionally, several people wanted the system to auto-tag items with things like the platform the managed object was on (Linux, Windows, etc.) or type of things it was.
You could then navigate your pile of managed objects by tags in addition to the (still default) tree based navigation panel. Searching, which we finally managed to get into the product at the same time, would also search over tags.
What does systems management usually do for 'best practices',
and maybe online help? That's right it makes some [stuff] up - a
top down taxonomy that may or may not have some real value in
the world (ITIL).
Wouldn't it be better to keep the top down taxonomy but add a
practioner-led filter to the best practices? Let practitioner define
problems and solutions to problems, because they know best -
but and this is a big but - these folks are only creating metadata -
data about the data, information about the information. In other
words the tags provide a 'schema' for the 'data' at the back end.
But with dramatically faster navigation, based as it is on solutions
to real problems, rather than models of problems.
(As an aside, that was a nice example of RedMonk reaching out and working with developers instead of only coming in from the top.)
One of the more "soft" selling points of tags was the idea that users would add value to the platform post install. As James was getting to, instead of just taking the out-of-the-box understanding of their system's structure, users could use tags to not only create their own navigation metaphors, but also meta-data.
The customized navigation experience was, of course, the up-front pay-off and differentiator. Tags give users one, dead-simple way to customize the UI to their liking. Rather than being forced to use a tree view to navigate their IT world, users could navigate their own tags. There are trade-offs to that of course, but I'd argue that having both a hierarchical (tree) and flat (tags) navigation UI makes a user's life better.
All in all adding tags and search was an exciting addition to the UI from our (the developers) perspective.
Of course, once you have the base level tags in, you start dreaming up exciting new uses for tags. Like a "dynamic tag" that's automatically added to problematic systems or applications you're monitoring. You could have a tag like "in_alert" that contained all of the items currently, well, in alert. Indeed, the line between tags and the equivalent of Smart Playlists gets a bit blurred.
The Tagful CMDB
Tags become even more useful in systems management when you take a more RESTful approach to a CMDB. Each Configuration Item is URL addressible, can contain any number of tags, and you use those tags or something else to express relationships between each CI in the CMDB. In moments of Web 2.0 drunkenness, it's easy to think things like "a CMDB could just a big REST-based, tag server!"
Once you move into a REST, URL-centric world, you realize that tags themselves are ways of easily creating URLs and, thus, whole new "resources" for others to consume.
There's a certain attractiveness to that simplicity. The huge elephant that you need to eat, however, is coming up with a general and simple enough data model and semantics to lay the ground-work. Behind-the-firewall applications -- like CMDBs, at least in their current state -- can't rely on the scale-effect of the public internet like the wikipedia. So you have to bake in people caring enough to garden those systems. Meaning, process and explicitly stating that the gardening is part of someone's job.
Historically, the systems management space is terrible at coming up with widely accepted and used data models and semantic bags. If it weren't, I could point to The Data Model here. Instead, there's at least 4-5 I could point to, not even including all the proprietary ones that each product line uses. The philosopher in me loves dissecting and figuring out these models, but the programmer in me hates it in that I'm re-learning each time I encounter a new model.
Now, while that may seem like a dim view, one aspect of RESTful approaches that provides some level of hope for this go-around is the emphasis on simplicity. If you have XML and HTTP, and can express the entire interface into a system in 5 pages, how much up-front time do you need to spend building interop into the system?
Ultimately, the problem of making systems management platforms more open and more useful is a cultural one. Those involved need to push in the technical simplicity that allows more people to get involved in the systems management world. The current data models and protocols are probably too complex to get a wider audience excited about using and extending existing platforms.
Previous Topic
