Enterprise Architecture And New Technologies

R.L.Narain has invited my views on James McGovern's post on non-suitability of Ruby for enterprises.

My Take: Amongst many things that James has said, his view that a very small percentage of enterprise architects must have read about Ruby and in general enterprise CIO’s are more overwhelmed and busy thinking about the strategic intent of their own enterprises appear quite on the mark. The point is - enterprises are in general risk averse and their set of concerns on new technology absorption are very different. See my post on a related topic. More often than not,it is change management and organization’s pace and ability to absorb newer technologies /processes that would determine the choice and success of the initiative. In doing so,CIO’s of large enterprises naturally look for references, endorsements, depth of talent that is generally available with their chosen/preferred service providers and the views of influencers that the organizations would listen to – consulting firms and analysts. While technically it might be the case the Ruby can facilitate agile development, the buzz around Ruby in so far as I have seen across the world looks limited. It may not be a valid argument to look at .WS* and other more "sophisticated" SOAP as detined to solve more complex issues than REST based services. Ruby, PHP – these are all really capable, robust tools helping in creating good apps quickly, maintaining and extending those to serve as distributed application systems - generally startups may prefer this. The established enterprises deal with technology selection in different ways – key consideration includes impact on all elements of their ecosystem – legacy technologies, resident skill sets , the way IT is perceived within their enterprises, partner communities, enterprise architecture etc. One can’t take a simplistic view that as X,Y,Z can do this, then by extension, all enterprises can do so. Besides different set of considerations – some of which I have touched upon above – key issues may also revolve around costs – if is very difficult to arrive at a normalised TCO for newer technologies across business entities – which could be as different as chalk and cheese. Narain - while your views on changing architctural standards look valid, in reality what’s applicable to dot.com /web2.0/on-demand companies may not apply to the Walmarts and Chevron Texaco's of the world.