What is middle-layer architecture, and why does the insurance sector need it?

Almost all international email service providers offer multilingual applications. Moreover, the apps can work on various devices with different hardware and operating systems. However, those email providers do not develop separate apps for each language and gadget. Even such a giant as Google cannot afford to build multiple versions of Gmail for different circumstances: it is merely too irrational and expensive.

Email apps are one example of the so-called layered architecture inherent in modern software solutions. But what about the systems working on legacy platforms with old cores created in the days of mainframes? Are the ones still widely available in banking, insurance, and other industries? How can they adopt digital transformation requiring flexible, dynamic front offices? The middle-layer architecture hints at a viable approach to the issue. Read and discover implementation opportunities for multi-tier architectures.

Check the software solutions we offer for insurers:

Digital channels for the insurance sector – Improve your CX with advanced technologies

What is middle-layer architecture?

Everyone knows what the most general client-server software architecture is. Many can guess that something lies between a client side and a server. Several intermediary layers addressing particular services constitute the software structure in most cases. If the layers can work independently, such an architecture is called “layered,” “multi-layer,” “middle-layer,” “tiered,” “n-tier,” and the like.

Despite seemingly different names, the core idea behind them is the same: the increasing complexity of modern apps requires separating a project into several independent parts (or layers, tiers) to provide more agile operations and easier changes. Theoretically, the number of layers is unlimited, but it is worth considering the simplest three-tier architecture to get familiar with the concept.

Client-facing (presentation) layer. This layer represents content to users via GUI. Users access the layer through devices of almost any type: desktops, laptops, mobile gadgets, etc. There should be a presentation element that delivers content to users through the client: a website accessible via a browser, a mobile (desktop) application, or any other software component through which users can interact with the system. Staying atop the system, the layer is interconnected with the lower tiers.

Business logic (application) layer. This is a middle layer in the three-tier architecture. It is responsible for business logic separated from both the user interface and databases. The layer provides a set of rules allowing the application to run under the guidelines established by the app’s owner. The layer can consist of multiple elements running on different servers. In many cases, such elements work as independent service layers with conceptually similar functions.

Database (persistence) layer. This bottom layer provides storage and retrieval mechanisms allowing upper tiers to access data files available on servers or media. Hence, users can operate the database through the user interface under the business logic set by the application layer. It means that data files become accessible from the upper tiers without affecting the very data-access logic. Since the architecture is horizontal, changes made at one layer leave other tiers untouched. Updates to the database layer have nothing to do with the application layer, for example.

You might be interested in the related articles:

How to develop a chatbot for an insurance company
How insurance companies can improve customer experience with a mobile app

How do n-tier architectures work?

The core working principles of multi-layer architecture determine many (if not all) aspects of modern software development. Developers and their clients consider the structures of their projects in terms of the client, server, and everything in between. Moreover, the labor division within the software development sector implies specialists and teams devoted to different layers of digital architecture. Understanding how an n-tier architecture works is critical for anyone involved in digital transformation.

• The middle-layer architecture allows changing and maintaining different app elements in a flexible manner at various stages of both development and operation. Besides, scaling up layers is possible when necessary.
• The layers’ functions are separated to communicate via different protocols or networks. Deploying applications becomes easier when different blocks are not interdependent.
• Complex projects can run beyond a single physical layer when elements communicate via networks with no need to engage the entire system from top to bottom all the time.
• Layers work independently from each other as from the involved networks and subnets. Hence, their intercommunication goes with neither interruption nor disturbance.
• The smooth operation of the entire system occurs due to maintaining the layers under functional segregation.
• The business logic layer and derivative service layers act as an intermediary that harmonizes data patterns according to the users’ inputs from the presentation layer and the available databases from the bottom layer.
• All layers are self-sustained, but if necessary, a component of one layer can foster the functionality of an element (elements) of another layer.
• The multi-layer architecture allows to achieve both the independence and interdependence of layers when one or another is needed.

You might be interested in the following article:

How to automate insurance operations with technology

Benefits of layered architecture

Simplification of software infrastructure management is the most general advantage of layered architecture. Another valuable outcome of using multi-layer architecture implies easier and cheaper development of scalable, product-intensive, and cloud-based applications that can be upgraded progressively according to the requirements of the time. Moreover, such an approach helps upgrade various legacy systems quickly and with lower risks. In other words, system customization becomes easier to perform.

When a project is divided into layers, its creators, users, and owners face no difficulties in grasping the functionalities of each layer. The consistent data transfers between layers improve the app’s usability. It is much easier to find an object to be changed or upgraded when all objects are distributed between corresponding layers. Layered architecture helps assign tasks when differentiated according to layer characteristics, while no constraints appear for scaling objects within each layer.

At the same time, some challenging factors of the layered architecture implementation are also available. A multi-layer system’s upgrading can require a deeper analysis that may result in extra expenditures. Besides, layering may affect the overall performance of the system since each subsequent level depends on how each preceding one is executed. To avoid performance issues, no redundant multiplication of service layers is recommended.

Why layered architecture is important for digital transformation

The agility achieved with layered architecture increases the value of any business in the days of digital transformation. It is especially crucial for mature sectors to adapt to the expectations of modern customers. Many companies from those sectors are reluctant to modernize their apps based on legacy cores. Pretty pathetic interfaces of those apps deliver nothing but poor customer experience. It’s no wonder since software solutions created in the days of COBOL have nothing similar to the modern must-have functionalities such as customer relationship management (CRM) and the like.

Large transnational insurance organizations with rich histories belong to that category oftentimes. Their leadership realizes that the obsolete legacy-core software they must keep using causes difficulties for staff and customers. However, respectful insurance companies can hardly afford to abandon their legacy software since the insurance business never stops. Therefore, insurance companies face the following challenges in attempts to modify their legacy platforms:

1. The corporate software solutions with legacy cores designed in the 1980-90s have little to no chance to meet all customer expectations since the specialists capable of making changes at the core level are pretty rare.
2. Vertical architectures of the legacy core are rigid to be transformed into horizontal layered architectures. Unfortunately, such a transformation is painful, slow, and expensive.
3. Building modern solutions atop legacy cores can be a palliative in many cases: the missed middle layers prevent the platforms from enabling many progressive functionalities such as CRM, data analytics, data integration, etc.

At the same time, insurance companies have enough arguments to create multi-layer architecture either from scratch or atop their legacy cores. Otherwise, their business continuity is at risk of failing in the competition with more agile rivals. So how can they overcome constraints inherent in their legacy systems when building layered architecture?

• Dividing the app structure into layers is possible when creating separate components responsible for smaller parts of the entire business logic.
• The app components (aka layers) can be distributed across several servers to compose horizontal n-tier architecture.
• The existing core layer can be supplemented with one or more service layers capable of sharing the business logic of the legacy core. At the same time, such new service layers provide better agility in terms of maintenance and upgradability.

Despite technical and organizational difficulties along with a time-consuming process, insurance legacy platforms can become layered ones if their owners clearly realize all pros and cons of digital transformation. However, when a policy decision to upgrade a legacy system is made, some specifics of layers remain to be grasped.

Learn what experts think about the future of insurance technologies: 

Podcast with a founder of BriteCore: Achieving growth with the help of technology
Interview with a former CEO of Willis Nordics: How technology impacts insurance

Middle layers in insurance: Features and designs to create

A particular cultural shift happens when a legacy platform acquires middle layers. Instead of keeping and processing all data in one place, intelligent data segregation distributes different datasets across layers. Which dataset belongs to which layer is the key question to be resolved at a pre-design stage. Although all insurance companies seem similar in their activities, particular circumstances determine the functionalities of each project. Therefore, the project owners (insurers) and software developers should consider the following issues to provide the middle layers under design with relevant features.

• The number and characteristics of the explicitly distinct locations where the company operates. The language diversity and legislative aspects can determine how many components and microservices the customer-facing layer (layers) may need.
• The staff composition (agents, clerks, managers, leadership, etc.), responsibilities, and data access levels.
• The range and nuances of policies in the context of the markets and industries (healthcare, finance, manufacturing, etc.) where the company operates. Different employee benefits may require very distinctive policy packaging.
• The common fundamental qualities inherent in all policies reflect a particular sectoral image of the company. They cover obvious advantages against available rivals.
• The general rules under which all policies can be handled to meet customers’ expectations from different sectors.
• The inner data landscape should determine all applicable data security measures.
• The desirable features of user interfaces: functionality of separate dashboards for customers and agents.
• The data analytic tools are applicable to each layer, along with access permissions to the analytics.

Three middle areas of architecture for insurance

When all issues mentioned above are conceptualized, a development team can get down to building corresponding middle layers. The layers’ number depends on a particular sectoral profile of the customer company and on the extent of digital transformation to be applied to its legacy core. All middle layers can be distributed between the following three areas.

The digital area. Everything related to user experience belongs to such an area. In addition to the user interface, some supporting layers can be created. The area covers interfaces for both customers and agents. Besides web and mobile UIs, such tools as chatbots, AI-backed assistants, push notification modules, data-collecting IoT devices with corresponding interfaces, and other API-based solutions can constitute the middle layers of this area. Content management platforms, CRMs, personalization tools, customer support, and agents’ onboarding modules can act as independent layers within the area as well.

The decoupling area. Data integration facilities form the middle layers of such an area. They provide asynchronous data deriving from various sources in the user-facing layers to process and store the data in the central core. Easier communication between various layers and faster access to different datasets results from data integration. The middle layers of this area act as an event hub for all platforms and services. They are built according to modern software architectural approaches such as event-driven, reactive, domain-driven, microservice-based, and the like.

The records and insights area. The middle layers of this area support the existing monolith core of the legacy system, with features providing business intelligence, data security, analytics, and overall service management. Even though a legacy core can be a foundation for the records-&-insights area, its middle layers are not the bottom tiers: layered architecture implies horizontal relationships between system elements.

As we see, any legacy-core insurance platform is hardly destined to stay petrified in the days of digital transformation. Modern software architectural patterns can be applied to both new built-from-scratch insurance projects and mature legacy-platform ones if middle layers come into play.

Conclusion

The layered architecture reflects an up-to-date software development approach to complex systems required to be user-friendly and agile. Middle layers can significantly expand the capabilities of seemingly non-upgradable legacy-core platforms widely available in the insurance sector. Middle-layer architecture provides them with digital transformation opportunities sufficient to conduct a cultural shift to another class of service – Insurtech.

A comprehensive development team of experts for any layers inherent in multi-tier architecture is needed to transform a legacy insurance system into an insurtech platform. Besides, hands-on experience in such a transformation won’t hurt. Our company has both the team and experience. Contact us today to start your exciting journey to a new level of insurance service.