The system is designed according to the Open System principle, which allows both the developers of our company and our clients to use the tools created in it. We have made all the settings mechanisms available, from the segmentation of analytical accounts for an arbitrary chart of accounts, to creating and modifying the existing banking products, reports, routes, statuses, operations, event management, as well as program and client interfaces. Several mechanisms are proposed for integrating our CBS with other systems. It is possible to independently expand its functionality and adapt to the individual characteristics of the bank.
Given the extensive experience of interaction with banks, creating and developing an individual versions of our software, the emphasis was shifted from development to customization. This approach allows you to configure any version of the supplied banking product, both for a small and for a large backbone bank.
This approach has a great advantage and allows you to get an individual solution customized for a particular client which does not complicate the implementation of the system in general. At the same time, the use of unified configuration mechanisms makes it easy to maintain the system, regarding the localization of the bank's accounting and product policiy features.
At the same time, this solution does not make the bank completely dependent on the developers in terms of price and timing of the subsequent implementation of new functionality. There is also the possibility of various options for maintaining the system, from full outsourcing to standard ABS functionality support by our company's specialists and independent support of our own business processes.
An individual approach to setting up the system also greatly affects the performance of the system, which is especially important for banks with a large amount of data and users.
Another very important principle is the object orientation of all the functionality that ABS has. Despite the relational nature of the Oracle DBMS, when designing the data structure, we strictly observe the inheritance mechanism, both at the table level and at the program code level. For example, the common base properties of all primary objects are in the parent structure of tables and packages, and the specific properties inherent in the corresponding inherited objects are in the inherited tables and packages with the appropriate naming system.
This means that for each technological entity (customer, account, document, transaction, operation, etc.) the ABS provides a unified approach, both in design and implementation. This primarily leads to the normalization of data storage and retrieval, which in turn greatly affects the performance of the system and its maintenance.
With this approach to design and development, we have achieved 100% storage of the executable code at the level of ORACLE DBMS or Oracle Weblogic Server, which makes it possible to create a client application that performs only data display functions, i.e. functions of the user "showcase". The existing mechanism can significantly reduce the cost of creating new user interfaces and allows you to flexibly and quickly connect both your own additional "showcases" for displaying and managing data and those of the client's. In this case, for our customers, the time for creating new products is significantly reduced, as well as the cost and time of their implementation, respectively.
he whole main focus has been shifted from development to customization using the system designing tools, where you can customize everything from the GRID tabular view to dialog boxes, reports, products, business processes, etc.
All business logic is implemented in PL/SQL for the Win client and in Groovy and Pl/SQL for the Web client.
For all basic system objects there is an API (Application programming interface) developed, which is used for integration with other systems. This mechanism is completely open and described in the technical documentation for the system. Due to this, when external modules are connected to the ABS, same rules apply to all actions with internal system objects as when performing standard operations inside the ABS.