The transition to a new version of an Enterprise System

Understanding how an ecosystem transitions from one version of the core ES package to another provides a frame for understanding the process a new version undergoes from the point of release from the vendor to the implementation in the client organizations. The following analysis of the transition process first addresses the process for ISVs, then the VARs, and finally the ecosystem as a whole.

1.4.2.1 Transition process of the ISVs

When a new version of a core ES package is released by Microsoft, the ISVs in the ecosystem begin upgrading their add-ons to be compatible with the new version and to utilize the new features. In a transition process of ‘Strategizing’, ‘Upgrading’, and

‘Selling’ the ISVs gradually make the transition to upgrade their add-ons to complement the new version, as illustrated in Figure 3. In the ‘Strategizing’ stage the ISVs try to understand and compare the benefits and shortcoming of the new version and asses the demand for upgraded add-ons that are compatible with the new version.

As a result of the ‘Strategizing’ stage, the ISVs decide which add-ons to upgrade and which to leave on the old version for the time being, and the transition process moves to the stage of ‘Upgrading’. In this stage the ISVs upgrade their add-ons to be compatible with the new version of the core ES package. The transition process of the ISVs then moves to the stage of ‘Selling’ the add-ons and, and depending on the demand for the upgraded and non-upgraded add-ons, the ISVs adjust the strategy in the next iteration of the transition process.

Figure 3. Transition process of the ISVs (adapted from earlier version of paper II)

1.4.2.2 The transition process of the VARs

When a new version is released, the VARs in the ecosystem also begin a process of transitioning to the new version through the stages of ‘Strategizing’, ‘Pushing’, and

‘Implementing’, as illustrated in Figure 4. The initial stage of ‘Strategizing’ is similar

to that of the ISVs, as the VARs prepare a strategy of how to make the transition by trying to understand the new version and compare the benefits and shortcomings of the new version. As the VARs are dependent on upgraded add-ons from the ISVs when implementing the new version in client organizations, the strategy is influenced by the availability of upgraded add-ons. Furthermore, the strategies of the VARs are also dependent on the amount of experience with implementing the old and the new version. As a result of the ‘Strategizing’ phase the VARs move to the stage of

‘Pushing’, in which they try to persuade client organizations to purchase either the old or the new version. However, as the clients form their own perceptions about the new and the old version and create a ‘pull’ for one of the two versions, the resulting implementation may be different from that of the initial suggestion of the VARs, illustrated by the crossing paths in Figure 4. If the result ends in the VARs implementing the new version in the following ‘Implementing’ stage, new experience is gained which influences the strategy phase in the following iterations of the process of transitioning to the new version.

Figure 4. Transition process of the VARs (adapted from paper II)

1.4.2.3 The transition process of the ecosystem as a whole

Viewing the transition process from a perspective of the software ecosystem as a whole provides an opportunity for a holistic perspective of the transition process, as illustrated in Figure 5. When a new version of the core package of an ES is released by Microsoft, the vendor begins to exercise pressure on the ISVs to upgrade their add-ons and on the VARs to begin implementing the new version in the client organizations. As part of the ‘Strategizing’ stage at the ISVs and the VARs, the partner companies compare the benefits and shortcoming of the new version with the old version and communicate a response back towards the vendor for improvements of the core package. Concurrently, the partner companies begin the transition process cycles in which the VARs demand upgraded add-ons and the ISVs supply the upgraded add-ons back to the VARs. During the transition process, the VARs are pushing both the old and the new version to the clients, and the clients in turn create a pull for one of the two versions.

Figure 5. Transition process of the Microsoft software ecosystem (adapted from a previous version of paper II)

The interconnectedness of the actors in the ecosystem entails a potential inertia in the transition to, and diffusion of, a new version of the core ES package. First, the dependence on add-ons entails that if the ISVs have not upgraded the add-ons, the diffusion of the new version is slowed. Second, the push/pull configuration between the VARs and the client organizations entails that even if the VARs have decided to try to push the new version to the client organizations, the clients may still demand an implementation of the old version, thus slowing the transition process. However, the reverse scenario is also found in which the client organizations demand the

implementation of the new version - even when the VARs are pushing for implementing the old version. The client organizations may thus also drive the transition to the new version of the ES.