The best all round phrase I can think of to establish whether any given technological deployment is going to succeed is ‘appropriate response'. This term encapsulates many themes. The easy ones are
1. Cost/benefit analysis
2. Testing cycle resilience
3. Redundancy and resilience protection
4. Benchmarking
However, as we've seen, there are ‘hidden extras' which bring an adequate strategy to the level of an exemplary or ‘best-practice' strategy. These include
1. Geopolitical resilience
2. Regulatory compliance
There may be others. The intent here is not to be exhaustive, especially given the scale and scope of the world's financial services industry, but to point the way and open up new areas of strategic thought.
Cost/Benefit - This is the cost of the deployment outweighed by the benefit. This must be taken in context to short-, medium- and long-term plans. One of the shortcomings of many firms today is the focus on ‘short termism'. Results must be immediate or at worst short term; pay-backs in the region of 18 months are common constraints from the business to the technology staff. Such short termism is generally counter-productive, but often technologists have difficulty getting the message across to the business management. My advice to technologists in this area is to learn the language. The greatest difficulty for many technology projects is the lack of mutual understanding or worse, the perception that you do understand the other half of the business. This is most often found in the lack of understanding at C level of any technology detail. Technologists are equally guilty; their insistence on a coded language full of abbreviations does not achieve what it should.
What started out as the use of abbreviations, to make otherwise-long complex terms more understandable, breaks down when more than 30% of any sentence is composed of such abbreviations - it becomes a linguistic sub-set in its own right. The result is either that C level staff don't understand the terminology (but are afraid to allow that to be seen) or that technologists use it increasingly to try to maintain an aura of mystique around what they do (purportedly to protect their position and status). If technologists either did not use or explained their terminology better business management would understand the case better, allowing some flow of dialogue between the two regarding the scale of cost/benefit analyses. In particular, technologists should not be afraid of asking senior management to explain how they came to their conclusions about the time-scale of cost/benefit analyses nor the other assumptions underpinning those constraints. C level staff on the business side are equally to blame. Business language has followed the technologists in the use of often confusing or complex terms. So, we end up with two sets of people trying to communicate in different linguistic codes - and that's before we think about layering in the possibility of different real-world languages for the larger multicountry organisations.
In the light of this, for the most successful large-scale implementations, consultants, usually viewed as the bane of projects, can be extremely useful as ‘interpreters'. Returning briefly to cost/benefit analyses, the issue is what is the appropriate benefit for the cost concerned and over what period can that benefit be delivered. This is generally not as simple a task as it first looks. I identify 24 sets of global regulations together with the areas in which they overlap from a compliance perspective. Those overlaps can have one of three statuses: destructive, constructive and neutral impact. A destructive overlap between say EU Data Protection Directives and Sarbanes-Oxley means that the nature of the two sets of regulation results in technology solutions that do not have any commonality. So in order to comply with each regulation, separate costs are incurred. Constructive overlaps, as will be obvious, occur when the nature of the overlap allows for both sets of regulation to be complied with from one set of costs. The difficulty is that the benefit from one technology deployment may not become apparent in the same time frame as the benefit from another. So, best practice in the area of cost/benefit analyses is to avoid the tempting idea of simplifying the analysis so that ‘even business people can understand it' but to plan out the cost/benefits into short, medium and long term. below demonstrates this for a constructive overlap scenario.
The initial high cost is rewarded soon after deployment with a short-term benefit. As time goes by and the deployment ‘beds in' the cost to comply with a different set of regulation is reduced and the benefit increases. Finally, in the long term, the benefits of complying with multiple constructive overlap regulatory regimes mean a more integrated system, lower costs and therefore a higher long-term benefit than even the short-term predictions allowed for.
Testing Cycle Resilience - We will return to this theme again and again in this article, particularly in because it is one of the fundamental technology management issues. The main differentiator in many technology projects is the degree to which testing is authenticated. For internal builds, the organisation may have control of the testing facility directly indirectly if however, in most cases, cost constraints or time constraints put in place by the business management create problems for technologists. This usually ends up in a vicious circle when deployments don't work as the business expected because internal testing was not as rigorous as it might be. Similarly however, technologists must be aware that there is no such thing as a perfect system and that testing must be ‘appropriate' to the overall need.
Business-critical deployments clearly need much stronger testing and retesting than deployments that are neither business- nor time-critical. Outsourcing of technology or buying in a technology that already exists may seem to obviate those issues. However, this is not always the case. As financial services companies continually seek the market advantage and a narrow window in which to exploit it, we must recognise that well over half of the third-party application providers for instance, are relatively small in comparison to their customers. Many do not have strong enough testing and quality assurance (QA) processes if they have them at all. I know of one software company selling to wholesale banks that, for the first ten years of its existence, had absolutely no QA at all. The programmer that wrote the code also tested the code and released it to market. When you use an external supplier for a technology development, while the delivery time may be shortened, the apparent cost reduced and the available ‘functionality' increased, the reality is that many of those ‘savings' will be lost either though the process of due diligence on their testing facilities or by failures post-contract.
Redundancy and Resilience Protection - It is fascinating to watch financial services firms from a ‘high' vantage point. We spoke earlier about the morphology of the industry and its many comparison to biological forms. This might be viewed as a pointless exercise but actually, you can easily map out the large reactions of the industry whether that be to regulatory or technological change, and see how the industry displays most of the chacteristics of the animal kingdom.
We react, as an industry, from instinct, not really from any ability to plan long term. All our sociological and political structures are short term, even our governments change every few years with who knows what consequences. As a result, we don't really have a long-term strategic view. The net result is that we have to spend far more than we would expect on resilience and redundancy. Resilience is the ability of a technology deployment to operate as planned, and keep operating. Redundancy is the plan that takes effect if resilience fails. Best practice in managing any technology deployment is to have both issues covered and included in cost analyses.
Benchmarking - In the same way that benchmarking for corporate actions processing has not really existed until relatively recently, benchmarking for best practice in technology management is also woefully absent from our combined agendas. The difficulty is that the issue doesn't really sit completely within any one discipline - management or technology. Technologists focus on whether the deployment meets the required objectives and constraints; for example, whether an application meets its functional specification. Managers focus on whether the deployed solution meets the business requirements of delivery time frame, budget etc. Neither of these add any value to the process of technology management which is strange given that if no attention is given to it, no improvements can be made. As I hope to have demonstrated by the end of this article, attention to the management of technology as a combined discipline can add significant value to a financial services firm over the medium to long term.
Our website is not responsible for the information contained by this article. Articleinput.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.
Note: This article was sent to us by: Matthew Jenkins at 01062010
1. Regulations in the use of technology in financial services
All articles are property of their respective authors. Please read our Privacy Policy!
© 2009 ArticleInput.com.