Posts Tagged ‘insurance’

5 Ways IoT is Changing Insurance

Thursday, April 28th, 2016

You may appreciate IoT – for insurance, and you may not. Whatever you may think about the Internet of Things (IOT), generally, insurance industry experts think that the IOT will have significantly impact your insurance products, risk pools, loss control, data collection, and sharing of information. For those of you who aren’t so sure about it, here are some of the best things we found out about this feature.

iot_funny

  • Usage-based insurance. Currently, insurance companies gather information from the vehicles of potential customers — think Progressive’s Snapshot — by combining telecommunications with information technology (telematics). They want to determine the vehicle’s history of speed, turning patterns, driving distance and other metrics in a particular geographic area in order to fix a price for insurance coverage how drivers are actually using their automobiles. In the future, IOT devices will talk to each other and give a more precise picture of this type of data, in real-time . The carriers of the future will know more about you and the steps you take to change your habits. IOT will enable carriers to reduce loss ratios, improve growth and margins. Insurance analysts expect that it will prove financially sound for both the carrier and the insured.
  • Sensors: Homes and businesses have been using sensors for a while to track light usage, temperature, toxic fumes, and other metrics in our buildings. Up until now, the sensor reported its information one-way. With IOT, the communication becomes two-way. The sensors will alert customers to the potential for dangerous conditions and reduce the risk of loss from environmental factors that the sensor recognizes as flawed.       Insurance carriers like this aspect because consistent monitoring reduces the risk of a problem spreading or in the case of immediate threat contact the authorities, fire, or health services automatically.
  • Biometrics: We are all familiar with smart devices we call “wearables”, like Fitbits. With the IOT emergence and the improved data enhancements, wearable devices will enable health providers to determine compliance with rehabilitation appointments for disabled patients. Employers will monitor employees activity times and the monitors will even track your heart health. Smart devices will get smarter, communicate with each other and become more customized to your behavior. In the future, biometric devices will not only collect information but report it back to the wearer or to the wearer’s physician, an employer or insurer. A monitor tracking blood chemistry, for example, will alert the wearer to a potential heart attack. This is one are of IoT that is already starting to gain traction. In fact, a recent CB Insights survey shows there are now more than new 50 start-ups with focusing on wearables for the life insurance sector alone.
  • Diagnostics:  Manufacturers embed smart sensors in all sorts of machines, from toys to appliances to industrial machines. As these devices are internet enabled and capable of “talking” to other smart devices, insurance carriers that provide warranties on these various smart devices will be in a position to sell products that offer reports identifying potential impending problems with the device before the problems happen.
  • Carriers’ transformation: The biggest change will occur in the way carriers operate. The tremendous amount of data will mean insurance companies have to figure out the logistics: how are their legacy systems going to communicate with all these devices, how will they store all this data that smart devices deliver; how will they sort through the information and make some sense of it. Some industry analysts predict the IOT will consist of billions of smart devices sending 50 trillion gigabytes of data by 2020. That is four, short years away. The time to figure out the logistics of these changes is now. The in-house IT department meet the need, not only in size but in sophistication. Carriers will need to not only look internally but at third party partners to help streamline and modernize to meet the come wave.

If you want to read more about how the Internet of Things will relate to the insurance field, please see the article entitled “IBM Internet of Things for Insurance“.

To talk more about how FAST is preparing insurers for the IoT future give us a call at 732-225-0008 or visit us at www.fasttechnology.com

 

Getting the Most Out of Your Investment: Three Steps to Revitalize Your Legacy System

Tuesday, October 4th, 2011

Companies don’t need to “rip and replace” large portions of their IT investments in order to gain the set of features they wantBy taking a multi-phased approach to incrementally roll in functionality, organizations can benefit from quicker ROI without the costs and risks associated with “big bang projects”. This multi-step approach is a win-win for business and IT; business can reap the benefits of go-to-market features sooner and IT will be able to adapt to changes more quickly.  Here is our recommended three step approach to revitalizing your IT architecture:

  1. Leverage What You Can: Revitalization efforts have to be carried out with a focus on leveraging your existing architecture. Wrapping your existing assets in web services keeps some of the older technologies in play.
  2. Implement As Needed: Keep it simple and only add functionality that’s really needed. By purchasing pre-built components that augment your existing systems, you can add the functionality you want with minimum configuration and customization.
  3. Rapidly Build New Functionality: Once you’ve decided on the new functionality that you would like to add to your system, we recommend that you rapidly develop these applications using software development automation frameworks such as FAST 8x. By rapidly building SOA-compliant components, you can leverage modern technologies and get the benefits of development efficiency.

Once you have implemented all three steps, you are on your way to fulfilling immediate business needs while achieving long term architectural goals for the future.

If “double dip recession” happens, is your IT group prepared?

Tuesday, August 9th, 2011

I started writing this blog a couple weeks ago…so, now that the market has dropped by 10% it might not look as impressive that I am asking this question.  Obviously, we’re all hopeful that the economy can stabilize and all of our budgets don’t get cut for 2012.  Unfortunately, that might not be the case.

“More with Less”

If you look at Celent’s CIO study from earlier this year, the major theme was: Business expects more from IT. They reference supporting expanding list of initiatives, prioritizing across business groups, escalation of expectations of IT, and balancing cost reduction/capability creation as key challenges and pressures they’re facing.

 

In the last downturn, companies settled for budget cuts equating to less productivity.  Now, I believe we’ll be challenged to get the same amount done for less budget. So, what can be done?

  • Go Agile – if you’re already using an “Agile-like” development methodology, great.  Dive in and examine how you manage your priorities, who the impact players are, and which areas of the process are adding most value.  Eliminate everything else.
  • Get the most out of the tools that are currently available – FAST 8x  (http://www.fasttechnology.com/software/8x/) is an example and I’d be remiss if I didn’t promote our own software.  With FAST 8x, you can build smaller components to solve targeted business problems at a fraction of the cost, time and risk.
  • Avoid big mistakes – Diversify by spreading out your initiatives and deliver value sooner rather than later.  Don’t buy that big packaged core system that is going to be a burden on the entire organization, cost too much money, and risk the farm.
  • Staff reduction is not a “cure all”.  Obviously, eliminating staff and consultants are necessary triggers that can be used to work within a budget cut, but that will most likely compound the problems with the business needing more.  In some cases, you might want to cut even deeper to free up cash for tools and the “right people” to help you navigate through these times.

Pressures and challenges could increase.  Are you prepared?

 

Tom Famularo

FAST

20 Questions to Understand What Your Vendor Means by “Re-Architect”

Friday, July 29th, 2011

I think the term “re-architect” needs to be stricken from our vocabulary.

Whether you’re building a home or a system, the architecture is the first thing you decide upon.  It’s fundamental.  Just as the architecture for a home lays out the blue print for the physical structure, the architecture of a system lays out the blue print from which components and functionality are developed. Before the first batch of concrete is poured or the first line of code is written, you put that blue print in place, and from it every piece of the home or system is defined and developed.

With large-scale systems like policy administration, every line of code is written with that architecture in mind and it is core to everything in the system.  The architecture defines the very essence of the system – it is beyond “foundational”.  Once you go down an architectural path, you might be able to make changes to it, but there’s no re-doing the architecture unless you throw everything out and start from scratch.

So when vendors throw around the term “re-architect”, I think it can be very misleading.  “Re-architect” seems to imply that they have applied some fundamental, structural changes to the software without compromising the system itself; yet, to truly “re-architect” anything would mean a complete overhaul of the architecture that defines it. So, it’s kind of a misnomer.  If they had actually rewritten the system, they would say “we did a complete 100% rewrite from the ground up”.  If they didn’t rewrite it, then there is NO WAY the system is not compromised by the legacy architecture it had.  When you’re purchasing a system – large or small –, there’s a fair amount of legacy architecture and legacy code that comes with the package in almost every case.  You may be OK with that, but you need to have a good appreciation for the extent of it.

Along the lines of finding the “freshness date” or newness of the architecture of the system – as well as just doing some good due diligence – here are 20 key questions I think you need to be asking your vendor as part of the assessment:

  1. When was the last time you “re-architected”?  What parts were not rewritten and why?
  2. Why was the “re-architecting” deemed necessary? And what was the overall impact to the system in terms of % of code rewritten?
  3. What year was the oldest code in your system written?  (I suggest you have the vendor make that a contractual representation and you should get an honest answer.)
  4. For your policy administration system, do you have a monolithic or component based object structure within your code?  If component, do your components reference each other within the code?  Are there database joins that go across your components?
  5. Can you tell me how many lines of code your software is (by language)?  (The purpose here is to gain an understanding of the ratio of newer code to legacy or older code.)
  6. How many customers have converted or committed to converting to this new architecture? For those who have converted, what was the average project duration?
  7. How many lines of code did you write for each of your last three new client implementations?  How long did those implementations take?  (Make sure you can reconcile the lines of code to the duration and that it passes the “smell” test – in other words “if there’s that little code, why did it take so long?”)
  8. Assuming coding changes are required (and they will be), what restrictions are there on using external consultants?   Here the vendor will likely represent that you don’t need to make changes to the core system – do not under any circumstances accept that answer.
  9. How many developers do you have supporting clients offshore and onshore on this platform today?  (Given the low amount of programming you will be told is required, make sure you can reconcile this answer to the answer in #7.)
  10. Am I forced to use your proprietary rules engine?  How easy is it to swap out?
  11. What contractual guarantees are you willing to make about maintaining this platform in the future and future releases?
  12. What is the biggest implementation (# of policies) that anyone who is running on one of your past two releases of the platform we are buying?  (Work to make sure that the answer IS for the platform you are buying.)
  13. List your current clients for the platform I am buying and version of the platform they are running.   (Accept that some clients can’t be named, but insist on a complete list.)  Exactly what functionality are they using and what is the product mix?
  14. Can I have the attendee list from your last user group meeting?  This IS NOT highly confidential and they should be able to give it to you.
  15. Who was the last policy admin customer to go into production for individual life?  Individual annuity?  What were the released version those companies used?
  16. How long did it take your last policy admin customer to go into production (from initial requirements through production)?
  17. Over the past five years, how many companies who have selected your platform where you started projects and the customer never ended up going into production?  (This is information you can learn for yourself in the industry.)
  18. How many policy administration customers do you have that haven’t made a significant number of code changes for customization?  Please name them.
  19. How many policy administration customers have done production upgrades to a newer version over the past five years?
  20. How many customers have terminated maintenance agreement in the past three years?

 

John Gorman

FAST