In the past year or two, most systems management companies and projects have focused on getting the 1.0 version of their product out the door. Recently, however, I’m finding that IT and systems management companies I talk with now have bandwidth to work on fitting themselves into the big picture of IT and systems management. That is, the next 12 to 18 months look like they’ll be ripe for partnering between the Systems Management 2.0 companies I’ve been watching over the past year, and even among the “1.0″ crew.
While there’s been a fair amount of partnering so far — e.g., OEM agreements with Hyperic, Splunk and CA, and work towards partnering-through-standards — what I’m looking for, and often advice companies around, is partnering with the intent of creating IT management suites that purposefully integrate together instead of being duct-taped together.
For example, service desk oriented stacks like Service-now.com could be purposefully integrated together with one or more of the Systems Management 2.0 platforms to create something (near?) to an enterprise IT management suite. There’s work to be done, for sure, but the technology is there, each in nicely drawn boxes that don’t have messy overlap.
Growing a Platform
In the conversations around partnering and integrating, the question is always, “who can we plug into?” That is, in my re-wording, “who has a platform that we can work with?” Ostensibly, The Big 4 have platforms, but as The Big 4 differentiates themselves on being suites themselves, there’s a healthy suspicion about how open that platform is.
I, of course, urge everyone, Big 4 or no, to make their systems as open a platform as possible. The questions with the Big 4 along these lines are:
how fast they’ll move
how much support they’ll give to ISVs and developers extending their platform
how easy they make it for people to add new functionality via “plugins,” “modules,” or what have you
Can just anyone extend the platform, or do you need to be a sizable company?
In the open source space, the 4 names that come up each time — usually from people I’m talking with even before I say anything — are: Zenoss, Hyperic, GroundWorks, and openQRM.
Other companies, like FiveRuns, have the potential but haven’t formalized or released a plugin architecture. And of course, there are the open source projects like Nagios and OpenNMS. BMC’s Performance Manager is primed architecturally to be an open platform as well (I should know, I was on the team that implemented much of that original technology…which could be taken as a disclaimer/strong bias as well).
On that note, many people have expressed a strong desire to know which one they should choose to integrate with. Obviously, The Little 4 and The Big 4 would do well to start telling the story of why they’re the one.
Why? 1 + 1 = 3
In the end, the point of having a platform is allowing others to add value to your software by integrating in their own code and ideas. More specifically, 3rd parties can add value that you don’t have time to add. The customer sees the platform as a whole rather than what company X or Y produces. So, from that perspective, as the platform provider, you can be at the core of that value. For this effect, however, the ecosystem around that platform needs momentum and scale. The biggest community wins.
In my mind, the case is this: a systems management platform increases in value when it can monitor and manage as many things as possible with as little care and feeding as possible. As in software in general, in systems management, the key pivot is still having a killer application. What’s different than other domains in that model, though, is that each company has the potential to need a different killer application based on the way they use their IT and the rate at which they need to change their IT to run the business. This a foil to IT Doesn’t Matter: sure, if you (and your IT colleagues at competitors) can’t change fast enough you don’t matter. Sidewalks and waste-water don’t “matter” if they don’t do anything different year-to-year.
Thus, a “closed” systems management platform will miss the boat on the above angle because one company, no matter how big, won’t be able to innovate, support, and maintain those killer applications fast enough. This is why we have the constant tension between “best of breed” and “suite” solutions in systems management.
Hijacking Platforms
The antidote is creating an open platform. That is, delivering software that:
Provides a robust, base-line of scalability, data-warehousing, a common UI, and common data-model, workflow, and semantics. At the very least, the platform needs to take an ESB approach and provide the method by which different systems can talk with each other with the minimal fuss
Provides well defined end points for 3rd parties to plug data, management, and workflow into the system
The last point is what often separates the successful platforms from the unsuccessful ones. Developers and ISVs need to be actively courted and encouraged to come “play” on the platform. At the beginning, the onus is on the platform company to bring others on rather than on the 3rd parties to figure out and come to the platform.
That said, once the developer pool reaches a critical mass, the focus of the platform owner becomes one of maintaining rather than only promoting the communities involvement in the platform. Indeed, if the community itself doesn’t take over the job of promoting the platform, the original job isn’t done.
A couple of examples would be really nice here, wouldn’t they? Microsoft in the ’90’s is the classic example, while open source in general is the newer one. As of yet, I’m not sure there are undisputed examples of previously closed source enterprise software companies doing this: Sun’s long-term strategy has strong over-tones, of course. Perhaps I’m just not thinking of them.
Frameworks
For old hands, the notion of frameworks brings on violent shakes and laughs of aversion. Visions of CORBA and clean-up crews dance around the bar at this point. Indeed, delivering a platform is a dicey, architectural proposition. It’s hard to not screw it up.
The problem is that once you release public interfaces, you can’t change them. To hedge against this, you start generalizing those interfaces to the point where they’re not detailed and/or low-level enough. At that point, your 3rd parties are handicapped and can’t do everything they need to.
Either way, if you design bad integration points, you have to live with them.
Now, that thinking is from an OO mind-set, more importantly, a static language OO mind-set. There’s a certain, as I used to call it, “good enough” mindset that we see on the public web that hedges against the danger of framework stinkatude. Here, “sloppy” (in comparison to static, OO-land) coding is the norm: HTML, dynamic languages, JSON, HTTP, and punk IT. We used to just call it “pragmatic.”
I don’t have the angle figured out fully, but instead of being generalized, the interfaces are simplified. My theory (and I stress theory) is that the SOA we see on the public web “works” and evolves, not due to standardizing on the exact same interfaces (aside from a few core semantics), but more because:
The core technologies are very forgiving and sloppy
The interfaces and systems are simple enough that you can (re-)learn them in a matter of hours instead of days or weeks
It’d seem, then, that successful open platforms in systems management would do well to start with those points.
Now, don’t misunderstand me here. What I’m talking about are the public interfaces and integration points. Not the back-end. The actual machine that runs an open platform is a different story. Figuring out where to draw that line is a constant battle and one of the other challenges with providing an open platform. But, if it were all easy, there wouldn’t be much money involved would there?
Disclaimer: Zenoss, FiveRuns, BMC, Sun, and IBM are client. As is Eclipse, whose COSMOS project is linked to.
Previous Topic
