Bi-Modal IT for the Modern Insurance Company

Does the news of insurance start-ups in Silicon Valley have you nervous? Wondering how you can compete when your IT department tells you it will take six months to get that next mobile app out to customers? If this applies to you, then two-speed architecture is something you should consider. Also known as two-speed IT or Bi-Modal IT, two-speed Architecture can get you where you’re going quickly while maintaining the harder-to-change back office systems. In today’s ever-changing world of customer-facing applications, traditional IT methodologies and frameworks just don’t cut it anymore. Waiting six months to get a mobile application out the door is so 2014. Nowadays, you need to get those apps out the door in weeks. How can you do that, you ask? How can you take a traditional IT department and equip it with the tools necessary to thrive in a modern environment? The answer, as you’ve probably guessed, is Bi-Modal IT. As the name implies, Bi-Modal IT describes an IT environment that works in two different modes. In this case, it has two distinct environments that run at two different speeds while still interacting with each other. The traditional, almost static back-end systems that run the business are the components that make up the slow environment. That environment is supplemented with a front-facing API layer that allows for the quick development of mobile and web apps.The exposure of an API layer that interfaces with traditional back-office systems directly or indirectly creates an environment where front-end applications can be rapidly developed using a myriad of technologies and an agile methodology. The front-end applications can be web applications, mobile applications, or some business-to-business web services.

First, a quick note about Agile: We’ve been around the block a few times and have seen Agile implemented at many a Fortune 1000 company. We can tell you from experience that they aren’t doing Agile. Why is that? It’s because those legacy IT systems do not lend themselves well to the agile process. If you are implementing a new insurance administration system, can you go live with a release that only incorporates 75% of the features you need? Of course not, you need all the features to run the business. On the other hand, if you have a great idea for a mobile, customer-facing app that enhances your business, can you go live with an application that only incorporates 50% of the features in the first release? Yes, you can. Technology start-ups do it all the time. Get the first release out there as quickly as possible and delay some features for future releases. Iterate many times and release often. An agile methodology allows you to do that.

An Agile development environment will help get you started, but it is the API layer that allows for change. An API layer allows your consumer client applications to be developed in whatever language your star development team uses or whatever language best suits the application. If you are writing the best iOS insurance claim app incorporating the features of the latest iPhone including 3D touch, GPS, and access to the camera; write the application in Swift. If you need a web page to allow a customer to view the status of their claim, write it in JavaScript. The development environment is only constrained by the talent you have. Have a new potential hire who does her best work in Python? Bring her on board! She’ll be productive in days, not months.

Another benefit of an API layer is the ability to allow outside organizations to build your front-end apps without having to know the details of the systems running the business. If you don’t want to hire the best Swift developers; hire the best Swift development company instead. Visionaries might even find ways to expose parts of their API to the public and crowd-source some of their development.

One more important point is that your high-speed environment needs access to the information in your stable environment but should not be completely dependent upon it. So while your API could directly interface with your traditional applications, it really shouldn’t. Just as a change in your high-speed environment shouldn’t impact your stable environment, change in your stable environment should not negatively impact the high-speed environment.

Every insurance company should already have a slow speed environment with tried and true methodologies for change. This important environment enables all of the complex processing that runs the business. Enacting a policy to allow for a quick change in such an environment is not a great idea since those systems need to remain fairly stable. However, a fast, adaptable, and expandable environment is also necessary to allow access to all the benefits of the modern digital world. The key is to enable both of these environments to exist simultaneously in an integrated yet not dependent way so that the change in one does not impact the other.