Brain Dump of an Insurance Technologist
Underwriting - The term is derived from Lloyd's of london insurance market, where insurers will literally write their names under the risk information slips. The term indicates careful evaluation and ownership.
Showing posts with label Architecture. Show all posts
Showing posts with label Architecture. Show all posts
Thursday, December 31, 2020
5 Decisions impacting ‘Data on Cloud’ strategy for insurers
Insurance companies are doubling down on their data, analytics and A.I investments to be ready to compete in a ‘Post-Covid’ digital economy. In the last couple of years, multiple cloud-based technology platforms have emerged and Insurers are actively exploring ways to take advantage of this technology ecosystem.
It is not an easy decision as technology is rapidly evolving and there are many strategic questions to ponder -
· How do you ensure that you have an ability to pivot in future in response to evolving technology and business needs ?
· Should you redefine your data model or continue with the same ?
· What should be your data integration strategy?
· What kind of A.I/ML capabilities you need to provide ?
· How do you provide a self-service data visualization augmented by A.I ?
I have explored these aspects in my ‘Point of View’ article - 5 Decisions impacting ‘Data on Cloud’ strategy for insurers - https://www.lntinfotech.com/wp-content/uploads/2020/10/POV-5-Decisions-Impacting-Data-on-Cloud-Strategy-of-Insurance-Enterprise.pdf?pdf=download
Friday, January 4, 2019
AI driven Knowledge Management
I have been working with a large insurance company to define its knowledge management strategy and solution architecture. As I dug deeper into business scenarios, I realized that ‘Knowledge Management’ is the key area where A.I technologies will have immediate and significant impact on insurer’s bottom line.
.... click here for more ->
https://www.linkedin.com/pulse/ai-driven-knowledge-management-amit-unde/
Wednesday, September 18, 2013
New article : Big data Trends 2014
The recent article in Alsbridge Outsourcing Center - Big Data Trends 2014, includes some of my thoughts on how Insurance companies can effectively leverage the super abundance of data - http://www.outsourcing-center.com/2013-09-big-data-trends-2014-new-uses-new-challenges-new-solutions-58181.html
Here are some excerpts -
Here are some excerpts -
In this era of low interest rates, insurance companies need strong real-time analytics capabilities to achieve the elusive underwriting profit and sustained growth,” explained Amit Unde, chief architect and director of insurance solutions for L&T Infotech. “Going forward, the competitive battles will be played on the data turf. It’s the companies that leverage both external and internal Big Data, predictive analytics and adoptive underwriting models that will come out on top.
With Google Maps and location intelligence services, the underwriter can view a property from all angles and assess distance from a coastline, flood plain or other potential hazards. Online access to hundreds of different data sources—from videos to photos to loss trends and other documents— is now just a few clicks away,” Unde said. “But, without the right tools, mining this data is still a highly manual process.
I wouldn’t be surprised if, in the next five years, the next big player in the commercial insurance industry was a new company with a Big Data-driven automated policy issuance and claims payout model,” Unde said. “Automated decision-making has the potential to transform the industry, enabling small players to compete with large insurers, based on their technology.
In the insurance industry, companies should validate against a set of rules or cross-verify against multiple sources,” Unde said. “However, in most cases, it doesn’t make sense for insurers to boil the ocean to get 100 percent data accuracy. It makes better sense to apply the 80/20 rule to achieve the desired accuracy for the 80 percent of the dataset without having to invest intensive efforts—then asking ‘did you mean’ questions in the remaining 20 percent of cases.Let me know what you think about the article.
Monday, February 1, 2010
Agile adaptation of Architecture Evaluation Methodologies
I discussed some of the architecture evaluation methods in my previous post. In short, the idea is - Rather than just using a checklist for technical evaluation, we should test drive each functional scenario against architectural decisions and judge the impact on quality attributes (utility tree) and evaluate the architecture. Such a review will be more specific to the project and hence, more beneficial.
Many accept the advantages of these methods, however, often criticize these methods for their overhead. I think, these methodologies can certainly be adapted for agile use. We do not have to stick to the the elaborate process that SEI has recommended, but instead, we should adapt it for our use by sticking only to its principles. In fact, in my experience, these methodologies are more beneficial if we use them in conjunction with agile development methodologies.
- Amit Unde
Many accept the advantages of these methods, however, often criticize these methods for their overhead. I think, these methodologies can certainly be adapted for agile use. We do not have to stick to the the elaborate process that SEI has recommended, but instead, we should adapt it for our use by sticking only to its principles. In fact, in my experience, these methodologies are more beneficial if we use them in conjunction with agile development methodologies.
Why Architecture evaluation is important for Agile methodologies?
In Agile world, the application functionality is to be built in agile way, with constant visibility to business, and frequent changes to the features. However, the same is not the case for its architecture. If the architecture is allowed to evolve with changing requirements, it causes frequent rework, constant re-factoring and in fact, it counters the ‘Agile’ response. It makes sense to spend upfront time on architecture evaluation and ensure that it is flexible to accommodate the future changes.
In Agile world, the application functionality is to be built in agile way, with constant visibility to business, and frequent changes to the features. However, the same is not the case for its architecture. If the architecture is allowed to evolve with changing requirements, it causes frequent rework, constant re-factoring and in fact, it counters the ‘Agile’ response. It makes sense to spend upfront time on architecture evaluation and ensure that it is flexible to accommodate the future changes.
What are the steps in evaluation?
I assume that you have background of standard evaluation methods such as ATAM / CBAM. If not, refer my last post. Though SEI has defined a very elaborate process, I think, only the following are critical steps –
Step 1 – Prioritize functional scenarios along with all stakeholders and identify architectural approaches and alternatives
Step 2 – Generate Quality Attribute Utility Tree and specify Stimuli – Response for each scenario
Step 3 – Analyze architecture approaches and identify all possible
a) Risks,
b) Non-Risks,
c) Sensitivity Points ( interdependencies) and
d) Trade-Off Points.
Step 4 – Quantify the Benefits of different architectural strategies and corresponding Cost and Schedule implications
Step 5 – Calculate desirability (benefit divided by cost) and Rank the alternatives.
Step 6 – Make decisions and document
What about the overhead of evaluation? How can it be done in Agile Way?
To make these methods more agile, use following techniques -
- Evaluate on Sampling basis –Short-list only the unique and critical scenarios that are likely to change.
- Create the artifacts such as Utility Tree as part of Architecture development process and not just for evaluation. The act of creating the utility tree will improve the thought process while defining the architecture.
- Evaluate everyday as soon as you discuss the scenarios in the war room. All the stakeholders are present in the war room. This avoids extensive planning, presentations, and elaborate evaluation exercises.
- During the evaluation, apply the utility tree to each scenario and evaluate the Sensitivity Points, Risks /Non-risks points, and Trade-off points. In case of alternative solutions, estimate Cost and perform Cost-Benefit analysis.
- Evaluate not only for the defined scenarios, but also for the possible changes. Get the ‘change’ scenarios from the business to evaluate the impact of changes. The architecture should be flexible to accommodate such changes.
Wednesday, January 13, 2010
Test Drive your Architectures for effective evaluations
Are you one of those sitting in ivory towers of Enterprise Architecture Group, tasked with responsibility of evaluating project architectures and ensuring IT Governance? If you have done few reviews before, you would know that it is highly subjective process that depends largely on the evaluators’ technical skills, functional/environmental knowledge, authority structure, and other political forces. The evaluators who are parachuted into the project group for reviews are especially handicapped due to lack of knowledge of functional requirements, and often only concentrate on ‘technology’ implementation reviews. Hence, most of the reviews remain superficial and only partially beneficial.
So how exactly should you evaluate the architectures?
I would say do what you do when you buy a car. Test Drive! You will only know the car’s performance when you actually drive it and feel it, and not just by reading specifications or by asking questions. Similarly, to evaluate the architecture, apply it to the specific functional scenarios and measure the quality attributes.
Carnegie Mellon Institute (SEI) has developed the architecture evaluation methodologies on the same principle. The most known methods are –
This methodology analyzes how well the software architecture satisfies the quality attributes (e.g. scalability, modifiability, performance etc), by applying the architecture to short-listed functional scenarios. It prescribes developing a quality attribute utility tree, and analyzing it for each scenario and alternative architecture approaches. For each scenario, the method prescribes identifying the following –
a) Sensitivity points – a collection of components that are critical for achieving a quality attribute,
b) Trade-off points – a sensitivity point that affects multiple quality attributes, typically trades one off for the other,
c) Risks – something that inhibits the system from achieving its quality goal (this also includes the decisions that are not taken),
d) Non-risks – something that is done right (and should not be changed)
CBAM begins where ATAM leaves off. It prescribes analyzing the cost, benefits and schedule implications as well for architectural approaches before making the final decisions.
This is more of a design review than architecture review, but uses the same principle of applying design to scenarios, and even writing a pseudo code to evaluate different parts of design.
The SEI has documented a very formal step by step process for all these methods. One way that may be counter productive as people tend to focus on activities, rather than the principles behind these methods. There is a great scope to tailor these methods to suit your organization, and conduct such evaluation in agile way.
More on this topic later…
- Amit Unde
Thursday, April 24, 2008
Role of an Architect
I recently published an article in Microsoft Architect Journal about the 'Role of an Architect' from system integrator perspective. http://www.msarchitecturejournal.com/pdf/Journal15.pdf
For HTML version, click - http://msdn2.microsoft.com/en-us/arcjournal/cc505970.aspx
Any comments ?
For HTML version, click - http://msdn2.microsoft.com/en-us/arcjournal/cc505970.aspx
Any comments ?
Wednesday, November 14, 2007
Microsoft Certified Architect - Is it worth it?
Since I pass my MCA certification (solution architect) last year, I keep getting many questions from peers about MCA. Given the cost and efforts involved in getting certified, many wonder if it is worth getting certified.
I think, it definitely is. Here is why -
1) First, it is pretty hard to get through. That is what makes in more valuable. It is recognized highly in the industry. You may be surprise to know how many CIOs are aware of this certification. I am personally benefited from the MCA title at numerous occasions.
2) It is not only the Technology certification. It stresses equally on many other aspects such as Leadership, Communication, Organizational Dynamics, Strategy, and Processes along with technology (breadth and depth). You will not be able to get through if you are too operational OR too hands-off.
(Contrary to popular belief it is nothing to do with Microsoft technology. I presented case study based on J2EE technologies.)
3) It certifies the experience and not the knowledge alone. In the interview, all the questions are targeted for judging what you have done (rather than what you know). The questions are pretty deep. It is almost impossible to bluff in front of 4 experienced senior architects.
4) It is a great experience of going through the certification process - the mentoring, preparations and appearing in front of the board for interviews. You learn a lot in the process. You don't lose much even if you happen to fail.
5) Finally, though it is tough, if you have experience of architecting systems and if you put right efforts preparing your case studies and presentations, it is something achievable. It is definitely worth trying if you want to make career as an architect.
If you are not aware of Microsoft certification process, refer to - http://www.microsoft.com/learning/mcp/architect/solutions/default.mspx
I found a very interesting blog that describes the architecture process in a much lucid way - http://blogs.dirteam.com/blogs/natashamocke/archive/2007/09/02/microsoft-certified-architect-certification-process.aspx
I will be happy to assist if you are preparing for the certification.
I think, it definitely is. Here is why -
1) First, it is pretty hard to get through. That is what makes in more valuable. It is recognized highly in the industry. You may be surprise to know how many CIOs are aware of this certification. I am personally benefited from the MCA title at numerous occasions.
2) It is not only the Technology certification. It stresses equally on many other aspects such as Leadership, Communication, Organizational Dynamics, Strategy, and Processes along with technology (breadth and depth). You will not be able to get through if you are too operational OR too hands-off.
(Contrary to popular belief it is nothing to do with Microsoft technology. I presented case study based on J2EE technologies.)
3) It certifies the experience and not the knowledge alone. In the interview, all the questions are targeted for judging what you have done (rather than what you know). The questions are pretty deep. It is almost impossible to bluff in front of 4 experienced senior architects.
4) It is a great experience of going through the certification process - the mentoring, preparations and appearing in front of the board for interviews. You learn a lot in the process. You don't lose much even if you happen to fail.
5) Finally, though it is tough, if you have experience of architecting systems and if you put right efforts preparing your case studies and presentations, it is something achievable. It is definitely worth trying if you want to make career as an architect.
If you are not aware of Microsoft certification process, refer to - http://www.microsoft.com/learning/mcp/architect/solutions/default.mspx
I found a very interesting blog that describes the architecture process in a much lucid way - http://blogs.dirteam.com/blogs/natashamocke/archive/2007/09/02/microsoft-certified-architect-certification-process.aspx
I will be happy to assist if you are preparing for the certification.
Subscribe to:
Posts (Atom)

