Brief history of life insurance tech horizon in the recent past

When I met a friend in the evening from the insurance industry, I expected him to tell me few exciting things on tech horizon in the insurance industry in India. Instead, he told me that they were evaluating an integrated back-office system, which would replace many best of breed systems including core insurance system. This would mean the company would discard investment of millions of dollars and efforts of thousands of person years. About 5 years back when I came across world’s leading ERP and Enterprise systems provider’s plans to bring in an integrated suite for insurance companies in India, I wondered whether there would be any takers for them in India.

It has been for a while since I gave serious thought to tech matters for life insurers since I quit my last assignment as the CTO of an Insurance major in India. Sometimes, its very interesting to just look back and ponder over the past while one looks ahead. Here is how insurance tech scene was when I left to co-found Navitus Education, an eLearning venture in 2013:

1. Mobility: My company was engaged in revamping a very successful mobility initiative that we had launched, one of the first of its kind in the industry. While we had started working on the version 2.0 of our initiative, our other peers in the industry had started to work on their version 1.0.
2. Enterprise Social Collaboration: Corporate versions of Facebook, Enterprise social collaboration was expected to be big. In fact so big that few reports predicted that email was going to be dead. Few early adopters including our company in the industry did make attempts to implement enterprise social collaboration, unsuccessfully though.
3. Analytics: Analytics has been the darling of the industry in different shapes and forms for years now. The  buzz in 2013 then was to hire analytics as a service thanks to attention that some of the start-ups received in the media. However, due to the huge cost involved in hiring the data scientists and associated tools, analytics as a service remained out of reach for the industry.
4. Customer facing Apps: Customer facing apps such as self-service Portal, CRM, Illustrations Application, Insurance receipting systems had entrenched themselves well in corporate IT landscape. The corporate IT spend in these areas mostly was for incremental enhancements.
5. Distribution Management System: EDM/CMS, whatever name they existed under continued to be the trouble maker “numero uno” for the IT departments for various reasons: complex distribution hierarchies, unrealistic expectations by distribution teams, over-promise by vendors, and so on.
6. Core Systems: After the initial flips flops the insurance settled for 2-3 core insurance and auto underwriting systems.
7. BPM and Document Management Systems: Afte the initial hiccups and accidents around scalability, the dust had settled in case of most of the insurers.
8. HR and Related Systems: HR managers first were busy hiring and later particularly post 2008 firing employees. Most of the companies were satisfied with implementations of solutions such as HRMS & self service employee portals.
9. SOA: SOA was something on which consultants & vendors made money. Consultants sold SOA engagements & held seminars & workshops. Whereas, SOA vendors claimed that theirs was the only comprehensive SOA platform & product vendors claimed that theirs was the only product that was fully & truly SOA compliant.
10. Cloud: Whether it was Infrastructure As a Service, Platform As a Service or Applications as a Service, industry was extremely cautious in adoption of cloud thanks to the regulations.
11. IT Infrastructure (DC, NW, etc) and Infrastructure Operations Management: Companies followed models largely driven by what Indian promoters implemented. Few leveraged their parents infra while others outsourced. Notable experiments included opex financial model for computing infrastructure and VDI.
12. Information Security/BCP: Was just a lip service and largely addressed to keep the auditors and boards happy. Considering it as a strategic investments area was out of fashion then. In the quest for topline, efforts and investment in these areas were considered sin. However, as data leakage issues surfaced, few companies including mine did start looking at particularly Information Security a little more seriously.

 

Enterprise Mobility (Part IV): Mobility Platforms

If you are in the middle of selecting and/or researching for mobility platforms, it is very likely that you may come across variety of vendors offering platforms types such as:

• Mobile Enterprise Application Platform (MEAP)
• Mobile Cosumer Application Platform (MCAP)
• Mobile Application Development Platform (MADP)
• Mobile Device Management (MDM)
• Enterprise Mobility Management Suites (EMMS)

Should an organisation have all these platforms? Or are these platforms just buzzwords? These terms, on one hand represent the evolution of the mobility platforms, while on the other hand to a certain degree, creativity of the analysts who coined and keep coining these terms.

Mobility platforms are evolving from 2 broad sets of enterprise mobility requirements:

1. Platforms for developing and managing mobile applications during run time, and
2. Platforms for managing administration and security of data and devices

At the beginning of their evolution cycle, mobility application platforms, were referred to as MEAP or MCAP and more recently this family is referred to as MADP. Similarly, the mobility admin & securliy platforms which were referred to as MDM earlier, are now referred to as Enterprise Mobility Management Suites by Gartner in their 2014 Magic Quadrant report.

Mobility application platforms typically offer the following:
– Development Environment, which can be used to build cross platform apps
– Run time environment or server-side environment for data routing, transformation and movement / integration / syncing between mobile devices hosting the mobile apps and back-office applications
–   Mobile Apps Administration in terms of user management, version management, etc.

Mobility Admin and Security Platforms offer the following features:
– Mobile Devices Lifecycle Management: Registration, Administration, Retirement
– Device Trackinig
– Data Security & Encryption
– Data back-up
– Remote data wipe-off
– Private App Store
– Remote support

Considering that Mobility application platforms offer much more than development toolkit, one wonders as to why they should be called as Mobile Application Development Platforms.

A lot of platform vendors from both the families of these platforms, are already offering overlapping functionality, particularly, Mobility Application Platforms are fast encroaching into the area of Enterprise Mobility Management suites. I expect these two types of platforms to consolidate into single platform. So, in case you are in the middle of choosing either (and particularly) the application platform or mobility management suites, then make sure to check the product roadmap of these platforms.

Enterprise Mobility, Part III B

Non Functional Requirements, Part B (To read part A, click here)

vii. Device Registration

In case mobile apps are built for employees, organisations typically want better control on who the users are and what devices these apps are accessing from. So, while mobile app can be downloaded from a public app store and installed, by default, user with valid username and password may not be able to use the app. The device’s unique id registered with the with organisation so that it can be authenticated that only valid users have access to the application and corporate data. Even in cases, where the mobile apps are for customers and partners, restrictions on no. of devices from which the app can be accessed can give comfort to both the users as well as the organisations and protect privacy and confidentiality of data.

viii. Private App Store

There are multiple ways, in which, enterprise mobile apps can be distributed. Mobile apps can be published in public app stores or can be distributed through corporate IT infra, or apps can be hosted in private app stores. Establishing private app stores can give organisations much better control on what employees can install on the devices, especially if devices are owned by the organisation. It is expected that, as  mobility initiatives become enteprisewide, organisations would naturally opt for private app stores and hence it may makes sense to plan for one right for the initial stages of the initative.

ix. Device Deactivation / De-registration

Mobility initiatives face a major change management risk. A long with the ease & empowerment they offer to the employees particularly in the field, they tend to enforce discipline, bring about uniformity in processes, and also at times increase in efforts in the hands of the end user. One of the ways by which this risk can be mitigated is by threatening deactivation of the app in case of non use. So, one of the requirements we encountered was to deactivate the user login in case user did not login into the app for 3 continuous days. The reactivation in this case would require users to give explanations to supervisors and super bosses. Permanent device deactivation is also required in the form of device de-registration when the employee leaves the organisation.

x. Device Tracking

Device tracking is critical for organisations where mobile device is owned by the organisation. Mobile devices like smart phones and tabs are expensive investments, and hence it becomes necessary for organisations to track them so that they can be recovered in case of theft or loss. One of the requirements, that I had encountered was to recommend optimum path for sales or service executive while addressing customer sales / service requests and compare the actual path and deviations. Also, send real-time alerts to the executive to address urgent customer requirements in case of irate or priority customers.  Thus device tacking may be become an important risk mitigation mechanism as well as means to achieve tactical benefits.

xi. Remote Back-up

Remote back-up of the data on the device can be useful in case the device is lost or damaged or is required to be reset. Hence organisations may seek mobile apps to have a feature to take back-up of the critical mobile app data and have it stored on the central servers.

xii. Remote Wipe-out

Remote wipe-out is the last option in case the device is lost. This can at least ensure that critical organisation data does not fall in the wrong hands.

These are some of the non functional requirements, which mobility initiative architects and analysts may or may not hear from business users but certainly may have to consider while implementing their respective enterprise mobility initiative. The list of these requirements above may not be comprehensive and also may not be applicable to all the mobility initiatives. One would be required to carry-out cost benefit analysis then decide whether the solution being implemented should design for these non functional requirements.

Enterprise Mobility, Part III A

Non-functional Requirements

Enterprise Mobile Initiatives, as discussed in the previous post, are complex & challenging endeavors. While it may be a single app, or multiple apps, the easier part of the Enterprise Mobility jig saw puzzle is to address business / functional requirements. These are mostly explicitly stated by business users. The more challenging aspect is addressing non functional requirements. These typically come up over a period of time as the mobile apps start getting used by enterprise users. If these requirements are not addressed quickly, then can even lead to failure of the mobility initiative.

I have listed some of the prominent non functional requirements below, based on my experience. I must confess, however, we learnt some of these requirements the hard way while the mobile apps were in use by the end users. In one case, we had to recall the app, pause the initiative, fix the issue and relaunch. This meant rework, anxiety and project cost escalation. I do not say these requirements would be applicable to the mobility projects that you may be associated with, but certainly, you should pay as much attention to these non functional requirements as much you would to functional requirements.

i. Offline functioning of Mobile Apps

A large number of use cases of Mobile apps are related to sales & distribution/customer service, enabling this staff operating in the field. The consumer that they have to deal with, in the field needs to be served quickly, without hick-ups. Connectivity of mobile devices especially inside buildings is always a challenge, and our early experience showed that sales / customer service staff has to face a lot of customer ire, when the app couldn’t function for lack of connectivity. So, mobility apps may be required to operate in off-line mode.

ii. Data Sync capability between the mobile device and data center servers

Once a mobile app is required to operate in an offline mode, it is inevitable to have business rules and validation logic coded in the mobile app and also app transaction data stored in the mobile device, although temporarily. Typically, the requirement in case of off-line mode apps is to send the data to the back-office apps so that business transactions can be triggered / fulfilled within the promised SLAs. Sync capability can be built either auto (mostly) or manual.

iii. Data Security in case of storage data in the mobile device

Apps supporting off-line mode operation, store data in the mobile device itself. In one of the apps that I was building, the stored data included customer data and along with the signature. The Risk team flagged it as a major risk, and we were required to not only sand box the data folders but also store the data encrypted. So, mobility solution architects are required to assess sensitivity and risks associated with the data managed by the app and establish appropriate level of controls.

iv. Mobile Apps Version & Release Management

Expect, if the mobile initiative / app being implemented is mission critical, the mobile app to undergo a number of enhancements. Such new versions of the mobile app carry not only enhanced functionality but also fixed bugs and so, the occurrences of release of versions can be frequent in the initial phases of the project. Thus enterprise mobility initiatives need to plan for proper version management and version release processes. Download and self installation of the new versions as soon as they are available may be required to be automated and coded in the mobile solution.

v. Remote Support

Most of the mission critical enterprise mobility initiatives are meant to be used by mobile workforce, who operate in the field with minimum support or touch-points with office locations with proper IT support infrastructure. In case, the mobile apps involve complex and long transactions such as new customer acquisition transactions, mobile workforce needs top quality support. Such support either could be local or remote. For remote / centralised training & support desk to be effective, they need to be provided with software tools, which can enable them to either take remote control of the mobile devices or view shared screens.

More non-functional requirements will be covered in the next blog post.

Enterprise Mobility, Part II

Defining Enterprise Mobility Initiative

Many organisations look at their Mobile initiative as a Single App initiative, especially in the initial phase. They tend to equate the initiative as one point application like any other enterprise class system. Mobility project starts as a pilot or POC project with time and budget constraints. As the POC initiative gains momentum and takes the shape of larger enterprise wide initiative, requirements for basic foundation, typically non-functional requirements need to be addressed. Else, the initiative starts imploding giving rise to data issues, scalability issues and so on. So it is essential to address these non-functional requirements right at the inception stage.However, before we discuss these requirements, lets define the criteria for Enterprise Mobility Initiative.

Mobility initiative should be considered of Enterprise class, if it meets any of the following criteria:
1. 3-5 mobility apps are built/required to be built
2. Users group include any of 2 of the following groups: Employee / Customers / Business Partners / Suppliers
3. No. of users exceed 500
4. Mobile Device strategy for employees covers BYOD
5. Integration with back end systems involves more than 2 back end systems

Once the organisational mobility initiative meets, any one of the above criteria complexity in areas listed below increases many folds:
– App support for Multiple Mobile OSs,
– User Experience on multiple devices / OS / form factors,
– User Management,
– Device Management,
– Data Management,
– Integration Management
– System Administration
– Time To Market

And this increased complexity requires a platform based approach to develop and manage run time environments of these mobile applications.

In case of large enterprises, it is only a matter of time, that the initial POC or pilot project takes shape of Enterprise class. Architects responsbible for mobility initiatives in these organisations should either plan for platform based approach right from the beginning or alert organisations of rework.

Lets look at some of the critical non functional requirements, essential in building this platform based approach in the next article.

Enterprise Mobility, Part I

Introduction

Business organisations have spent their energies on leveraging mobile devices for delivering businesses value for over a decade now. Initial mobile apps were simple SMS based apps running on feature phones. Some organisations even had custom-built POS (Point of Sale or Service Devices) fitted with mobile sim card and running simple new business or payment collections apps. Easy to carry, Mobile devices were and are seen as a very potent device in the hands of customers or mobile employees engaged in sales and customer service activities. Self service apps running on mobile devices can deliver instant gratification to customers and improve productivity of mobile employees. Despite the advantages, enteprise mobile apps did not see as much popularity or serious thought amongst corporate think tanks, as early mobile technology posed challenges in terms support for multiple OSs, user experience and device & data security.

Organisations started thinking seriously about mobile apps after the launch of iPhone in 2007 and particularly in 2009 when Android based smart phones started becoming popular globally. Smart phones allowed organisations to build apps with rich user interface leveraging data connectivity. The corporate mobility initiatives received a real impetus in 2010, when iPad and Samsung Galaxy Tab was launched. Tablets overcame the limitation of smaller screens issue that smart phones posed and are light & rugged enough for mobile employees to carry them along with themselves. I implemented one of the early large scale mobility initiatives for an insurance company in India, one of the toughest and challenging assignments of my career.

Most critical success factors (CSFs) for the successful implementation were completely non technical such as CEO sponsorship & support for the project, CEO driven Change Management within the organisation, Big bang implementation approach, An incentive programme for the users, and a Support Center to monitor the application utilisation & provide technical support. However, technical design & architecture and technology selection & implementation approach were perhaps the most critical factors for successful implementation of the project. Some of our technology design and implementation choices were very deliberate, while others were based on our view about the future of mobility.  In the following blog entries I’ll focus on the technical aspect of the enterprise mobility initiatives discussing questions such as:

• How does one Define Enterprise Mobility Initiative?
• What should be the approach to implementing Enterprise Mobility Initiative?
• What critical business/ technology requirements that enterprise mobile apps need to meet?
• What are various mobility platforms such as MEAP, MCAP, MADP, MDM, EMMS?
• What are the architecture components of Enterprise Mobility Solutions?
• What OS should the mobile apps be supported on?
• What is the right mobile app: Native or Hybrid?

While I pen down my thoughts, it would be interesting to hear your views. Do share your experience. Also do not hesitate to write to me in case you have questions or need clarifications.

Tablet Wars

Yesterday, a colleague brought to my notice, an offer from a leading Android Tablet manufacturer. The sales promotion offered the Tablet at a significant discount and also included a number of freebies such as a bluetooth headset and almost about Rs 4,000 worth of movies and games to download.

When one correlates it with what is happening recently in the in the Tablet segment of the market, its not very difficult to see what is likely to emerge over the next few years. Here are some recent developments in Tablet market:

* Google launched its Nexus Tablet in July with a starting price of $199

*  Apple’s iPad Shipments, Market Share Surge, IHS Reports:  After testing initial success and Apple consistently lost the market share (which was obvious considering that they created Tablet market segment!) till the end of 1st quarter of 2012. However, Apple arrested the decline and showed growth in Q2 of 2012 when their market share improved from 58% to about 70% after the launch of “The New iPad”.

* As Tablet Race Heats Up, Apple May Try Smaller Device: Many newspapers and journals are now speculating that Apple is expected to launch a 7″ tablet in Q3 or Q4 of 2012.

* Microsoft announces the launch of Surface Tablets: Tablets will be launched in October and initially will be available in 2 models, depending on the version of Windows 8, the tab will be running on and the processor (One with Windows 8 Pro running on Intel processor, while the other on Windows 8 RT running ARM processor). Incidentally, I also had a presentation from and discussion with Microsoft team on Windows 8 and could assess the impact of the OS & Surface Tablet on corporate IT landscape.

Considering these recent developments, I was not at all surprised of the sales offer from this leading Android Tablet manufacturer. If we are not already witnessing, we are indeed going to witness mother of all wars for supremacy in the Tablet device segment spanning next few years. No one can predict who will be the winner, but one can see some trends emerging:

1. Microsoft is positioning its device as a single personal device unlike other Tablets which typically act as an additional or supplementary device to the Desktop PC or Mac. Considering this as well as its dominant position in Desktop OS segment (92% market share, source: NETMARKETSHARE), Windows will emerge as a dominant player in Tablet and Tablet OS market.

2. Corporates will more likely standardise on Windows Surface or Windows OS Tablets for their employees rather than other Tablets considering the compatibility of Apps between Desktops and Tablets running on different versions of Windows 8.

3. Apps are here to stay, which means that IT department of organisations will have have to maintain multiple versions of Customer and Partner facing apps even if they standardise on Windows 8 as OS for their employees.

4. Microsoft may emerge as the dominant player amongst the corporate employee segment with option of BYOD (Bring Your Own Device)

5. Most of the international and marginal players will not be able to move beyond their niche. Ultimate fight for supremacy over Tablet and Tablet OS market will be between Apple and Microsoft, with Android being a distant 3rd player.

6. MDM (Mobile Devices Management) software is likely to emerge as a very flourishing business segment and we will see more players entering this segment.

7. Adoption of Web Portal technology as an enterprise application segment is likely to decline.

8. Sale of Desktops and Laptops may see decline, although desktop usage will continue in those cases where complex client end computing is required.

9. Price wars are eminent.

10. It will benefit to be a customer!

What is your take on the future? Would be glad to hear from you.

PS:

Following are 2 links giving Tablet comparisons, which you may find useful:
1. Nexus 7 Tablet vs. Kindle Fire vs. the Rest: Spec Smackdown
2. Tablet comparison chart

Sidewalk: Democracy 2.0, participatory democracy

Last 2 weeks, India witnessed an unprecedented nonviolent & peaceful agitation to pursue government and parliament to enact an anti corruption law. It involved one man, a Gandhian, named “Anna Hazare” going on fast demanding immediate enactment of the law. Thousands across India supported & participated in the agitation. As the health of the fasting 74 year old Anna deteriorated government, parliament and representatives of the so called “civil society” worked together to resolve the impasse. While, the law has not yet been enacted, On Aug 27, 2011, 2 houses of the parliament passed a resolution unanimously to enact a strong anti corruption law. This has been now considered a historic day by many. While others, although in minority feel that the agitation and means adopted to pursue the government and parliamentarians were undemocratic. Those who have opposed and criticised the movement have not provided answers as to how people at large can be involved in democratic process going beyond voting in elections once in 5 years.

To my mind, the biggest ill with the largest democracy in the world is that it is not as participatory as it should be. Having said so, I have lot of questions. What is participatory democracy? Does participatory democracy mean voting once in 5 years alone? What are the elements or aspects of democracy in which people can participate? What are legitimate, constructive, and decentralized ways by which people at large can be involved in policy making making process? Will such a process be feasible,effective and efficient? Can Information Technology play a role to make participatory democracy a reality?

I never thought that political science could be so interesting. I am not a student of political science. But I must say that it is the right time to be a student of political science. If we feel that recent agitation involving scores of citizens across India was not democratic, then we must find & come up with ways & means by which citizens can be enabled to participate in democratic processes in democratic ways.

Interestingly, when I googled on participatory democracy, Google threw up a Wikipedia page on participatory democracy: http://en.wikipedia.org/wiki/Participatory_democracy



I also came across at least 3 initiatives where citizens are or are being involved in framing the consitution:

* Iceland crowdsources its next constitution

* Egypt’s Watiqah (Basic Document) for human rights principles to be enshrined in constitution

* Morocco’s crowdsourcing initiative for consitituional ammendments

While Democracy 2.0 is much beyond crowdsourcing, I feel it is time for Democracy 2.0.

Sidewalk: Business Design Principles

Sometime back, I was invited to participate in a Round-Table discussion by Welingkar Institute @ Matunga, Mumbai. The theme of the roundtable was Empowering India. At the end of the round-table, participant’s views were sought on new breed of MBAs – Business Designers & Business Design.

Business Design was very aptly defined by one of the participants as design of Strategy, Product, and Process. Organisations have specific functions which take care of Strategy, Product and sometimes even process design. Process design though is largely addressed through quality initiatives like ISO, Six Sigma and TQM. Now when an MBA is packaged as a Business Designer, the package indeed looks attractive. Very raraly though MBA would get an opportunity to work on all the 3 aspects of Business Design simultaneously with the exception of Consulting.

I have had an opportunity to go through Business Design, when we launched IndiaFirst Life Insurance, the latest entrant in life insurance sector india. My work largely focussed on operations and process design, and here are my inputs:

1. Focus on the customer and end user

May sound a bit cliched, but remember that the product and process & systems you are designing are for customers and users respectively. Understand the pain areas & challenges of your customer / user, while carrying out your business design. A solution or design that addresses end user’s challenges automatically improves the acceptability of the solution.

2. Business Design has to be contextual

While designing process or product, you needs to see the context in which they are applied. When IndiaFirst project team was formed, most of us came to the table with strong agency driven life insurance company background. Whereas IndiaFirst is largely a bancassurance company. When we were made to see our business in the context of bancassurance, we realised that agency driven life insurance operational processes could be improved upon significantly to establish low cost n faster TAT operations. What works in one environment may not work in another. What works for an old organisation may not work for new organisation, and vice-versa. So, understands the context before designing business.

3. Design the blueprint & establish a roadmap

In case of operation or system design, make sure that the blue-print of the design is ready in sync with long term business goals. Business designers tend to typically trade short objectives for long term goals due to cost and time constraints. Any operations or systems built keeping in mind short term goals involve rework and waste. Make sure that you understand long term business objectives, draw a blue-print identifying all the components of the solution and define implementation roadmap in case you have to opt for an incremental approach to implementation.

4. KISS – Keep it Simple n Stupid, stick to basics

Innovation is a buzz word today. If you do not innovate you are out of the game. Designers, as a result, are always under tremendous stress to innovate n come up with completely radical n new ideas. As a result, most of the time, business designers over-engineer & over-complicate processes and products. Avoid over-use or emphasis on technology.

Sidewalk: IT Process Model

In one of the on-line forums, a colleague posted question on processes in end user organisations to ensure effective delivery by IT functions.

A number of times, while implementing any process framework, the focus is on the letter rather than the spirit of the framework. Process framework needs to be adapted and not adopted. The emphasis is always implementing processes as they are rather than customising them to the needs of the organisation. There are well established process frameworks like COBIT and ITIL. I would propose the following IT Value Chain process lifecycle framework, which would have core value chain processes and support processes. Typically, core value chain processes would be:

> Strategise and Architect: Formulate IT Strategy and design IT systems and infrastructure Architecture

> Plan & Evaluate: Plan system and infrastructure implementations and evaluate & select system and infrastructure technologies

> Develop and Implement: Develop and Implement IT system and infrastructure projects

> Enhance & Maintain: Enhance & maintain IT systems and infrastrcture

The above processes could be drilled down into sub-processes and activities such as RFP, System Delivery Management, Change Management, etc.

Examples of support processes would be: IT Governance, Information Security Management, Asset Management, IT Procurement Management, IT Payments Management, etc.

What do you think?