Institutions evaluate the implementation of software in terms of its effectiveness, efficiency and support for growth. Generally, we might consider that software falls into three broad categories, all of which are found within firms and organisations across the financial sector: vendor supplied software, either directly or indirectly, as part of an ‘integrated' solution; in-house or bespoke software; and open source software.
The acquisition of open source software should be subject to the same rigours as any proprietary, vendor-specific software. In its use are the major risks. These risks might be considered as analogous to those of in-house developed software. However, FOSS solutions sit astride these two common approaches; they generate the benefits of both and some of the disadvantages, as risks. The idea of future use is important when we consider the normal procurement life cycle. An important criterion is the way a software vendor supports its product. That is, a number of questions have to be satisfied and weighed as part of the selection process.
Is the software vendor viable? That is, is it likely to be around for an estimated five years, the safety margin of most written-down software assets? There are many such questions that contribute to the selection process. Inevitably there are trade-offs, but all vendors will attempt to address the questions as best as they can and seek to make themselves as competitive as possible. At the end it often seems to be a question of money - how much does it all cost?
It is a cliché within the context of this article that software requirements are determined by the institution's strategic business objectives. These are tightly linked to risk management. This includes issues such as: code changes, platform architectures and product maturity, and practical concepts such as forking, the integration of systems, support and the total cost of ownership. What do these risk look like?
Open source code is publicly available. This fundamental feature has enormous implications. The business has to have a clear idea of what it needs from the software, because a vendor has not carried out research on its behalf, tested and tried solutions in the unforgiving arena of competitive sales, to produce a durable and convincing product that meets a number of identified needs. The institution has to do this for itself, or at least with the context of industry best practice. The firm has to have the ability, in terms of skills and experience, to commit longer-term to the process of software development. These demands present a series of risks that relate closely to those of in-house development. But such costs are flexible and frequently only estimates. The purchase must also satisfy a range of very human responses - such as the look and feel of the solution, how user-friendly it is and so on, which are not quantifiable. These qualitative elements can be as important. But, overall, it is the risks of this purchase that this process of questioning and prioritising seeks to minimise.
Using this model the institution should: follow accepted software development cycles; test and trial code thoroughly; ensure the code meets all the criteria of acceptability, common to user acceptance testing, such as confidentiality, integrity and availability of systems and data; be confident of its capabilities and ensure that controls are in place; and manage and protect its intellectual capital. There are so many challenges in getting software from a variety of vendors to work together that frequently firms have to rely on the specialist arms of systems integrators to patch together a working framework. Apparent incompatibilities have to be overcome. Ensuring solutions can share information through a workflow or internal business process, ensuring their ‘interoperability', is a primary objective for many procurement cycles. Along with this is the necessity to reveal hidden cost in platforms, where the apparent cost of purchase is inflated because of the need for specific platforms on which to run the solution. A proprietary software product from a vendor is generally certified to be compatible with its hardware platform. Beyond that, vendors will vary considerably in their commitment to the platforms available in the market. This is especially so for the smaller vendors with niche interests. For some time, the call has been for players to produce products that are compatible with open standards. The exact nature of these standards and their acceptance, however, also varies. A particular advantage that open source can claim is its commitment to open standards.
For this reason alone, it is often more interoperable than proprietary software. However, certain concerns and risks do quickly come into play. Everything depends on the market and the willingness of vendors to recognise and work to standards. Very often there is strong vendor selfinterest in promoting a specific standard, especially when protostandards are competing for control of the market. A dominant vendor can dictate what the standard will be - generally one which it has contributed to and to which its software most conforms. But supply and demand might force other vendors to adopt competing standards. To reach consensus is not always easy, nor is it timely. Once agreement has been reached a standard can then go through a process of recognition and support, and develop a formal certification process. Simply stating a product conforms to open standards, which should greatly assist interoperability, is not enough.
The product must be certified; it must undergo a process, often costly, of testing and approval. Generally when vendors agree on a standard some form of funding is forthcoming to set up a standards oversight body to support the certification process and maintain the standard. These costs are met from industry profits. Questions might arise over how such costs are met from something which is nominally ‘free'. Considering this, financial institutions using open source software should be careful to ensure it meets their needs for compatibility and interoperability and closely examine the context in which it will be used. There may be hidden costs in buying-in extra skills and experience to ensure the software works within its intended operating environment.
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: Lisa Hunter at 01082010
1. Technology projects and firm resources
All articles are property of their respective authors. Please read our Privacy Policy!
© 2009 ArticleInput.com.