Nucleus Of A Methodology, The Pain
Why my interest in SOA methodology?
Because there's money in a clear understanding of SOA implementation methodology and in the creation of Enterprise Service Bus frameworks. An effective SOA implementation for a Fortune 1000 company could run into tens of millions. A refined methodology which reduced potential failure could be worth a million when applied across many multi-million dollar projects.
Current Deductions -
1) Use a commercial ESB bus. This would reduce potential failure by a great deal. A good estimate is difficult, perhaps a 10-50% reduction in the project failure rate?
2) Pursue a minimal implementation. Complexity is multiplicative, not additive. Compare the features of a full implementation versus a minimal implementation, from the IBM SOA Redbook -
Full Implementation contains 50+ features.
Minimal Implementation contains 15 features.
That's got to be 3X to 10X greater complexity, which means the project failure rate skyrockets.
3) Use an existing security model which is ESB-specific. Again, this is an issue of exponential complexity for marginal gain.
4) SOA / ESB is an appropriate methodology for an heterogenous environment. I doubt if it's justifiable in a small scale or homogenous environment.
5) ESB's value is that it functions as a mediator. It encapsulates and isolates state information and minimizes object dependencies. This should be quantifiable in terms of transaction costs using prototype models. Total # of transaction costs could be a proxy of total project complexity, which is a proxy for statistical failure rate. There is a market for a modelling tool which predicts transaction costs. An even better tool would compare legacy transaction costs against proposed SOA implementations.
6) The complexity risk in adapter connectivity is small. Each adapter might need transaction and security legacy code, but they are independent of each other so there's no scalability or exponential complexity issues. I would tend to factor out the Adapter component of the preceding model, it has minor relevance.
7) In retrospect, the heterogeneous component of the model is probably fairly easy to predict. If we have a rough measure of total complexity (see #5), we know one of three factors in the equation. The remaining factors, team size and tool set, are driven by adoption of frameworks, project timeline and acceptable risk.
Big failure issues -
1) Managing complexity and rate of change in WS-Policy structure.
2) Clean separation of business logic from bus logic. This is a nebulous area.
----
I'm flattered, but why would the European Patent Office take such an interest in this site? 
Posted by credit card debt consolidation on February 20, 2007 at 09:24 AM EST
Website: http://del.icio.us/credit_card_debt #