conclusion.tex

%!TEX root=index.tex
\section{Conclusion}
The general insurance industry is under financial risk due to losses incurred from the frequency and severity of catastrophic weather events. Unless the insurers can effectively balance high risk policies with lower risk ones, their business model may not be sustainable in the future. ClimatEdge\index{ClimatEdge} has a number of planned offerings around tornado, hail, and flood probabilities that will give insurance underwriters the additional data necessary to categorize the risk level associated with policy offerings.\\

Initial offerings can be developed around tornado and hail probabilities without investing in anything other than a modern server with several terabytes of storage. From an implementation point of view, hail and tornado offerings have enough similar computational requirements and data storage capacity\footnote{The creation of a proprietary hail index, as opposed to buying or partnering, would require more volume, greater variety, and faster velocity.}, that considering them separately did not add qualitative substance. Planned hail forensics are even simpler, just displaying the presence or absence of hail for any recent time frame in a specified location. However as research moves forward into using the \gls{merra} data to reduce uncertainty across offerings, the volume increases substantially. Even with more complex visualizations such as maps or real-time alerting for forensics, it is unlikely that these offerings will ever meet the velocity, volume, or variety necessary of a big data solution. Both the future global and domestic flood offerings will require a substantially more complex framework in order to succeed. Flood will have petabytes of satellite, radar, and news data along with the complex analytics necessary to distill that data into usable probabilities. Unless a scaleable and elastic framework is put into place, the flood portion of ClimatEdge\index{ClimatEdge} will have difficulty succeeding.\\

A big data\index{big data} framework that is both flexible and loosely coupled has the greatest chance of meeting future offering requirements while allowing various technology components to be upgraded. Many commercially available offerings are dependent on particular technologies that have well established strengths and weaknesses. If the framework presentation layer is dependent on a particular storage layer implementation, those two layers are forever tightly coupled and unable to be separated without a major overhaul. While it is expected that a certain amount of coupling is needed\footnote{It is possible to develop abstract interfaces between the layers which minimize the impact of switching technologies.}, e.g. the presentation layer may need to know that certain data structures exist within the data store, it should be possible to implement those structures in Cassandra\index{Cassandra} or MySQL\index{MySQL} as determined by the solution architects.\\

There are several areas of future research centering on how best to store publicly available data sets. There is a dizzying array of tradeoffs in deciding whether to implement remote \gls{api}s, clone the data sets internally, or develop and deploy big data\index{big data} appliances at partner agencies. What is even more daunting is that the solutions will likely vary based on the data set and the offering, leading to the problem of what works well for climate data, may not work well for healthcare or other commercial big data services.\\