Management by Feed/Feed Management, Part 3: The RSS Golden Hammer

Much of the thinking around improving the feed reading experience is centered around humans creating and consuming the content in the feeds. When it comes to selling software, it’s often the non-human uses of technology that pay the bills. So, what if we change the types of publishers and consumers on either end: computer->human, or human->computer, or computer->computer? How could we use RSS to improve software?

Systems Management is Just an Example

My head is so thourougly stuck in systems management now-a-days that most of my ideas come from that domain. But the thing is, systems management is just collecting, analyzing, and reacting to information and data…which is the cycle that just about all software behind the firewall operates in. So, you can analogize these things to other systems with a little bit of name changing.

Affordable Simplicity

The other important point to remember is that all of these things are easy in a closed system, where you control all the end points. That’s when binary solutions work great like JMS, Jini, or JXTA to pull from the Java pool, or CORBA to pull from the past. But once you start inviting other systems to the party, things get ugly fast if the method of interop isn’t as simple as possible. And ugly costs money.

Feeding Computers

• Patch management. This would really just be a format/protocol change for the process that already exists. But, it would provide a nice standardization that people wouldn’t need to battle over in commite. Every piece of software could deploy patches as enclosures. While how those patches got applied would be the magic that you pay for and the muck that you deal with, the important thing is that any project that could generate an RSS feed with the appropriate enclosure could participate in patch management. They’d still have to format that enclosure correctly to work with the given patch management software, but it’s better than nothing, and maybe some day (knock on wood) even that could be standardized.
• Telling the system things it might be interested in to help “train” it. Splunk Base and collaborative systems management comes to mind as an example data-set to work with: people are submitting error conditions and (you’d hope!) ways to fix those errors. This data can be fed into Splunk or whatever tool and used to teach the systems management tool new trouble shooting tips. When it sees an error like that, perhaps it should (or should NOT) freak out and wake up the sysadmin.

Computers Talking to Computers

Updating data as in a CMDB. A CMDB is the “centralized” data store for all information related to IT: your assets, problems with those assets, processes, or anything you might feel the need to “document.” The magic of a CMDB is making it easy to update without costing you a lot of money. Each “configuration item” (or CI) in the wild (a machine, an application, or, more abstractly, a business process) could have an RSS feed that details it’s changes, storing it locally. The CMDB would poll those RSS feeds to update the CI records.

This is another thing as with patch management: the function is not anything new, but standardizing on the format is valuable so that third parties can participate. Enabling Metcalfe’s law is extremely valuable in systems management: the more nodes participating in the network, the more stuff you’re monitoring and managing, and the more value your systems management software will be to your users and customers. (As you can guess, this applies to all software platforms, not just systems management platforms.)

Easy Composite Applications

“Composite Applications” help put mounds of data into context. The promise of composite application platforms is that it won’t only be possible to mash information together, but that it’ll be cheap and agile.

While there are many platforms, and whole companies for creating composite applications, the simplicity of composite apps as we know them on the public web is hard to beat. For example, portlets (in the most generic sense) could just be mini RSS readers that allow people to assemble streams of information on the glass as most people do on their blogs with JavaScript includes. Adding little “action links” to feeds (or “feedflare” as FeedBurner calls them) adds behavior into the data.

For example, you might use one of these mini RSS reader portlets to feed workflow items to authorized users: a certain point in a workflow may require a manager to approve an order or task. The feed could be include FeedFlare that has two links: Approve or Reject for each item. This would kick off the whole process with auditing and other enterprisey goodness. But the point is, the human’s involvement (often the most expensive and the bottleneck) would be improved and the underlying code and protocol would be simplified.

(Management by Feed/Feed Management Series: part 1, part 2, part 3.)