Release Methodology - R17 J-1

After completing this learning unit you will be able

to:

Describe the software lifecycle

Differentiate Frequent release, Generally Available release
Explain the release methodology in T24
Describe T24 updates
Explain the workflow to install a T24 update

Release Methodology - R17 J-2

 Tired of doing things manually and with the invention of the computer,
man started thinking of creating software for every possible walk of life.
Software helps you work more effectively and accurately. Based on the
requirement, the first step would be to design and code the software.
Testing to see if all is well is the next most important step. After this is
done, the software is ready for use and can be implemented in real
time. Nothing in this world is perfect and neither is software. Using a
software in most cases bring up issues with it, some simple and some
critical. These are commonly referred to as bugs. Reported bugs are then
fixed for the clients.
Every software evolves with time. There might be new enhancements or
functionality changes which will result in updating the code and
redesigning the software. These are then tested and released as a
improved version of the existing software. Every new version of a
software is referred to as a release.
This is the cycle all software go through.

Release Methodology - R17 J-3

 Similar to any software life cycle, T24 also has a life cycle. Temenos releases a
new version of T24 every year with newer functionality to keep up with the
growing demands of the market. This yearly release is called a GA release
which stands for Generally Available release.

After the GA is released, Temenos will work towards releasing the next GA.
But what if a client faces an issue with the GA it has installed? If reported, the
Development team will work to fix it in the GA stream. The fix will be packed
into an update for the component on which the fix is done. This update will be
available on the updates portal for the client to download and install.

If the client requests for new functionality, the new functionality will only be
provided in the next release. New enhancements will not be introduced into
a released AMR stream.

Project Builds , which were internal builds, used to be released frequently.

They were named as PByyyymm , where yyyy represented the year and mm
the month. There could be more than one project build in a month. The
project builds were generally not shipped to clients.

Release Methodology - R17 J-4

 After R13GA, Temenos has moved to Frequent releases, rather than traditionally releasing
Generally Available T24 release once every year. In the new release methodology, there are
monthly releases every month. When a desirable number of enhancements have been added
to T24, Temenos announces an AMR (Annual Maintenance Release). The difference here is
that AMR release cycle is not fixed to one year. There may be multiple AMR’s announced in a
year or none.
This allows an implementing client to get a monthly release which is an early bird release
before the software gets finalised for the next AMR.
Each month’s release is named after the release month and year. For instance, the October
release of 2014 is called as 201408.
Each frequent release would contain the enhancements that have gone into the preceding
frequent releases, bug fixes and new enhancements. Though AMRs are typically released
annually , a frequent release that has sufficient new functionality built in could be released as
an AMR.
The monthly releases are software releases but need not have streams created for them .
Which means if there is a bug in the monthly release, it is fixed in the Dev stream and is
available only in the next monthly release. If however a monthly release has been implemented
by a client , then there would be a separate maintenance release stream for that release, to so
that Temenos can support the client.
Project Builds , which were internal builds, used to be released frequently. They were named as
PByyyymm , where yyyy represented the year and mm the month. There could be more than
one project build in a month. The project builds were generally not shipped to clients.

Release Methodology - R17 J-5

 There are two phases to a Monthly release.
1) Month 1 - Design and Construction phase– Where the requirements for
the specific enhancements are gathered and technical specifications are
frozen by the respective verticals (Treasury, Retail, Islamic etc). The
enhancements are coded and unit testing is performed for the respective
verticals. Bugs identified are corrected and the code is delivered . A Dev
build cut is taken at the end of Month 1 with the naming convention
YYYYMM. Eg: 201308 or 201411.
2) Month 2 – Testing phase – Where stabilization of the product is focused
with System Integrated testing. At the end of Month 2 the monthly
release YYYYXX is released. In parallel, the design and construction phase
of the ensuing monthly release YYYY(MM+1) is performed by the
respective development teams in the various verticals.
For e.g., presuming 201307 Monthly release is released on 1st July, Design
and construction for this release would typically take place during May and
testing during June so that release takes place on 1st July. The Design and
construction phase of the enhancements for the 201308 monthly release
would also run in parallel during June such that code for 2013008 can be
delivered by 1st July. On August 1st, 201308 build would be released.
May-Design & Construction -> June-Testing-> 1st July 201307 Monthly release
June-Design & Construction -> July-Testing -> 1st Aug 201308 Monthly release

Release Methodology - R17 J-6

 • Frequent releases are released on a monthly basis and comprise of new
functionalities, bug fixes and enhancements . They are named in the format
YYYYMM where YYYY stands for the year of the build and MM for the
month in which that particular build is released. Examples of frequent
releases are 201302, 201409 etc..
• Each frequent release contains the cumulative enhancements from all it’s
preceding releases upto the last AMR. For instance the 201408 release
would contain all enhancements and fixes in the frequent releases post
R14AMR till 201408.
• A frequent monthly release could become an AMR.
• AMR have so far been released once a year. However, there could be
multiple AMR releases.
• After the AMR is officially launched, no further enhancements are done in
that release.
• Naming convention is in the format RXX where XX stands for the year of
release and 000 denotes that it is a GA release
• Examples of AMRs are R07, R08

Release Methodology - R17 J-7

 This is an overview of how the T24 Updates system works.
The bank requires an update.
It can search for the updates in the Temenos Customer Support Portal (tcsp),
provided the bank has registered with the tcsp. After the registration, the
bank should register its T24 system with the Temenos Customer Support
Portal. This is a one time step. The system information (in the form of an xml
file) should be extracted from the bank’s T24 Server using toolbox and with
the extracted information, the T24 system can be registered with tcsp. The
bank should login to the tcsp, select the registered T24 system, check for
available updates. A list of available updates will be provided to the bank. The
bank may then choose an appropriate update, download and install it using
the T24 updater tool. For detailed explanation on every step, refer to the T24
Updates course.

Release Methodology - R17 J-8

 TAABS is T24 Automated Analysis and Build system. It is a web portal to ensure smooth
delivery of the Initial System Build (ISB) via a single access point. Initial System Build is a
T24 environment delivered to a client. The delivery of ISB involves the Distribution team,
Implementation Team, TAABS team . TAABS integrates and co-ordinates their various
activities to deliver the ISB to client. The TAABS process starts with the initiation of
request for a Client T24 Environment by the Implementation Team. Client implementation
form / Software Request Forms (SRF) , Package request form(PRF) and TAFC forms
available on Temenos Unit-T, are first filled by the implementation team with details like
the Products purchased by the Client, the Client Details, the Local Currency, the Bank
Date, the Database, the Operating System etc. Either the project management or the ISB
team applies for License and maintenance codes. On verification of these documents, the
licensing team issues license and maintenance codes. TAABS questionnaires available on
the Unit-T are filled by the implementation team during various workshops. These
questionnaires capture the T24 parameters based on the Client Requirements, which are
loaded into the T24 Environment during System Build. Using these details, TAABS team
initially prepares the Base System Build (BSB), on which OS and DB conversion process is
performed, updates and Regional Layer Maintenance(RLM) components (i.e., interface
and third party components) are installed. Post this process, Initial System Build is put
through the testing process and sufficient health checks are done and the build is handed
over to the Distribution team. The Distribution team then ships the software via SFTP
server. A copy of the ISB is also shared with the IPRM (Integrated Packaging and Release
Management ) team for any local developments thereafter.

Release Methodology - R17 J-9

 For banks that are running T24 already, we perform an upgrade. The upgrade
changes the codebase and modifies the data layout as appropriate.

Release Methodology - R17 J-10

 1. There should be only one frequent release for a particular month -
TRUE – usually true
2. AMR can be released multiple times in a year. TRUE – Yes from R13
there can be multiple AMR releases
3. Updates comprise new functionality, enhancements and bug fixes
FALSE – Only bug fixes
4. Project Builds comprises new functionalities, enhancements and bug
fixes TRUE
5. Naming convention for AMR is RXX TRUE
6. Naming convention for Frequent Release is YYYYMM TRUE
7. Temp Releases are given to new clients FALSE - They are given to
clients having an existing release of T24

Release Methodology - R17 J-11

 In this learning unit, you learnt about the release
methodology in T24
You will now be able to
• Describe the software lifecycle
• Differentiate Frequent release, Generally Available release
• Explain the release methodology in T24
• Explain the workflow to install a T24 update
• Describe T24 upgrades

Release Methodology - R17 J-12