James and I talked with Jose Mora of CA/Clarity today; thanks to Janice Thomas for putting together the call. The content of the call is under NDA for now so this post isn't about the briefing per say. But in looking over their public website, you can see that Clarity's existing UI has dollar signs in it. Literally.
In systems management, that's the kind of thing that gets dorks like me excited.
As I often mention in my Big 4 vs. Systems Management 2.0 conversations, the Big 4 have been climbing the value-chain to more C-level sales in the recent past. That's all well and good, but there's still the Morlock level to worry about. (To be fair, in my role as analyst I probably get more C-level pitches than tool-level.)
We all know the "IT doesn't speak the language of business" train of thought. It holds quite a bit of water. Conversations are two way, however, and business often doesn't speak the language of IT. This same divide exists, at many magnitudes higher, in software development: those damn developers won't write the software I, a product manager/marketer, keep asking for...or...those damn "marketing people" don't know what they want.
One Rosetta Process
To me, Agile Software Development is largely about responding to that problem: getting the stake-holders and the code-monkeys to talk to each other and give each other rapid enough feedback to actually work together.
Another large part of Agile Software Development is adding transparency to both the business side and development side of software creation. The business people are forced to boil down what they want to simple requirements that are prioritized; the developers are forced to report on their progress and demonstrate what they're doing frequently. (Ideally, at least ;>)
Now, pulling back to systems management -- more generally, "IT" -- one of the popular goal-bundles is keeping costs under control and managing risks, or "keeping the lights on." Those goals don't align perfectly with the "deliver software" goal of Agile, but the core practice of transparency matches well.
So, whereas in Agile Software Development, the thing you're making transparent is "what is our current progress" (expressed best with a burn-down chart), in IT management, the thing you want to make transparent is "how much is this costing?"
Traditionally, answering that question is left up to management. It's rare for end-of-line workers to think, "we're burning $20 a second right now." At least, it's rare for systems management tools to make that cash-burn transparent.
Mistrust Is Expensive
The "problem" with cost-based IT is that there aren't enough managers to make all the decisions. To address this, what you need to do is push that cost-based decision making down as low as possible. Doing that is largely about trust -- "can we trust Joe Admin to make the right choice for the company?" -- but the entry fee is creating tools that give end-of-line workers access to that information: that make the cost of running IT transparent to all the concerned parties.
The scenario is this: I'm an admin, "keeping the lights on." There are 10 different fires in front of me, and I need to figure out which one to work on first, which one next, etc. I could call over my manager and ask him, or -- if I had the tools -- just see the dollar amount that each problem was "worth." Then, picking the easiest triage, take care of the most costly problem first.
That's been a dream for awhile, but what I haven't seen is an implementation that's open enough to truly deliver it. Looking over Clarity's web-site, from a slide-ware level, I can start to see how they could have the capacity to be a repository for that information, though I have no idea if it's a technical reality. Of course, a fully operational CMDB would give you the same thing...if the vision pans out.
Along those lines, it'd be interesting to see some of the Systems Management 2.0 folks get more enterprisey by pulling information from Clarity or Clarity-like systems. What was it that The Startup Exec said about why he sold to the enterprise? Because that's where the money is.
How to Check SOA Off Your List
For those looking to inject some SOA into their systems management platforms, this seems like the perfect opportunity for some light-weight composites. When an event pops up on a console, make a small call to the repository and get how much that related systems is worth: then just composite it into the display.
This scenario is great for a JavaScript include based composite and hinges on a friendly URL protocol. You can look at the scad of Web 2.0 JavaScript includes to get an idea of how it works: for example, the tag-cloud and/or del.icio.us network sections in the sidebar of my blog.
Point being: innovation and development of this should be cheap because it's already been figured out thanks to consumer-tech. Don't leave that money on the table.
Think Like a Platform, Not a Dead-end
Part of the architectural and marketectural thinking that this implies is to start thinking of your systems management (and, really, any large piece of software, e.g., ERP) system as a platform instead of a cul-de-sac (or "dead-end" if I was being cynical). Knowing to have simple points of composite-integration like JavaScript includes, REST APIs, and even (gulp) SOAP APIs comes from platform centric product management.
Otherwise, if you're thinking of your application as stand-alone, there's no way you can rationalize out the time and money to spend on "non-user facing" features like APIs. The flaw in that thinking is thinking of your users as UI-bound. In this day and age, users should be getting to your system through more than just the UI: through services, JavaScript includes, and other mashup driven work-flows.
And if you want to shove all of that into the brimming SOA bucket, go ahead if it helps you out. You always need a little utopia as air-cover for handling the plain, old muck.
Maxing Out Employee Value
Rhetorically, the nice thing about each of these points is that they spring from one general rule: there is so much going on in any business, organization, or work-flow that management can no longer run everything. Therefore: push decision making down to the furtherest end-point possible. It follows that you must train and education your people to be decision makers instead of just mouse-clickers.
The point for software is understanding that nature of management and creating tools that enable it. To me, the more open and quick-n-easy to integrate with your software is -- the more of a platform it is -- the more your software aligns with how decisions are made day-to-day in business: aggregating as much information as possible on one "screen" (often in someone's head), and then taking a best guess about the next move.
Previous Topic
