http://smart-future.org/2009/10/wave-3-dilemma/ ...the future looks bright through my shades... Tue, 15 May 2012 05:02:56 +0000 hourly 1 http://wordpress.org/?v=3.3.2 http://smart-future.org/2009/10/wave-3-dilemma/comment-page-2/#comment-6845 Andy Bentley Thu, 19 Aug 2010 15:03:03 +0000 http://smart-future.org/?p=232#comment-6845 One other aspect of the acquisition process that is broken IMO, is that contractors have historically build a system for one program, then gotten paid again and again to build the same/similar system for other programs. There is little incentive for contractors to build re-usable components or services that could be used by many programs. This is especially true for SOA, and hence the slow adoption. Contractors will build services and claim inter-operability but usually inject proprietary or non-interoperable technologies to ensure vendor lock in. IMO any system that is build to have a SOA like service interface should either have a pay-per-use payment model or have the interfaces and standards strictly defined. The hard part about strictly defining the interfaces in complex system is in leaving no wiggle room anywhere; which take a long time to spec out. The pay-for-use payment model would greatly incentivize contractors to build re-usable services. Getting the granularity of the services right is hard and getting the paymet dollar number per capability is hard. The right balance needs to be wrought to ensure that contractors dont build thousands on micro services that get called hundereds of times to increase the payments. One other aspect of the acquisition process that is broken IMO, is that contractors have historically build a system for one program, then gotten paid again and again to build the same/similar system for other programs. There is little incentive for contractors to build re-usable components or services that could be used by many programs. This is especially true for SOA, and hence the slow adoption. Contractors will build services and claim inter-operability but usually inject proprietary or non-interoperable technologies to ensure vendor lock in. IMO any system that is build to have a SOA like service interface should either have a pay-per-use payment model or have the interfaces and standards strictly defined. The hard part about strictly defining the interfaces in complex system is in leaving no wiggle room anywhere; which take a long time to spec out. The pay-for-use payment model would greatly incentivize contractors to build re-usable services. Getting the granularity of the services right is hard and getting the paymet dollar number per capability is hard. The right balance needs to be wrought to ensure that contractors dont build thousands on micro services that get called hundereds of times to increase the payments.

]]>