Martin Fowler, one of the most respected thinkers in the software engineering field, once wrote that the language used to write software is relatively irrelevant. The architecture of the system, and how intelligently it’s implemented, is of much greater importance. Thus his classic book on architectural patterns – the language used is irrelevant.
The analogy has some application to information technology systems as well. When you look at a system’s feature list, can you really assess how well that system will solve your business problem? The more complex the problem, the more relevant the question. Ultimately, features are irrelevant. Solutions are all that matters.
In my industry, for example, it is common for licensees to send out an RFP with dozens of pages of features, asking the vendors to indicate whether their system handles those features or not. Rarely, though, do you see an RFP that states a strategic business problem needing to be solved. Does a company really care about whether your system handles sliding scales on royalty contracts? Do they really care whether your statements are customizable? The CEO of that company is concerned with profit, quality, brand, risk and cash flow. That’s about it.
Features don’t solve those problems. The process using those features, though, does. If we can improve your profit by x%, reduce risk by y%, and improve quality by z%, isn’t that more important than whether your sliding scales reset every year or not?
The question then becomes, how best to evaluate a solution? That topic is the subject of much debate and literature. The key point, though, is that a solution is so much more than the system (i.e. the features).
For the record, MetaComet’s Royalty Tracker(r) royalty software does handle all the above mentioned features, and just about any other feature needed by a royalty department. More importantly, though, our expertise and experience saves companies money, reduces their risk, improves quality, and protects their brand.