Special thanks to 'Jerman of the Board' for this blog post on a good book, "The Paradox of Choice." Just from the links on this page, I intend to go out and get the book right away.
Quote: "The basic premise of the book is that TOO much choice leads to LESS satisfaction. In other words, More is Less."
I see this all the time in software development as well. If a customer is given a choice of 'buy commercial software or build an IT system', and money is no object, then they will choose to build a system, every time, because they have infinite choices about the features they want. They will also expand the cost of the system to include expensive features that will never justify themselves. Some business users who are familiar with the experience of having an IT analyst write down every word are too spoiled to actually purchase commercial software, because it doesn't meet 110% of their stated needs.
But the moment you say "you have no choice to write your own... you must buy something available," then suddenly the software that is available on the market will work just fine. They pick one, implement it, and live with it for years.
So if we take this logic and apply it to SOA, what should we provide when we create the list of services that the enterprise 'needs' to have (the periodic table of services)? Do we provide 40 different endpoints that are minor variations on 'create a customer' or do we provide three, one for each of three different (standardized) interaction patterns?
I suspect that if we provide 40, the customer will want 42. If we provide three, they will pick one and move on.
So if you are considering a list of enterprise services that exceeds 500 core services across the enterprise, perhaps this is an opportunity to think again. Too much choice is not necessarily a good thing.
PingBack from http://msdnrss.thecoderblogs.com/2007/08/19/the-perfect-service-oriented-architecture-is-small/
Many years ago, I worked as a picture framer, under the tutelage of a wise man, who gave me this advice: Always suggest solutions to the customer, and rein in the decision-making process. First, the customer is not a professional, and doesn't know what can or even should be done. Second, even arbitrary decisions made with confidence by a professional inspire confidence and attenuate indecision. Third, the customer will often have unrealistic expectations about what can be achieved for the money.
In the software business, the same holds true, only more so. Users have unrealistic ideas about what computers can do. It is not that computers cannot do almost anything, but a matter of time and resources.
The KISS principle is always in play. The more complex a system is, the more likely it is that there will be flaws in it. Consumer demand always exceeds reality. Expecially in the first iteration of a product, features should be reined in as much as possible.
The mechanical pencil comes to mind. A pencil is essentially a rigid structure that fits the human hand, and contains a graphite rod for drawing. Most pencils are made of wood, with a graphite rod embedded in the center. A knife or sharpening tool is used to keep a point on them. I whittles the wood and the graphite. A mechanical pencil is a pencil that has a permanent rigid structure for holding the graphite, a mechanical means for inserting graphite rods into the structure, and a mechanical means for pushing the graphite rod a small way forward out the tip. The advantage of a mechanical pencil is chiefly that a sharpening tool/mechanism is not required. The disadvantages include a much greater expense, complexity of use, and eventual breakdown of the mechanisms, requiring another mechanical pencil purchase.
Considering the cheapness of wooden pencils, and the ease of sharpening them, mechanical pencils are not really an improvement at all. There may be specialized uses for which they may be useful, but for the most part, they are a case of technology beyond common sense.
I agree that the customer is unaware of what can or should be done. We are 'trusted advisors' and should take that seriously. However, I'm also suggesting that we should intentionally produce fewer possibilities.
This goes beyond offering good advice. Why? Because our market, the services spanning layer, is in its infancy. No one knows for sure what the "right number" of services is, or what they look like.
When the market is mature, then, perhaps we can introduce the services-version of a mechanical pencil. Right now, it's very probably the wrong time.