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 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.

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.


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

Happy New Year

Happy New Year! May the new year be brighter and happier to all!

I know, off-late, I have not been able to blog for a number of reasons or should I say excuses. But I have also realised that last few months I have been hopelessly out of touch with the latest in the IT world, which is not such a wise idea. So, you will keep hearing from me more often!

And here is the most impressive new year advise that I received:

“Due to cost cutting don’t turn off the light at the end of the tunnel.” 🙂

Keep in touch. Keep writing. Keep smiling.

Sidewalk: Best IT Implementation of the year 2007 – India

PC Quest of India is inviting nominations for Best IT Implementations for the year 2007. The only qualification criteria is that the implementation be for use in India though hosted any where. So if you think you have an implementation to nominate, here is the way to go:

Good luck.

BPM Series: New Year Resolutions of a BPM Project Manager – Resolution #4

Resolution #4: I will have performance benchamrking done before every BPM roll-out

A typical BPM implementation such as the one I was involved in recently, for automation of New Business process involves integration and interaction with multiple back-office systems. In a number of cases, BPM implementations also have imaging or content management system as one of the components. And if such BPM implementations are carried out to automate mission critical processes, response time and speed of the system becomes extremely critical. Just imagine, user clicks on a work item in the worklist and it takes 15 or 20 seconds for the system to open the work item and document image for the user. A system that has un acceptable response time can cause huge amount of resistance amongst user community to accept and use the system. In such cases, infrastructure sizing and tuning ahead of the implementation becomes extremely critical.

So, for a successful BPM implementation, talk to users and agree upon the acceptable performance standards. Assess the load during the peak business period and make sure that your production infrastructure and software are tuned to take the peak load through a performance benchmarking exercise involving load testing, and soak testing. Such tests record system performances for the target load. The test results provide enough inputs to de-bottleneck production environment by ensuring adequate infrastructure is deployed and software applications are appropriately configured.

Resoultion #3

SaaS, Shared Services, BPO – Will they converge?

Now that’s an interesting question. Combination of SaaS – Software as a Service offered along with the process service either in the form of Shared Service or BPO seems very very feasible and attractive proposition.

However, I think that SaaS, on its own, is yet to prove itself as a credible alternative to packaged / custom-built software applications. SaaS is in a very primitive form to convince IT as well as business organizations to opt for itself for mission critical applications such as Core Insurance system or ERP. There are a number of parameters that need to be given consideration before a decision in favour of SaaS can be taken. Few days back I had written a blog entry “Software as a Service – A reality check!” detailing parameters that can govern decision of organizations against or in favour of SaaS.

Are shared service and BPO two sides of the same coin?

In shared servies, you seek to pool resources offering similar services to various departments / divisions / SBUs within the organization. The objective is to achieve economies of scale, and maintaining optimum level of resources so as to reduce costs as well as offer SLA based services to consumer departments / divsions / SBUs. Examples of shared services are call centers, payroll, analytics, leagal and complicance services.

Is BPO greatly different from Shared Services? The only difference is that BPOs typically tend to be independent organizations which offer the same services as that of Shared Service organization but primarily to “external” customers. Sandy Kemsley argues that an enterprise is usually captive to its shared services, whereas they have a choice with an external SaaS (BPOs). Well that may not be completely true. I know many instances where there have been captive BPOs set-up by MNC organizations at on-shore as well as off-shore locations. Also, many a time organizations are forced to opt for BPO companies within the same corporate group when there are credible and better options available outside of the group.

I feel that shared services and BPOs are two sides of the same coin. They bring about the similar benefits to the organizations. There are merits and demerits in either models. BPOs especially if they are external organization, may offer superior services considering the customer – service provider relationship especially if the exit barriers are very low. On the other hand, Shared Services, being internal to the organizations can draw comfort from the fact that the sensitivity of data or records are still managed within the four walls of the organization.

I expect SaaS to mature over a period of time and then convergence of SaaS and BPOs is simply inevitable. Already organizations such as IBM, and Infosys have both package applications as well as process outsourcing services to offer to the market. What would really stop Infosys to offer loan processing service deployed on their core banking solution – Finalce as SaaS. In India I know at least one bank, which have outsourced their complete IT set-up to Wipro. What would stop this bank from using software applications developed on Wipro’s Flow-brix as SaaS in combination with credit card payment collection services from Wipro’s outsourcing unit. Just think about it.

TWIKI: Implementing TWIKI 02

About 4 months back I wrote a blog entry “Implementing Twiki – 01” on our attempts to implement TWIKI – an open source WIKI software, using which we wanted to build a Knowledge Management application for our Project Management Office. There has been so much talk about Open Source software that I was tempted to experience the fruits of Open Source first hand, besides we really do not have budget for such an initiative. One of the obstacles that we are facing is the lack of training material and trained resources. Or may be we are not aware of such self-help or CBT material that could be helpful to us to train ourselves on functional, technical and system administration aspects of the software so that we could quickly build applications using TWIKI.

Having said so, we have made progress. We managed to install the software within a week and I could create a simple page detailing the purpose of our TWIKI implementation. Encouraged by our recent success, we have set ourselves very stiff target and we hope to be ready with one or two applications by the end of this month.

Any advice or help is always welcome.

Software as a Service: A reality check!

Reading the customer success stories of and the apparent potential of SaaS (Software as a Service), we recently undertook a project to examine whether and how SaaS could be helpful to our company. Incidentally, unlike most of the poupular tech and management 3 lettered jarons, SaaS is a four letter acronym!

On closer examination of the concept in the current form and our business environment, we came up with the criteria and a quantitative model to decide whether and which business processes & requirements could we support using SaaS. Some of the critical criteria are as listed below:

1. Integration requirements: Does the software system need to be integrated with multiple back-office systems? Adopting SaaS is alot easier, if system has minimum or no integration requirements.

2. Software changes / customizations: Do the business requirements supported by the applications are subject to change very often requiring frequent changes and enhancements to the software? If initial as well as the post implementation frequency of system changes / enhancements is less, then possibility of adoption of SaaS is high.

3. Confidentiality of data: Does the business policy of the company or regulations mandate application data to be guarded and protected within the four walls of company or demand special or extra-ordinary security measures in maintaining the data. SaaS may not be adopted in such environments.

4. High Availability / Mission criticality: Is the system mission critical or of strategic importance requiring 99% plus uptime? Enterprises may not want to depend upon an external service provider for such applications?

5. Total cost of ownership: What is the extent of initial investments? What is the is the total cost of ownership? Many concepts do not take-off in organizations as initial investments are high and hence ROIs are difficult to justify. SaaS could be a good option for such systems.

6. No. of users: What is the likely number of users in the organization? Relatively low number of users coupled with high initial investments may force organizations to consider SaaS?

7. Nature of software application: How would you classify the software: Core (OS, RDBMS, Application Server) / Infrastructure (BPMS / Rules Engine/ Portal / KM / BI system) / Business Application (ERP / SCM / CRM) / Business Support Software (MS Office / E-mail / Calendar)? Non-mission critical Business Application software and Business Support software could be easier to adopt as SaaS.

After critical evaluation, we could hardly conclude in favour of SaaS for some of our strategic initiatives such BPM & Imaging, Core Insurance system upgrade, Claims Management System, or Business Intelligence System. Despite the aggressive push and over-optimism by SaaS enthusiasts, I feel SaaS is long way away from becoming a key factor in impacting enterprise architectures.

BEA’s acquisition of Fuego – Interesting & Intriguing

On March 1, 2006 BEA Systems Inc announced the acquisition of Fuego Inc – provider of a pure-play Business Process Management System (BPMS). The announcement was very interesting at the same time very intriguing indeed.

Interesting because, this is one more significant announcement made by BEA after the acquisition of Plumtree in August 2005. In the month of January, in my blog entry Year 2006 – Beginning of the end for pure-play vendors? I had commented on SOA driven Composite Application software providers.

“…These are infrastructure software consisting of components such as BPM, Portal, Integration, Mobile, Analytics, Content Management, and Services design and deployment software. Composite application frameworks aim to bring together a wide spectrum of technologies, which have been so far dominated by pure-play vendors, under one roof.”

BEA’s Aqualogic, of which Fuego is going to be a part of, precisely aims to offer what Composite Application software aims to provide. Following is an excerpt from BEA’s FAQ on acquisition of Fuego.

“…The BEA AquaLogic Business Service Interaction product line is a new, integrated set of BEA AquaLogic products used to enable companies to compose services from a wide variety of information, applications and technologies to agilely support their end-to-end business processes. As business processes change, the services that support them can also change. Likewise, as underlying services change companies can simply “unplug” the old service, version and catalog the service, and plug-in the new service with no change to the business process, making it immediately available for use across the enterprise.”

Now about the intriguing part. In the workflow space, this is second acquisition by BEA. In the year 2000, BEA had announced acquisition of Workflow Automation – a Canadian firm providing workflow engine jFlow. jFlow was then supposed be relaunched as eProcess Integrator as part of BEA’s integration offering as well as stand alone BPM engine. Even today, BEA continues to offer BPM functionality as part of their Integration suite – BEA Weblogic Integration 8.1, which supports human as well as system to system workflow as part of the processes executed within and beyond the boundaries of the organization. If that was indeed the case, then why did BEA acquire Fuego when they already had a BPM engine? Also, is there a migration path for the users of current BPM engine? Reasons for BEA’s Fuego acquisition could be that BEA’s existing process engine may not offer strong human workflow capabilities and also could be weak in the area of process definition and process management – essential components of process lifecycle.