Software Engineering : trategic choice in a new decade Barbara Farbey & Anthony Finkeltein Univerity College London, Department of Computer Science, Gower St. London WC1E 6BT, UK {b.farbey a.finkeltein}@ucl.ac.uk 1. ABSTRACT Thi paper dicue the trategic choice faced by oftware engineering manager and ketche a framework for analying thoe choice. It draw attention to the idea of a oftware upply network which i novel in the context of oftware engineering and ha ignificant implication for economic of oftware development. 2. INTRODUCTION The late 1990 aw a proliferation of technical and organiational advance in oftware engineering and in it application. For the oftware engineering manager thee advance provide both a range of opportunitie and a coniderable challenge in defining a oftware trategy. That trategy mut now include: - linking the oftware organiation' work to corporate trategic prioritie - undertanding the market for the oftware organiation' product, it nature and compoition - defining the ditinctive capabilitie of hi/her own oftware organiation vi a vi outide oftware houe and commercial off-the-helf package - undertanding the nature of the network of upply that feed oftware production. Thi i a more complex picture than it wa in the early 90. The fundamental iue regarding alignment with corporate trategy and achieving value for money have not changed. But the context and the option have changed, and the iue have broadened to include quetion of purchaing and upply. At the very leat, management need a guide to the new option and iue and how they fit together. Thi paper aemble a framework for the development of uch a guide. The framework place particular emphai on the impact of oftware trategy on requirement management. 3. DEVELOPMENT OF THE FRAMEWORK The framework i built in three tage. The firt tage identifie the trategic purpoe of the ytem, it intended market, the type of ytem and the level of ytem requirement. Together thee form the "trategic context" for development or acquiition. Working through thi part of the framework locate the propoed ytem within a trategic "pace". Aociated with any pecific location are a number of iue. Thee include anticipated trategic outcome, the nature of the cot, benefit and rik, potential organiational and di, option for requirement management and for managing the ytem effort within the organiation. The framework thu ha two dimenion, trategic purpoe and iue, which we how a a matrix. Each cell in the matrix i, from the manager' point of view, a potential iue to be reolved. The next tep in the argument i to et out the contemporary option with repect to the ytem development and acquiition proce. Following Fine [4] the guiding principle here i that for optimal reult, development and acquiition choice mut be made together - a Fine ha it "3-D concurrent deign". We are arguing additionally here that 3-D concurrent deign hould be done within a trategic location which affect the logic of the choice, and extend the matrix appropriately. The third part of the framework emphaie the new thinking in upply chain management and organiational deign. Thi pecial focu i intereting becaue there i now enough experience with outourcing and COTS, and with the new way of doing buine, to addre quetion of inter-organiational relationhip, contract deign and upply network compoition in the context of oftware engineering management. The lat tep i to glue the matrice together. The final matrix erve two purpoe. Firt it i a map for manager to addre the option and iue ytematically, whilt maintaining ight of the whole "terrain". Second, it i a reearch framework which we will ourelve ue to reearch and develop guideline for manager to help them addre the iue.
4. THE NEW SYSTEMS DEVELOPMENT AND ACQUISITION CONTEXT Corporate Strategy In term of trategic purpoe there are fundamentally three poition which the ytem() under conideration will be required to addre. Thee poition are defined with repect to the current technological frontier. Firt, the organiation may be lagging behind it competitor. The purpoe of the propoed ytem() i to catch up. Second, the organiation may be technologically in contention, but want to hift the balance of reource. For example a the larger, well-etablihed firm move into e- commerce, they come to trike a trategic balance between all the divere channel open to them. Third, the organiation may be attempting to change the rule of the game uing new technology. Nowaday that uually mean information and communication technology, but it could be a different way of organiing, a in the new upply chain management. The quetion are on two level: firt, how can we ue ytem to help achieve a competitive breakthrough and econd, can better oftware management of itelf produce a radical breakthrough - reducing cot and time to market. Sytem type The extenive ue of oftware ytem notably include different genre of ytem, for example embedded ytem, information ytem, ditributed ytem and group of ytem in product familie. Individual ytem have for many year been et in the context of a ytem trategy, but for product line, a Clement and Northrop [1] point out, "... the evolution of a ingle product mut be conidered within a broader context i.e. the evolution of a product line a a whole" (my emphai). It i the "broader context" which require new trategic thinking. Market Structure The tereotypical textbook ytem of the early 1990 wa a ingle, tandalone ytem built for a ingle, known cutomer. Many ytem till are. But ytem today may alo be built for: - a very mall number of known cutomer - for a ma market, for example COTS or web ite - or, in the cae of "future legacy" ytem a it were, like banking ytem, for future unknown cutomer and technological condition. Table 2 Policy Implication: Sytem Type, Market Structure, Level of Requirement Economic Organi ationa l Techn ical The firt quetion i therefore i about how a propoed ytem chime with trategic purpoe. Thi will affect the view taken on the cot of the ytem, the range of benefit expected and the attitude to rik. purpoe will affect deciion a to what can be afely outourced and what may have to tay in-houe. too will be affected. One can peculate, for example, that the requirement of a ytem intended to upport a trategic breakthrough will be volatile - becaue they are "new". Thi would imply a ignificant meta-requirement for flexibility. The firt three row of Table 1 ummarie thee conideration. Table 1 Policy Implication: corporate trategic purpoe Economic Organia tional Catchup Repoitio ning Break through Benefit Di Technical Single, tandalone ytem Product family Re-ue Single, known cutomer Very mall no. of known cutomer Ma market Unknown, future cutomer Intitutional, high level level Sytem level Di
The level of requirement Not all requirement arie from the fact of the ytem. Some are trategic requirement of the organiation. Other may come from tandard indutry intitution or legal regulation. Indutrie operate in different way and thee way will be reflected in the requirement for any ytem erving the indutry. King [8], for example, i reearching "high-level requirement". Thee are requirement that flow from the organiational and intitutional etting of a ytem, rather than directly from the application of the ytem itelf. Corporate trategic requirement may alo be outide the immediate functional demand of the ytem, adding trategic value, rather than functional value. The tracking ytem whereby cutomer can follow the progre of a parcel, for example, are not eential to the progre of the parcel itelf, but eential to the competitivene of the organiation. The ditinction i important becaue attempting to change a high-level or trategic requirement will have evere implication for cot and rik. One can ugget therefore a diviion of requirement into - Indutry, intitutional, or "high level", requirement - requirement - Sytem level requirement. Table 2 ummarie the ytem type, market tructure and requirement level conideration. 5. PROCESS MODELS There are a variety of model for ytem development. We mention thee without expanion a they will be familiar to oftware engineer: waterfall, piral, prototyping, extreme programming and "ynch. and tabilie" [2]. A with the other option, they raie financial, organiational and poibly trategic iue and the correponding matrix i hown in Table 3 Table 3 Policy Implication: proce model Economic Organi ational Waterfall Spiral Prototyping Extreme programming "Synch. and tabilie" Di Technica l 6. POLICY OPTIONS FOR SOFTWARE ACQUISITION The 1990 aw a variety of development in the procurement poibilitie for oftware. Outourcing The outourcing movement wa, and i, a complex one. Outourcing ha not alway been ucceful and i till evolving [10]. Neverthele, it repreent a ditinct option for contemporary oftware engineering manager and, a it mot critical feature for thi dicuion, mean cooperation between two organiation, partly embodied in a formal contract. COTS The concept of purchaing readymade oftware ha alo become commonplace with the development of commercial off the helf ytem (COTS). COTS are ignificant in oftware acquiition becaue they offer a different relationhip between vendor and purchaer from that of an outourcing contract. At the extreme, a hrinkwrapped package for example, the relationhip i a pot contract. A typical outourcing contract i relational, extending over a period and involving ome form of partnering. From the point of view of the purchaing organiation, moving to COTS implie a different form of internal organiation, moving from "being a developer and producer of ytem, to being a conumer and integrator intead" [15]. ASP A econd, related development in that it utilie predeveloped oftware i the advent of oftware Application Service Provider (ASP). Significant iue that arie with ASP for the conumer organiation, however, are thoe to do with how the ytem are financed: from the capital or the revenue budget. The timing of expenditure i different too. ASP are eentially rented ytem. The cot i pread out over the life of the ytem in ue, not largely up-front a it i with other type of acquiition [5]. Open Source With the ucce of Linux a third development i perhap at hand, namely the eriou, indutry-trength ue of "free", open-ource oftware, exemplified alo by Netcape Navigator [6]. In the face of thee choice the oftware engineering manager need to contruct a trategy for oftware acquiition. Table 4 ummarie the variou type of acquiition. In practice each row i not "pure". There i a variety of outourcing type, jut a there are variou degree of "off the helf". Moreover, the reality i likely to include a combination of all thee method and the combination i itelf a management iue. But the matrix
a tabled will at leat act a a tarting point for further detailed dicuion in the organiation. Table 4 Policy Implication: acquiition method Economic Organiational Techni cal In-houe developme nt Outourced developme nt COTS ASP Open ource Legacy upgrade Combinatio n Di A before the iue form the column of the Table. However, the major implication of the new method of acquiition i that all of them entail relationhip beyond the uer/ conumer organiation. There are thu very ignificant iue relating to the nature of thee relationhip, their conduct and value. Two key group of iue concern relationhip management, both formal and informal, and quetion of organiational learning in network. Thee are taken up in the next ection. 7. INTER-ORGANIZATIONAL RELATIONSHIPS Inter-organiational ytem, and hence inter-organiational relationhip, have been on the Information Sytem reearch agenda ince the advent of EDI in the 1980 [13]. Outourcing gave an added urgency and impetu to the reearch, particularly perhap becaue many organiation found the outourcing relationhip difficult to manage, with the vendor organiation often able to hold the whip hand [11] a quoted in Lacity and Hirchheim [10]. We urmie that the management apect of COTS, evaluation and the relationhip with upplier will provide an added twit. Open ource acquiition will alo throw the potlight on relationhip, if only becaue one ide, the upplier, are not providing the oftware for money, but for ome other form of reward. But Information Sytem outourcing i only a part of the tory. In recent year there ha been coniderable development of new arrangement and form including joint venture, alliance, imaginative partnering arrangement and upply chain management [9, 12]. In partnerhip, of what ever form, there i a range of choice a to how work i organied acro the contituent organiation. With the commoditiation of oftware ytem in the hape of COTS, and the continuing move to re-ue via component and kernel, oftware engineer do not necearily develop large oftware ytem themelve. Intead they aemble, compoe and glue component together. The oftware manager ha, in principle, the ame kind of choice a hi counterpart in other area of the organiation. There i a upply chain, or a upply net, in oftware development, albeit it i likely to be a hort one. The next tep in the paper therefore, i to pell out the choice. Type of contract A baic ditinction i dicued by Kay [7] when he expand on the ditinction between pot contract, claical contract and relational contract. Spot contract, like thoe for ome COTS, or a Kay remark a "lettuce from a green grocer", are hort term, baed on tandard term and take place at market price. Claical and relational contract are different from pot contract in that they are longer term. Claical contract in Kay' definition are explicit. Kay give the example of a property leae. They are formal, legal and binding. Outourcing contract are baed on legal contract. Relational contract are implicit. They may have a partial bai in law, but the dominant element i trut. Marriage i the example given by Kay. Early outourcing contract were often relational, although a Lacity and Hirchheim point out [10], thi did not alway lead to happy reult for the conumer organiation. Supply network compoition A principal finding in previou reearch on the upply chain i that "In a fat clockpeed world, arie from the concurrent deign of product, procee and capabilitie." [4, italic in the original], [3]. "Clockpeed" i Fine' term for the rate of evolution of product, procee and organiation. He i particularly intereted in fat clockpeed indutrie, thoe that evolve very quickly and in which product or procee have hort live. We have looked in the coure of the paper at product and proce. Outourcing can uefully be een a a reditribution of capabilitie [14]. COTS could be een a embedded capabilitie. In either cae, but more particularly in outourcing within a network of upplier, there i a quetion a to where the capabilitie lie and how to make optimal ue of them. However, becaue capability take time to develop, it may be that it i not necearily an independent choice - independent that i of the choice of a upply network. With repect to capability we ugget not a new row, but a new emphai on capabilitie,
organiational learning and indeed knowledge management, within the column on co-operative. Table 5 ummarie thee idea. Table 5 Policy Implication: Inter-organiational relationhip Economic Organi ational Supply network compoition Contract type Ditribution of expertie/ capability Di 8. GLUING IT ALL TOGETHER Tech nical : organiational learning We believe that the idea that product, proce and capability mut all be deigned together can now, and hould now, be applied to oftware engineering. One way to do thi i to wallow the matrix whole, working through it ytematically, and it urely ha to be iteratively, forming a holitic picture of product, proce and capability acro the poible network and deigning them accordingly. Table 6 therefore how a ummary verion of the option, for eae of navigation Table 6 Context, option and iue - ummary ISSUES Economic Organiational Tech nical CONTEXT purpoe Sytem type Market tructure Level at which requirement are pecified OPTIONS Proce model Acquiition option Contract type Supply network compoition Ditribution of expertie Di : organiationa l learning 9. CONCLUSION Thi paper ha attempted to define the terrain in which the oftware engineering manager make choice about the way oftware i developed. It ha ketched the context, the policy option and the area which will be at iue a the choice are made. Thee are brought together in tabular form, providing a framework for deciion. The paper ha alo highlighted area of the terrain, the idea of a oftware upply network, which will be unfamiliar becaue the choice are relatively new. The framework make a tart in aiting manager to do concurrent deign by drawing together the relevant iue and allowing them to be addreed ytematically. However, we have a yet no practical experience to report. That come next. REFERENCES: 1. Clement P., and Northrop L.M., 1999) A framework for oftware product line practice, SEI Interactive, 2, 3, On-line at <http://interactive.ei.cmu.edu/feature/1999/september/backgrou nd/background.ep99.htm> 2. Cuumano, M.A. and Selby, R.W. How Microoft Build Software, Communication of the ACM, 40, 6, (1997) 53-61 3. Farbey, B. and Finkeltein, A. Exploiting upply chain buine architecture", Poition paper, Eder-1 (1999). On-line at <http://www.c.virginia.edu/~ullivan/eder1/> 4. Fine, C.H. Clockpeed: winning indutry control in the age of temporary. (1998) Pereu Book, Reading, Ma. 5. Gillan, C., Graham, S., Levitt, M., McArthur, J., Murray, S., Turner, V., Villar, R. and Whanlen, M.M. The ASP' impact on the IT Indutry: an IDC wide opinion. International Data Corporation. 20323 (permiion needed for quote) (1999) On-line at <http://www.idc.com> 6. Hecker, F. Setting Up Shop: The Buine of Open-Source Software, IEEE Software, 16, 1, (January/February 1999) 7. Kay, J. Foundation of Corporate Succe: how buine trategie add value, (1993) Oxford Univerity Pre, Oxford, Chapter 4 8. King, J.L. (on-line at current ite to June 2000) <http://www.ic.uci.edu/~king/reearch.html> 9. Lorange P. and Roo J. Alliance: Formation, Implementation and Evolution,.(1993)Blackwell, Oxford 10. Lacity, M. and Hirchheim, R. Information Technology Outourcing, in Rethinking Information Sytem, Currie, W. and Gallier, R. ed., (1999) Oxford Univerity Pre, Oxford, Chapter 14 11. Lacity, M. and Willcock. L. An empirical Invetigation of Information Sytem Outourcing: Finding from Experience, Oxford Univerity Working Paper (1996) 12. Lamming, R. Beyond partnerhip: trategie for innovation and lean upply, (1993) London: Prentice Hall 13. Reeker, N and Smithon, S. The Impact of Electronic Data Interchange on Inter-organiational Relationhip: Integrating Theoretical Perpective, HICSS-28 Minitrack, "Meauring the Effectivene/ Impact of Emerging Technologie", Jan 3-6, 1995 14. Scarbrough, H) The External Acquiition of Information Sytem Knowledge in Willcock L.P. and Lacity M. (ed.) Sourcing of Information Sytem: Perpective and Practice, (1998) Wiley, Chicheter, Chapter 4 15. SEI (1998), Carnegie Mellon Univerity, COTS BASED SYSTEMS initiative. On-line at <http://www.ei.cmu.edu/cb/practice.html>