Archive for the ‘architecture’ Category

Now about those weights

February 4, 2007

Last week I wrote about product comparisons, and a way to add some rigor to the typical approach. The problem has always been that if the weights and scores are all judgements, it’s too easy to fudge the decision to make your favorite product win. So, based loosely on my approach to scoring candidates and building a career path, I came up with some criteria for scoring.

Here are some categories for weighting the decision criteria. I’m going to try these in the current product comparison.

0 – Totally unimportant – why then is it included in the comparison?

1 – Nice to have feature: users will be delighted, but not rely on this criterion.

2 – Should have feature: users will gain productivity or ease of use from this criterion.

3 – Expected feature for a product of this class

4 – Must have: we are relying on this criterion to support an important aspect of our business.

5 – Criterion that we will use for competitive advantage

So now, there should be far fewer criteria weighted at 5, and we should also have far fewer scoring 5.

Typically, I have used weight x score to determine the weighted score, but with the way these are worded, it’s almost something like 2^weight x 2^score would be a more useful scoring function.

Blogged with Flock


About product evaluations

February 2, 2007

One of the first higher-level tasks I remember doing back when I was a co-op student was to evaluate a number of products and decide which one to purchase.  My manager wanted a defencible position so that when we shelled out five grand per seat to do it, we would have a good reason.

So, somewhere I read a paper on producing such a thing (this was long before the WWW had been invented, and frankly, it’s hard to recall how we found information before Lycos).  Basically, it came down to identifying the criteria that drive the decision – usually a list of features – weighting them, and scoring each of the competitors on the criteria.  The one with the highest weighted score won.

Usually, the scores were pretty close — close enough that you could easily fudge it one way or the other.  After all, if the scores weren’t close together, the decision would be easy, right?

So, here I am, working on yet another one of these things, and realizing that it’s all a bit of a sham, and I’m thinking there must be a way to put some structure around these scores.  I have such a structure for scoring candidates in a job interview, but more on that later. 

So, let me try these on for size:

0 – Does not have the feature

1 – Has hooks that would enable us to build this feature if we really want it

2 – Has minimal support for the feature

3 – Has the expected support for this feature

4 – Supports this feature with some added bells and whistles

5 – Has a strong leadership position on this feature.

Now, what about the weights…

technorati tags:, ,

Blogged with Flock


January 31, 2007

Somehow, I managed to miss the resolution on the whole SOAP vs REST debate. I remember being thoroughly out-gunned by Paul Prescod in a debate at our old company on this topic. That was about four years ago. The debate was raging, and today, everyone’s just decided to go ahead with what they want to do. Everyone, that is, except a few people on Infoworld, who apparently recognize the still-glowing embers as an inferno.

So what happened? As near as I can tell, a number of things have occured to make the debate less relevant, and perhaps even declare de facto winners:

  1. There are some of tools today that let you choose the type of interface you’re going to offer quite late.
  2. The SOAP specs morphed and added the document encoding.
  3. A whole boatload of enterprise companies jumped on the SOAP bandwagon

Looking on, which ironically does not appear to have its own API, it appears that there are about twice as many REST APIs as SOAP (183 vs 87). Having said that, SOAP is the standard for just about any enterprise integration project: almost every software package has a SOAP interface now.

So, I guess the debate resolved into two camps. If you’re looking to integrate within the enterprise, and perhaps with partners, do it through SOAP. If you’re offering a public API, and your business depends in part on the uptake of that API, do it with REST.

The REST side makes perfect sense: REST is all about using WWW protocols that make sense over the Internet. On the other hand, if we’re using SOAP mostly within the enterprise, it makes me wonder what happened to CORBA. I think I’ll leave that particular stone unturned – I know what happened to CORBA, and I still have the flashbacks to prove it.

technorati tags:, , , ,

Blogged with Flock