Comments for FAST - Blog http://blog.fasttechnology.com Flexible Architecture. Simplified Technology. Tue, 13 Sep 2011 18:54:02 +0000 hourly 1 http://wordpress.org/?v=3.2.1 Comment on Email Updates by Rob Motaghedi http://blog.fasttechnology.com/email-updates/comment-page-1/#comment-2928 Rob Motaghedi Tue, 13 Sep 2011 18:54:02 +0000 http://blog.fasttechnology.com/?page_id=367#comment-2928 Like what you guys are doing on the software & service side in the L/A space. Like what you guys are doing on the software & service side in the L/A space.

]]> Comment on Problem Solving, SOA, Agile, Legacy Replacement and Watermelons by Steve Cohen http://blog.fasttechnology.com/2011/04/problem-solving-soa-agile-legacy-replacement-and-watermelons/comment-page-1/#comment-2393 Steve Cohen Tue, 19 Apr 2011 15:01:44 +0000 http://blog.fasttechnology.com/?p=278#comment-2393 Nice summary of an age-old problem Tommy. One frightening aspect (for me) of growing older is that I find myself quoting Patton more often. Two of his quotes apply well here - "A good plan, violently executed now, is better than a perfect plan next week." and "Take calculated risks. That is quite different from being rash." Another approach to thinking about your problem is to treat the "places" the fix needs to be made as a set. If I can minimize the number of sub-sets I need to handle I will generally have a better outcome. One of the keys of good structured development, whether done in a classic waterfall or with one of the newer RAD or agile methodologies, is that you partition functionality into bit-size subsets. Thus repairing any fundamental flaw in initial assumptions is generally done within that subset (a function or module). In other words, one implementation strategy for the fix might be to try to minimize the set by moving some repeating functionality into a common module. This also moves towards fixing the problem (poorly structured code) rather than the symptom (we have to fix this in 27,343 places). You also touch on some organizational issues. One of my maxims for group-think or meetings is that kicking the can down the road is (almost) always worse than any of the alternatives being considered. Pick one and get on with life. Nice summary of an age-old problem Tommy. One frightening aspect (for me) of growing older is that I find myself quoting Patton more often. Two of his quotes apply well here – “A good plan, violently executed now, is better than a perfect plan next week.” and “Take calculated risks. That is quite different from being rash.”

Another approach to thinking about your problem is to treat the “places” the fix needs to be made as a set. If I can minimize the number of sub-sets I need to handle I will generally have a better outcome. One of the keys of good structured development, whether done in a classic waterfall or with one of the newer RAD or agile methodologies, is that you partition functionality into bit-size subsets. Thus repairing any fundamental flaw in initial assumptions is generally done within that subset (a function or module). In other words, one implementation strategy for the fix might be to try to minimize the set by moving some repeating functionality into a common module. This also moves towards fixing the problem (poorly structured code) rather than the symptom (we have to fix this in 27,343 places).

You also touch on some organizational issues. One of my maxims for group-think or meetings is that kicking the can down the road is (almost) always worse than any of the alternatives being considered. Pick one and get on with life.

]]> Comment on An Old Cliché: Less is More by Garima Jain http://blog.fasttechnology.com/2011/03/less-is-more/comment-page-1/#comment-2325 Garima Jain Thu, 10 Mar 2011 18:35:45 +0000 http://blog.fasttechnology.com/?p=274#comment-2325 This is so real and so well consolidated. Also, more often than not, vendors do not conduct regular performance tests during the course of customization. When the performance deterioration becomes visible, this becomes another area of development and hence another cost addition for the customer. The focus of the product development group should be to build a strong basic design keeping the basic business logic in consideration. Keeping a robust yet basic design will help making customizations without compromising on stability and keeping costs iin control. This is so real and so well consolidated.

Also, more often than not, vendors do not conduct regular performance tests during the course of customization.

When the performance deterioration becomes visible, this becomes another area of development and hence another cost addition for the customer.

The focus of the product development group should be to build a strong basic design keeping the basic business logic in consideration.

Keeping a robust yet basic design will help making customizations without compromising on stability and keeping costs iin control.

]]> Comment on An Old Cliché: Less is More by Steve Kendrick http://blog.fasttechnology.com/2011/03/less-is-more/comment-page-1/#comment-2319 Steve Kendrick Wed, 09 Mar 2011 18:05:05 +0000 http://blog.fasttechnology.com/?p=274#comment-2319 John, Tom paints a very relaistic picture of how we got to where we are with life policy admin systems. Many of the domain experts for earlier systems have moved on, retired or died. Off-shore vendors are recruited to maintain the old with less domain knowledge and limited skills in vintage technologies. Meanwhile the cost to maintain these beasts is "dead money" and contributes nothing to business growth. The vendor challenge as I view it, is to help the customers sort through a strategy of legacy systems versus new product roll-out. Many buyers attempt a strategy of converting old systems to new technology platforms only to learn the economics won't work. Also, the current IT and business folks haven't got the skills necessary to implement the new technologies (e.g rules engines). While many carriers are learning their dilema, trying to help them think through a strategy to address old and new is critical. John,
Tom paints a very relaistic picture of how we got to where we are with life policy admin systems. Many of the domain experts for earlier systems have moved on, retired or died. Off-shore vendors are recruited to maintain the old with less domain knowledge and limited skills in vintage technologies. Meanwhile the cost to maintain these beasts is “dead money” and contributes nothing to business growth. The vendor challenge as I view it, is to help the customers sort through a strategy of legacy systems versus new product roll-out. Many buyers attempt a strategy of converting old systems to new technology platforms only to learn the economics won’t work. Also, the current IT and business folks haven’t got the skills necessary to implement the new technologies (e.g rules engines). While many carriers are learning their dilema, trying to help them think through a strategy to address old and new is critical.

]]> Comment on An Old Cliché: Less is More by Jeff Simpson http://blog.fasttechnology.com/2011/03/less-is-more/comment-page-1/#comment-2318 Jeff Simpson Wed, 09 Mar 2011 11:53:56 +0000 http://blog.fasttechnology.com/?p=274#comment-2318 I agree with Tom. One of the other things I would point out is that vendors need to also react to technology and architecture trends (example browsers in 2000, rules engines in 2005, SOA today). It is a major investment to properly re-architect larger systems to adequately meet these trends, so vendors either don't do it or just end up "wrapping" their existing code - net result is "check the box" for the latest trend, but really doesn't meet the spirit of it and it makes it that much more difficult to manage moving forward (compounding the problem Tom refers to). I agree with Tom. One of the other things I would point out is that vendors need to also react to technology and architecture trends (example browsers in 2000, rules engines in 2005, SOA today). It is a major investment to properly re-architect larger systems to adequately meet these trends, so vendors either don’t do it or just end up “wrapping” their existing code – net result is “check the box” for the latest trend, but really doesn’t meet the spirit of it and it makes it that much more difficult to manage moving forward (compounding the problem Tom refers to).

]]> Comment on A Hidden Root Cause Problem with Software Products by Jeff Simpson http://blog.fasttechnology.com/2011/01/a-hidden-root-cause-problem-with-software-products/comment-page-1/#comment-2274 Jeff Simpson Sat, 22 Jan 2011 13:25:41 +0000 http://blog.fasttechnology.com/?p=243#comment-2274 I agree with this. I would add that the older the system, the more the magnified the problem and ramifications are. Looking at the Life Insurance and Annuity software space in the U.S., the code for three leading systems is 10-30 years old and all shared an early high growth success rate and have dealt with significant acquisitions. Companies like Apple and Google have solved half of the equation by throwing money at the problem, but most companies cannot afford to do that, nor do they have the talent levels. I agree with this. I would add that the older the system, the more the magnified the problem and ramifications are. Looking at the Life Insurance and Annuity software space in the U.S., the code for three leading systems is 10-30 years old and all shared an early high growth success rate and have dealt with significant acquisitions. Companies like Apple and Google have solved half of the equation by throwing money at the problem, but most companies cannot afford to do that, nor do they have the talent levels.

]]> Comment on If Policy Admin Systems Are a Thing of the Past, What’s Next? by Mike Hydanus http://blog.fasttechnology.com/2010/08/if-policy-admin-systems-are-a-thing-of-the-past-whats-next/comment-page-1/#comment-1100 Mike Hydanus Mon, 30 Aug 2010 01:37:17 +0000 http://blog.fasttechnology.com/?p=208#comment-1100 Hey Tom - you see, people do read this stuff! All good - looking forward to our efforts this week... mph Hey Tom – you see, people do read this stuff! All good – looking forward to our efforts this week…

mph

]]> Comment on Fixed Price Waterfall Projects: Perception vs. Reality by WikiRandy Fisher http://blog.fasttechnology.com/2010/07/fixed-price-waterfall-projects-perception-vs-reality/comment-page-1/#comment-1044 WikiRandy Fisher Tue, 24 Aug 2010 15:03:39 +0000 http://blog.fasttechnology.com/?p=145#comment-1044 Responding to "...we would complete our testing and deliver to the client – and the business users would say “this isn’t what we And we would say “but it meets the spec”. want”. - it seems to me there is an important role, that hasn't been explicitly stated. That is, 'checking in' frequently with the business users - to understand their perception as well as identify business pressures that have an impact on the gaps. It's an important feedback loop - that can help you build greater understanding on both the business side and development team, AND in parallel - build buy in and engagement for what comes down the pipe from the development side. - Randy Responding to “…we would complete our testing and deliver to the client – and the business users would say “this isn’t what we And we would say “but it meets the spec”. want”. – it seems to me there is an important role, that hasn’t been explicitly stated. That is, ‘checking in’ frequently with the business users – to understand their perception as well as identify business pressures that have an impact on the gaps. It’s an important feedback loop – that can help you build greater understanding on both the business side and development team, AND in parallel – build buy in and engagement for what comes down the pipe from the development side.

- Randy

]]> Comment on 8 Reasons Why Large Policy Administration Systems Are a Thing of the Past by Gail Nelson http://blog.fasttechnology.com/2010/07/8-reasons-why-large-policy-administration-systems-are-a-thing-of-the-past/comment-page-1/#comment-664 Gail Nelson Mon, 19 Jul 2010 22:53:27 +0000 http://blog.fasttechnology.com/?p=137#comment-664 Tom, Excellent post! You've penned an accurate description of the issues facing those insurers saddled with outdated systems that need to improve their business results, and done it all in plain-English. Tom,

Excellent post! You’ve penned an accurate description of the issues facing those insurers saddled with outdated systems that need to improve their business results, and done it all in plain-English.

]]> Comment on Why Most Successful Companies Stop Innovating and 8 Ways to Avoid the Trap by The Boston Guide http://blog.fasttechnology.com/2010/04/why-most-successful-companies-stop-innovating-and-8-ways-to-avoid-the-trap/comment-page-1/#comment-419 The Boston Guide Wed, 23 Jun 2010 13:38:04 +0000 http://www.fasttechnology.com/blog/?p=103#comment-419 Kudos from one brainiac to another. :) Kudos from one brainiac to another. :)

]]>