The perfect service oriented architecture is... small

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.