> Tangible business benefit comes in two basic forms: > > (1) Internal - cost reduction etc > > (2) External - Benefit to customers - increased functionality, more > rapid response to requirements > > Category (2) is something customers will pay for, (1) is not and tends > to be about the law of diminishing returns.
I tend to agree that (1) is not, unless the savings are huge due to process optimization... Not a REST example, but more generally SOA + BPM: we executed a $200m workflow automation & exception management program at a major bank, of which over 25% was severance costs alone (they shed 850 out of 2500 operational employees). It had to go to get board-level approval to get the capital, but they spent it (saving them $40m/year on people alone, let alone process execution times). As for economic laws, I would suggest that the argument for REST is about increasing returns due to network effects. > Measurement of (2) is done via looking at the bottom line. I'm curious if market responsiveness really is quantifiable in this way, I think cash flow & reduction in working capital is likely a measure of responsiveness, because sometimes responsiveness costs you *more* -- impacting the bottom line. Business-aligned Agility/responsiveness tends to occur in three ways, in my view: - decentralized (more accurately "federated") decision making - reduced coordination costs (capex, opex & time) - reduced lead times The argument for SOA in general is about decentralizing computing to enable better responsiveness, but providing a governance framework to ensure this occurs in an aligned fashion. Secondly, the reduction in deliverable sizes and standardization of interfaces will help to reduce lead times (though there's a lot more to be said about process improvement here than just SOA). Thirdly, coordination costs are directly related to the architectural style of how interoperabilty occurs. The shape and granularity of your interfaces will determine how costly it is to integrate & coordinate components in your system. Thus, the need for good SOA governance. But this also leads to the argument for uniform interfaces: at ever increasing scales, federated governance breaks down, and a form of anarchy emerges. In such an environment, you can only pick the most general operations possible. In the case of the web, we were talking global scale, so HTTP picked operations that scaled for a global anarchy, and the web was born due to the network effects from that decision . > So in the context of gaining tangible business benefit, REST vs SOAP is > nowhere and therefore "pointless". You might be able to make some claim > in respect of category (1) but it's going to be difficult to prove and > I've seen very little of how REST vs SOAP means anything in respect of > category (2). Contrast the marginal cost of integrating a dynamic website onto the web vs. the marginal cost of integrating a system with EAI or RPC... Cheers Stu ------------------------ Yahoo! Groups Sponsor --------------------~--> Great things are happening at Yahoo! Groups. See the new email design. http://us.click.yahoo.com/TISQkA/hOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
