OneShield Podcast Transcript:
Rakesh Parikh, VP Product Engineering
Q: Can you describe for us what OneShield’s OneShield’s Services Designer is?
TESL stands for transaction engine services layer. And, it’s essentially a framework for exposing transactions and other functions as services.
In addition, it also includes a host of prebuilt services and interfaces. These services support entity and data management, product structure management, and rules and transaction processing such as rating, statistics generation, full policy transaction creation and execution etc. — basically all the things that are essential to conduct insurance processing through APIs.
Q: How does OneShield’s Services Designer differ from the OneShield Enterprise Platform:
It doesn’t, it was architected on the same exact platform. With everything we develop, we standardized on a consistent structure and format for accessing these services and although it enhances the overall offering for our clients using these services does not require deep knowledge of how the OneShield platform works internally.
OneShield’s general philosophy is to implement as much business functionality as possible via configuration. In keeping with this philosophy, these services are configurable using OneShield’s Designer tool and can be tailored to specific organization, product or channel needs.
The benefit is, our clients can utilize what is already provided by OneShield leveraging the framework or they can add new services extending the API layer as needed.
Q: Just out of curiosity, the APIs and such, do they simplify or rather expedite the integration process?
These APIs greatly simplify the integration process by providing pre-built services that allow external systems to take advantage of all that the OneShield platform has to offer. This equates to a much lower time-to-market with OneShield’s Services Designer than with a traditional, hand-crafted approach.
Q: What are some of the business drivers behind the development of the TESL and what is its role in OneShield’s product roadmap?
We started OneShield’s Services Designer to help one of our clients, Erie Insurance, create a unified portal across their different systems and environment. The OneShield platform has a native design tool, OneShield Designer, that configures virtually every aspect of the application including product definition. Product definition includes products, coverages, forms, underwriting rules and rating algorithms. Access to this wealth of metadata is provided by metadata services. Accordingly, OneShield was a perfect fit to be architected as a product repository that could be accessed through API’s to handle all their insurance product management and transaction processing.
OneShield’s Services Designer was created to allow creation of these APIs and we were able to do that, to not only support the functionality but also meet all of their other criteria, like performance and scalability. Where traditionally, IT groups have taken months to create these services. With OneShield’s Services Designer it’s possible to do that more quickly to allow insurers to respond faster to market needs.
Moving forward we are enhancing existing services and interfaces by adding billing and claims APIs to the existing portfolio of services and interfaces. And, as we get more and more into this interconnected world… integrated services… micro-services… OneShield’s Services Designer will enable our platform to be able to extend these kinds of services.
Q: We understand OneShield’s Services Designer will eventually help take insurers and OneShield clients into new and emerging areas. Can you give us some examples of these future possibilities?
We all understand the disruption that’s occurring in business and business processes across industries. At some level, insurance is just catching up, particularly when it comes to servicing the customer and understanding the customer journey.
The question is, how can systems and platforms like OneShield’s help organize, participate and manage and thrive in this disruption. It is important to realize the backend platforms that are needed for supporting these new transaction types need to be solid. That’s where the strength of the OneShield platform is with its flexibility and robustness.
So, these platforms, like ours, become the hub for making the data connections and providing servicing capabilities for this.
These need services in the backend to conduct transactions and business and this is where OneShield’s Services Designer helps. By quickly and easily enabling and exposing the transaction processes that a platform provides as services… And, these services or APIs may be channel-specific or -agnostic.
What these channels need to do, whether they are enabled by OneShield or not, is connect to the APIs through OneShield’s Services Designer. And, the best part is it can be enabled within days, not months like it used to be.