Similar to the past few years at this time of year, we are in the process of preparing a global banking platform deals report for 2010. As we have done since 2005 to help application delivery teams make informed decisions, we will analyze deals’ structure, determine countable new named deals, and look at extended business as well as key functional areas and hosted deals — all to identify the level of global and regional success as well as functional hot spots for a large number of banking platform vendors.
In the past, some vendors told us that they are not particularly fond of us counting new named deals while only mentioning extended business, renewed licenses, and the like. Why do we do this, and what is the background for this approach? First, extended business as often represents good existing relationships between vendors and banks as it represents product capabilities themselves. Second, we have asked for average deals sizes and license fees for years, but only a minority of vendors typically discloses this information. Thus, we do not have a broad basis for dollar or euro market shares — and I personally shy away from playing the banking platform revenue estimates game.
An Alternative Counting Model Could Be Implemented Easily . . .
Consequently, available data makes counting new named deals the only feasible way to represent an extending or shrinking footprint in the off-the-shelf banking platform market — and thus to also represent customer decisions in favor of one banking platform or the other. Some vendors suggested introducing weights for the size of the bank and the relevance of the seven world regions (for example, North America and Asia Pacific). We could easily do so, but there are problems with this approach:
A few days ago, I “rediscovered” a brochure from a museum in Stockholm. It reminded me of an early 17th century warship: The Vasa. She was the most powerful warship of her time — albeit for less than half an hour, as she sank during her maiden voyage. The reasons for this disaster include top management interference, overly sophisticated requirements, weak communication, and overengineering. Why is this relevant today? Because projects have not changed that much: The Vasa story reminds me of a number of interactions I had with Forrester clients about banking platform transformation projects that ran well — or not so well.
A large share of the less-successful projects showed a number of the ingredients of the Vasa story, causing what I like to call the Vasa effect: predictable failure. Examples include:
Off-the-shelf projects that had to manage a burden of business requirements that were so sophisticated that no off-the-shelf system could ever hope to cope with all of them in a cost-effective way. In parallel with the Vasa story, in these cases nobody dared discuss whether the last 15% or even 5% of the requirements were really important enough to justify the additional cost — or whether delivering 85% of the requirements would be good enough.
So-called off-the-shelf solutions that were more custom-built than a real custom-built solution. They had to align with a bank’s off-the-shelf strategy while living up to concretely defined, highly sophisticated, and very individual business requirements, including solitaire business process definitions.
A couple of days ago, global banking platform vendor Temenos announced that it has signed an agreement to acquire Odyssey Financial Technologies, which specializes in the private banking, private wealth management, and asset subverticals of financial services. The deal is expected to close around mid October: Temenos will pay more than 60 million euros and take on Odyssey’s existing debt obligations of more than 20 million euros. Here is my initial reaction to the planned acquisition.
On the asset side, Temenos will get the private banking platform Triple’A Plus, portfolio management and decision support solution WealthManager, plus clients such as Banque Cantonale Vaudoise, Delta Lloyd, and RBS Coutts Bank. This will help Temenos accomplish the necessary extension to its private banking footprint: In spite of prominent private banking clients such as EFG Bank, over the past few years Temenos’ T24 has not been as successful in the private banking/wealth management arena as, for example, ERI Bancaire, SunGard, or Tata Consultancy Services Financial Solutions as far as new named customers are concerned — not to mention the various regional private banking pure players.
At the same time, the Odyssey solutions will add additional technologies and architecture to Temenos’ already existing acquired portfolio: Not considering the two “classic” Temenos banking platforms T24 and TCB and the mobile solutions of recently acquired specialist vendor FE-Mobile, Temenos acquired multiple smaller banking platform vendors over the past few years, including Financial Objects in the UK and Viveo in France, plus further firms such as business intelligence and reporting vendor Lydian Associates.
I have discussed questions such as “Which banking platform vendor is the right one for a given financial services firm in its specific requirements context in a given country?” with Forrester clients for some time. Interestingly, the share of these discussions touching on questions such as “How viable is vendor X?” and “Is vendor Y the right one for a bank the size of mine?” is increasing. What is the reason for this?
It is clear that in such a global situation, the reduced deal numbers of many vendors and the economic trouble of some are reason for concern for many delivery teams making or supporting the long-term decision for a new banking platform vendor — particularly when preliminary findings from a Forrester survey show a new thrust for the renewal of the financial service application landscape. At the same time, banking platform vendors’ behavior is changing:
I just returned from a business visit to India, and on the long way back, I had the time to sort out some observations and ideas on the future of the banking backbone that I had discussed with bankers as well as banking platform vendor execs over the past few weeks. But let me start from the beginning.
A few days ago, CSC announced its new Celeriti banking platform, which consists of five products: Celeriti Customer, Celeriti Deposits, Celeriti Loans, Celeriti Cards, and Celeriti Merchant. The solution includes, for example, a strong business process focus, business intelligence, and the so-called Web Portal User Interface. The platform has been built around IBM application infrastructure, runs on multiple operating systems such as z/OS, z/Linux, Linux, and Windows, and has been validated for use with the IBM Banking Industry framework. Here is my initial reaction to Celeriti.
In discussions on cloud computing, I often talk to architects who have been told to create a "cloud strategy." This sounds appropriate enough, but there’s a devil in the details: When the task is "create a Technology X strategy," people often center strategy on the technology. With cloud, they aim to get a good definition of pure cloud and then find places where it makes sense to use it. The result is a technology strategy silo where cloud is placed at the center and usage scenarios are arranged around it. The problem with this is three-fold:
Considering the full business dynamics of any given usage scenario, there is a wide continuum of often strongly competing alternatives to pure cloud (including cloud-like and traditional options).
The rapid pace of market development means that business value equations along this continuum of options will keep changing.
Your business needs integrated strategy for many technologies, not simply a siloed cloud strategy.
Most of us have already heard that Sybase will become part of SAP — or, to be more precise, that SAP and Sybase announced that SAP's subsidiary, SAP America, Inc., signed a definitive merger agreement to acquire Sybase. When this acquisition takes place, there will be various impact areas across SAP and Sybase’s combined portfolio. Rather than discussing this big picture, I would like to focus on SAP for Banking.
Jean-Jacques Rousseau wrote, man is born free and is everywhere in chains. So too Enterprise app deployments are conceived as self contained yet everywhere are integrated with legacy and complementary apps.
My colleague Ken Vollmer and I are looking at packaged apps integration best practices and how these might change as some apps move to the cloud. We are asking:
What kind of middleware do you use?
How do you help process owners to assemble (composite) processes that have transactional integrity?
What do you do about the conflicting data models of apps from different stables – for example yours and those of a third party or perhaps in –house?
How far can so called “canonical” data models and meta data help to overcome such problems?
If you have experience and an opinion about what constitute the top three best practices in such packaged apps integration, or if you can warn about the three most egregious pitfalls to avoid we would love to talk with you.
The mobile channel is increasingly relevant in business strategies, application architectures and applications of financial services firms. Consequently, we are all aware that the headline represents a strong exaggeration. So, why this statement? Is there any substance in it that application architects, application developers, and enterprise architects need to consider? Interactions with a number of banks indicate that the answer is yes.