8/14/2019 TCB History and Development Architectures
1/37
06 November 2013
Temenos CoreBanking
History and Development Technologies
8/14/2019 TCB History and Development Architectures
2/37
06 November 2013
Agenda
Temenos CoreBanking History
FSDM: Financial Services Data Model
Development Methodology
AppBuilder
Volumes
8/14/2019 TCB History and Development Architectures
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.
8/14/2019 TCB History and Development Architectures
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
8/14/2019 TCB History and Development Architectures
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
8/14/2019 TCB History and Development Architectures
6/37
06 November 2013
FSDM. The Origins
FAS90
WBC TRUST CMIM
CustomerProjectsBankingKnowledge
8/14/2019 TCB History and Development Architectures
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
8/14/2019 TCB History and Development Architectures
8/3706 November 2013
FSDM. Hierarchy. A level
The 9 Data ConceptsInvolved Party Arrangement Condition Product
Business Direction Item
Classification Location
EventResource Item
8/14/2019 TCB History and Development Architectures
9/3706 November 2013
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
8/14/2019 TCB History and Development Architectures
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
8/14/2019 TCB History and Development Architectures
11/3706 November 2013
FSDM. Hierarchy. C level
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
8/14/2019 TCB History and Development Architectures
12/3706 November 2013
FSDM. Hierarchy. C level
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
8/14/2019 TCB History and Development Architectures
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.
8/14/2019 TCB History and Development Architectures
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
8/14/2019 TCB History and Development Architectures
15/3706 November 2013
Methodology Phases
Enterprise Definition
BOA/TA
Protocycling
Technical Construction
Delivery
C`Development
8/14/2019 TCB History and Development Architectures
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
8/14/2019 TCB History and Development Architectures
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)
8/14/2019 TCB History and Development Architectures
18/37
06 November 2013
Methodology: BOA / TA (ERD-EntityRelationship Diagram)
C Objects
8/14/2019 TCB History and Development Architectures
19/37
06 November 2013
Methodology: BOA / TA (STD-State TransitionDiagram)
8/14/2019 TCB History and Development Architectures
20/37
06 November 2013
Methodology: BOA / TA (PDD-ProcessDependency Diagram)
Simple PDD
h d l (
8/14/2019 TCB History and Development Architectures
21/37
06 November 2013
Methodology: BOA / TA (PDD-ProcessDependency Diagram)
Transactional PDD
8/14/2019 TCB History and Development Architectures
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.
8/14/2019 TCB History and Development Architectures
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
8/14/2019 TCB History and Development Architectures
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
8/14/2019 TCB History and Development Architectures
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
8/14/2019 TCB History and Development Architectures
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
8/14/2019 TCB History and Development Architectures
27/37
06 November 2013
Methodology: Technical Construction.Rule Hierarchy
8/14/2019 TCB History and Development Architectures
28/37
06 November 2013
AppBuilder
A Sophisticated Development Tool.
Allows to develop and maintain informationsystems independently of the productionplatform.
Proprietary 4 Generation Programminglanguage.
8/14/2019 TCB History and Development Architectures
29/37
06 November 2013
AppBuilder. Production Environments
8/14/2019 TCB History and Development Architectures
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.
8/14/2019 TCB History and Development Architectures
31/37
06 November 2013
AppBuilder: Description
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
8/14/2019 TCB History and Development Architectures
32/37
06 November 2013
AppBuilder: Description
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
8/14/2019 TCB History and Development Architectures
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
8/14/2019 TCB History and Development Architectures
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
8/14/2019 TCB History and Development Architectures
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
8/14/2019 TCB History and Development Architectures
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
8/14/2019 TCB History and Development Architectures
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