Architecture
Navida Pro High-Level Architecture Frontend and Backend
This section provides a comprehensive architectural overview of the Navida Pro mobile application Platform. It is intended to convey the significant architectural decisions that have been made and focuses on providing:
- A description of the solution architecture, including major components and their interactions, processes, and data.
- A common understanding of the drivers (requirements, constraints, and principles) influencing the architecture.
- Explanation of how the architecture satisfies the drivers.
- A description of the hardware and software platforms on which the system is or will be built and deployed.
Solution Objectives
Objectives :
• Improved patient care and increased focus on prevention
• Strengthening customer loyalty and trust
• Perception as a health insurance (complementary to transactional offers)
• Link to the ePA
• Orientation through connected customer journeys between services and transactions
• Link to the AOK ecosystem via „Meine AOK“-login
With Navida pro, AOK will opens up the eco system to external offers and integrate them in to the existing customer journeys.
Big Picture
The Navida Pro application represents a sophisticated digital health solution that has been meticulously crafted to provide a seamless and intuitive user experience across both iOS and Android platforms. By choosing to develop the application natively for each operating system, the developers have ensured that the app takes full advantage of the unique features and capabilities of both environments. This native development approach allows for optimized performance, better integration with device-specific hardware and software features, and a more responsive interface that adheres to the design standards of each platform.
Design-Driven Development Paradigm:
The development of Navida Pro is guided by a design-driven paradigm, which places a strong emphasis on user experience (UX) and user interface (UI) design. This approach ensures that the application is not only functional but also aesthetically pleasing and easy to navigate. By prioritizing design, the development team aims to create an app that engages users and provides a straightforward and enjoyable experience.
Backend for Frontend (BFF) Layer
Supporting the native applications is a robust Backend for Frontend (BFF) layer, which is built using Spring Boot microservices. The BFF layer acts as an intermediary between the frontend (FE) applications and the backend (BE) systems. It is tailored specifically to the needs of the frontend, providing APIs that are designed to deliver the exact data and services that the mobile applications require. This layer abstracts the complexity of the backend systems and provides a streamlined interface for the frontend, enhancing the overall performance and scalability of the application.
API Gateway (KONG)
An API gateway, specifically KONG, is implemented as a critical component in the architecture to facilitate several key functionalities. It sits between the frontend and backend systems, serving as a single entry point for all API requests. The API gateway enables multi-tenancy, allowing multiple AOKs to use the application while keeping their data and configurations separate and secure. It also provides scalability, ensuring that the application can handle a growing number of users and data without degradation in performance. Additionally, the API gateway manages the APIs, offering features such as rate limiting, authentication, and monitoring, which are essential for maintaining the security and reliability of the application.
Drupal-Powered CMS
The backend systems include a Content Management System (CMS) powered by Drupal. This CMS is responsible for controlling the configurations and content specific to each AOK. It allows for dynamic content management, enabling administrators to update information, adjust settings, and personalize the app experience for different user groups. The use of Drupal, a widely-adopted and flexible CMS platform, ensures that the system is robust, secure, and capable of supporting a wide range of content types and workflows.
Transactional Data Storage
For storing transactional data, Navida Pro utilizes a database powered by PostgreSQL. This choice reflects the need for a reliable and scalable data storage solution that can handle complex queries and large volumes of data. PostgreSQL is known for its robustness, data integrity, and compliance with SQL standards, making it an excellent choice for applications that require transactional data processing.
This solution architecture is compliant with most of the following IT Services policies and principles: • The following principles are explicitly reflected.
| S. No. | Guiding Principles/Policies | Description |
|---|---|---|
| 1 | Native platform and operating model powered by Open contract | • Natively support multiple plugins/features customized for each AOK healthcare experiences with one platform |
| 2 | Plug and Play architecture | • Flexible onboarding for new plugins and features to enable business capabilities faster • Modular Design: PnP architecture promotes breaking a system into smaller, self-contained modules or components that can be developed independently and easily integrated with other modules. • Loose Coupling: PnP systems aim to minimize dependencies between components by using well-defined interfaces and communication protocols. • Dynamic Configuration: PnP architecture enables dynamic configuration and discovery of components at runtime. |
| 3 | Design Driven | • Design Driven Development (DDD) approach revolves around the premise that software should be built around the ultimate interface first. • In Navida pro project, Figma is used for UI design and Backend-for-Frontend (BFF) microservices provide data specifically for the design. • DDD allows developers to have a clear view of how software components will interact with the user-interface. |
| 4 | Innovation | • Adopt an innovation culture through a continuous focus on transformation and insured customer |
| 5 | Reimagined Objectives | • Designed ground-up to support the transformation reimagined objectives |
| 6 | Separation of concerns | • Simplifies the development, maintenance of the platform and allows maximum reuse, and increased technical flexibility • Minimal data access (direct read/indirect writes), features are separate tables and minimal correlations |
| 7 | Service and Component Orientation | • Design for loose coupling, modularized, interoperable, scalable architecture |
| 8 | Integrated, Secure, Scalable, flexible | • Build unified integrated system. • Secure by design to ensure security is an implicit part of systems. • Leverage power of cloud (Auto scaling, resiliency, security features of cloud) |
| 9 | Complexity under control | • Evaluate dependencies and eliminate risks. • Well documented API/interface and Data specification |
| 10 | Automation as a core | • Automation is indeed a core priority in today's fast-paced technology environment. • Automation of onboarding new application-oriented keyboards (AOK) from the CMS side cuts down the time consumed in otherwise manual processes. |
| 11 | Secure by design | • Secure by Design is a concept in system architecture and software development that promotes security and privacy as fundamental aspects of a system. • Service Isolation ensures each microservice is responsible for a specific set of functionalities. • Domain Abstraction refers to the idea that all implementation details, including security measures, should be hidden away behind a simple interface. • API Gateways act as a protective barrier for your microservices. • Database Access Isolation helps in minimizing risk associated with unauthorized access. |
Platform Architecture :
The AOK mobile platform is designed to have three important factors in mind.
- Customization : The platform should be highly customisable so that functional features can be controlled and configured dynamically and support multi tenancy in all aspects
- Plugability : The platform should be highly plugable so that new featues , tools and technologies can be seamlessly integrated to the platform with ease.
- Automation : The platfom support high level of automation in terms of the continuos delivery of software release, functional testing, etc.
in order to achieve these goals, the platform is designed in
Navida Pro Mobile Platform
AOK Mobile Platform (AMP) will be the foundation of the Navida App with AMP Frontend, Backend and CMS
Plugins, functions of the app, can be developed internally and externally
-
Open Contract, Base App and plugins are automatically linked to the AOK Navida App
-
Open Contract describes the life cycle and integration possibilities of a plugin
-
Backend and CMS are accessed via a unified API gateway from the frontend
-
Third-party data is prepared in dedicated backend services for the frontend – BFF concept
-
Each AOK edits and creates its own content and configurations – no need for additional work from developers anymore
- Standardized interfaces Plugins are integrated with the Open Contract and thus provided with all information and updates
- Design system for plugins and base app The Open Contract provides a set of pre-built UI components - so each plugin automatically gets the same look & feel
- A modern architecture on a native basis The native basis of the AMP frontend with the modular architecture forms a future-proof basic framework
- Accessibility is a priority A low-barrier interface is a priority - with the native interfaces of iOS and Android, we offer a solid basis for this
The AOK Mobile Platform (AMP) combines internal and external Services via a unified Frontend
AMP Frontend can be customized through various Configuration Options - Styling and Feature Options are edited live by AOK
► Configurations from the CMS are loaded and
displayed directly when the app is started
► Settings in the CMS are made by the AOK on a
user-friendly interface - direct effect on the app
► Feature toggles are made in a matrix
(visible / embedding type)
► Adjustments to colors and texts in a
table/list
► The backend provides technical configurations
analogous to the AML app
► With which backend (URL) the app has to
communicate
► App content, such as designs and flows, are
updated via the regular release cycle
► Adding new AOKs is done via the CMS (remotely)
The Open Contract automatically connects Plugins with the AMP App - due to the native Implementation there are no Limits for these Plugins
- Plugins are married / merged with the frontend via an automated process
- The open contract is written natively for both platforms - interfaces must be kept the same in terms of processes
- The Open Contract itself loads its settings directly from the CMS and thus fades features in and out
- Plugins can come directly from the AOK or be commissioned from third party manufacturers
- An integration guide supports service providers
in integrating with AMP - These rules of the game
increase stability and make responsibilities clear
The Open Contract automatically connects Plugins with the AMP App - due to the native Implementation there are no Limits for these Plugins
- For frontend development, we rely on the recommendation of the respective platform - Swift + SwiftUI for iOS and Kotlin + Compose for Android
- The Open Contract provides a library of UI components for both the Base App and the plugins for free
- Plugins are not developed directly in the frontend, but within a test app in the Open Contract
- Plugins can build their logic with multiplatform tools to save time during development - example: Kotlin multiplatform mobile
- The plugins basically only map logical components or redirect the user, life-cycle and authentication tasks are handled by the AMP frontend
Base App and Open Contract form the Framework for the Plugins - these are arbitrarily interchangeable and customizable
- The so-called Base App uses the components of the Open Contract and provides only a few interfaces itself
- Due to the high UI content in the Open Contract, the test UI for the plug-ins can be designed as close to reality as possible
- Plugins are married to the AMP only in the Base App
- Plugins know about the user's checkout affiliation and can thus customize their content
- Plugins themselves provide their UI to be displayed in the different integration options app
