• PAGE ONE
• INDEX
• HOME

Software package approach to information systems development

Steve Skidmore

THERE IS a strong tradition of bespoke systems development in information systems delivery, where `in-house' analysts and programmers develop systems to meet the specific requirements of an application. In the formative years of computing there was littl e alternative to this approach because generalised software packages did not exist and the fragmentation of the hardware market reduced the viability of such an approach. For many years the market place was:

ASupported by the notion that systems developers had to be part of the company (like production staff, catering staff and cleaners) and located in an identifiable IT department;

*Dominated by mainframe and minicomputer manufacturers delivering expensive and non-standardised technology. The hardware spend (both for purchase and maintenance) dominated the IT department's budget;

*Restricted to a limited set of software packages, usually framed to follow legislative requirements (such as integrated accounts) and only available on a restricted number of hardware platforms.

However, in the intervening years, a number of trends have affected this perception of the marketplace.

*The recognition that IT may be best organised as a procurement, rather than development, department. There has been a trend towards outsourcing as companies have downsized to concentrate on their core business. Consequently, the number of developers lef t to produce the in-house solutions has reduced significantly. IT is not the only function to be affected in this way. Cleaning and catering, once provided by local employed labour, has now been outsourced by many companies.

*The reduced cost and standardisation of hardware has meant that fewer organisations are tied into a manufacturer's strategy. Software is available across a limited set of dominant platforms and the cost of moving from one platform to another has conside rably reduced. Software (or more accurately the people who develop it) is now the most expensive part of systems development. As a result, the cost of software production is closely monitored.

*Finally, the passage of time has led to more software products being made available. This has strengthened particular market sectors (for example, there are many integrated accounts packages available in the market) as well as broadening the scope of pa ckage solutions. There are packages for golf club administration, patient records, marketing, family tree construction, etc.

As a result, many organisations have focused more on fulfilling their requirements through the purchase of an appropriate software package. The perception is that this is a cheaper, faster and more reliable approach to systems development. Hence the task is to find a package that fulfils user requirements or differentiate between competing packages that all appear to do the job. This paper looks at some of the perceived advantages and disadvantages of the software package approach to information systems delivery.

Advantages of the software package approach

Cost savings: The most quoted advantage of the software package approach is reduced cost. The purchase of a software package is perceived as significantly cheaper than developing a bespoke alternative. In a bespoke system the cost of systems development is borne completely by the organisation commissioning the system. In a software package solution, the cost of the systems development is spread across all the potential purchasers of the system. For example, a building company estimating, accounting and job control system that currently costs 2,000 to purchase, actually cost 600,000 to develop. This cheapness is usually an important factor in deciding to pursue the software package approach.

Time savings: The bespoke systems development needs to be tightly specified, designed, programmed and tested. This part of the lifecycle is very time-consuming and during this period requirements may change, so complicating the process even further. The software package is a product that already exists. It can be purchased and implemented almost immediately. There is no requirement for design, programming, unit and systems testing.

Quality benefits: A further perceived advantage of the software package solution is hinted at in the previous point -- the absence of unit and systems testing. The software package is a proven product that has undergone systems testing (in development) a nd user acceptance testing (by the users who have already bought and used the package). Hence the product should be relatively error-free, as well as fulfilling most of the functional requirements of the application. The implementation should not be affe cted by the programming errors and misconceptions that can bedevil bespoke systems development.

Available documentation and training: In the software package approach the documentation can be inspected and evaluated before purchasing the product. The documents (such as user manuals and HELP systems) are usually of high quality because they represen t an important part of the selling process. In contrast, the documentation supporting a bespoke systems development is not available until very late in the lifecycle and is often sub-contracted to users who do not have the time to do the job properly.

A similar principle applies to training. Prospective

purchasers can attend a course prior to buying the product and so further evaluate the suitability of the package. Similarly, economies of scale allow the software vendors to produce and provide high quality training courses, supported by professional tr ainers, at a relatively cheap price.

Organised maintenance and enhancement software products are usually supported by a formal maintenance agreement. Although this agreement costs money, it usually provides:

*Unlimited access to a help desk, where experts can sort out user problems;

*Upgrades to software that correct known faults and also include new functionality defined and agreed with the user community.

The cost of this support and enhancement is again spread across a number of users and so can be offered relatively cheaply to each individual customer. The cost of providing such services would be extremely expensive if they were borne completely by an o rganisation commissioning a bespoke development. The upgrade issue is particularly significant to organisations purchasing accounts and payroll packages. The functionality of such systems is affected by legislative changes made by government. These chang es are frequent and unpredictable. It is comforting for the customer to know that all amendments are covered by the agreed software contract.

Try before you buy: This is perhaps the most significant advantage of the software approach -- the ability to examine the product in detail before purchasing it. This is clearly not possible in the bespoke approach to systems development where the produc t is not ready until the end of the project. The evaluation of the package can be assisted if it can be borrowed (or rented) for a trial period and used in the target hardware and software environment. This can be supplemented by visits to actual users ( reference sites) where the operation of the package can be observed and user comments and experiences documented.

However, it must be recognised that the ability to `try before you buy' places the initiative with the user and not the supplier. Hence the fit-to-user-requirements must be ascertained and confirmed by the customer, not the supplier.

Disadvantages of the software package approach

Ownership: In the bespoke systems development approach, the ownership of the software usually resides with the purchaser -- the customer, not the supplier. This is particularly clear if the development is undertaken `in-house', because the ownership of t he code clearly resides with the organisation, not the IT department or individual programmers. Even if an external software house produces the code, the contract usually specifies that the source code belongs to the commissioning agent (the customer) an d not the supplier.

In the software package approach, the ownership of the software usually remains with the supplier. Customers are licensed to use the product, but they never own it. This ownership issue has a number of implications:

*The supplier decides the future development of the package. Hence, future functionality is not in the control of the customer -- although of course they can lobby for certain features to be included in future releases.

*The software supplier can make decisions about the ownership and support of the product. These decisions may have far reaching effects on current customers. For example, the software supplier may decide to withdraw support from earlier versions of the p ackage. Hence customers may be forced into unnecessary (and potentially expensive) upgrades. This may involve hardware upgrades: The software supplier may decide to sell their product to a third party. Individual customers may be unnerved or inconvenienc ed by such a move. For example, a few years ago a popular package was sold to a large industry player with a reputation for aggressive customer relations. Many customers of the package were worried by this move (despite assurances from the new owner) bec ause they were more comfortable with the `laid-back' approach of the former owner. Some began to make plans to move their systems to a rival product.

The key issue here is that the software purchaser has little control over the future direction and ownership of the product they are buying. This is not the case with a bespoke development.

Financial stability of the supplier:

Internal Information Systems (IS) departments do not go out of business. However, external software suppliers are subject to the vagaries of management and the markets. There is a risk that they may go out of business, or experience financial problems th at affect the quality of their support and development services. It is possible to reduce these risks (through escrow agreements) but the disruption likely to accompany the enactment of such an agreement should not be underestimated.

Competitive edge: Many organisations claim that they use (or wish to use) IT and IS as a competitive edge in the market place. They develop bespoke systems to give them that edge. In the software package approach, the software solution (or product) is op en to all competitors and potential competitors. It is difficult to see how such a solution can provide a competitive edge, as all potential competitors have access to that solution.

Failure to fit requirements: One of the most commonly claimed disadvantages of the software package approach is the inability of the product to fit all (100 per cent) of users' requirements. This means that either:

*Users have to make compromises and accept that they will not get all the functionality they require; or,

*Tailored amendments will have to be made to the software product to deliver the required functionality.

Whichever way is chosen, it is clear that most software packages do not fulfil all the user requirements defined for a particular application. Furthermore, they often include facilities and functions not required by a particular user, which only serve to confuse users when the product is implemented into the organisation. In contrast, the bespoke solution should completely fulfil all the user's requirements and, if it does not, will be amended until it does.

Legal redress: In a bespoke development, the ultimate failure of the system to fulfil the user's functional requirements can be resolved (usually in favour of the customer) by law. Clearly this last resort is inappropriate if the system has been develope d by an internal IS department, but it is an option if the system has been developed by an external software house. Legal redress is well documented in a number of high profile cases.

However, the legal responsibilities of a software package provider are more complex. The licensing agreement is defined in favour of the supplier. In that agreement there is usually a clause that states that the package may not support the functional req uirements of the customer -- and it is the customer's responsibility to ensure that it does. Unfortunately, many customers do not take that responsibility seriously and are unable to properly assess whether a particular package supports their needs -- or 80 per cent of their functional requirements -- whatever 80 per cent means!

The changing nature of requirements:

There is plenty of evidence to show that requirements change during the lifetime of a system. These changes are due to a number of factors:

*Users change. New managers arrive who have a different perception of requirements and the business process. They demand new output reports to support their particular management information requirements.

*The business changes. The business may decide that it wants to operate in a different way. This may be led by new product and marketing initiatives or may simply be a reaction to changes in the business environment that forces the company to re-think it s organisation, products and services.

*Changes due to:

Actual experience: Using the software may lead to a realisation that functional requirements were not quite correct.

Emergent hardware and software technologies: Bespoke systems can usually be amended to reflect these changes. However, software packages may or may not. The problem is still one of control. It is not possible for the software supplier to predict or to co pe with changes in a particular business implementation. Some of the changes may be incorporated into a future release but, at the outset, there is no guarantee of this.

The main point is that users normally evaluate potential packages against the current requirements of current users and this may lead to products quickly becoming

inappropriate in dynamic organisations and market places.

Tailoring software package solutions

Tailoring and amending the software package is often suggested when the package fails to completely meet all the user's requirements. There are a number of approaches to this. The first option is to ask the software house to make the changes and to pay a ccordingly. However, this begins to reduce the advantages of the package. It incurs cost and delay and, because it involves program specification, design and testing, it can also reduce the quality of the product. It also removes the try-before-you-buy e lement from part of the product and it is unlikely that bespoke documentation and training will be produced.

This approach also assumes that the software house is willing to tailor the product to meet an organisation's specific requirements. In many instances the software house is not prepared to make such amendments. The reason for this is that the company wis hes to offer a standard product. Tailoring a particular implementation creates specification, programming and testing problems and costs and it is unlikely to be very profitable. However, their reluctance is primarily due to the problems of controlling r eleases and ensuring that future upgrades (containing new functionality and fault fixes) work properly with both standard and tailored releases. This latter issue is a major problem because most software houses want to reduce the number of versions they support, not increase them. Changes are controlled more easily if they can be rolled into the standard version of the software.

An alternative to software house amendment is the purchasing and amendment of source code by the Customer Company. In this approach, the customer buys the source code of the product at a certain instance in time and then undertakes all subsequent amendme nts and upgrades himself. This removes most of the advantages of the software package approach. The product now becomes a bespoke solution -- but a solution where internal developers are, at the outset, unfamiliar with the construction and operation of t he programs and data structures. Consequently, there is a large learning curve in the early stages of source code acquisition. Two other problems must be recognised and they both concern support.

*Errors due to coding are no longer fixed under a support contract, even if those errors occur in code unaffected by bespoke changes.

*Future upgrades of the native software package cannot be reliably integrated into the bespoke solution. The specification of the changes may be used in producing bespoke amendments.

The purchasing of source code may reduce programming effort, but the time taken to confidently understand the operation of the software often means that such time (and cost) savings are marginal. There is also no guarantee that the underlying design is f lexible enough to support the changes that are likely to be required in the future.

Organisations now have the opportunity to fulfil most of their information system requirements through software packages, rather than building bespoke solutions. The advantages of this approach, particularly the perceived cost and time savings, appear se lf-evident. However, there are disadvantages, which must be carefully understood and evaluated before selecting and purchasing a software package. The organisation must also be aware that it is probably entering a long-term commercial relationship with a supplier. It may be costly and difficult to end such a relationship, as converting data from one product to another may be prohibitively expensive. Hence the risks of the software package approach must be identified and appropriate risk avoidance and mi tigation actions developed.

(Source: Student Accountant, ACCA.)