Temenos Globus / T24 Banking Package

Print Friendly, PDF & Email

TEMENOS T24 a.k.a. Globus

T24 (previously named Globus) is a banking integrated and modular package (also named a “legacy system”). For a commercial description, see the official site of Temenos Group AG.

“Temenos T24 is a complete front- to back-office, CRM and product lifecycle management software platform that powers core banking operations.
Consistently ranked as the first or second best-selling core banking software platform worldwide for the past 14 years (International Banking Systems Sales League Table), T24 has been developed using a complete service-oriented architecture that’s modular so banks can deploy and integrate the required functionality alongside the needs of their business.” (Source: Temenos Group AG)

To summarize the definition of this product , it could be the most flexible system you’ve ever met. In some way, it could (and should!) be compared to a toolkit.
From my own perspective, after quite many years spent (and counting) on this banking package:

This product differs from other ones in its segment with:

  • A technology coming from the 70’s: this may appear to be antique, but similar technologies (such as Unix) are still and successfully operating in many sectors nowadays.
  • An amazing flexibility: Again, we could use the term of “toolkit” better than a “plug and play” banking solution. On one hand this implies mid-to-long term implementations projects. On the other hand you have the satisfaction to meet most of business requirements during the set-up phase. Furthermore, local developments are fully taken into consideration as they remain isolated from the core system, but with strong interactions with it at the same time: this means that every product upgrades (releases) will not have impacts on local developments.
  • A very wide functional coverage: based on a modular organization, this solution can either fit an entire bank or specific business niches. Even if each module not always represents the  “state of the art” in its domain, the inherent flexibily provides ability to cover the gaps using local developments.


Now what’s one bank’s wish-list when selecting a package?

  • reduced maintenance of functional evolutions costs
  • controlled hardware budgets
  • capacity to cope with increase of volumes
  • flexibility to follow quickly new business orientations without strong vendor’s dependance.Following my own experience, this package meets most of these targets.

An native integrated database: Universe/J-Base (for the ones not adding a standard RDBMS (Oracle,…) layer)

  • does not require any database admnistrator (who can say that nowadays? 😉
  • is very powerful compared to more popular ones, mainly because of multivalued fields, easy to configure / maintain.
  • pseudo-relational database (also called surprinsingly post-relational. For me, this should means that it became relational at the end!). No integrity controls, some redundancies, etc…but nothing dramatical. The model is roughly well designed, just a bit heavy with more than 1600 tables. Furthermore, the database appears to be faster that a classic RDBMS SQL-based one: anyway, modern relational databases are not famous for their access performances.
  • is extremely robust: I’ve been involved in few benchmarks testing, and lacks in the design of some programs were appearing rapidly. Once fixed, high volumes stress-tests were giving amasing results for such a database. Actually, Universe (now JBase) was born in the late 60’s, and derived from Pick multivalued systems, which were built for US large governmental companies (the NASA ;-D,…). On the top of this, in all clients sites, we can notice a zero downtime of the database for decades(!), which can not be compared to “modern” RDBMS. More details on this topic from wikipedia here.

Since several years, the vendor has isolated the banking programs from the database layer. Then, new clients have chosen Oracle or SQL Server RDBMS. Since this is a less native DB, performances are of course a bit decreasing with such a choice, but banks are benefiting from Oracle / SQL Sever DB administration tools.

On the other hand…

  • A proprietary development language: Globus/T24 integrates a specific compiled language called UVBasic. Quite easy to learn, but as not a standard language. Considering the success of this package, easy to find qualified resources nowadays.
  • The official site talks about “Open Standards”. Clearly, all theses points are related to progresses the company have done in order to open its system. You can read for instance: ‘J2EE application server’, ‘user interface through browser’, ‘HTML and XSLT’, ‘connectivity through XML and Web Services’, ‘C language code’, ‘Java development environment’. All theses marketing topics should not alter a reality: the native database is needing some efforts to extract information easily. Having the data on Oracle does not means you extract what you want using simple SQL queries.

To moderate this risk: During implementation stage, an effort should be done to build and train a dedicated team, in order to get an IT staff of one bank deeply involved in the product, and being able to maintain it easily after go-live. After all, and whatever the legacy system chosen, a high level of team’s implication is the key factor for a successful implementation.

More technical resources on “Post Relational Databases” available on this link.

, ,

  1. No comments yet.

You must be logged in to post a comment.