2.2. Software business

2.2.1. Software business modes

The software company’s contracting process building starts from the business concept and strategy that the company has selected for itself. The company has to know clearly in which business it is in. As already briefly discussed in Chapter 1, the focal software business modes relevant for this study are the COTS, tailored and MOTS also named as enterprise solutions software. Other classifications also exist as the perspective taken to analyse the business environment calls for different categorizations which better fit each case, see (Autere, Lamberg et al. 1999). Their classification scheme also capitalizes three categories, where the first is software products (packaged software, pre-packaged software), the second is tailor made software (bespoke software) and the third embedded software used as part of some equipment. Lippold (1998, 50) analyses software markets using a classification that is based on three categories of mainframe-software, midrange-software and software for personal computers. According to him these categories resemble proprietary systems software (tailored), open systems software (MOTS) and mass-software (COTS) applications. In all these different segments the needs of customers are different and thus the contracts have different contents and elements.

In this study embedded software is not taken as a separate entity instead the software development of packaged and tailored software are analysed separately. The reasons for this are that the companies selected for the study were in COTS, tailored and MOTS business. To reflect these three different software business modes on the Williamson’s Efficient governance proposition (Fig. 2) the COTS business could be found from the Market governance domain, the tailored and MOTS business again from the Bilateral governance sector on the first hand. But after closer cooperation or even acquisitions process the companies could move to the Unified governance domain. The bilateral governance is characterized by mixed investments and recurrent transactions.

Rajala et al. (Rajala, Rossi et al. 2001) have recently come up with a framework for analysing software business models that also include product development categorization. They have identified following options for product development: project, product platform[1], parameterised product, core product and product family. The COTS business mode corresponds with the product that is defined to focus on “the development of a single product or product family to be delivered to several customers as is” (ibid, 51). The tailored approach again is equivalent to the project that focuses on the tailor-made solution to customer’s needs. Lastly the MOTS business mode is similar to the parameterised product with the definition of “customisable product that can be tailored to a degree” (ibid, 51). However, the categorization is a question of definition that is emphasized by the angle of approach used and needed in each separate study.

Seppänen et al. (2001) introduce a new concept of Original software Component Manufacturer (OCM). They relate it with the older term of Original Equipment Manufacturer (OEM). This is a growing and interest invoking new business mode in the software industry. The component business can be placed between the COTS and MOTS business where the software components offered are complete smaller or larger packaged software modules or applications or the customer may require some changes in the component in order to be able to implement it in the application under development[2]. The concept does not reckon with the size of the software, but only on the future usage mode. In its purest form the OCM company just assembles the acquired components to produce the needed application, procuring all the needed components outside of the firm (Guthrie 1999). However, this business is still in its early stages, as the environment is not yet developed enough, i.e. it lacks effective business models, trade centres (intermediary organizations), standards, as well as the contracting issues being under development (Seppänen, 2001). Adler (1995) also argues for the business infrastructure that needs to determine component packaging, specifications, pricing, distribution channels, support and quality certification issues. In this context the IPR formulates an important issue on how the component producing company is able to receive its justified share of the whole business. This is, of course, also connected to the license contracts and the licensing policy to which the partners are committed.

The product platform concept is another one example of MOTS business, closely related to the software business mode where the platform is defined as a strategic core of a product family (Sääksjärvi 1998). Sääksjärvi (ibid) suggests that the software companies using this development approach could augment their product portfolio. This could help the problem of small software companies, as typically their growth strategy starts from resource selling (tailoring) and many of these companies later find it difficult to expand or even to develop their proprietary software supply base. This is also an essential contractual issue. The platform concept is demanding from several aspects including technological, architectural and design perspectives (ibid). Thus for new start-up companies it may be hard to begin with as it is more research and development emphasized and this needs advanced capital investment. However, with clear strategy the software companies are able to build an expanding library of reusable software components for further use. According to Frakes (1994) the build-up process needs long-term support and guidance from the management’s side. He argues for a systematic reuse program that includes training, incentives’ management and changing the development culture. Also some unresolved legal issues exist, when these components are sold outside the organization. Among these are the questions of rights and responsibilities, i.e. to what extent the producer could be liable if the software component fails and causes damage (ibid). Lim (1996) gives an extensive overview of the legal issues concerning the software reuse. He emphasizes the importance of understanding the distinction between the legal and contractual issues, in each case when the parties are negotiating about rights and obligations (ibid).

According to Saarinen and Vepsäläinen (1994) one relevant approach for the customer is to concentrate its own software development on the critical area of the core competence and procuring other development resources from outside. This compels the customer to make careful decisions about future investments in a situation of uncertainty as future cooperation means, for the customer as for the supplier, a long-lasting relationship.

The customer has to weigh the advantages and disadvantages between developing the application in-house or acquiring it from a software supplier. From the supplier’s point of view it is valuable to understand the customer’s environment and considerations in the contracting situation. As the procurement means a choice among (usually) several software suppliers – company’s own IT-department, outside experts and consultants, MOTS or COTS software suppliers – and several contracting forms. This includes the manifold field of IPR; copyrights, patents, license, etc. Usually the managers are interested in investments with high specificity and low risks offering a high payoff. Correspondingly, investments with common requirements and high uncertainty are avoided. But firms to achieve competitive advantage by innovative software application use usually demands specific software with high risks and high development costs (ibid).

2.2.2. Software development practices

This section briefly introduces the most commonly used conceptual process models used in software development. It is also observed how the software contracting process is seen in these different approaches, if it is at all. The software process models are essential aids as they provide guidance and structure for the software development process. First the basic models found in Pressman’s (1997) extensive work on Software Engineering are depicted. Good process design minimizes the likelihood of process breakdown, but they also provide ways of dealing with breakdown if it occurs, so that the customer-supplier relationship is not irreparably damaged. This needs clear commitment for measurable process outcomes from the customer’s perspective (Burlton 1995).

Linear sequential model. The linear sequential (stage wise) model was one of the first defined and most widely used traditional paradigms for software engineering, see Fig. 5. It is also called the ‘classic life cycle’ or the ‘waterfall model’. It specifies a systematic and sequential approach to software development, starting at the system level and extending through analysis, design, coding, testing, implementing, to the software maintenance, see also (Boehm 1988, Marciniak & Reifer 1990, Cugola & Ghezzi 1998). The model gives the order for the consecutive stages and also establishes a transition criteria for progressing from one stage to the next as well as the feedback loop to the previous stage(s).

The analysis stage is done together with the supplier and customer. At this stage the requirements are specified and the software engineer must understand the business and the environment of the customer. During this stage the common ground and communication habits for future work are laid. The required functions, behaviour, performance and interfaces are determined. The requirements are documented and jointly reviewed. Therefore this approach is also called as document-driven process (Boehm 1988).

The design stage is more of an engineering task as it focuses on data structures, software and hardware architecture, human-computer interface representations and procedural detail. This stage produces the next level blueprints and documentation for the future coding work (Pressman 1997).

The code generation stage is then the phase where the actual program code is generated utilizing different kinds of aids, e.g. reusable code, code generators. This stage is not visible for the customer, only if there are some ambiguities in the specifications is the customer contacted and the problem cleared up.

The testing stage is needed though the individual software modules are tested during the code generation stage. During this stage the separate modules are linked together and their cooperation must be verified as far as possible with different kinds of test methods. The customer usually takes part in the testing process in the later part of the stage when the supplier’s testing staff has already corrected most of the errors. The customer can do the testing either at the supplier’s premises or at their own premises. Nowadays it is also common for the customer to test the application over the Internet.

The implementation stage is the final step when the new application is delivered and installed according to the contract officially to the customer. This is also an important phase in the life cycle of software procurement, as the customer has to verify the correctness and functionality of the delivered application[3].

After all these stages have been implemented successfully the use of application by the customer’s staff starts. But normally during the first weeks and months it turns up either programming errors or misunderstandings in interpreting the original system specifications. These problems must be fixed in order to get the software operational and accepted. The number of required changes is often used as a measure of a project’s effectiveness and success; many changes signify an inferior effort (Iansiti & MacCormack 1997). After this warranty period the normal maintenance phase starts during which the customer and supplier discuss possible future enhancements and new features. They may be in nature functional or performance based issues.

The problems that are connected to this model arise from its sequential nature. Among these difficulties are: the real projects seldom have the sequential flow as the model depicts, at the start of the software project the customer does not always know the specifications as exactly as needed thus the completion criteria for the analysis and design phases are problematic (Boehm 1988). It takes time to get a working version of the application to the customer for inspection and finally the software development process is dependant on concurrent tasks (Pressman 1997).

This problem also expresses itself with the contracting as the customer may not know definitively what he wants and this indeterminacy also harms the supplier when he tries to estimate the scope of the project. For this reason Lott (1997a) has introduced a staged contracting paradigm that helps both the customer and the supplier to determine more accurately the proposed software project. A staged contract for software development means that the work is contracted based on significant milestones in the development process. The software project is not specified fully in advance but in piecewise steps moving from stage to stage.

As Lott notes the practical minimum is two stages where the first stage is usually the analysis stage, Fig. 5, where the application and its operational environment is specified in detail, the customer’s and supplier’s current and future methods of operation. When this stage is done the customer has the specification documents at hand that are much more detailed compared to the first sketch and idea of the application. Now the customer can advance by asking new bids also from other software companies. The supplier may also leave out and decide not to bid for the following stages. This depends on the experience learned from the previous stage’s cooperation. The next stage usually involves the rest of the stages as depicted in Fig. 5. In some cases the implementation process can be bided again, but this is not usual as the needed know-how at this stage is in the hands of the supplier. However, third parties may do the training and maintenance phase again.

This approach from the contracting viewpoint is interesting and also advantageous as the contracts can be formulated more accurately and without many undefined issues. The price tag is better for the customer as the supplier can propose a lower price as he has more information and knows the content of the future obligation more exactly. The resource requirements and the time schedules can be better estimated. This benefits both parties as the risks are reduced as this approach permits sophisticated risk management. The second benefit for the supplier is that he avoids the risk of investing significant resources in a proposal that will not be accepted. The stage approach also minimizes the risk of being involved with an intractable partner. For both parties it is also an advantage as the staged model sets clear milestones for payments.

Lott has identified some drawbacks of this staged approach. First, the customer must accept and understand the staged approach. Secondly, using a staged approach results in significant budget instability for the supplier. Third, some customers may have the hidden agenda of stealing the supplier’s expertise during stage one. But this could also be solved with contractual matters. If the supplier uses some proprietary solutions during the first stage these may in the later stage lock in the customer without any real choices. Finally the staged approach is not needed in projects that are scheduled under three months, as the three month period is usually possible to determine in detail (Lott 1997a).

Humphrey (1989) also criticises the waterfall model for its rigidity and ineffectiveness. He also argues strongly for trust as the key element in the customer-supplier relationship. If trust did not exist then according to him the partners would need exact statements of what is wanted. The work itself would be characterised by rigid standards and documentations following each individual step in the project. Further each step would be first inspected and approved formally before moving to the next step. The problem with trust is that it is formed slowly during the cooperation between the partners, but it is easy and quick to lose. Humphrey divides the necessary conditions of trust building to depend on history, understanding and awareness. As he further argues, “One of the fundamental benefits of establishing a mature software process is that you can know precisely where you stand and you can keep your management properly informed” (ibid, 412). This software process can be understood to include the software contracting procedures as well. Thus the obvious need for mature software process calls also for a defined and mature contracting process that gives the software development process its needed freedom.

The “old” wisdom concerning effective and successful software contract criteria from 1980’s as stated by Humphrey (1989, 416) still holds during these more turbulent days:

1. The vendor must be trustworthy and technical competent.

2. The buyer must be capable of identifying technical competent vendors.

3. The contract presumes mutual trust.

4. The software quality assurance and audit ensure honest and disciplined performance.

5. Initially the highest-priority task is to arrive at agreement on what is to be produced, a plan to produce it and acceptance criteria.

6. It is recognised that the operational concept and the product requirements will evolve throughout the contract and that appropriate provisions will be made to handle the resulting scope and plan changes.

In one case a Finnish national health organization had produced in cooperation with one software company specifications for the future application bid. The analysis stage lasted one year and during this period the partner company had gained so much detailed firsthand information – tacit knowledge – about the specific field of activities that was not available for the other second round bidders in the specification documents. The company was also prepared in advance for the short bidding time period. So in reality, there was only one bidder and the company knew the situation[4].

Spiral model. The spiral model is an evolutionary software process model that combines the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model (Pressman 1997). Boehm (1988) first proposed this model in his seminal article about the paradigm. This model contains six task regions:

In Boehm’s (1988) original article four different phases were depicted: determine (above: customer communication), evaluate (planning and risk analysis), develop (engineering and construction and release) and plan (customer evaluation).

Each of these regions itself include several subtasks depending on the scope and complexity of the application under development. The evolutionary process starts from the core of the spiral from the customer communication region and revolves in a clockwise direction as if it was coming out of the spiral, see Fig. 6.

This resembles the staged approach in the waterfall model as both models evaluate – after a executed stage or as in the spiral model after each cycle – the rationality of entering into the next stage or round or whether to terminate the project. If the previous model was document driven so the spiral model can be said to be risk driven as it has in its roots the risk management consideration. Fig. 6 also depicts the whole life cycle process of the application, from the first development project, through maintenance projects and enhancement projects until new application development initiatives. Pressman (1997) describes the model as featuring a realistic approach to the development of large-scale systems and software. In the real world, software and especially the understanding of the customer and following this, the specifications evolve as the process progresses. The customer and developer can more clearly see the possible problems and risks.

One of the problems associated with the model belongs to the contracting situation. Convincing the customer that the evolutionary approach is controllable may be difficult (Pressman 1997). Boehm (1988) admits that the model works well in internal use, as it is easier to have a flexible and evolutionary software development environment with a company’s own IT-department. According to him several contract mechanisms exist to help establishing flexible contracts, but these need further development work (ibid). However, to have the same level of freedom and accountability in contract software acquisition is much harder, as the software products are not well specified in advance as they sharpen during the development process. This makes the contracting situation more difficult with many open and sketchy specifications. On the other hand the stepwise approach should address the customer to see the benefits of the model, refer above the section discussing the staged contracting. In the spiral model the customer or its representative is involved during the communication, planning and evaluation stages that gives the customer a good viewpoint from the contractual perspective how the project advances according to the plan. Kilde (1998) argues that the spiral model is in practical commercial use often too extensive and complicated.

Concurrent development model. The concurrent development model can be presented schematically as a series of overlapping major technical activities, tasks and their associated states (Davis & Sitaram 1994, Pressman 1997). One activity can be in any one of the states noted at any given time. For example the activity of analysis can be in the state of: under development, under review, awaiting changes, under revision, baselined or done. All activities exist concurrently but they may reside in different states. In this model the events trigger transitions from state to state (Pressman 1997, 47).

In Fig. 7 the total lead time is the time taken to fulfil the initial objectives of the project. The concept time is defined as the window of opportunity for including new information and for optimising the match between the technology and its application context (Iansiti & MacCormack 1997).

The response time is the period during which the window is closed, the product’s architecture is closed and new information or technology is rejected. In the more conventional approach, i.e. the waterfall model the corresponding concept development stage could be followed by implementation phase only after the first mentioned phase has been fully performed. Though both models have the same total lead time for the application development. The flexible process approach is more equipped for shorter response time and is therefore more suitable for the rapidly changing environments, e.g. the Internet. This type of development is almost a must in the Internet market as there the opportunity windows are very short. The global Internet network is characterized by the wisdom that the first on the market takes all – even though the offering were not the best solution. Sensing right the needs of the customers and the market are the most important elements for successful growth in the business.

The usage of this development method has been extensively, and in detail, described by Cusumano and Yoffie (1999) in their book about the growth and development of the company that produced the Netscape browser. Cusumano and Selby (1995) have also described the variation of this method in Microsoft. They call it the synchronize-and-stabilize software development model. It has the same objective; to be as flexible as possible in accepting enhancements as late as possible but still retaining the alpha, beta and final release as functional entities. The Microsoft approach is further characterized by the team’s vision from which the program manager derives a rough functional specification, which the team evolves until the end of the project (Cusumano & Yoffie 1999). According to Cusumano and Yoffie the basic idea of this approach is to give programmers lots of autonomy to evolve designs iteratively but force team members to synchronize their work frequently and then periodically stabilize their design changes or future innovations. The ultimate goal is to balance between hacker-type flexibility and speed with professional engineering discipline (ibid). They further noticed that most PC and Internet companies would tolerate incomplete documentation because they stress code production, not the documents.

This development method is well suited to companies building their own COTS programs and application for the competitive markets. It is also an interesting possibility for the MOTS companies as they have the same requirement and objective with their development process to post-pone the task of differentiating a product, in this case the application, for a specific customer until the latest possible point in the supply chain (Feitzinger & Hau 1997). As the product should be designed so that it consists of independent core modules, which are then complemented with customer specific parts. See also the platform strategy as described above. Following this road would take the company to modular process design and mass customisation that are based on three processual principles: postponement, re-sequencing and standardization.

But there are also dangers in this concurrent development approach, as the software development process with its subprocesses must be managed rigidly. This is especially the case nowadays as software development is distributed over the network, even to other countries with different customers and business habits. In the concurrent development model the focus of the contracting problems are changed more to the contracts with the subcontractors. However, Iansiti and MacCormack (1997) do not give any ideas how this software development process could be used together with procuring customers, as it may be difficult without a close and long-standing cooperative relationship where both partners have strong mutual trust. This processual mode is thus better suited for in-house development work either for the company’s own proprietary software or software developed for marketing purposes later.