I watched a Service-Oriented Architecture project fail first-hand. Technically it's not failed yet, but it seems likely now. I don't have the background to know the true cause, but I posted the quagmire of SOA in January of this year -
"IBM carefully crafted a system design which attempts to span the range of all things to all people. This could be a possible failure point of SOA."
I believe that SOA's greatest weakness is at the operational level. The strategic level of SOA is well-defined with training, documents and templates. My experience at coding and low-level implmentation is that tactical level is sound, too.
What's left is the operational level - a methodology and structure to convert strategic goals into tactical constructs. So let's draw up the nucleus of an operational structure for SOA -
What do we know that's concrete?
1) There's a high-level SOA structure which should take priority over tactical requirements.
2) At any point in time, there's an optimum project complexity that's achievable by the latest toolset and a certain team size. As team size grows, risk of failure rises. As complexity grows, either the toolset or team size (or both) must increase to compensate.
3) The greatest component of complexity is class differentation.
4) Existing frameworks can reduce complexity if the project is defined in a standardized form.
to be continued...
( Jun 07 2006, 03:43:13 AM EDT ) Permalink Comments [1]
Posted by credit card terminal and processing on February 20, 2007 at 10:40 AM EST
Website: http://del.icio.us/credit_card_terminal #