Living on the Cutting Edge : Automating Continuous Customer Configuration Updating Slinger

Software producing organisations cannot continuously update their end-users’ configurations. By not automating continuous updating, costs to test, release, and update a software product remain exorbitantly high and time to market exorbitantly long. This paper displays the feasibility and profitability of continuous customer configuration updating, with the help of two practical case studies and a technique to model and estimate time to market for a software product. Automating continuous updating enables vendors and customers to flexibly define release, delivery and deployment policies, and subsequently reduce time to market with minimum effort. Such flexibility enables customers to be in full control of how and when product knowledge and updates are delivered, tested, and deployed. Furthermore, such flexibility enables vendors to focus effort on its product development instead of release, knowledge delivery, and deployment support tools. 1. Customer Configuration Updating To date product software is a packaged configuration of software components or a software-based service, with auxiliary material, which is released for and traded in a specific market [26]. Manufacturing product software is an expensive and non-trivial task for software vendors. Software vendors daily face the challenge to divide their resources to develop, release, and deliver high quality software, for which there are always more requirements and opportunities than a tenfold of developers could implement. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Copyright 200X ACM X-XXXXX-XX-X/XX/XX . $5.00. Furthermore, extreme competition is forcing software vendors to reduce time to market and to release new features as often as possible. Time-to-market can be shortened by component reuse, reallocation of resources, and by automating processes in the development and delivery cycle. In this paper we focus on process automation of the release, delivery, deployment, and feedback processes, also known as Customer Configuration Updating (CCU). In earlier work customer configuration updating has been positioned as the release, delivery, deployment, and usage and activation processes of product software [11]. The release process describes how and how frequent products and updates are made available to testers, pilot customers, and customers. The delivery process describes the method and frequency of update and knowledge delivery from vendor to customer and from customer to vendor. The deployment process describes how a system or customer configuration evolves between component configurations due to the installation of products and updates. Finally, the activation and usage process concerns license activation and knowledge creation on the end-user side. The importance of CCU is often criticized as systems are more often supplied to customers as an on-line service, thus requiring no more software delivery and deployment on the customer side. There are multiple sides to this “servicization” trend, however. Services are more often deployed on home user systems as well. Simultaneously, an increase is seen in the use of product software on mobile devices, requiring different deployment mechanisms. Examples can even be found of services and products that are deployed on mobile and embedded devices, offered as services, and on customer PCs. Two such examples are TomTom, offering its product on embedded devices in the TomTom Go, as an online service with TomTom Maps, and deployed on your portable device with TomTom Navigator, and Google, offering the Google Mini embedded device, Google on-line websearch, and Google Desktop for the home PC. As such, the demand for research in the area of CCU is increasing, rather than decreasing. Furthermore, interesting blends of software are becoming more common than traditional software packages. Automating CCU contributes to product software vendors in two ways. First, software vendors can serve a larger number of customers when less overhead is required per customer [9]. Secondly, software vendors become “quicker on their feet” by automating CCU. Due to more frequent integration builds and automated test runs developers see results of their contributions quicker and testers can test more recent versions of the software. Also, developers and testers lose less time (re)deploying the application locally after different developers have contributed to the project. Finally, if customers are involved in testing new features, they can work with newer versions than with traditional weekly or daily builds. Finally, customers are better protected against security holes that can be patched quicker. Overall, by automating CCU a software vendor can reduce its time to market and battle the demand for flexibility of its software products [2].