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.
In a conversation with a vendor in the application portfolio management space the other day, we got on the subject of what "Cloud" means to them and by extension to their current and future customer base. My colleagues have written extensively on what it may mean to Oracle, Microsoft, IBM, HP and others, and our conversation began discussing the potential of cloud-computing from a vendor perspective - for instance:
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.
Those are words you don't want to hear when playing chess. Similarly, you don't want to be checkmated in the rough and tumble of the business real world.
To win at chess and in business to you have to make smart decisions constantly and consistently - decisions that are guided by a carefully crafted strategy designed to checkmate your opponent or, at a minimum, to stay in the game. Deciding what moves to make in chess is hard enough even though it is just you and your opponent. The decisions businesses have to make everyday can be much more complicated and the stakes are much higher.
I want to develop a Web application - a really good Web app. The kind of Web app that will make me so rich that I can buy an $9.4 million co-op over looking Central Park, a Yacht registered in Monaco, and hire an architect to build my dream-house west of Boston that is a combo of Buckminster Fuller, FLW, and MTV cribs.