TCB History and Development Architectures

8/14/2019 TCB History and Development Architectures

1/37

06 November 2013

Temenos CoreBanking

History and Development Technologies


2/37

06 November 2013

Agenda

Temenos CoreBanking History

FSDM: Financial Services Data Model

Development Methodology

AppBuilder

Volumes


3/37

06 November 2013

Temenos CoreBanking History

Project started in late 1993.

System rolled in October 1998.

About 1,000,000 man-hours effort.

Full range of banking applications.

To provide services to over 80 rural savings banks.

Partnership between RSI (Rural ServiciosInformticos) and IBM.


4/37

06 November 2013

Temenos CoreBanking History. Goals

Four major goals:

Provide maximum Flexibility. To accommodatemultiple requirements from different Rural Banks.

Reduce Development and Maintenance Costs.

Increase Productivity. Provide a system that talks

the user language to facilitate explanation and usage.

Provide Platform Independence and Scalability


5/37

06 November 2013

Temenos CoreBanking History.Goals achievement

Usage of aFinancial Data

Model

Usage of an AdvancedDevelopment

Method

Usage of anadvanced

DevelopmentTool

F L E X I B I L I T Y

COSTS REDUCED

GREATER PRODUCTIVITY PLATFORMINDEPENDENCE

SCALABILITY

FSDM Methodology AppBuilder


6/37

06 November 2013

FSDM. The Origins

FAS90

WBC TRUST CMIM

CustomerProjectsBankingKnowledge


7/3706 November 2013

FSDM. Layered Approach

A

B C

C' D

A level Very high levelmetamodel, based upon 9 dataconcepts

9 Data Concepts125 Entities

B level Classification mo del

of the banking businessdefinitions

2225 ClassificationLabels(Schemes and Values)27 ClassificationHierarchies

C level Flexible and genericERDs, with a structurebased on Business Objects

548 Entities1311 Attributes

923 Relationships11 Business ObjectSets54 Business ObjectERDs



FSDM. Hierarchy. A level

The 9 Data ConceptsInvolved Party Arrangement Condition Product

Business Direction Item

Classification Location

EventResource Item



FSDM. Hierarchy. B level

INVOLVEDPARTYTYPE

InvolvedParty

INVOLVED PARTYROLE TYPE

Organisation

Individual

ORGANISATIONTYPE

FINANTIALOBJECTIVE

LAWTYPE

MARITALSTATUS

HEALTHSTATUS

GENDER

Partnership

Corporation

Government Body Profit

Non-Profit Public

Private

Unmarried

Married Separated


10/3706 November 2013

FSDM. Hierarchy. C level

Businessobject

Level C is composed of Entity Relationship Diagrams,grouped according to Business Objects

A Business Object is a set of entities that containinformation about a fundamental concept (Focal Entity) in an ERD


11/3706 November 2013


Customize C Level

CustomizeTraces

CorporationGovernmental

Lucronolucro

Public Private

SolteroCasadoSeparado

SanoIncapacitado

HombreMujer

DivisinGrupo

Departamento

ORGANIZACION

OBJETIVOFINANCIERO

TIPODELEGISLACION

ESTADOMARITAL

ESTADODESALUD

SEXO

Individuo

UnidaddeOrganizacin TIPODE

ESTRUCTURA DEU DEO

TIPODEPA

Participante

TIPODEPAPEL

Traces

Subtipo Atributiva

Focal

Otr a

Entidad Asociativa

Supertipo

Tipo de

Relacin

Clasificacin OtraFocal

Original B Level

Users

CorporacinGubernamental

Lucronolucro

PblicaPrivada

SolteroCasadoSeparado

SanoIncapacitado

HombreMujer

DivisinGrupoDepartamento

ORGANIZACION

OBJETIVOFINANCIERO

TIPODELEGISLACION

ESTADOMARITAL

ESTADODESALUD

SEXO

Individuo

UnidaddeOrganizacin

TIPODEESTRUCTURA DEU DEO

TIPODEPA

Participante

TIPODEPAPEL

B LevelC Level

Customized

FSDM

Customize

B Level

Original Traces

Subtipo Atributiva

Focal

OtraEntidad Asociativa

Supertipo

TipodeRelacin

ClasificacinOtraFocal

Original C Level

The FSDM customisation


12/3706 November 2013


Organization Individual

INVOLVEDPARTY

16

ARRANGEMENT

19

CONDITION

Price

Interestt

7

LOAN

PRODUCT

9 LOCATION

Address

City

3

CLASIFICATION

Industry

Market Segment

31

Plan

BUSINESS DIRECTION ITEM

20

EVENT Transaction

Event

33

RESOURCE

One Share

OfficeEquipment

Document

14

Business Objects

One Share


13/3706 November 2013

FSDM. Hierarchy. D level

At D level both, the design of physical data and DataBase structure is done.

This design will support the data model designed inprevious levels.


14/3706 November 2013

Development Methodology

Basic development method

Highly customized for Temenos CoreBanking

Based on information engineering

Main ideas behind it: Identify Business Objects For each Business Object, perform simple event analysis Perform transactional event analysis Construct prototypes (protocycles) of the applications


15/3706 November 2013

Methodology Phases

Enterprise Definition

BOA/TA

Protocycling

Technical Construction

Delivery

C`Development


16/3706 November 2013

Methodology: Enterprise Definition

GatherFunctionalRequirements

Customize B & C levels

Reinterpret requeriments

Restructure Applications

Start CDevelopment

Analysts

Data Group

Reuse group Analysts andReuse group

Data Group

IdentifyTransactions

Analysts


17/37

06 November 2013

Methodology: BOA / TA (Business Object Analysis / Transaction Analysis)

For each identified Business Object:

Draw its Entity -Relationship Diagram (ERD)

Analyse focal entity life cycle status in a State TransitionDiagram (STD)

For each transition in the STD, analyse each triggeringevent in a Process Dependency Diagram (PDD)


18/37

06 November 2013

Methodology: BOA / TA (ERD-EntityRelationship Diagram)

C Objects


19/37

06 November 2013

Methodology: BOA / TA (STD-State TransitionDiagram)


20/37

06 November 2013

Methodology: BOA / TA (PDD-ProcessDependency Diagram)

Simple PDD

h d l (


21/37

06 November 2013

Methodology: BOA / TA (PDD-ProcessDependency Diagram)

Transactional PDD


22/37

06 November 2013

Methodology: Protocycling

During protocycling :

Windows and window flows were constructed and approved by theusers.

Dry prototypes were the norm. In special situations, somewhatwet prototypes were developed to show specific functionality.

After approval :

BOA/TA analysis had to be refined. Windows were fully documented:

Window states. Default values. Transactions triggered Etc.


23/37

06 November 2013

Methodology: Technical Construction

Major goals : Have the code show the high level of reuse identified duringanalysis.

Maintain a clear trace between the logical and the physicalworlds.

Achieve a high degree of documentation quality.

To achieve these goals, the Pool ofprogrammers concept arose : Analysts and programmers clearly separated. Pool control to balance the workload of the pool. Communication established via worksheets.

M h d l T h i l C i


24/37

06 November 2013

Methodology: Technical Construction.5 layers Architecture

Presentation Event Coordination LogicalServices

DataAbstraction

PhysicalAccess

Window flowand windowpresentation

User actioninterpretation

Performlogicalservices

Provideentity andattributeaccess

Providephysicaldataaccess

This structure has been enforced by using Templates

M th d l T h i l C t ti


25/37

06 November 2013

Methodology: Technical Construction.5 layers Architecture. 2 Tiers Example

Temenos Corebanking

PRESENTATION COORDINATION LOGICAL SERVICES DATA ABSTRACTION PHYSICAL ACCESSLOCAL EXECUTION

PRE

CON

INIEST_INIFIJ_INI

HOST EXECUTION

TRN

MVF

EVT

SRV

ACT

VAL

CTR

XXF SRVSQL

COP.

Local DB

Device

TRD

TRD

TRD

SQL HOST DB

BATCH EXECUTION

IMS

BAT

INIFIN

INIFIN

EXP

TRI

TRB

MVF

MVF

P C S I D E

M A I N F R A M E S I D E

M th d l T h i l C t ti


26/37

06 November 2013

Methodology: Technical Construction.5 layers Architecture. 3 tiers Example

PRESENTATION COORDINATION LOGICAL SERV. DATA ABTRAC. PHYSICAL ACCESSEJECUCIN LOCAL

PRE

CON

INI

ACT

VAL J a v a - C

l i e n

t

M i d d l e T i e r

M a i n F r a m e

APPLICATION SERVER -EJECUTION

CTRVAL

TRD

SRVTRD

SQL

MAINFRAME - EJECUTION

TRNMVF

EVT

SRV

TRD

SQL

LOCALDATABASE

HOSTDATABASE

M th d l g T h i l C t ti


27/37

06 November 2013

Methodology: Technical Construction.Rule Hierarchy


28/37

06 November 2013

AppBuilder

A Sophisticated Development Tool.

Allows to develop and maintain informationsystems independently of the productionplatform.

Proprietary 4 Generation Programminglanguage.


29/37

06 November 2013

AppBuilder. Production Environments


30/37

06 November 2013

AppBuilder: Description

AppBuilder stores all application information ina central REPOSITORY.

An AppBuilder application consists ofOBJECTS which have RELATIONSHIPS witheach other, based on a DetaModel.

Applications are developed and maintainedusing tools provided by AppBuilder.


31/37

06 November 2013


ER Diagrams Window definitions Application Hierarchies

Matrices Help, Text, and Keywords Rules code

Name Address

CityState

The Customer Detail Screen isused to enter new customers,delete customers, and modifycustomer information.

Choose the Quit push button tocancel the previous action.

do whileWINDOW_RETCODE_'EXIT'converse window CUSTOMER_DTLcaseof WINDOW_RETCODE

case 'Open'use rule

DISPLAY_CUST_LIST case 'Delete'

Process

Entity

Users and Projects Migrations Security

Quit

AppBuilder stores all application informationin a central REPOSITORY


32/37

06 November 2013


FUNCTION PROCESS RULE FILE

COMPONENT

WINDOW

VIEW FIELD

SET

VALUE

refines is defined by

refines

accesses

usesuses

converses

accesses

has

has

includes

includes

contains

Is domine of

has

An AppBuilder application consists of OBJECTS which have RELATIONSHIPS with

each other, based on a DataModel:

has


33/37

06 November 2013

AppBuilder: Objects

Approximately 95 AppBuilder Object Types e.g. RULE, COMPONENT, WINDOW, VIEW, FIELD,

SET, VALUE, FUNCTION, PROCESS, TABLE,COLUMN

Most are logical (analysis objects) Ones used to generate code are: RULE,

COMPONENT, WINDOW, VIEW, FIELD, SET,VALUE, FILE

AppBuilder Objects have Attributes

Some AppBuilder Objects have source code


34/37

06 November 2013

AppBuilder: Development Tools

DATA

PROCESS

LOGICAL

PHYSICAL

ERD STD PDD

DBD HD

WFDRP WP

SD ACD PND

MD

ERD =Entity Relationship Diag. STD =State Transition Diag. PDD =Process Dependency Diag. MD =MatrixDiag. DBD =Database Diag. HD =Hierarchy Diag. RP =Rule Painter, WP =Window Painter, WFD =Window

Flow Diag. SD =Server Diag. ACD =App. Configuration Diag. PND = Physical Network Diag

Repository


35/37

06 November 2013

AppBuilder: Development Environments

3270 MainframeWorkbench (TSO)

Repository(DB2)

PC WorkbenchesNT o W2000 + DB2

Upload /download

OS/390

Repository

Win-NT/2000+

SQL Server

AIX+

Oracle

WorkgroupServer


36/37

06 November 2013

TCB Volumes

Analys i s Objec t sEntities 1500

Attributes 3500Business Objects 198Simple Business Events 2900

Transactional Events 2100

Cons t ruc t ion Objec t sTables 2800Windows 2500Rules 60000


37/37

Summary of Design Benefits

Methodology Industry standard methodologies ERDs, STDs, PDDs Widely accepted and understood

Case Tool Developed Enforces implementation / adherence to the methodology Documents the business process Generates the consistent code Documents the system

What is delivered A pre built system covering a wide range of products

Business flexibility through user definable parameters and rules Powerful product builder based on reusable functional objects A powerful development tool which allows the product to be expanded

Using a controlled and standard development self documenting environment A catalog of resusable business objects and rules