During any economic downturn, corporate finance departments look for ways of reducing cost. If the cost cutting can be in the finance department itself, all the better. However, the current environment is somewhat different as there is also a crisis of confidence among the investor community and hence any cost cutting in finance must avoid damaging standards of corporate governance.
The webinar next week is focusing on an area which if correctly addressed, fits the bill by improving standards and reducing the manual effort (and hence cost). Account reconciliation may not appear be the most obvious area to look for hidden costs. However, anybody who has struggled to reconcile their own credit card statement to receipts can probably imagine the amount of effort required by large corporations to do the same across thousands of accounts across multiple business units and even countries (on the webinar, Gary will be talking about a corporation that needed 500 employees and over 100,000 man hours of effort to complete the task).
The solution that Smartstream is proposing - based on their experience in corporate finance departments as well as large financial services firms - is a form of business process management designed specifically to solve this type of problem. This makes a lot of sense as the reconciliation problem is first of all one of process optimization and knowledge capture - then one of supporting the management of the inevitable exceptions (those reconciliation problems that cannot be automatically resolved using the defined business rules and workflows).
If this sounds like something your organization could benefit from sign up for the webinar here.
Ronan
The debate on the death of SOA was an echo of Anne Thomas Mane's controversial blog post of the same title. Her thesis is that SOA has been badly hit by the recession as she puts it:
"SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession"
However she goes on to move the blame away from the recession
"It's time to accept reality. SOA fatigue has turned into SOA disillusionment. Business people no longer believe that SOA will deliver spectacular benefits. "SOA" has become a bad word. It must be removed from our vocabulary."
As Gartner spotted a few years ago, IT trends follow a pretty predictable path from hype to crash to becoming part of the landscape. Therefore, we shouldn't be surprised to see many organizations and some industries back off SOA - particularly when the service oriented concept really doesn't fit into their main business (for instance investment banking for the most part is more comfortable with an event driven architecture).
Conversely, we shouldn't ignore the fact that some industries find SOA a great fit - such as insurance (as reinforced by Software AG's announcement of a major Chinese insurance company committing to SOA as a vehicle for growth).
However, while I agree with Anne's general point that SOA is looking tired, I am not as concerned about the long term impact as Anne is:
"The demise of SOA is tragic for the IT industry. Organizations desperately need to make architectural improvements to their application portfolios."
Even where SOA does not remain as the headline project, the benefits will continue to accrue - particularly with regard to the focus on governance and development of best practise and structures within the organisation to promote appropriate cooperation and pooling of expertise around integration. I recall much of what is now called SOA governance being in place in the large international banks which attempted to adopt CORBA back in the 1990s. As such SOA has acted as a vehicle for transferring the learning these leading organisations had developed to a much broader set of companies. Therefore, even if the SOA project is deemed to have failed, the organization has probably learnt much about how to solve the necessary complexity of many integration projects.
And finally, if SOA isn't the headline what is? Unfortunately for many, for the next while the project headlines will be utterly pragmatic: do whatever maximizes the chances of short term survival. However, I believe that over the last year (at least) we have seen the beginning of the next major IT trend: data integration (yes - I know data integration isn't new but what is now emerging is new and significant). This is a trend which both builds on the SOA legacy (I am firm believer than SOA naturally brings the emphasis back to data integration) and provides a pragmatic and credible solution to immediate business challenges.
Ronan
However, XBRL is far from new - I first ran into it back in 2001 or 2002 when it was coincidentally being promoted as the antidote to our last generation of corporate collapse (enron et al). For those readers not familiar with the standard, XBRL supports the expression of financial statements in XML format and to facilitate this has developed XML definitions of terms and the relationships between terms used both across all industries and within individual industries. By expressing all of this information in XML, it becomes possible to submit company reports electronically in a format which (unlike pdf for instance) enables the information to be sliced and diced to ensure compliance or indeed support any other analysis or even comparisons between companies or industries.
Therefore, it is natural to extend XBRL to focus on risk measurement in particular as IBM and its data governance council are doing with their proposed creation of a taxonomy of Risk based on XBRL. According to the data council chairman, Steve Adler:
"Creating a risk taxonomy using XBRL will provide a vocabulary and a common language allowing everyone to understand what risk means, and that's the first step in making it easier to calculate and report. When we have semantic clarity around the way organizations describe risk, incidents, events, losses, claims, exposures, forecasts and reserves, it gets easier to aggregate loss information, analyze it with standard actuarial methods, compare past exposures to present conditions and opportunities, and forecast potential outcomes."
This is clearly an ambitious goal but the question is not whether the standard can be defined but rather whether it can be implemented and whether there will be sufficient business or regulatory drivers to get it implemented.
The answer to the first question is probably yes: Unlike in 2001/2002 when XBRL was first promoted, there is now a much greater level of maturity around data integration and hence much of the required infrastructure is already in place. However, XBRL is an exacting standard and there may well be significant upgrades required to existing XML processing tools which often struggle with more complex schema standards.
The answer to the second question is entirely in the hands of the regulators and their political masters.
Ronan
Yet Brady Dougan, Credit Suisse chief executive, yesterday painted a picture of an investment banking future all but stripped of the exotic derivatives and highly-leveraged products that dragged the Swiss bank into losses. It will, henceforth, emphasise client flows over proprietary trading
As a strategy it makes sense in the new investment banking world: exotics have a greater potential for profit and for loss. If this becomes a general trend (as seems plausible), how will it impact IT spending? Less proprietary trading and less interest in complex instruments will certainly change the focus of IT projects in investment banks over recent years: Potentially less growth in volume meaning less investment in infrastructure capable of supporting the volume, and less exotics mean less investment in systems capable of trading and more importantly calculating the risk.
This thought reminded me a recent conversation with a vendor who saw the big growth in Financial Services in core banking system replacement projects - as banks consolidate, so will the core banking systems and hence so will the need for the integration projects required to wire these systems in.
The combination of the two trends would certainly change many banks' IT strategies (and vendor sales strategies). And that is all before the EU review of hedge fund regulation even starts!
Ronan
"SOA and BPM projects cannot effectively deliver on their promise if they don't resolve issues related to the various data formats, semantics, hierarchies, inconsistencies, staleness and inaccuracies within the underlying data sources."
This weakness in many SOA/BPM projects tends to lead to SOA/BPM being restricted to specific problem types where all the participants have similar and preferably simple data models. In many industries, including financial services, this has meant SOA and BPM is more often found only in secondary business areas (HR, operations etc) where the data is simple and static or in areas with well defined processes (for instance in the case of BPM, message fixing or client on-ramping).
The problem is that many SOA evangelists focus exclusively on the functionality side of the service and ignore what I sometimes refer to as the implicit data model embedded in any service definition. To quote Madan again:
"Most business processes supported by SOA are inherently data-driven. Yet
many organisations don't intuitively think about their SOA or BPM
problems as data problems."
This mismatch is potentially fatal to success with SOA/BPM and Madan's paper is most timely (not only because she agrees with my own views of course!) and well worth a read. To address it effectively requires significant thought and effort combining appropriate software, data governance and leveraging standards (such as those the EDM council is working on).
Ronan
Unfortunately, I believe that the challenge that vendors already face in getting the users to pay for support will only get worse: This is the most discretionary payment most organisation will ever be asked to make and will inevitably be the first to go. It is simply too dependent on altruism and long term benefits.
However, I do not see this as the end for growth in OSS: the already established projects will inevitably be more widely adopted and supported by the major vendors. At the other end of the spectrum, the independent contributors who have made a living off consultancy related to their niche project will also continue to get work. However, I can see the small specialist vendors being further squeezed between reluctant customers and reluctant funders - both groups wondering where they will get money from to give to the vendor. This means I suspect that the volume of mature and advancing OSS projects may decline outside of the niche projects driven by the single expert and those under the protective wing of the major vendors (IBM, Red Hat et al).
Ronan
]]>To quote Michael Atkin, managing director of the EDM Council in the press release:
"As data management becomes both an increasingly important regulatory and business priority,financial institutions are realizing the importance of EDM to their operational infrastructure".
EDM focuses on is itself broad in scope, with Ajay Bhargava defining it here as having six main components:
• Data architecture
• Data quality management (DQM)
• Metadata management
• Master data management (MDM)
• Data security
• Data governance
Addressing each of these across the organization requires a significant amount of effort (and the EDM council is focusing primarily on standardisation of data terms and definitions).
Why is EDM becoming more important? To a large degree for similar reasons as it's more glamorous cousin, SOA: To address the requriement for faster more efficient real-time integration and to avoid the cost and risk associated with stitching together potentially incompatible islands of data.
]]>James kicks off his article with an amusing story of a vendor asking for a demonstration of intent from James before the vendor would engage with James' employer (a large bank). It sounded a little like the sales guy had being listening to my hokum peddling friends a little too long! I can't remember ever being in a position to ask for something like that. As James puts it the burden of demonstrating value always lies with the vendor and I am sure he was politely shown the exit.
The real world challenge for all vendors is actually to be able to stay engaged with the customer until the funding cycle can come around with a placeholder for the type of project that suits your product. In theory, selling simply requires the locating of projects with budgets available which fit your product. However, in my own experience this doesn't happen very often as by then in most cases the product has already been chosen or at least a short list created. I have been asked in the past how long is the enterprise infrastructure software sales cycle - my answer must be: it really depends on the customer cycle more than the speed with which you can demonstrate value. This is of course where those unpaid for proof-of-concepts come in - to stay engaged and to mold the customers view of the world into seeing your product as the solution. As James also states: there is cost to the customer associated with any engagement even if supposedly unpaid for..
As we look forward into 2009, the overarching agenda will probably be 'do more for less'. However, translating that into specific projects that a vendor can go after is of course not possible: There won't be a budget for cost cutting! Rather, the cost cutting agenda changes the emphasis of every opportunity. For all suppliers this can be challenging to prove over and above other products making the same claim - even if you product is uniquely better (here again we come back to the unpaid for proof-of-concept).
The only solution is a little like living the virtuous life: Stick to your principles, listen to constructive criticism from people you should trust (including your customers), hunker down for a long struggle and hope for your rewards in the next life (or at least budgetary cycle).
]]>“Fundamentally, there are four types of firms in the industry. Those that: 1) Were banks, are still banks, but don’t want to be banks. 2) Weren’t banks, but now want to be banks. 3) Weren’t banks, don’t want to be banks, but tell the regulators that they are banks. 4) Aren’t banks, don’t want to be banks, but are told by regulators that they’re banks.�
From an IT planning perspective, this puts us all in a difficult situation: While we can assume that compliance will remain a major driver of IT projects in 2009, the focus will be on opportunistic responses to specific requirements as they arise and it probably won’t be until 2010 until we can assess the new regulatory landscape as a whole.
However, even if we can’t speculate on what the new wave of compliance will hold, we can speculate on the themes which may emerge. In particular, it is reasonable to assume that there will be a much stronger focus on real time assessment of risk which in turn will drive a more integrated and real time view of risk exposure across multiple asset classes. This will partly be driven by regulators wishing to ensure that firms can stay at all times within capital requirements in this highly volatile market and economic situation. However, once life was settled down, it will also be driven by the wish of banks to maximise profitability by improving their ability to manage their exposure to risk in real time.
Ronan
]]>the associate was unaware that the original document – which contained 24,000 individual cells, included some rows marked with an 'n' to signify those assets that Barclays would not be taking onJust to restate what I said last time:
the data may well be out of date or simply wrong with the obvious implications on decisions (and risk measurement and compliance!!). The reason the data will be out of date is obvious: in many cases there is no easy mechanism to ensure it is up to date and there is no easy mechanism to flag the problem when it is.
Clearly, excel is here to stay for a very good reason - it is a powerful and effective tool which users like. However, we should remember to incorporate it within any data governance strategy. Moreover, the problems caused by excel today should be fair warning to any organisation considering an uncontrolled dive into mashup style opportunistic applications which also provide powerful capabilities married to the potential for great mix-ups.
Ronan
]]>To start with Jay Lyman who disagrees when he states here that
"The more I consider the continued gloomy outlook, the more I am convinced the economic struggle will translate to increased interest, use and adoption for open source software."
And quotes OSS vendors who are saying to him:
"We think organizations are being forced to cut costs at the same time they are being forced into compliance and regulation, so it’s driving deals our way."
The first comment does make sense when departmental budgets are tight, there is a very sensible tendency to look for cheaper solutions and a very human tendency to look for solutions which do not require staff reductions: Where easier to save money than to remove the software license fee element.
However, that very tendency may have the first knock-on effect that will impact on the longer term development of OSS. As is well recognized among OSS vendors (for want of a better term) and analysts, the OSS specialists have struggled even in relatively good times to get users to pay the maintenance and consulting fees that they need to survive. It is also widely understood that most OSS projects rely on the vendor side to drive the project forward and in many cases provide most if not all of the code. Therefore, while the OSS project may become more widely adopted, the vendors could suffer from the same challenges as closed source vendors. This may result in consolidation in favor of the giants (IBM, Red Hat, Oracle etc) who have the scale and stamina to prosper. If this happens, it will slow down innovation and development of OSS in general.
However in another related piece he identifies what could be a longer term fly in the ointment:
"Big banks and insurers are among the primary forces that have ushered greater open source acceptance and maturity in the enterprise. It began largely with Linux and internal development, but has since spread to other parts of the infrastructure."
Jay is right to point out that financial services – and investment banking in particular - has been at the vanguard of OSS adoption and has also been instrumental in starting and funding some of the key infrastructure OSS projects. This has been the case for many years – probably starting with OpenAdapter from DKW up to more recent projects such as active-MQ. With less investment banks in existence and potential less room and interest in innovation, the OSS drive into infrastructure may stall.
Ronan
]]>Unfortunately, we can’t really speculate on the future trends based on what is happening right now to IT spend. What we are seeing are simply reactions to reducing budgets: people are cutting back on some projects and leaving others in place. However, this is not due to any long term strategy review. Rather in the absence of any better idea, the pre-crunch strategies are being adjusted and trimmed – not reinvented. Since we are the middle of the storm wait-and-see is the only option.
Equally, I think the view I have read and heard that the current trends will simply continue and be amplified (for instance even more need for low latency, high performance systems) is as simplistic as those who predict a return to ‘old-fashioned’ almost local banking based on some sort of subjective assessment of trust and reputation.
Fidelity International's Michael Gordon's article in the FT got me thinking a little more about what we could be facing in a while. Taking some of the ideas from the article, I will make some of own leaps into the dark and suggest what the future holds for IT:
(1) Banks will be much more tightly supervised by their ‘home nation’ authorities. In theory this may increase the requirement for regulatory enforcement systems. However, it depends how the regulation is manifested – if it takes the form of direct government supervision rather than reporting, it may not result in extra investment in IT-driven compliance. The emphasis of regulation may well shift - particularly in Europe where the EU has focus on customer friendly regulation intended to level the playing field across Europe (e.g. SEPA and Mifid). In contrast, the new age of compliance will focus on protecting and controlling banks.
(2) There may be a move away from the very complex (and hard to understand) financial instruments and potentially a reduction or at least a slowdown in the increase in overall trade volume. This would be a major change of focus for investment banking IT which has struggled for years to keep up with requirements for ever greater transaction volumes and requirements to support new and complex derivatives in ever shorter time frames.
(3) There will be a requirement for better transparency in every aspect of the bank’s business. This one should actually drive additional IT investment – in solutions which support better and more rapid transparency (BI, CEP et al).
I said that these are leaps in the dark – however that is all we can do right now. But the greatest leap of faith right now is to expect that the shakeout in banking will not result in an equally major shakeout in the way banks will use IT.
Ronan
]]>I will pass over my own concerns about what I see as the long standing and on-going abuse of the patent concept for this class of business ideas (Imagine if somebody had patented the concept to laptops or worse still, patented putting toilets on airplanes – which is closer in originality to this one!) and focus on the core issues. Yes, I can see why floating data center may have certain advantages in terms of land costs and cooling issues (no property tax and all that cold sea-water close at hand). However, I would wonder whether the extra costs would out-weigh these.
Which suggests to me that the main ‘benefit’ may turn out to be avoidance of data privacy laws. However, even this benefit is not going to work in many parts of the world. For instance, European data privacy laws stop export of personal data to locations not covered by similar laws (and Swiss banking laws famosly go much further). Add to that the rather obvious risk of attack and natural disaster on these datacenter vessels and the further risk that they get used to store data associated with illicit activities which would obviously benefit with extra-territorial locations, makes it all seem rather pie-in-the-sky. I guess I now know what the Google patent team do with their “20% time on your own projects�.
Ronan
]]>Back when it was announced in May, Gartner administered what by its standards is a
savage beating with the damning comment:
“After two unsuccessful forays into the collaboration market, Oracle is back with the next generation of Oracle Collaboration Suite. Gartner believes Beehive is unlikely to be any more successful than past efforts.�
Looking at the description of the product, I was even more surprised to read that Oracle Collaboration includes
"a complete range of collaboration services including conferencing, instant messaging, email, calendar, and team workspaces"
It sounds a little like the set of collaboration services you would have expected 5 to 10 years ago. Where is the support for the modern Web2.0 collaboration technologies: Wikis, RSS et al. Many banks are starting to experiment with Web2.0 and I think Oracle is missing a trick by not recognizing this change - particularly as Oracle already owns Web2.0 technology from its BEA acquisition and WebCenter which it could inject into Collaboration.
Ronan
]]>Whether such regulation is useful is arguable. Ex-SEC chief economist Richard Lindsey argues it isn't here and points out the problem with much regulation:
"The problem with prescriptive regulations is that sometimes you get outcomes you don't want. Also, if you draw some lines, the game becomes how close people can get to the line. Flexibility works better."
Often regulatory compliance becomes tick-the-boxes to cover legal requirements to the letter and no more but don't necessarily deliver the benefits expected by the regulator. The Single European Payment Area (SEPA ) initiative in the EU is a case in point. The banks have in most cases done just as Mr Lindsey says: stayed close to the line which means they pass compliance but SEPA is not yet there in a real sense.
Unfortunately, even if compliance solutions will not deliver benefit to the banks (beyond avoiding jail!), they will still be taking up the decreasing IT investment dollars and diverting the creative energy and focus of IT departments. This may result in some short term benefit to vendors who can fit into the new regulation gap. However, longer term I believe further emphasis on regulation actually undermines the IT value proposition as it diverts attention away from activities that focus on IT as enabling business. Perversely, this may also delay initiatives which may actually be more effective in avoiding repeats of the current situation (for instance around business intelligence to increase visibility and control of risk) than the additional regulation.
Ronan
]]>