Reference Architecture

To maximize the flexibility to extend, customize UX/UI and Integration, and help minimize the impact to upgrades, the Banking Application Reference Architecture has been decoupled into distinct layers. This summary provides an overview of the architecture stack, the various shared and non-shared layers, extension points, etc.

See Temenos Digital Banking Platform Architecture for reference.

• Objectives of the Architecture
• Architecture Layers
• Typical Flow Between the Different Layers
• Components
• Extending the Core Architecture Layers
• Visualizer Project Organization and Shared GIT Repository
• Visualizer Tooling Support
• Navigating Through the Architecture Layers

Objectives of the Architecture

• Flexibility to extend and change the UX/UI and Integration without completely jeopardizing future upgrades.
• Increase developer productivity by re-using common architecture layers and components across the Native and Responsive Web channels.
• Make functionality as configuration driven as possible to avoid code dependencies, application re-deployments and downtime.
• Extensions mechanisms to be intuitive to developers and non-intrusive to product.
• Modularize features to enable shared Business Services and better management across the Application suite - app to be broken into multiple modules and upgradability at module level.

Architecture Layers

Previously, all the UX/UI, business logic and integration were directly interwoven into the application, meaning that any changes made the upgrade path, maintenance and support difficult or near impossible. The Banking Application Reference Architecture structures the application definitions and code into distinct layers with strict rules on how to extend them. The goal is to preserve the upgrade path and maximize the sharing of objects and components. This is based on the typical MVC (Model View Controller) architecture, but with additional controller and model abstraction layers.

With flexibility comes complexity  While the "previous" model may be more development productive, but the longer-term cost of maintenance and support is much higher. The decoupled MVC architecture requires good tooling support to highlight the interactions, shared components, dependencies and extensions.

Typical Flow Between the Different Layers

The decoupled layers are designed to be flexible. So, some controller functions may not need any further interactions and may call other controllers. The following is a basic representation of a typical flow requiring client and back-end integration services.

Components

Common components are typically used in the form UI layer to share common titles and segments, and reuse them across the Visualizer projects and channels. Components can also be common code that can be shared across the controllers. The banking solution uses components heavily and it is recommended that any developer must be familiar with the Visualizer component model before changing anything in this area.

Extending the Core Architecture Layers

The whole premise of the architecture is to help minimize the impact of changes to upgrades. This is done by locking the core Temenos Digital controller objects and providing a mechanism to extend them. The form definitions and view controller objects may be modified directly, and the upgrade compare tool is used to highlight and merge customization. This effectively abstracts the UX/UI away from the business logic and data layers. You may also extend the data model and object services in Quantum Fabric directly and through pre/post processing to support data and integration enhancements. The following diagram shows the layers and where the solution can be customized and extended. The line between the form/view controller layer marks the demarcation between direct changes and the extension framework.

See also Extension Points for information on the various extensions available to extend the banking apps.

Guidelines for Customizing and Extending the solution

The following are the basic guidelines for customizing and extending the solution:

Client Application

• The UX/UI layer, forms, and view controllers are modified directly. This layer is viewed as totally decoupled from the business logic and can support different themes and custom forms. At the time of upgrade, modifications are identified and can be merged and replaced on a case-by-case basis. This is typically the most customized area of the architecture.
• Never change the core product presentation and business controller layers. They are locked but can be "extended" to override methods as per the extension framework. There is a more detailed information and examples on this in the developer documentation, but developers effectively create separate extension modules using the Visualizer tooling and place their custom code in these. During the upgrade time, the core product controllers may be replaced and then the extensions are reapplied.
• Business APIs are static and support third-party or custom solutions. For example, OCR scanning. They have a fixed interface that cannot be changed and describes the input/output/exception processing.

Server Back-end

• Back-end data changes are applied to the data model in Quantum Fabric and the supporting Object Services. For example, adding extra attributes (fields), new custom entities (tables) or operations (methods). The model objects are generated from the Quantum Fabric Object Services, supporting all the defined operations and CRUD methods. These are used to support data calls from the applications business controllers and should never be directly modified.
• Use Pre/Post processors against the Quantum Fabric Object and Integration services to allow for code extensions and special processing.

General Guidelines

• All enhancements should follow the same architecture cadence as the product to retain consistency, standards, and a smoother upgrade path.
• The configuration framework enables dynamic changes to the app behavior and should be used wherever possible to prevent the hard coding of rules into the application. The configuration parameters are defined in the Quantum Fabric back-end and are loaded into the application when it is started. The values can then be used dynamically in decision logic.
• The product upgrade is used to highlight project differences and enables merge and replace. A tool run that effectively compares the current project with the new upgrade, and reports the differences and areas of refactoring. These may be selectively merged or replaced on a case-by-case basis.

Visualizer Project Organization and Shared GIT Repository

Temenos Digital has two separate Visualizer projects, one for responsive web and one for native. There are technical and practical reasons for this since web and native are fundamentally different in terms of UX/UI interaction design components, components, third-party SDKs, and UX/UI interaction design. Bundling hundreds of forms and view controllers into one project for all five web, native tablet, and phone channels is not that practical or productive.

In the following diagram, the forms and view controllers are unique to each project. The presentation/business controller and model objects may be shared across both the projects. In some cases, the presentation controllers may be unique to the Web or Native projects.

This means that a shared GIT repository model needs to be implemented, one for web, one for native, and one for all the shared objects. There is a separate detailed documentation on how to set this up.

Visualizer Tooling Support

Developers must be familiar using Quantum Visualizer before attempting any new developments or extensions to the banking solutions. Developers must also enable the MVC extensions option when working with the Banking Architecture.

• Once MVC extensions are enabled in Visualizer, different architecture layers and application modules are highlighted and organized on the right hand side for easier identification and navigation.
• The forms, controllers, extensions, and components are logically assigned into modular app groups. These form the basis of what is shared and what is not shared.
• Developers use the tooling to extend existing controllers to add custom logic.
• Forms and view controllers are modified directly and then the differences are identified and merged using the upgrade tool.

In the following Visualizer screen snips, you can see how the app groups have been defined for the logical modules. For example, AccountModule is logically separated into project dependent and shared. All the forms, controllers, and the modules are then grouped accordingly making them easy to locate and navigate through.

Navigating Through the Architecture Layers

When working with such a decoupled architecture with many inter-dependent layers, it can be challenging to find all the points to track and implement changes. The Quantum Visualizer app groups help to modularize the forms, controllers, models, and the components into logical groups; but you then need to understand the technical flow of the business process.

To help with this, the functional and technical flows (Retail Banking and Spotlight) are described under the feature description and specification section of each application area. These include logical high level flows, screen/object cross references, and architecture navigation flows. See the following examples.

We are continually trying to improve these and would appreciate any feedback, and additional flows and cross references that we should incorporate.