It's (Third) Party Time

A lot of computer products, particularly in the monitoring / administration domain, are centered around some third party piece of hardware of software. Usually a company finds that they can greatly enhance and simplify the admin and reporting on another company's flagship product. Presumably the original company is either unable or unwilling to make it easy manage their stuff because they're concentrating on their core problem domain.

As an example, if you build backup servers, you're working on getting that backup stuff working smoothly, not necessarily on making it easy to manage or get information out of it. Sure, you include some out of the box support for doing some of the stuff, but ultimately it's an immature solution that feels like it was tacked on at the last second. It's particularly bad with hardware vendors. They usually can't design decent user software or APIs.

This creates a great opportunity for software companies to swoop in and carve out a spot in (or create a market for) the area of third party management software. If you can write a piece of software that makes the administration of Foo servers more simple, particularly in a large enterprise environment where the out of the box tools break down, then you'll be sitting pretty for a while.

You Mean, We Can Make Money Off This?

One of the problems occurs when the original vendor suddenly realizes that their software sucks. If they ever get off their ass and write some decent management stuff around their product and bundle it for free, then customers have much less incentive to go looking for your offerings in the first place. If other companies begin offering management solutions around the same product, you will see even more of a decline in sales.

The temptation seems to be to get into a feature war with everyone else. Once you've exhausted all of the useful features you start to include numerous niche features and one-off customer requests. Dump these onto a product sheet in no particular order and you look just as good, if not better than all of your competitors. A lot of these features aren't likely to matter very much to the people that use the software, so you need to get some marketing materials, product advocates, consultants, etc to push your product to the people that make the decisions (and don't actually use the product). For more on this you can see the ClearCase situation in another post.

Now you've lost your way. You started out simplifying the administration of another company's product and have created what is, more than likely, an overly complicated and hard to use product of your own.

Wider Is Better

Rather than freak out and get all feature crazy when the competition starts, it's better to diversify what it is your product simplifies. For example, if you've a database tool for a particular backend, why not add support for another database backend before exhausting your laundry list of niche features? Of course this works better if you're simplifying or abstracting multiple offerings from vendors in the same problem domain that are likely to be found uneasily co-existing in large organizations.

By that I mean, you want to do something like take three operating systems and present a common management interface for a problem domain (like security or backup) that sensibly abstracts away the subtle differences. This allows an admin to more easily administer the hodge-podge of systems he's found himself in charge of. And, since the same person is likely to have to deal with all three, your tool is quite handy. Handier in fact than if three people each only deal with one of the situations. Then the fact that your tool acts as an abstraction for all three isn't particularly useful, especially since each of them will have their own, very deep on functionality, tool that they prefer. No, I think the better target is to go wide and relatively shallow. It's also better insulates you from the competition, either from the original vendors (who usually don't care about working with products from other vendors) or other third party companies (who may not have their act fully together).

And Your Point Is?

What's my point? Up to now, what I'm talking about is fairly obvious to most people. The issue comes in when you consider how your original, one vendor product came to be. I've seen a lot of software teams and companies paint themselves into corners by making the assumption that their product only works with one vendor product or by tightly coupling domain / business logic to the first product they support. When they finally get around to adding support to more products they often find out their "abstraction" doesn't play well with others. By then it's too late. It's all well and good to only build exactly what you need at the time, but you need to think about where you're going. This is something I haven't fully figured out with agile development. This "architectural escape velocity" doesn't seem to come easily in the bite size chunks that agile advocates. I'm not saying it can't happen, it's just very easy to get it very wrong.

As early as you can, hopefully when you initially start your project, you might want to start asking these questions:

  • What other vendors' products could we manage?
  • How have the vendors represented this domain differently?
  • How can we create a unified view (abstraction) of this domain?
  • If something doesn't fit the abstraction, how can it still fit into our product?
  • How do we keep one-off customer requests from making our core product less maintainable?
  • How can customers get information into and out of our system?

That's just a start. I'm sure there are more (and probably better) questions to keep asking yourself. Answer these early and often (like you release) and let it affect your planning. Don't be tempted to just say, "we'll worry about that later" because by then it'll cost too much to change.


Leave a Reply