Workflow Orchestration

What Is It

To illustrate the purpose of your workflow orchestration layer, let's consider an example: generating a quote. This process involves a series of steps:

1. quote validation
2. rating
3. form template selection
4. quote creation
5. document generation.

Each of these steps can be encapsulated within its own transaction-level microservice, acting as a reusable building block that can be configured and utilized throughout the system. This microservice layer establishes the foundation for insurance product configurations and the underlying data model.

However, serving quotes may involve multiple front ends, such as internal sales flows, broker portals, and direct-to-consumer (D2C) experiences. Additionally, quotes may be generated without a front end through distribution partners using APIs. Repeating the same set of steps for quote generation across different sources would be inefficient. Instead, the workflow orchestration layer lets you bundle these steps, ensuring that calling the "generate quote" function automatically executes the necessary steps, 1 through 5, each time. This bundling or orchestration allows for a cohesive flow of operations within the system.

The workflow orchestration layer also serves as the integration hub for connecting with other systems, such as billing and payment processing platforms, enabling seamless data exchange and process coordination.

Building

When constructing your core tech stack, it is valuable to adopt a three-layer architecture, comprising transaction-level microservices, workflow orchestration and integration, and front end(s). This architectural approach provides clarity and flexibility in system development and enhances modularity.

• Data: Your database and data model are the core of your system, underlying all 3 layers of your architecture. It's important to consider how you want to represent common objects such as customers, policies, and quotes.
• Transactions: This bottom layer houses all the atomic ways you interact with that data: creating a quote (see step 4 above), binding a policy, etc. This is where you keep your rating, underwriting, and forms logic and templates.
• Workflow orchestration and integration: This layer coordinates the transactions in the previous layer, so that various front ends and APIs can work with the same flows. This is also where you connect to any third-party integrations—again, so that your front end and APIs can interact with them smoothly.
• Front end(s): Your front ends are of course the most visible layer of your architecture. But they simply call the API endpoints established in the previous layer.

As you grow, it's common enough to have entirely different teams working on these different layers: UX designers and front-end developers on the front end, back-end developers on transactions and workflow orchestration, data folks on the database, cloud engineers and architects enabling the whole system.

This structure also echoes best practices in the industry. So if you ever do find yourself bringing in external solutions to supplement your tech stack, you'll have an easier time of it. (See modularity for more on this.)

Maintaining a clear separation of these layers enhances scalability and enables more diverse options for future system enhancements.

Buying

When considering policy software platforms from vendors, it is essential to assess which layers of the three-layer architecture (see above) they address. Understanding the capabilities of each vendor and matching them to your needs is crucial. Consider the following points:

• Vendor Solutions: Evaluate vendors based on their focus and offerings across one, two, or all three layers of the architecture. Knowing their areas of expertise will help you align their offerings with your requirements effectively.
• Transitions and Vendor Lock-in: When transitioning between solutions, it is often possible to start with one or two layers rather than undergoing a complete overhaul. If you use a single vendor for all three layers—for expediency, simplicity, or cost—don't be afraid to ask for a look under the hood to make sure the 3 can be split out cleanly. It's better to look into it when you're just getting started than to wait till you've decided you don't like them. Think of it like getting a pre-nup.

By carefully evaluating vendors and aligning their capabilities with your specific needs, you can make informed decisions while minimizing the risk of being locked into a single solution.