Application Life-Cycle Management
A literature study
By Samuel Sabbagh Student number 1304445 Email s.sabbagh@gmail.com 22 februari 2008Rijksuniversiteit Groningen, Netherlands Faculty of Economics and Business
Thesis to complete the degree:
MSc Business Administration specialisation Business & ICT Supervisors
Prof. Dr. E.W. Berghout
Faculty of Economics & Business Rijksuniversiteit Groningen Drs. ing. A.C. Commandeur
“IS applications like products have life cycles – and contribute
P R E FA C E
M A N A G E M E N T S U M M A RY
The research set out in this thesis was initiated in response to the wish of the management at UWV to have an instrument developed that enabled the practise of “application life-cycle management”. The following is the problem statement governing this research:
“Management at UWV wants a practical instrument to be able to manage the life-cycle of
applications.”
From this statement the following questions where identified for further research: 1. What is an application?
2. What is the application life-cycle?
3. What is application life-cycle management?
4. What are the current methods of carrying out application life-cycle management? 5. How relevant are the current methods to public organisations?
6. What method is currently employed by UWV?
7. What are UWV’s wishes for the future practise of application life-cycle management? At the outset of this research it was envisioned that the first five research questions where to be answered by a thorough literature study and the last two by interviews at UWV. Combining the two sources of information would then lead to the development of an instrument for ALM grounded on the one hand in current literature and being specifically tailored to UWV. Due to a lack of time, the practical side of the research had to be forgone, meaning the relevant stakeholders at UWV were not interviewed as planned. The consequence of this was that the development of the instrument could only be based on literature and as such remained theoretical.
The instrument eventually developed is based for a great part on some of the methods for ALM (and related topics) currently in existence. In effect, the literature research provided a number of building blocks with which a new instrument could be developed. The instrument turned out to be one in tabular form, analysing functions (supported by applications) rather than applications themselves. The criteria on which each function / application should be analysed need to be identified in future
TA B L E O F C O N T E N T S
PREFACE ... i
MANAGEMENT SUMMARY ... ii
LIST OF FIGURES... iv
CHAPTER 1 – Introduction and background ... 1
1.1 Research topic ... 1 1.1.1 Social significance... 1 1.1.2 Scientific relevance ... 2 1.2 UWV ... 2 1.2.1 Mission ... 2 1.2.2 Core tasks ... 2 1.2.3 Responsibilities ... 2 1.3 Research Questions ... 3 1.3.1 Relevant stakeholders... 4 1.4 Research method ... 4 1.5 Research overview... 5
CHAPTER 2 – Background concepts ... 6
2.1 What is an application? ... 6
2.2 The application life-cycle ... 8
2.2.1 Related concepts: ‘Application Portfolio (Management)’... 10
2.2.2 Related concepts: ‘Information Systems Planning’... 10
2.3 Application life-cycle / portfolio management... 10
2.3.1 Full life-cycle management ... 10
2.3.2 Application Portfolio Management (APM)... 11
CHAPTER 3 – Existent methods ... 12
3.1 Bedell... 12
3.1.1 The method... 12
3.1.2 Identification of indicators ... 13
3.1.3 The working of the method in ten steps ... 13
3.1.4 Advantages ... 15
3.1.5 Possible improvements... 15
3.1.6 Link with ALM ... 15
3.2 Information Economics ... 15
3.2.1 The method... 15
3.2.2 Advantages ... 17
3.2.3 Possible improvements... 18
3.2.4 Link with ALM ... 18
3.3 Investment Portfolio method ... 18
3.3.1 The method... 18
3.3.2 Economic contribution ... 19
3.3.3 Contribution to the business domain ... 19
3.3.4 Contribution to the IT domain ... 20
3.3.5 Analysis ... 20
3.3.6 UWV ... 21
3.3.8 Possible improvements... 22
3.3.9 Link with ALM ... 22
3.4 Gartner... 22
3.4.1 Fitness for Duty ... 22
3.4.2 Gartner Toolkit: Application Assessment ... 23
3.4.3 Gartner ‘Workplace Application Classification Framework’... 24
3.5 The ISO 9126 model for Quality of software... 24
3.6 SIG maintainability Model ... 25
3.7 McCabe index of Software Complexity ... 25
3.8 Software providers... 25
3.8.1 CA Clarity ... 27
3.8.2 Primavera P6 ... 27
3.8.3 Compuware Changepoint ... 27
3.8.4 Efficient frontier ... 27
3.9 Comparison of methods used for application life-cycle management... 28
3.10 The relevance of existent methods to public organisations ... 29
CHAPTER 4 – The instrument... 30
4.1 Building blocks... 30
4.1.1 Investment selection method - Bedell ... 30
4.1.2 Information Economics – Parker, Benson & Trainor & Investment portfolio method – Berghout & Meertens ... 30
4.2 The instrument... 31
4.2.1 Possible criteria – Technology domain ... 32
4.2.2 Possible criteria – Business domain ... 33
4.2.3 Possible criteria – Financial... 33
4.3 Weighting the instrument ... 33
4.3.1 Bare-minimum... 34
4.3.2 Weights 1 through 4 ... 34
CHAPTER 5 – Conclusions ... 35
REFERENCES... 36
LIST OF ABBREVIATIONS ... 40
APPENDIX A – Bedell in Practise ...Error! Bookmark not defined. A.1 Indicators explained...Error! Bookmark not defined. APPENDIX B – Information Economics in Practise ...Error! Bookmark not defined. APPENDIX C – Strengths and weaknesses of different PPM software packagesError! Bookmark not defined.
L I S T O F F I G U R E S
Figure 1. Business structure UWV. Source: UWV Annual Report 2005... 3Figure 2. Applications and layers. Source: Luijten 2005 p132 ... 6
Figure 3. The life-cycle according to Berghout & Nijland 2002... 8
Figure 4. Overview of indicators with the Dutch counterparts as used by van Reeken 1992. ... 13
Figure 5. Bedell investment matrix (for specific IS). Source: Lobry & Wolfsen 1999... 14
Figure 7. IE criteria per domain. Adapted from Renkema 2000 with addition of Wiseman 1992... 17
Figure 8. Investment Portfolio. Adapted from Berghout & Meertens 1992... 19
Figure 9. Application performance indicators. Source: Harris & McRory 2006. ... 23
Figure 10. Gartner Toolkit: Application Assessment. Source: Weiss 2007. ... 23
Figure 11. The original ISO 9126 attributes. Source: InSIGight July 2007. ... 24
Figure 12. Magic Quadrant for IT Project and Portfolio Management. Source: Gartner 2007... 26
Figure 13. IT portfolio management. Source: Caruso 2007. ... 26
Figure 14. Comparison of methods chart. Adapted from Renkema 2000. ... 28
Figure 15. The instrument. ... 32 Figure 16. Indicators per activity...Error! Bookmark not defined. Figure 17. Indicators per function. ...Error! Bookmark not defined. Figure 18. Invest in IT or other assets? ...Error! Bookmark not defined. Figure 19. Which activities to invest in...Error! Bookmark not defined. Figure 20. Which functions to invest in for a specific activity (‘AG’ in this case)...Error! Bookmark
not defined.
Figure 21. Proposals. ...Error! Bookmark not defined. Figure 22. Scoring of proposals for the IE method. Adapted from Delahaye & Van Reeken 1992.
C H A P T E R 1 – I n t r o d u c t i o n a n d b a c k g r o u n d
The first chapter of this research is concerned with introducing the topic in general, the case organisation in specific and outlining the setup of this research. This will be done as follows: in the first section, a general introduction to the research topic will be given, along with an overview of the envisioned significance of the research, followed in section 1.2 by an introduction of the case organisation. Section 1.3 will provide the problem statement and subsequently the research questions derived there from, followed by the research method in section 1.4. This chapter concludes with an overview of the rest of this research, in section 1.5.
1.1 Research topic
“IS applications like products have life cycles – and contribute more or less to the business and drain more or less resources from the business during the evolving phases of their lives” (Ward 1988). While the application life-cycle has been researched implicitly over the last few decades (as early as 1978 by Cave and Salisbury), it really was not identified explicitly until 1994 when the Werkgroep (Taskforce) Information Economics (WIE) devised the application life-cycle ‘disc’, with the phases: exploitation, identification, justification and realisation.
In 1994, the life-cycle devised by the WIE was state-of-the-art, yet it did not take long for other academics to expand upon the initial idea (e.g. Swinkels 1998 and Berghout & Nijland 2002). As such, a substantial amount of academic research has already been carried out in the field of the application life cycle. The tendency is to focus on specific phases of the life-cycle however, as such, a ‘big picture’ overview of fit between business and IT is missing. Swinkels (1998) on the subject: “Most of the current literature is directed at a specific part of the life-cycle or at a single concept and thus neglects their relationship with the other activities and concepts and the relevance of these.”
Besides this lack of an integral overview, there is no clear definition of terminology in this field: some authors refer to the application life-cycle (e.g. Braaksma 2005 who mentions it, yet concentrates his research on the first two phases), some to full life-cycle management (e.g. Berghout & Nijland 2002), others to applications portfolio management (e.g. Ward 1988) and yet others to evaluation of information systems (e.g. Wiseman 1992).
The objective of this research is to lay the groundwork for the development of an instrument that can be used to manage the life cycle of applications (specifically at the case organisation UWV). Before undertaking this research, a clear definition of what an application is will have to be found, since till now the word is being interchanged freely with ‘information system’, ‘software’ and even ‘information communication technology’. A distinction might also have to be made between the definition in academic literature and the one at UWV. It needs to be clear however that the developing of an instrument alone will not facilitate the managing of the application life-cycle, it needs to be matched by the processes to employ it (Azoff 2007).
1.1.1 Social significance
Seeing as the research is carried out at UWV, the social significance is to be judged from UWV’s perspective, which is not to say that the research will not have significance for a wider social body. One would expect any relevance to be applicable to society as a whole seeing as there is hardly a company or institution to be found that does not use a myriad of different applications, which all need managing.
and employing it in other organisations (whether they are for-profit or non-profit) could prove to be possible.
On a more elementary level, the instrument will facilitate insight into the life cycle of applications at a company and allow for more efficient management of said life cycle. Seeing as how every phase in the life cycle consumes an amount of scarce resources, more efficient management will eventually reduce cost and generate business value from IT, as well as provide for a much more transparent application landscape.
1.1.2 Scientific relevance
The main academic contribution of this research is the integration or tying together of multiple existent techniques (see section 1.4 for a non-exhaustive list) for the management of the application life-cycle into one up-to-date, flexible and practically useable instrument. Literature research has shown there to be relatively little material looking at the management of the entire life-cycle, due to which this research should provide a unique addition to the existing body of knowledge.
1.2 UWV
UWV was created in 2002 through the merger of the five previously existent social insurance organisations (SFB, GUO, Cadans, USZO and GAK) to become the central Dutch social insurance and employment agency. As an independent organisation, UWV operates under the responsibility of the Ministry of Social Affairs and Employment and on 31 December 2006 had a workforce of 18,196 people and in excess of 8,000,000 customers (all people employed in the Netherlands as well as all Dutch employers).
1.2.1 Mission
“‘We stimulate work. If working is impossible, we ensure temporary aid, swiftly.’ This mission stems from the Dutch SUWI law and in practise means that UWV and its partners endeavour to help people to start working (again). Only in case that working is impossible does UWV provide temporary aid. Through pro-active help by coaches, among other things, UWV ensures that an unemployed person has the best chances of finding a job and as such keeping the duration of the aid short.” (UWV Kompas 2005)
1.2.2 Core tasks
UWV has four core tasks (UWV Kompas 2005):
• Work: keeping or getting a ‘customer’ working, through cooperation with partners.
• Social-medical affairs: the evaluating of illness and inability to work based on fixed criteria. • Aid: the provision of aid, swiftly and correctly, in case of inability to work.
• Data services: ensuring that the ‘customer’ has to provide information on work and income to the government only once.
1.2.3 Responsibilities
A comprehensive overview of the responsibilities of UWV can be found on the website of the Ministry of Social Affairs and Employment:
and provides subsidies for the re-employment of persons on disability or unemployment benefit. The institute has an extended network of regional and local agencies performing the basic social insurance administration functions (collection of contributions, claim assessment, benefit payments, initiation of reintegration activities).” (UWV annual report 2005)
Figure 1. Business structure UWV. Source: UWV Annual Report 2005
1.3 Research Questions
Achieving a cost efficient and functionally effective application portfolio is a challenge for every organisation and even more so for UWV, seeing the way it was created (see section 1.2). Until now, the focus at UWV has been for a great part on reducing the number of duplicate applications, in so doing lowering cost and creating a standardised infrastructure (K&M year program 2006/2008). After its inception (post-merger), there were cases where there were up to six applications doing (nearly) the same task or supporting (nearly) the same business process. In some cases the best of the duplicate programs was chosen, in other cases all duplicates were replaced by a new application and in some cases all duplicates were shut down all together (K&M year program 2006/2008).
identified the need for an instrument to be designed to manage the life-cycle of current applications and prioritise investments in new applications.
The above is translated into the following problem statement:
“Management at UWV wants a practical instrument to be able to manage the life-cycle of
applications.”
When looking at the title of the proposed research and at the problem statement, several questions can be identified, which led to the formulation of the following research questions:
1. What is an application?
2. What is the application life-cycle?
3. What is application life-cycle management?
4. What are the current methods of carrying out application life-cycle management? 5. How relevant are the current methods to public organisations?
6. What method is currently employed by UWV?
7. What are UWV’s wishes for the future practise of application life-cycle management?
1.3.1 Relevant stakeholders
Besides the management of UWV, there are several other groups that are stakeholders to the project at hand:
• Information Planning (Informatie Planning) • Kill & Migrate (Killen & Migreren)
• Policy & Architecture (Beleid & Architectuur) • Finance (Financieel Economische Zaken) 1.4 Research method
The background and context of the research at hand will be identified / explored by carrying out extensive literature research in books and academic journals. It is not unimaginable that the definition of ‘application’ is of a more implicit nature, rather than being explicitly defined in documents, meaning most people know what is meant by the word without there being a formal definition. As such, the answer to the first research question will have to be distilled for a large part from internal UWV practises and documentation (e.g. ‘UWV reference architecture’ (Luijten 2005)) as well as what is available in academic literature (e.g. Swinkels 1998). Finding the answer to the second question on the definition of the application life-cycle should be less ambiguous, considering the firm grounding of the topic in existing academic literature (e.g. Berghout & Nijland 2002 or Swinkels 1998).
The third and fourth questions will be researched wholly on the basis of current academic literature. Background theories and concept will be taken mainly from academic journals such. An overview of previous methodologies for or part of application life-cycle management will be taken from, but not limited to the following existing application life-cycle methodologies:
• Bedell portfolio approach (Van Reeken 1994 or Lobry & Wolfsen 1999) • Parker, Benson & Trainor Information Economics approach (Parker et al. 1988) • Investment Portfolio Method (Berghout & Meertens 1992)
• Gartner research (Weiss 2007 or Harris & McRory 2006)
1.5 Research overview
C H A P T E R 2 – B a c k g r o u n d c o n c e p t s
This chapter first provides a definition of the word ‘application’ in section 2.1, followed by an overview of what the current research is on the application life-cycle in section 2.2. The chapter concludes by looking at the third research question on application life-cycle management.
2.1 What is an application?
For UWV, an application is defined in the “Referentiearchitectuur UWV” (UWV reference architecture) (Luijten 2005) as follows: “A collection of conceptually related, automated processing functions as well as the stored, automated data maintained by the functions. The functions and the data are functionally maintained as a single unit.” Applications are seen to have two layers (see Figure 2): a processing layer (B) and a data-services and storage layer (A). “The processing layer consists of all services with which data is manipulated or combined in a different way. […] The data layer consists of the actual stored data, as well as the services with which data is made available. [Furthermore] all UWV’s data should be available to all applications, as such the method of request for data should be standardised.” (Luijten 2005) There is a third layer, the presentation and guidance layer, which is mainly concerned with the user interface and as such is outside the scope of this research.
Besides a standardised method of data interchange (represented in figure 2.1.1 and defined by Luijten 2005 as the information flows between applications), applications are also expected to be independent, thus facilitating the replacing or shutting down of individual applications. As such, UWV has chosen (Luijten 2005) for a Service Oriented Architecture (SOA) (a formal definition of which can be found in Luijten 2005), implying the following: “an application need not be aware of the name, platform, location, message format or ancillary communication protocols of other applications with which it is in contact. Instead, an application’s services should be available to other applications through formalised, yet simple interfaces.” (Luijten 2005) At UWV, the goal is for resources to be made available as independent services, in line with SOA.
Furthermore, applications are seen to fulfil a function within what is called a ‘logic information system’, which is defined as: “a part of the information provision with clear boundaries, strong internal cohesion and relatively weak ties to other logic information systems. Figure 2 in its entirety could be seen to represent a logic information system, consisting of multiple applications with strong internal cohesion. UWV thus makes a clear distinction between what is an application and what is an information system; in this sense applications are defined to be a subset of information systems by the UWV reference architeture.
Swinkels (1998) makes a distinction between [investments in] ‘application information systems’ and ‘underlying IT architecture’. The difference between these investments is the generation of value; applications generate value (whether it be financial in the form of extra profit or less cost or improved functionality), whereas investments in architecture are seen to provide a platform, necessary for the creation of value, without delivering a direct contribution.
Van Irsel et al (1992) define an application according to two factors: a) whether or not the application has a specific purpose (as opposed to a common use, as is the case with so-called ‘infrastructural applications’ for example) and b) whether the benefits derived from the application are direct or indirect; an application is then defined as one that has a specific purpose and has directly appropriable benefits. This view is supported by Austin (2005) who devises the workplace application classification framework, which characterises applications along their ‘maximum return’ (measured in ROI) on the one side and their ‘deployment breadth’ on the other.
In 2007 Gartner research, Jim Duggan acknowledges that “even in the simple cases, an application will have multiple stakeholders and therefore, multiple views or names.” He subsequently sets out to provide a working definition; according to Duggan (2007) an application is:
• An aggregation of software code impounding business logic and rules • Transforming user or system input into data output
• For the purpose of automating and optimizing business functions, processes, tasks and activities
Furthermore, Duggan (2007) provides a number of application categories:
• Analytic: Any application with a primary objective of capturing, storing and manipulating data for query and analysis.
• Transactional: Any application with a primary objective of capturing, exchanging or transferring static data with standard or pre-defined reporting capabilities.
• Collaborative: An application with the primary objective of sharing and communicating information across a group in support of human-enabled processes.
• Hybrid: Applications created from two or more different types, with a mixture of the other types.
Duggan argues that “if an application candidate does not meet the working definition and fall into one of the categories, then it likely will be best treated as an enabling or integration technology tool or platform.” (c.f. ‘infrastructural applications’ of Van Irsel et al 1992).
Scardino et al (2005) provide a clear justification for the need of a central definition of the word ‘application’: “Each organization tends to define its applications differently, so it is important to have a single common definition to ensure consistency in the way application teams discuss the subject of the analysis. An application should be defined from the point of view of organising different programs and functions in a way that enables decisions about these applications.”
In the case of the research outlined in this thesis, UWV’s definition of application has been adopted seeing as this is the case organization, adding to it some points the other research outlined above. From our perspective the key points of the definition are as follows; an application:
• Consists of two layers: a processing layer and a data-storage layer • Is independent of other applications
• Has a specific purpose
• Should allow for sharing of data with other applications • Should generate direct benefits (or business value) 2.2 The application life-cycle
This research focuses on the application life-cycle, which, as stated previously, is a concept not entirely free of ambiguity. This section will provide an overview of the application life-cycle as it will be used in this research. The end of this section will also provide a summary of other related or similar concepts.
The most recent and thorough evolution of the application life-cycle is to be found in Berghout and Nijland (2002) and is depicted in the figure below (with addition of the initial WIE phases). The authors define the life-cycle as follows: identify, justify, design, build, implement, operate, maintain, abandon (Figure 3).
Figure 3. The life-cycle according to Berghout & Nijland 2002
the wording used. References to literature dealing more extensively with individual phases is provided for each phase.
• Phase 1: Identification What are possible interesting opportunities for investment? This phase can be steered by adding or removing criteria that proposals must meet. New investments may require additional investments in infrastructure, or result in the removal of existing systems. (See Braaksma 2005 or Berghout 1997)
• Phase 2: Justification Do the proposals meet the criteria and which combination of information systems contributes most to the organisation? Which projects are accepted and to be realised is decided in this phase. There are many different methods of evaluating investment proposals or project prioritisation, some of these are analysed in chapter 3. (See Braaksma 2005 or Berghout 1997)
• Phase 3: Realisation How to realise a usable application in such a way as to maximise the added value. This phase comprises all the activities needed to achieve the investment proposal. (See Sassenburg 2006, although his research focussed on software release decisions, which can be seen to be the transition between the ‘build and test’ phase and the ‘implement’ phase of the life-cycle)
• Phase 4: Exploitation How is maximum value realised using the existing system? The primary target of this phase is the achievement of the highest possible value from the system in its operation.
• Phase 5: Evaluation Was the maximum possible added value realised and if not how can one learn to improve this? To be able to carry out continual evaluation of the system throughout the phases above and to judge the beneficial contribution to the business, measurable performance indicators should be identified from the first phase.
• Abandon Although not one of the original five life-cycle phases, the abandon phase is a rather important one and deserves special mention as without it, applications appear to have a never-ending life. According to Gartner research (Heine 2006): “Aging and poorly used applications that should be retired contribute as much as 20% or more to the overall IT organisation resource baseline requirements.” There are thus significant cost reductions to be experienced following the careful monitoring and eventual removal of applications nearing their end-of-life.
In 2003 Gartner research, Zrimsek et al (2003a) note: “Enterprises must consider all phases of the [business] application life cycle to best navigate the challenges that each phase presents. Failure to include a phase, or any of the subcategories within a phase, will waste valuable resources and possibly doom the project to longer time frames, greater costs – or failure.” The life-cycle identified by Zrimsek et al (2003a) consists of four phases (strategise, evaluate, execute and manage), which then consist of 11 subcategories respectively. In a follow-up article, Zrimsek et al (2003b) advise their clients to: “[consider] all of your business applications holistically, rather than discretely.” While the importance of utilising an application life-cycle management tool to analyse the entire application portfolio holistically is recognised, individual applications should not be overlooked.
2.2.1 Related concepts: ‘Application Portfolio (Management)’
The concept of the application portfolio, in its earliest form, was identified by McFarlan in 1981 and since then has received a lot of attention form other authors (such as Ward 1988 for example). It is rather closely related to the application life-cycle, yet generally takes a more holistic view, aggregating the effect applications have on an organisation (Ward & Griffiths 1996), where ALM generally looks at one application at a time. The following definition of ‘the IT portfolio’ by McLure (2007) sums this notion up nicely: “An IT portfolio is a collection of IT initiatives that is characterised as investment activities developed and executed across a business unit, department, agency or even a whole government.”
With respect to the current research, the concept of analysing applications in a portfolio could be interesting as it provides a level of analysis one step up from the individual application analysis as with ALM. Integrating APM with ALM could ensure a view that is holistic enough to compare applications with one another, yet allow one to assess individual applications in detail.
2.2.2 Related concepts: ‘Information Systems Planning’
Information Systems Planning (ISP) is first identified by Dickson in 1984 (as quoted in Lee & Gough 1993) and consists of the following phases:
1. Perception: Identification of IS strategic value.
2. Evaluation: Identification of required business functions. 3. Selection: Prioritisation of potential IS projects.
4. Construction: Generation of preliminary IS plans. 5. Review: Assessment of ISP effectiveness.
Lee & Gough (1993) summarise the purpose of the method as follows: “The approach is designed to improve the effectiveness of the high-level planning processes for information systems […] it addresses not only the technical problems encountered in information systems planning but the whole range of problems which derive from social systems, organisational processes formal organisational arrangements, technology and the external environment. [Its purpose is] to identify which IS are needed rather than to plan in detail any specific system.” It appears the ISP method is intended as a more high level approach as compared to application life-cycle management, which concentrates on individual applications. Nonetheless, the method warrants mention in this research due to its similarity in setup to ALM and to illustrate such frameworks can be used on different levels.
2.3 Application life-cycle / portfolio management
This section explores what notions there are in current academic literature as to the management of the application life-cycle and application portfolios.
2.3.1 Full life-cycle management
As such, the benefits (which are realised in the exploitation phase of a project) are often weighed only against the initial costs, getting many projects approved which should not have been approved.
To counter this trend and dispel the paradox, Berghout & Nijland (2002) propose ‘full life-cycle management’, which they define as: “a comprehensive set of methods and techniques offered to manage systems along the system’s life-cycle. Furthermore, information is shared among life-cycle stages.” The authors conclude that: “[…] excellence of operations in only one or two life-cycle activities is relatively pointless and efficient and effective use of IT can only be achieved through full life-cycle management.” It needs to be noted that the authors refer to information systems, yet the general idea is just as easily applied to applications.
2.3.2 Application Portfolio Management (APM)
As with so many of the methods and theories explored in this research, there is more than one name for the concept of Application Portfolio Management. The discussion in this section draws from a number of different academic writings, each utilising a different name for the concept of APM, such as IT Portfolio Management and Project Portfolio Management (in the context of applications or IS projects). This research assumes these names to mean the same and chooses to use APM as a central name.
A clear and thorough definition of APM is provided by Duggan (2005): “Evaluation of the inventory of the current application stock for architectural fit, for suitability to the business needs, and for the prospective costs and risks of various application investment or retirement strategies establishes context for the budget process and influences the mix of development projects.” What is particularly interesting about Duggan’s (2005) definition is the fact that it looks at the “current stock” of applications as well as prospective investments and prospective retirement of applications. Furthermore it is good to note the inclusion of the ‘abandon phase’ in this definition. It becomes apparent from Duggan’s (2005) definition that APM takes a holistic view of applications, as previously mentioned in section 2.2. Jeffrey & Leliveld (2004) liken APM (which they dub IT Portfolio Management or ITPM) to managing financial assets in a portfolio, “balancing risk and return.” Caruso (2007) lists three benefits realisable by managing IT investments as a portfolio:
1. Easier measurement of value creation due to increased visibility of where money is being spent.
2. Improved prioritisation of projects along multiple dimensions, such as financial return or value to the business.
3. Greater alignment between investments and business objectives.
Ward & Peppard (as quoted in Hirvonen 2004) highlight the need for APM to “evaluate an IT system’s relation to business success and answer questions such as how much should be invested in new systems or technologies.” Hirvonen (2004) does note however that not all organisations yield the same benefits from application portfolio models; this is dependent on the maturity of an organisation. This opinion is supported by Jeffrey & Leliveld (2004) who develop a four stage maturity model of ITPM:
1. Stage 0 – Ad Hoc: Lack of real coordination in the making of decisions about investments. 2. Stage 1 – Defined: Key components of IT portfolios have been identified and documented,
costs and benefits roughly estimated.
3. Stage 2 – Managed: A standard ITPM process is in place that enables objective project selection and has a clear link with business strategy.
4. Stage 3 – Synchronised: High alignment between the investment portfolios with business strategy, a project’s value is measured throughout its life-cycle.
C H A P T E R 3 – E x i s t e n t m e t h o d s
This chapter will provide a comprehensive overview of what methodologies are currently available in the field of application life-cycle and portfolio management. The focus will be upon three larger and more complex methodologies, namely: the Bedell investment appraisal method (1985); the Information Economics methodology of Parker, Benson and Trainor (1988) and the Investment Portfolio method by Berghout & Meertens (1992). Besides this, attention will also be paid to several smaller methodologies, definitions of application criteria (as identified in Gartner research for example) and tools developed by software providers (such as the Computer Associates Clarity toolkit). Sections 3.1 through 3.3 will deal extensively summarise and analyse the methodologies by Bedell, Parker, Benson & Trainor and Berghout & Meertens so as to uncover what parts of if might be useful to the instrument to be developed in this research. The subsequent sections deal with less complicated methods, which are often no more than mere lists of criteria on which applications can be judged. An overview of current software available in the market for the practice of portfolio management will be provided in 3.9, with 3.10 looking at the distinction between public and private organisation with respect to application life-cycle management.
3.1 Bedell
The 1985 investment selection method of Bedell outlined in this section will be distilled mainly from an in-depth article written by van Reeken (1992), as well as a number of other articles and books as the original book by Bedell is rather difficult to come by. Section 3.1.1 below introduces Bedell’s method, 3.1.2 shows what indicators are used, while 3.1.3 provides a ten step summary of the working of the method. Sections 3.1.4 and 3.1.5 outline the advantages and limitations of Bedell’s method and 3.1.6 finally presents the link with ALM.
3.1.1 The method
The method centers around three core questions (van Reeken 1992): firstly and very basically, whether or not the organisation under scrutiny, considering its current state (both business and systems wise) should invest in information systems or in other assets. If the decision is taken that the organisation should invest in IS, the second question is what activities should receive IS investment. When it becomes clear what activities need to be invested in, the third question deals with which individual information systems should be invested in, as such Bedell eventually provides a means of prioritising different proposals. In summary, the purpose of this method is the selection of systems eligible for (further) development based on how well they support business activities (Lobry & Wolfsen 1999). According to Bedell (as quoted in van Reeken 1992): “[…] the effectiveness of information systems in an activity depend on the effectiveness with which those systems support the functions of the activity for which they were designed and the importance of the supported functions for the achieving of the goals of the activity.” With the addition of a measure of the importance of each activity to the organisation as a whole the method provides a way of directing investments to the areas in the organisation where they have the most effect. Effectiveness of an IS can be understood to be comprised of (Lobry & Wolfsen 1999):
1. Functional adequacy: according to Bedell, a system is functionally adequate when it provides the right information at the right time, supporting an activity in a timely manner.
2. Technical adequacy: according to Bedell, a system is technically adequate when it is reliable, maintainable and expandable.
3. Cost-effectiveness: according to Bedell a system is cost-effective when it is efficient in use, meaning there is no alternative that can provide the same service for a lower cost.
3.1.2 Identification of indicators
Bedell develops a dozen or so indicators so as to eventually be able to quantify the importance and effectiveness of information systems. An overview of the different indicators can be found in Figure 4 and an explanation of their meaning and development can be found in appendix A. It should be noted that for the various “importance of systems” indicators, Bedell in actuality refers to the type of
function (of an activity) supported by a system that determines importance.
Acronym Indicator in full
ESA EIA ESO EIO ISA ISO IIA IIO IAO Focus-factor
Effectiveness of a particular System to an Activity Effect of IS on an Activity
Effect of a particular system on the Organisation Effect of IS on the Organisation
Importance of a particular System to an Activity Importance of a particular System to the Organisation Importance of IS to an Activity
Importance of IS to the Organisation
Importance of a particular Activity to the Organisation Focus-factor
Figure 4. Overview of indicators.
3.1.3 The working of the method in ten steps
Steps to undertake in going through a Bedell investment analysis (van Reeken 1992): 1. The Importance of a particular Activity to the Organisation (IAO)
2. The importance of a particular System to an Activity (ISA) 3. The effectiveness of a particular System to an Activity (ESA) 4. The effect of all systems on an activity (EIA, EIO)
Figure 5. Bedell investment matrix (for specific IS). Source: Lobry & Wolfsen 1999.1 6. Should the organisation invest in IS?
Plot Figure 5 with the following indicators: EIO on the x-axis and IIO on the y-axis. This provides an answer to the question whether the organisation should invest in IT or not.
7. What activities should be invested in?
Plot Figure 5 with the following indicators: EIA on the x-axis and the Focus-factor on the y-axis. This provides an answer to the question what activity should receive the investment.
8. What systems are eligible for (further) development?
Plot Figure 5 with the following indicators: (ESA x ISO) on the x-axis and ISO on the y-axis. According to van Reeken (1992) Bedell does not provide a specific explanation of the ESO indicator or the way to derive it, according to Bedell (as quoted in van Reeken 1992), the ESO and the ESA indicators are identical as long as any one system does not support more than one activity.
It is important to note here that the “systems eligible for (further) development” do not represent the possible projects (which are only proposed in the next step), but rather the actual current systems in use, whether they be IT-based or not (in which case a score of 0 on the ESA indicator will automatically place any such project in the one of the two left quadrants of Figure 4: either ‘invest aggressively’ or ‘keep it running’ dependent on the value of the ISO indicator on the y-axis).
This step provides an overview of which specific functions within an activity should be invested in. 9. Selection of projects
1 Interestingly, the ISP method as outlined in section 2.2 employs a similar matrix with ‘technical quality’ instead of effectiveness and
In this step, business process owners (or others responsible for individual activities) are asked to come up with investment proposals for their activities, together with the cost of the project. Following this, projects can be evaluated on current ESA, future ESA if the project is undertaken (ESA’) and the cost. According to van Reeken (1992) a value of ISO/10 for the indicator ESA’ is ideal.
10. Prioritisation of projects
To finally prioritise the different project proposals, Bedell calculates the contribution of each proposal as follows: ISO x (ESA’ – ESA), reflecting the increase in effect should the proposal be undertaken and the relative importance of the particular system to the organisation as a whole. The analysis can stop here and projects can be prioritised solely on the basis of their relative contribution, but the financial aspect can be looked at as well. Dividing each project’s contribution by the costs of that project yields the per currency unit contribution of a project, which may give rise to a completely different prioritisation than on the basis of contribution alone.
3.1.4 Advantages
• Allows for the analysis of and prioritisation of investment proposals without the necessity of quantifying the costs and benefits (Lobry & Wolfsen 1999).
• Starts before there are any investment proposals and even considers whether or not the organisation should invest in IT or not.
• Looks at functions (supported by applications) rather than at applications directly. This allows for inclusion in the analysis of functions that are not currently supported by applications.
3.1.5 Possible improvements
• In theory, this method provides the option of analysing systems that support multiple activities within an organisation, yet this is not explained by Bedell and would most likely result in a far too complex analysis.
• There is no mention of risks in this method (Lobry & Wolfsen 1999).
3.1.6 Link with ALM
Bedell’s method is primarily useful for the “realisation” phase of the application life-cycle, although it is also suitable for the identification of new projects.
See Appendix A for a fictional workup of the Bedell method, which greatly helps to understand its workings.
3.2 Information Economics
The following section will provide an overview of the Information Economics method as presented in the 1988 book by Parker, Benson and Trainor. Section 3.2.1 below presents a summary of the IE method, with sections 3.2.2 and 3.2.3 outlining its advantages and limitations. Section 3.2.4 finally presents the link of IE with ALM.
3.2.1 The method
The IE method thus centers on a two-domain approach with ‘chargeout’ (Parker et al. 1988), meaning that the “costs incurred in the technology domain (the IS organisation) are charged to users in the business domain.” An illustration of this concept is provided in Figure 6., where the two arrows show the flow of the benefits (or value) and costs of an investment. The business domain receives value from investment in new services in the technology domain, but simultaneously is charged and thus incurs costs for the new services. Duggan (2007) underwrites a two-domain approach as undertaken by Parker et al. (1988), as he sees applications to be inherently tied to business value.
Figure 6. Two-domain ‘chargeback’. Source: (Parker et al. 1988).
According to Renkema (2000), in the Information Economics method, “the total appraisal of an IT investments proposal takes place in three steps, covering financial, business and technological criteria, both positive and negative.” An overview of the different criteria used in the information economics method can be found in Figure 7.
Appraisal Criteria Meaning
Business domain
Strategic match The extent to which the investment matches the strategic business goals
Competitive advantage
The extent to which the investment contributes to an improvement of positioning in the market (e.g. changes in industry structure, improvements of competitive positioning in the industry)
Management information The extent to which the investment will inform management on core activities of the firm
Value
Competitive response The extent to which not investing implies a risk; a timely investment contributes to strategic advantage
Risk Organisational risk The extent to which new competencies are required Technology domain
Value Strategic information systems and architecture
The extent to which the investment matches the IT plan and the required integration of IT applications
Definitional uncertainty The extent to which user requirements can be clearly defined Risk
Infrastructural risk
The extent to which the investment requires additional infrastructure investments and the IT department is capable of supporting the proposed system
Enhanced ROI
Value linkage The extent to which another department or area obtains money benefit from the investment
Value restructuring The extent to which an entire department is reoriented to more valuable work through the investment
Value acceleration The extent to which there exists a one-time cash benefit of getting something done sooner through the investment
Innovation valuation The extent to which the investment will provide or maintain a competitive advantage through innovation
Figure 7. IE criteria per domain. Adapted from Renkema 2000 with addition of Wiseman 1992.
For the IE method to be undertaken, proposed investments needs to thus be scored on each of the criteria listed in the figure above. The first step is to list the financial benefits and costs of each project, resulting in a figure for Return On Investment (which can be arrived at by using different methodologies, some simpler and some more complex; each organisation can use its preferred method (Wiseman 1992)). Parker et al. (1988) add four complementary factors to ROI to arrive at ‘enhanced ROI’, namely: ‘value linkage’, ‘value restructuring’, ‘value acceleration’ and ‘innovation valuation’ (for an explanation of these factors see Figure 7). According to Delahaye & Van Reeken (1992), enhanced ROI will have a value of between 0 and several hundreds percent and this needs to be converted to a scale of 0 to 5, like the other nine criteria. Their suggestion to do so is by making organisation specific intervals, linking certain percentages to a certain score. Parker et al. (1988) suggest using a predefined, universal conversion table to achieve the conversion, which they provide in their book, without explaining exactly how these intervals were identified.
The second step of the method is the weighting and eventual scoring of the five business domain criteria. Like with ROI, the criteria are to be rated on a 0 to 5 scale and each criteria is to receive an overall weight of 0 to 10, indicating that criteria’s importance to the organisation. The third step of the method, like the second step, is the weighting and scoring of the four technology domain criteria, as described in Figure 6. above. The weighting and scoring of the criteria can be carried out by a single person (Delahaye & Van Reeken (1992) suggest an ‘Information Economics Officer’) or by multiple people from both domains (as in Wiseman (1992), where business managers in conjunction with IT managers carry out this task).
The result of the method is a table like Figure 22 in appendix B containing all investment proposals and their individual scores on the ten different criteria (the two criteria ‘competitive advantage’ and ‘competitive response’ were omitted in Figure 22 as they are not relevant to UWV). By multiplying each proposal’s score on a certain criteria by the weight of that criteria and summing these figures, a total score per proposal can be identified. It is on the basis of this total score that a prioritisation of the proposals can be made.
3.2.2 Advantages
- Platform for discussion between business and IT Wiseman (1992) illustrates the roots of the methodology by stating: “Information economics should be seen as an intrinsic part of the strategic thinking that goes on in a business enterprise.”
- Highly adaptable (Wiseman) - Easy to understand and carry out.
3.2.3 Possible improvements
- Like with Bedell: linked projects. Parker et al. suggest either treating linked projects as one project or explicitly mentioning the linkage. Delahaye & Van Reeken (1992) treat linked projects as one, scroing the new ‘hybrid proposal’ by taking the maximum score received by the individual projects on a criteria.
- According to Lobry & Wolfsen (1999), the IE method is good to use for prioritising possible investments and just after the implementation of the investments, but has the tendency to value all implemented projects very highly in the long-run, due to the fact that the promoters of certain proposals know how to manipulate the model.
3.2.4 Link with ALM
The information economics method is used primarily for the identification of new projects and as such ties in with the first phases of the application life-cycle (“identification” and “justification”).
A ficticious workup of the Information Economics method can be found in Appendix B. 3.3 Investment Portfolio method
The following section will present the Investment Portfolio method of Berghout & Meertens (1992). A general overview of the method is provided in the following section, followed by a more in-depth look at different elements of the method in sections 3.3.2 through 3.3.4. Section 3.3.5 provides an analysis of the workings of the method, 3.3.6 judges the use of the method for UWV and the last 3 sections sum up the advantages, limitations and link with ALM of the method.
3.3.1 The method
According to Berghout & Meertens (1992), a major issue pertinent to the appraisal of IS investment decisions is the fact that a large share of the benefits are indirect in nature and more often than not are difficult to quantify. As such, the investment-portfolio method provides the possibility to graphically represent and compare both economic and non-economic aspects of proposed investments. Furthermore, the IP method provides a checklist of the various main- and sub-aspects that should be considered in an IS investment appraisal. The contents of this section are an overview and summary of the method by Berghout & Meertens (1992), appended by suggestions and clarifications.
The IP method follows the thinking of Parker, Benson and Trainor (1988) (see the Information Economics method as described in section 3.2) in the sense that a distinction is made between the business domain and the technology domain, with the former making use of the services of the latter, for which it is ‘presented a bill’. The task faced by the business domain is making optimal use of the services offered by the IT domain, balancing the benefits and costs. Simultaneously, the IT domain needs to create the best possible IT-infrastructure given the benefits generated by providing services to the business domain. It is essential to note the two simultaneous optimalisation processes. It should be noted that, unlike Parker et al. (1988), Berghout & Meertens (1992) use NPV as their financial factor instead of ROI.
circle, the greater the financial contribution, represented by NPV in the article by Berghout & Meertens 1992).
Figure 8. Investment Portfolio. Adapted from Berghout & Meertens 1992.
3.3.2 Economic contribution
As stated previously, the economic aspect is calculated by the Net Present Value methodology. NPV is based on discounting future cash flows to provide the value of an investment today, the amount of years included in the analysis should be equal to the expected economic life (usually the period of depreciation) of the proposed investment. Care should be taken that a clearly defined method of determining the size of the circles for NPV is employed, a suggestion would be to take the project with the smallest NPV as the base index and varying the size of the other circles in relation.
3.3.3 Contribution to the business domain
The contribution to the business domain is taken to be represented by the improvements to the (finished) products or services of the firm, attributable to the proposed investment. Such factors as product characteristics, product quality or service possibilities pertinent to a product are examples of areas of improvement. It is important to note that the contributions to the business domain are non-economic, or they would be included in the economic contribution aspect; this is mainly due to the fact that the effects under scrutiny are normally of a long-term nature, as short-term contributions are generally easily linked to expenditures or income. The contribution to the business domain needs to be evaluated by business management as they have a good knowledge of the current state of the business and the envisioned future strategic path, as well as a holistic overview.
Berghout & Meertens (1992) list four aspects which contribute to the business domain, which they take from Parker, Benson and Trainor (1988):
• Strategic match: The degree to which the proposed investment supports the current business strategy and as such contributes to the organisation’s long-term goals.
• Competitive risk: The consequences for the competitive position stemming from not undertaking the proposed investment.
• Management support: The degree to which the proposed investment will allow for better management of the organisation.
3.3.4 Contribution to the IT domain
The contribution of a proposed investment to the IT domain is the influence of the technology used in the proposed investment to the current and desired IT infrastructure as well as the envisioned synergy with other systems. A third relevant aspect of the contribution to the IT domain is the expected continuity of the proposed system. Overall, a judgement has to be made whether the proposed investment will accelerate or inhibit the development of future systems. The evaluation of contribution to the IT domain needs to be made by a firm’s IT management as they are most capable of judging influences on IT infrastructure.
Berghout & Meertens (1992) list three aspects which contribute to the IT domain, which they take from Berghout (1991):
• Adherence to the current IT standards: The degree to which the technology on which the proposed investment is based is in line with the IT standards of the organisation.
• Acceptance by the market of the ‘product’: The degree to which the technology on which the proposed investment is based is already accepted in the market; do others already successfully employ the technology?
• Continuity of the provider: Can it be expected that the provider of the proposed investment will stay in business in the future?
3.3.5 Analysis
As can be seen in Figure 8, each specific quadrant contains a word, which in essence sums up, or gives a recommendation as to what should be done with projects placed in the respective quadrants:
• The upper-left quadrant contains proposals which have a high contribution to the business, yet contains technology which either does not fit in the current infrastructure, or is otherwise perceived to be of poor quality, the recommendation: proceed with caution.
• The upper-right quadrant contains those proposals which should be executed, as they deliver high contributions to both the business as the IT domain.
• The lower-left quadrant contains the proposals that should be terminated immediately, as they do not contribute to either domain.
• Finally, the lower-right quadrant contains proposals that fit well with the current or envisioned IT infrastructure, but do not (yet) have a high contribution to the business domain, the recommendation here is to hold and wait until there is more need for the proposal from the business domain.
On top of the recommendation that can be given on the basis of a proposal’s placement in a specific quadrant, proposals can also be compared to one another on the basis of their relative positions and the relative height of their NPV; as such, proposals can be prioritised. The prioritisation of proposals yields two categories of positions:
1. Decidable positions: Projects that contribute more (to whichever domain) and have at least the same NPV, in relation to other projects. As such, it is clear which project should be carried out. An example would be two projects with identical NPV’s, one located in the upper-left quadrant (project 2 in Figure 8), the other in the upper-right quadrant (project 1): clearly, project 1 has priority, as it yields a higher contribution to the IT domain for nearly the same contribution to the business domain and equal NPV.
a) Added-value positions: Positions where a project delivers a higher contribution to either the business or the IT domain than another project, but has a lower NPV. E.g. project 3 located in the upper-left quadrant has three times the NPV of project 1 located in the upper-right quadrant.
b) Choice positions: Positions where one project delivers a higher contribution to the business domain, whereas the other project delivers a higher contribution to the IT domain, with a similar level of NPV. E.g. projects 2 and 4 in Figure 8.; while the first yields a higher contribution to the business domain, the second yields a higher contribution to the IT domain, which has priority?
Un-decidable positions will need to be decided on eventually and Berghout & Meertens (1992) suggest this will vary according to the specific wishes of organisations, where for added-value positions the trade-off is between overall contribution and NPV and for choice positions the trade-off is between contribution to business, to IT or NPV. To help in making a decision for a certain project proposal in the case of an un-decidable position, following are some suggestions for possible solutions:
• Identification of ancillary benefits: Some projects might have other benefits, not included in the analysis of the model, thus favouring certain projects over others. Examples could include: building a relationship with the provider, leading to (the possibility of) eventual discounts; certain projects might have lighter or cheaper infrastructure requirements, needing less support. Learning curves and other user related issues (e.g. user commitment to support / resist a certain system) might also be seen as benefits.
• Existence of dependencies or synergies between projects: Certain projects might require the implementation of others to be successful or might have increased effectiveness when implemented in conjunction with other projects. These dependencies and synergies do not necessarily have to be between new projects, but could also arise between existing systems and new projects and could also work in a negative manner as well in the sense that a certain new project could result in diminished effectiveness of an existing system.
• Judgement by a central decision maker: When there is no way of distinguishing one project from another in terms of benefits in might come to the judgement of the person / committee responsible for approving projects. This responsibility could depend on the magnitude of the investment, in the sense that some projects could be decided on by middle management, whereas others might have to be decided on by the CIO or the board.
Aside from looking at different positions, the IP method allows the filling in of different scenarios for each investment proposal, the scenarios being: best-case outcome, expected outcome and worst-case outcome. For NPV (the size of the circles), this can be illustrated by adding overlapping circles in different colours or by a circle consisting of a dashed line. When comparing different projects for a prioritisation, two circles per project can be made: one representing the worst-case situation and one representing the expected outcome. As such, a spread can be seen, which can influence the decision for one or another project.
3.3.6 UWV
Factors specific to UWV will have to be identified in interviews with relevant stakeholders, but a provisional list of possible factors can be found below:
• Economic contribution: The use of NPV is suitable for UWV, as this is a generic methodology of financially scoring projects.
of the Dutch government, its policy being shaped by law. The factor ‘customer service’ is relevant due to UWV being a public organisation, its nature is to provide the best and fastest service to its customers possible. The two synergy categories might be important on the one hand because UWV is such a big organisation with different divisions and on the other because UWV needs to have close cooperation with other public institutions such as the Dutch “Belastingdienst” (the organisation in charge of taxes in Holland).
• Contribution to the IT domain: The factor ‘adherence to IT standards’ for UWV can be dubbed ‘adherence to the Reference Architecture’, as the RA is where UWV’s IT standards are recorded. ‘Acceptance by the market of the product’ and ‘continuity of the provider’ both seem adequate measures, as the first will provide for a degree of benchmarking and the second for some security on the support side.
3.3.7 Advantages
• Allows for a non-financial approach • Provides direction for prioritisation
• Considers both the business as the IT domain • Provides a good platform for discussion
• Provides a clear visualisation of the project portfolio
3.3.8 Possible improvements
• Not much suggestion for solution to un-decidable positions • Is only designed for the first two steps of the application life-cycle
3.3.9 Link with ALM
The investment portfolio is designed only for the first two steps of the application life-cycle (“identification” and “justification”).
3.4 Gartner
While Gartner has conducted research into application life-cycle management and related subjects, no real unique methodologies have been presented. An example of this is the ‘business application life cycle’ as presented by Zrimsek et al. (2003a), which is very similar to the ‘application life-cycle’ as presented by Berghout & Nijland (2002). For this reason, the following section provides an overview of a number of frameworks or methods presented in Gartner research which provide little more than criteria by which applications can be judged or classified.
3.4.1 Fitness for Duty
Figure 9. Application performance indicators. Source: Harris & McRory 2006.
3.4.2 Gartner Toolkit: Application Assessment
Weiss (2007) provides 14 criteria on which to assess applications, they are listed in the table below:
Figure 10. Gartner Toolkit: Application Assessment. Source: Weiss 2007.
3.4.3 Gartner ‘Workplace Application Classification Framework’
Austin (2005) believes “there are four key workplace application classes that every enterprise should integrate into its strategic thinking and planning methodology.” The following classes are distinguished:
1. Birthright Workplace Tools: Applications that are considered to be universally useful and are (or should be) deployed to everyone. Examples include email and word processing applications.
2. Specialist Workplace Tools: Applications that are not considered to be useful for everybody and as such deployed to specialists in a certain function. These tools are largely used “out-of-the-box”. A UWV specific example is an application like BiZZdesign Architect, which is used to model IS architectures, which is only used by employees in charge of IS architecture and not available to others.
3. Task-Specific Applications: Usually not off-the-shelf combinations of workplace capabilities with function-specific applications.
4. Special Targets: Applications tied to specific, sometimes short-term business goals. These are deployed at a higher level in part due to the often high per-user cost.
According to the framework, the higher-up an application is the higher the return (as measured by ROI in this framework) and the narrower the deployment breadth. It has to be noted that without the basics, it is difficult, if not impossible to achieve special targets, in which sense this framework can be seen as being incremental in nature.
3.5 The ISO 9126 model for Quality of software
Clearly, an important factor in determining whether or not to keep, improve or replace an application is its quality (whether it be functional or technical). This also becomes obvious when you look at such investment decision methods like the ones by Bedell (1985), Parker et al. (1988) or Berghout & Meertens (1992). As such this section outlines the current ISO standard for software quality (as set out in van Zeist et al. 1996), namely the ISO 9126 norm. Originally the norm consisted of six main attributes and 21 sub-attributes, but was later expanded to include a total of 32 sub-attributes and was dubbed ‘the extended ISO model’. For an overview of the original attributes, see Figure 11 below. The use of this standard is that it provides a number of metrics that together can be used to measure the quality of software in a standardised manner.
Figure 11. The original ISO 9126 attributes. Source: InSIGight July 2007.
