Navigating Software Procurement in an as-a-service Industry. A Practice Guide for ICT and Procurement Professionals

Navigating Software Procurement in an as-a-service Industry A Practice Guide for ICT and Procurement Professionals

Practice Guide CONTENTS INTRODUCTION...2 HOW TO USE THIS GUIDE...3 PART A: AN INVENTORY OF FEDERAL GOVERNMENT PROCUREMENT REQUIREMENTS... 4 THE EVOLUTION FROM BUILD TO SUBCRIBE...4 CHARTING THE SOFTWARE PROCUREMENT LANDSCAPE...6 THE FOUR PROCUREMENT PRINCIPLES...6 THE NINE PROCUREMENT PROCEDURES...7 THE PROCUREMENT LIFECYCLE S FOUR STAGES...7 THE SEVEN MOST CRITICAL DIRECTIVES...8 THE IMPACT OF AGIMO CIRCULAR NUMBER 2010/004...9 PART B: ESTABLISHING A UNIFIED APPROACH TO SOFTWARE PROCUREMENT... 11 ENSURING A SUCCESSFUL SOFTWARE PROCUREMENT JOURNEY... 11 CONCLUSION... 12 PART C: PRACTICAL TOOLS & CHECKLISTS... 13 APPLYING THE UNIFIED SOFTWARE PROCUREMENT FRAMEWORK... 13 IDENTIFYING ALL TYPES OF AVAILABLE SOFTWARE (PHASE 2 & 3)... 14 ENSURING ALIGNMENT OF PROCUREMENT STRATEGY WITH CPGS (PHASE 2)... 16 ENSURING COMPLIANCE WITH AGIMO ICT POLICIES (PHASE 3)... 17 REVIEW TENDER CLAUSES (PHASE 3)... 18 REVIEW NON-FUNCTIONAL REQUIREMENTS (PHASE 3)... 19 ASSESS SOFTWARE TYPE RISKS (PHASE 3)... 22 ABOUT THIS PRACTICE GUIDE... 25 BACKGROUND... 25 DISCLAIMER... 25 REFERENCES... 26 Business Aspect Pty Ltd; 588 Boundary Street, Brisbane QLD 4000; PO Box 641, Spring Hill QLD 4004 PH: 07 3831 7600, Fax: 07 3831 7900; www.businessaspect.com.au; ACN: 112 888 785

INTRODUCTION The last decade has seen a stark change not only in the way software solutions are delivered to public and private sector organisations alike, but also how such solutions are procured. Gone are the days of expending large amounts of capital to secure an expensive software licence for a centralised mainframe environment or build custom business applications. Today buyers can choose from a wide range of software procurement options ranging from traditional up front payments through to per user, per month models. In response to this increasing array of procurement choices, Australian government agencies, like their international counterparts, have been quick to formulate strategies and policies to address each emerging trend. Each new directive, whether it has been to address the shift away from bespoke developed software to pre-built packages or consideration of open source alternatives, provides additional insight for both senior ICT and procurement professionals alike. The Australian Government has been particularly responsive, issuing detailed procurement guidelines and supporting policies to manage the estimated $733 million per annum spend on software across agencies operating under the Financial Management and Accountability Act 1997. These policies include the ICT Customisation and Bespoke Development Policy and Open Source Software Policy administered by the Australian Government Information Management Office (AGIMO). Despite the presence of these policies, feedback from individual agencies indicates there is a need for a unified approach to software procurement. A unified approach would not only ensure a level playing field for industry, but would provide a clear and simple means by which agencies can achieve the objectives of current software procurement policies, both for traditional and emerging as-a-service solution options. This Practice Guide is intended to help Chief Information Officers, senior ICT professionals, procurement specialists and their equivalents to arrive at the right software procurement outcomes through a disciplined, well-structured approach that balances cost, value and risk amongst all available procurement options. Business Aspect - Software Procurement Practice Guide Page: 2

HOW TO USE THIS GUIDE The guide is composed of three distinct parts designed to lead users through steps of awareness, options and selection of various software procurement strategies. Part A An Inventory of Federal Procurement Requirements What you have to deal with: In this part of the guide we outline the 50 wholeof-government requirements which need to be considered by Australian Government Agencies on a regular basis during ICT decision making, including software procurement. What are they and which ones are critical? What do they mean for you and how do they relate to one another? Part B Establishing a Unified Approach to Software Procurement Pulling it all together: In this part we provide a simplified way to pull all the relevant requirements together in a unified framework that enables practitioners to work through the procurement process in a well-structured way that observes all the necessary procurement requirements. Part C Practical Tools & Checklists Things that will help you to achieve the best outcome: This part provides a set of useful questions, templates and model clauses that ICT managers and procurement professionals can use as insertions in tender documentation and as part of the overall procurement decision-making process. These are based on well accepted cost, value, risk assessment models that are product and technology agnostic. Business Aspect - Software Procurement Practice Guide Page: 3

PART A: An Inventory of Federal Government Procurement Requirements THE EVOLUTION FROM BUILD TO SUBCRIBE Since the first generation of closed-ict platforms was replaced by more open solutions, enduser organisations have been forced to balance the benefits of flexibility and market choice with the overhead of managing diversity. Whether the solution was hardware or software, organisations have sought to balance the benefits of customisation against the cost of increasingly commoditised offerings. In Australia this balancing act as it relates to software solutions now represents a market estimated at $5.8 billion (split between infrastructure software (30.6%), middleware and development tools (34.8%) and end-user applications (34.6%)) and expected to grow to $9 billion by 2015. 1 When considered from the end-user organisation perspective it is estimated that the average large enterprise will spend 27% of their software budget on custom software development; that is software languages, application servers, application architecture or testing issues. This compares to an average of 35% spent on packaged application software, and 37% spent on platform and infrastructure software. 2 For Australian organisations, in excess of 75% of the overall software portfolio remains tied to on-premise software. 3 This profile was reinforced across the agencies interviewed by Business Aspect; with the most common method of procurement being proprietary and custom developed (or bespoke) software (see Figure 1). How often does your organisation use different software procurement options? Base: Six (6) Australian Government Agencies Very often Often Occasionally Rarely SaaS Proprietary Open Source Custom/Bespoke Very rarely Never 0 1 2 3 4 Figure 1 - Software procurement models in Australian Government Agencies Source: Business Aspect Business Aspect - Software Procurement Practice Guide Page: 4

In light of such significant and diverse spending it is not surprising that most organisations adopt principles or guidelines intended to optimise their software expenditure by first leveraging existing solutions, typically followed by consideration of commercial-off the shelf (COTS) solutions (including both corporately produced and open source) before any decision to invest in a bespoke or custom built solution. This pattern is expressed more commonly in the simple statement form of: Share before Buy, Buy before Build 4 However, due to the emergence of cloud computing as an ICT sourcing and delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (including software), there is a need to move to a more inclusive investment principle of: Share before Rent, Rent before Buy, Buy before Build This more expansive statement adds the notion of as-a-service through the inclusion of the rent option. This terminology represents the key notion of subscription, metered or measured usage consumption models inherent in cloud services as defined by the US Government s National Institute of Standards and Technology (NIST) definition for cloud computing 5. Indeed, even in traditional on-premise licensing arrangements by major vendors, including IBM, Microsoft and Oracle, there is an increasing move to amortised and usage-based approaches. The notion of renting as the procurement model for Software as a Service (SaaS) is also highlighted in the AGIMO Cloud Computing Strategic Direction Paper: Opportunities and applicability for use by the Australian Government, Version 1.0 which defines SaaS as: Offers renting application functionality from a service provider rather than buying, installing and running software yourself. The importance of considering as-a-service models as part of any modern software procurement cannot be under stated. SaaS has emerged as a viable delivery model for meeting the needs of enterprise IT services. A fact evidenced by the strong growth in global SaaS revenue which is forecast to rise from $US12.1 billion in 2011 to $US16 billion by 2013 and reach $US21.3 billion by 2015 6. In addition, SaaS will remain the most mature and largest model in cloud computing. SaaS offers advantages over traditional software implementations of faster return on investment, accelerated deployments, greater focus on core competencies and greater flexibility and scalability. At the same time initial concerns about security, response time and service availability have diminished for many organisations as SaaS business and computing models have matured and adoption has become more widespread 7. Faced with this newest, and potentially economically appealing, means of software procurement, Australian Government ICT and procurement professionals should ensure they fully understand how SaaS fits within existing software purchasing policies and guidelines. Without proper and balanced application of the foundation principles of the Commonwealth Procurement Guidelines and domain specific considerations of AGIMO s ICT Investment Business Aspect - Software Procurement Practice Guide Page: 5

policies, agencies may fail to achieve the primary objective of all Australian Government procurement which is ensuring value for money. CHARTING THE SOFTWARE PROCUREMENT LANDSCAPE Australian government business operations, like those of their private sector counterparts, are highly dependent upon Information and Communications Technology (ICT) for which software represents a significant component. Indeed, based on an estimated $4.3 billion per annum spent on ICT by Australian Government agencies, operating under the Financial Management and Accountability Act 1997 (FMA) 8 17% or $733 million per annum relates directly to software 9. When considered in terms of replacement value, existing software represents a core infrastructure investment of nearly $3 billion 10. It is this significant spend that has seen the value for money achieved from Government investment in software come under intense scrutiny by lead agencies including the Australian National Audit Office (ANAO), the Australian Government Information Management Office (AGIMO) and the Department of Finance & Deregulation. Recent examples of this scrutiny include: Failure by Austrade to include the clauses stating that Austrade would consider open source software; 11 Revision of a planned tender by the Department of Immigration and Citizenship (DIAC) for web development and hosting that appeared to favour open source over other models; 12 and The need for all agencies to pay close attention to different software asset risks and whole of life costs as identified by ANAO during a review of the Australian Bureau of Statistics, Civil Aviation Safety Authority and IP Australia. 13 The Four Procurement Principles As a result agencies wishing to procure software, irrespective of the type of software, must adhere to the Commonwealth Procurement Guidelines with particular emphasis on the following procurement broad principles: Australian Government Procurement Principles 1. Value for Money 2. Encourage Competition, including Non-discrimination & Competitive Procurement Processes 3. Efficient, Effective and Ethical Use of Resources, including Efficiency and Effectiveness & Ethics 4. Accountability and Transparency These principles are then to be applied by agencies to the overall Australian Government procurement process, with a risk-based approach based on consultation with central agencies to identify applicable policy guidance (see Figure 2). Business Aspect - Software Procurement Practice Guide Page: 6

The nine procurement procedures Figure 2 - Commonwealth Procurement Process Source: Commonwealth Procurement Guidelines Within the Commonwealth procurement process the following Mandatory Procurement Procedures need to be adhered to for procurements with a total cost of over $80,000: Australian Government Procurement Procedures 1. Procurement Thresholds 2. Valuing Procurement 3. Approaching the Market, including Open Tendering, Multi-Use Lists, Select Tendering, Direct Sourcing, Panels and Cooperative Agency Procurement 4. Request Documentation 5. Conditions for Participation 6. Minimum Time Limits 7. Receipt and Opening of Submissions 8. Awarding of Contracts 9. Notification of Decisions The procurement lifecycle s four stages In the context of the principles, process and procedures that make up the Commonwealth Procurement Guideline, AGIMO has identified four phases of an overall ICT Sourcing Lifecycle. Within this cycle, agencies need to not only apply the overarching Commonwealth Business Aspect - Software Procurement Practice Guide Page: 7

Procurement Guideline, but ICT specific policies and guidelines during a typical ICT project (see Figure 3). Case for Change Transition & Manage Four Phases of ICT Sourcing Lifecycle Procurement Sourcing Strategy CPG - Core Principles 1. Value for Money Enhanced by encouraging competition Promoting efficient, effective and ethical use Making decisions accountable and transparent 2. Non Discrimination All suppliers should have the same opportunity to compete 3. Efficient and Effective An efficient and effective procurement process incorporates rigorous risk management, enabling issues to be identified early in the process 4. Accountable & Transparent Process is open and sound Decisions justified and defensible CPG - Mandatory Procurement Procedures (Division 2) 1. Apply to all purchases over $80,000 including GST 2. Requires an open approach to market 3. Comprehensive request documentation (Para. 8.42) 4. Stipulate specifications describe features required & not prescribe any conformity assessment procedure 5. Conditions of participation limited to legal, commercial, technical and financial abilities to fulfil the requirements 6. Invitations to be open for a minimum of 25 days Source: Business Aspect based on AGIMO s ICT Sourcing Lifecycle and Commonwealth Procurement Guidelines Figure 3 - ICT Sourcing Lifecycle Phases mapped to Commonwealth Procurement Principles and Procedures The seven most critical directives Today there are 50 whole-of-government ICT directives, policies and guidelines issued by AGIMO which need to be considered by Australian Government Agencies on a regular basis. Almost half of these are required to be considered as part of any ICT procurement, and within this group seven (7) were viewed as being crucial to software procurement during the ICT Sourcing Lifecycle during Business Aspect s interviews of government agencies (see Figure 4). Business Aspect - Software Procurement Practice Guide Page: 8

Source: Business Aspect based on AGIMO ICT Policies and Guidelines Figure 4 - Core Australian Government ICT Sourcing Policies relating to software These ICT policies and guidelines have evolved over time to address the changing needs of the market, including the maturity of COTS solutions, adoption of open source practices by many vendors and more recently the emergence of SaaS as previously discussed. The impact of AGIMO Circular Number 2010/004 However, it is important to note that within the publication of the revised Australian Government Open Source Policy in 2011 (replacing the earlier 2005 policy) AGIMO has evolved a key principle in relation to the procurement of software by agencies. Specifically, the shift from a position of informed neutrality, one that did not favour open source or proprietary software, to one which requires that agencies give appropriate consideration to all available models of software, including alternative models such as SaaS (see Figure 5). Business Aspect - Software Procurement Practice Guide Page: 9

Source: Business Aspect based on AGIMO ICT Policies and Guidelines Figure 5 - Evolution of Australian Government stance on software procurement models This requirement for agencies to give appropriate consideration to all available models of software, in effect, increases the discipline with which agencies are expected to apply the Commonwealth Procurement Guidelines and principles of value for money and nondiscrimination. It no longer allows them to default to an existing procurement model dominated by on-premise licensed software. Further, the new policy not only requires Australian Government agencies to actively and fairly consider all types of available software through their ICT procurement processes, but also requires suppliers to consider all types of available software (including but not limited to open source software and proprietary software) when responding to agencies procurement requests. Indeed, suppliers are directed to provide justification outlining their consideration and/or exclusion of open source software in their response to Australian Government tenders. This latest position therefore allows suppliers the scope to offer a range of alternatives that can be considered in accordance with the Open Source Software Policy Principle 1 - Australian Government ICT procurement processes must actively and fairly consider all types of available software. In the context of AGIMO policies and the broader international trends, if agencies are going to meet these high standards of industry engagement they need to be cognisant not only of traditional but also emerging and alternative software procurement options. It is exactly the emerging trend towards cloud computing that has seen AGIMO publish new guidance in relation to cloud computing in the form of the Negotiating the cloud legal issues in cloud computing agreements and Financial Considerations for Government use of Cloud Computing 14. Business Aspect - Software Procurement Practice Guide Page: 10

Part B: Establishing a Unified Approach to Software Procurement ENSURING A SUCCESSFUL SOFTWARE PROCUREMENT JOURNEY Business Aspect identified, through the review of existing Australian Government and international jurisdiction documentation along with interviews with six (6) individual Government agencies, that despite the desire for increased rigour or discipline in seeking out solutions beyond the status quo, agencies struggle with where to begin. When these same agencies were asked what they felt was a simple means of addressing the challenges of software procurement in an increasingly as-a-service industry, the majority agreed that a framework which pulled together the individual pieces of the Australian Government policy landscape would be of practical benefit. It is with this need in mind that Business Aspect has developed a Unified Software Procurement Framework aligned to the AGIMO ICT Sourcing Lifecycle. The Framework is made up of three perspectives supported by two dimensions. Each of these dimensions contains tools, such as consolidated definitions of available software types and check-lists that agencies can employ to assist them to meet their obligations when navigating the sometimes treacherous waters of software procurement. Figure 6 - The Unified Software Procurement Framework Source: Business Aspect The objective of the definitions, processes and checklists is to provide an actionable framework for use by ICT and procurement professionals. For example, tender specifications need to be written around features required and not prescribe a particular software model. By providing checklists that prompt agencies to question various aspect of a tender, the framework assists them in ensuring that their tender will permit vendors to offer a range of Business Aspect - Software Procurement Practice Guide Page: 11

alternatives in accordance with the principle of actively and fairly consider all types of available software. Attachment 1 of this Practice Guide contains the following tools aligned with the perspectives and dimensions of the Unified Software Procurement Framework and the ICT Sourcing Lifecycle: Perspective Dimensions Tool Lifecycle Phase Market Identification & Engagement Definitions to assist in identifying all types of available software. Whole-of- Alignment & Checklist for ensuring alignment of Government Compliance procurement strategy with CPGs Whole-of- Alignment & Checklist for ensuring procurement Government Compliance compliance with AGIMO ICT policies. Agency Review & Assessment Checklist for ensuring completeness of tender non-functional requirements Agency Review & Assessment Tender clauses to ensure invitations are inclusive of all software types. Agency Review & Assessment High level risk assessment for various software types. Phase 2 Phase 2 Phase 3 Phase 3 Phase 3 Phase 3 Applying the Unified Software Procurement Framework is as simple as: 1. Sharing the definitions of the various software types with any business or ICT personnel embarking on an software procurement effort; 2. Applying the checklists during the procurement process, in particular during development of the Request for Tender (RFT); and 3. Undertaking the risk assessment during tender evaluation to ensure the agency is fully informed about the link between a given solution, its risk and financial profiles. CONCLUSION Navigating Software Procurement in an as a Service industry is complex and with the rapid pace of change in technologies, Australian government agencies need to consider all alternatives to ensure that they are obtaining the best available business solution and optimising their ICT spending. Although it would appear traditional software models will remain dominant for the foreseeable future, new generations of existing licensed software, open source solutions and the emerging SaaS offerings will change agency procurement patterns. This will result in a need to adjust resourcing and funding arrangements in recognition of greater emphasis on legal and contractual arrangements, while at the same time technical skills mix will move to higher value roles and operational expenditure rather than large upfront capital purchases. As illustrated throughout this guideline each software procurement model offers distinct business and technological advantages and agencies need to consider their options carefully. The Unified Software Procurement Framework, and its supporting tools which follow, have been designed to assist agencies to identify the key issues and risks associated with the main software procurement models in the Australian marketplace. Business Aspect - Software Procurement Practice Guide Page: 12

Part C: Practical Tools & Checklists APPLYING THE UNIFIED SOFTWARE PROCUREMENT FRAMEWORK The Unified Software Procurement Framework is intended to provide additional support beyond current policies for Australian Government agencies in the context of the AGIMO ICT Sourcing Lifecycle. This additional guidance is based on better practices identified by Business Aspect during previous client engagements combined with the specific findings of consultation with agencies and industry. It is intended that agencies would apply the framework s supporting definitions, checklists and assessments through Phase 2 Sourcing Strategy and Phase 3 Procurement of the ICT Sourcing Lifecycle as shown in below. Business Aspect - Software Procurement Practice Guide Page: 13

IDENTIFYING ALL TYPES OF AVAILABLE SOFTWARE (PHASE 2 & 3) The typical options available in the Australian marketplace today to acquire business software can be summarised as follows: Implement an on-premise solution by: o Undertaking custom or bespoke development o Licensing proprietary software o Adopting open source software Utilise an Application Service Provider (ASP) or Outsourcer Subscribe to a Software as a Service (SaaS) Faced with an increasing breadth of software procurement choice organisations must first ensure they understand what options are available. In addition, Australian Government agencies wishing to comply with the AGIMO requirement to actively and fairly consider all types of available software face the difficult challenge of ensuring their Request For Tender (RFT) and other associated documentation is clear about the definitions of the types of software that are being considered. Through secondary research, interviews with government agencies and software vendors, these options can be distilled down to a set of four (4) main software procurement models operating in the Australian public and private sector software market with several minor models also in play. The main-stream software procurement models are: 1. Custom/Bespoke Software 2. Proprietary Software 3. Open Source Software 4. Software as a Service In addition to the four main-stream software procurement models the following models can also be found in niche markets: 5. Application Sharing (between Agencies both Commonwealth and State) 15 6. Application Service Provision 16 7. Shareware 8. Freeware Each of the four main software procurement models are defined below based on existing AGIMO policies augmented by secondary sources and Business Aspect s market knowledge: Software Procurement Model Definition Custom/Bespoke Software Custom or bespoke software solutions are those developed by a government agency (in-house), or a commercial entity at the agency s direction, with the intention of implementation in only one agency. i.e. To satisfy a very specific set of unique business requirements. These solutions include solution components, interfaces, and modules (i.e. hardware, software, technology, or computer products). Business Aspect - Software Procurement Practice Guide Page: 14

Software Procurement Model Definition Proprietary Software Open Source Software Software-as-a-Service Proprietary software solutions are those where the original development has usually been undertaken by a commercial organisation, and which may be acquired for installation as is. In this way proprietary software is typically licensed from established software vendors under a pre-determined set of usage conditions. These conditions dictate how the software will be used either by an individual or within an organisation. Licensing arrangements are often based on per seat, whole of enterprise/volume, concurrent usage or number of processors running the software. Open-source software (OSS) solutions are those where the intent of the producer (an individual or organisation) is available in source code form. The source code is made available with rights normally reserved for copyright holders and provided under a software license that permits users to study, change, improve and at times also to distribute the software with varying degrees of permissiveness depending on the particular OSS license adopted. Software-as-a-Service are software solutions which can be rented from commercial organisations and delivered to various client devices through either a thin client interface, such as a browser, or a program interface, such as a smart phone applications. SaaS removes the need for consumers to purchase, handle the installation, set-up and often daily upkeep and maintenance of software. However, in many cases consumers are provided with user-specific application configuration settings. It is highly recommended that agencies include a copy of the above definitions for proprietary software, open source software and SaaS in all RFTs to ensure that responding vendors have a clear view as to what types of available software are being considered. Custom/bespoke software should not be sought from the market, in the case of Australian (Commonwealth) Government Agencies without approval as per the ICT Customisation and Bespoke Development Policy. Business Aspect - Software Procurement Practice Guide Page: 15

ENSURING ALIGNMENT OF PROCUREMENT STRATEGY WITH CPGs (PHASE 2) Does your procurement approach/strategy: 1. Foster value for money by encouraging Need to Procure Software competition? / No 2. Promote efficient, effective and ethical use of Procurement Strategy/Approach software capabilities? / No 3. Allow you to make decisions which are Does Procurement Strategy encourage competition? No accountable and transparent? / No 4. Discriminate against a particular software model or vendor? Promote efficient, effective & ethical use of software No / No 5. Allow all suppliers the same opportunity to compete? Accountable & transparent No / No 6. Incorporate a rigorous risk management approach, enabling issues to be identified early in the process? / No Does not discriminate against particular vendor or software model No Seek advice from AGIMO or the Procurement Division of the Department of Finance & Degreulation NB: Refer to Assess Software Type Risk below. 7. Demonstrate the process is open and sound? All vendors opportunity to compete No / No 8. Allow decisions to be justified and defensible? Incorporates rigorous risk assessmrent No / No If you have answered No to any of these questions, it is recommended that you seek guidance from the Procurement Division of the Department of Finance & Deregulation. Process open & sound No Allows decisions to be justified & defensible No Business Aspect - Software Procurement Practice Guide Page: 16

ENSURING COMPLIANCE WITH AGIMO ICT POLICIES (PHASE 3) If you have answered to the core Commonwealth Procurement Principles as outlined above, you can proceed with the software procurement by addressing the following mandatory procurement procedures that apply to all purchases over $80,000 including GST. For each procedure Business Aspect has identified either an existing AGIMO ICT policy or guideline that needs to be considered or provided links to additional tools within the framework that can be used. Procedure Required Action 1. Requires an open approach to market A public invitation issued via AusTender or other equivalent such as public print media. NB: The above applies unless a direct procurement is applicable. 2. Comprehensive request documentation (see para 8.42) A comprehensive RFT for the software acquisition is prepared and released inviting all software vendors to respond, if their products can satisfy the requirements. The RFT documentation should comply with Open Source Policy (AGIMO Circular 2010/004) and the incorporate the suggested clauses provided below. 3. Stipulate specifications that describe the features required and not prescribe any conformity assessment procedure 4. Conditions of participation limited to legal, commercial, technical and financial abilities to fulfil the requirements (see para 8.54) 5. Invitations to be open for a minimum of 25 days Specification written around required features and does not prescribe a particular software model. This will allow vendors to offer a range of alternative software models that can be considered by agencies in line with the Open Source Software Policy Principles. Conduct a review of the RFT s non-functional requirements to determine any capabilities that should be specified as being required using the Non-Functional Requirements Checklist provided below. Ensure invitations are open for a minimum of 25 working days. Business Aspect - Software Procurement Practice Guide Page: 17

REVIEW TENDER CLAUSES (PHASE 3) The emergence of SaaS means that a software procurement request may now involve both potential products (or goods) in the case of either a proprietary or open source licence AND a pure service in the case of a SaaS offering. Although often a software procurement involving proprietary or open source software would incorporate maintenance services, the pure services nature of SaaS makes it more akin to an outsourcing arrangement than a product purchase. To address the dichotomy which SaaS introduces into the software procurement landscape, Business Aspect proposes that agencies adopt the following clauses which address the principle of ensuring all available software types. These clauses are an expansion of the original samples provided by AGIMO in the Open Source Software Policy, adjusted to take account of the emergence of SaaS. Sample clause for inclusion in procurement plan/procurement documentation: [Agency Name] will actively and fairly consider all types of available software for ICT software procurements. Open source software and software-as-a-service will be considered equally alongside proprietary software. Sample clause for inclusion in RFQ/Select Tender Checklists: Have you considered all types of available software (including but not limited to software-as-a-service, open source software and proprietary software)? Sample clause for inclusion in RFTs for covered procurements: [Agency Name] encourages suppliers to submit and/or develop open source software for this tender. When responding to this tender, suppliers must demonstrate a willingness to actively consider open source software throughout all stages of procurement, solution design and implementation in order to produce a product that demonstrates value for money and is fit for purpose. This may include incorporating open source software components together with proprietary software components. In evaluating the tender, [Agency Name] will consider open source software and software-as-a-service equally alongside proprietary software. Sample clause for inclusion in RFTs in relation to pricing for covered procurements: When responding to this tender, suppliers must provide sufficient price information to enable [Agency Name] to develop an accurate view of the whole-of-life costs of the offer in accordance with the Australian Government s ICT Two Pass Review Process. When responding to this tender, supplies must include the transparent identification of all likely costs associated with licence acquisition, implementation (covering set-up fees, data migration costs etc) and ongoing costs (covering subscriptions, maintenance fees and support charges). Suppliers should also include estimates in relation to the expected personnel load on [Agency Name]. Sample clause for inclusion in RFT Assessment Checklist: Has the supplier sufficiently demonstrated that they have considered all types of available software (including but not limited to software-as-a-service, open source and proprietary software)? Business Aspect - Software Procurement Practice Guide Page: 18

REVIEW NON-FUNCTIONAL REQUIREMENTS (PHASE 3) In addition to the mandatory legal, contractual and financial requirements, agencies should give consideration to the following key non-functional requirements as they relate to the procurement of software during development of their RFT documentation. It is crucial that questions relating to an agency s position on key requirements, such as treatment of intellectual property or data locale, be determined prior to issuing an RFT. If comprehensive analysis of non-functional requirements is not completed then potential suppliers will not be in receipt of all constraints on the potential solutions they may wish to offer. Requirement Considerations Application Design Architecture Business Continuity Contract Period Data Locale Funding Model Intellectual Property Legal & Regulatory Compliance Degree of customisation required? Complexity integrating with existing environments and business processes? Degree future proofing being sought? E.g. Can the solution be deployed in a both on-premise and cloud environments? Does the offering meet the Australian Government Architectural Framework (AGA)? Are there particular business process or information handling needs? Who will be managing disaster recovery capabilities? How is continuity maintained? What business continuity plans are available from the vendors? E.g. What plans do vendors have in place for software development? Ongoing service provision? How long is the contract being undertaken for? What is the likely lifecycle of the solution given marketplace evolution and trends? Physical location of data stores, access arrangements, back-up and recovery in event of service failure? Is the data stored in Australia and can it be readily accessed and retrieved? What type of funding is available to support the contract? i.e. Capital versus operational expenditure. Is there a transfer of rights, patents or other ownership considerations? Does existing agency intellectual property need to be protected? Is this an opportunity to make agency intellectual property available? Does solution comply with Australian legislative and regulatory requirements, including Privacy Act, FOI Act, and Archives Act? Business Aspect - Software Procurement Practice Guide Page: 19

Requirement Considerations Manageability Performance & Conformance Privacy Reputation Scalability Security Service Provision Skills Requirements Standards Support and Maintenance Transferability Vendor Capability Does the software require specialist resources and infrastructure to operate? Can it be managed remotely? Can it be managed by a third party management tool? How easy it is to manage the software within the context & resource constraints of your organisation? What service levels are expected? How will these be measured, monitored and reported What are the service recovery levels? Are there expectations of financial restitution and damages? Is there a risk of compromise to confidential information or personal information? Does the software solution comply with the Information Privacy Principles (IPP s) and the Privacy Act 1988? Is there potential for the agency s reputation to be damaged as a result of a service failure, breach of security or privacy? Can it be scaled? i.e. Can the solution grow to meet the agency needs? What are the increments for growth, both technically and financially? E.g. Small and marginal or large and stepped increases? Do the offerings satisfy Protective Security Policy Framework, the Australian Government Information Security Manual (ISM) and Privacy Act 1988? Reputation, history and sustainability of the vendor? Portability of the application and data in case of a vendor failure? Can the software be supported by the current resource levels? Are new skills required to manage, operate, support and maintain? Does the offer minimise the chance of vendor lock-in? Are there any standards for interoperability or data portability that need to be specified? Are there prescribed platforms within the agency that need to be considered? Are external maintenance and support services available? Are there the necessary skills available to support the solution internally? E.g. Level 1 support teams? Are the licenses transferable under machinery of government changes? What about the application and data? Local capability/skilled resources available? Capacity to service and meet obligations? Business Aspect - Software Procurement Practice Guide Page: 20

Requirement Considerations Whole of Life Costs Have you have considered and included the cost associated with planning, design, construction and acquisition, operations, maintenance, renewal and rehabilitation, depreciation, cost of finance and replacement or disposal as well as environmental and social costs if applicable. Is the pricing information requested of the vendor sufficient to complete the worksheets required as part of the ICT 2 Pass Review? Business Aspect - Software Procurement Practice Guide Page: 21

ASSESS SOFTWARE TYPE RISKS (PHASE 3) The formalised management of risks during procurement is a key aspect of the Commonwealth Procurement Guidelines. Therefore agency procurement must incorporate a rigorous risk management approach, enabling issues to be identified early in the purchasing lifecycle. Like any form of procurement, each of the major software procurement models identified and discussed within this Practice Guide present different risk profiles across legal, financial and functional areas. Therefore, when presented with an RFT response containing a particular software procurement model, agencies will need to have: 1. Assessed the risk tolerance for each major risk factor in relation to the major software procurement types; 2. Determined what, if any, mitigation strategies or treatments the agency is intending to take in relation to the risks it is not willing to tolerate; and 3. Understood the cost of any mitigation strategy so that these can be taken into account during the final determination of value for money. The following table provides a high level guide to the implications of different software models across a set of factors arising from various non-functional requirements. Requirement Agency Reputation Software Types Custom Proprietary Open Source Software-as-a- Service Under your Under your Under your Under service providers Business Continuity Under your Under your Under your Under service providers Data Security Under your Under your Under your Provided by data escrow arrangements. Data Sovereignty Total Total Total May be limited as service provider has control of execution or compute platform. Development Roadmap Under your Under vendor s Under communities Under service provider s Funding Requirement Up front for project, then ongoing internal support staff or support and maintenance costs to a vendor. Up front for licence, then ongoing maintenance and support. Ongoing internal support staff or support and maintenance costs to a vendor. Ongoing fees to the service provider. Business Aspect - Software Procurement Practice Guide Page: 22

Requirement Intellectual Property Software Types Custom Proprietary Open Source Software-as-a- Service Agency owns, but Vendor owns. Community owns. Service provider may be shared owns. with developer(s) depending on the contractual arrangements. A potential risk is liability for an intellectual property infringement due to the number of contributors and the fact that they do not need to give any assurances about their contribution. A potential risk is the inability to run the software if the service provider becomes insolvent or ceases to trade. Intended Use Designed and developed for specific application. Designed to be used as-is, but deployed into the agency s preferred environment. Customisation is intended to be avoided in favour of configuration. As is or modified similar to custom or bespoke development. As is or with predefined configurations only. Interoperability Degree of interoperability dependent on design and standards employed. Dependent on standards employed by vendor and/or achieved through local customisation. Dependent on standards employed by community and/or achieved through local customisation. Dependent on the interfaces offered by the service provider. License Type Exclusive. Restrictive. General Public License (GNU) with or without restrictions. Subscription. No actual licence is provided. Instead this is covered by a contract or terms of services / usage. Outage Management Your responsibility. Your responsibility. Your responsibility. Service provider responsibility. Security Under your Considered as part of the design and development. Vendor provides some assurance there are no security vulnerabilities or when discovered they will be corrected. As it is community developed there are no assurances as to whether there are any security vulnerabilities. Vendor provides some assurance there are no security vulnerabilities or when discovered they will be corrected. Business Aspect - Software Procurement Practice Guide Page: 23

Requirement Service Level Agreements (SLAs) Software Types Custom Proprietary Open Source Software-as-a- Service Nil or defined by the agency. Depending on level of support purchased from vendor. Open source licenses do not contain the kinds of representations and warranties of quality or fitness for a particular purpose that commercial software vendors sometimes incorporate into agreements. High level SLA s typically provided but this area is evolving and specific SLA s can be negotiated with vendors. Support and Maintenance Typically provided by internal resources. Provided by vendor. Partly provided by community, mainly provided by internal resources or contracted third parties. Provided by the service provider. Upgrade Cycles Under your Under your control, but influenced by the vendor development roadmap and support options. Under your control, but influenced by the communities development roadmap. Under control of the service provider. Vendor Support. Contract Typically negotiated as part of the development contract. Medium to long term. Usually purchased as an adjunct to the software license. Typically a % of the total license cost. Medium to long term. Nil. Support arrangements need to be made separately with third party who offers support services. Medium to long term. Application support not required. User support usually included as part of service provision. Short to medium term. Business Aspect - Software Procurement Practice Guide Page: 24

About this Practice Guide BACKGROUND This practice guide was commissioned to aid senior IT and Procurement Managers of government agencies understand the evolving software market and how future software purchases can be optimised. Microsoft funded Business Aspect, an Australian business and technology consultancy company, to prepare an independent framework and practice guide in consultation with a range of Australian Federal and State government agencies. Business Aspect s investigation involved primary data collection, analysis of various secondary research sources, and interviews with technology and procurement executives and service providers including Microsoft. Business Aspect would like to acknowledge and thank the following organisations who participated in the consultation: Australian Government Attorney-General's Department Australian Government Treasury Department Australian Transport Safety Bureau (ATSB) Commonwealth Scientific and Industrial Research Organisation (CSIRO) Fujitsu Australia Microsoft Australia Queensland Department of Education and Training Queensland Government Chief Technology Office Red Hat Asia Pacific DISCLAIMER The information in this document is being provided on an as-is basis. It is intended to provide general information only and has been prepared by Business Aspect Pty Ltd without taking into account any particular organisation s objectives, financial situation or specific ICT needs. Readers should, before acting on this information, consider the appropriateness of the information having regard to their particular organisational circumstances. Business Aspect recommends readers obtain advice specific to their situation before making any ICT investment decision. Business Aspect Pty Ltd, its directors and employees do not give any warranty or make any representation, express or implied, at law or in equity, with respect to this information or its characteristics, quality or value, including without limitation the implied warranties of merchantability or fitness for a particular purpose. To the fullest extent permitted by law, all representations and warranties expressed or implied by law are expressly disclaimed. Business Aspect warrants that it has used commercially reasonable care in preparing this information which represents Business Aspect s best collective judgment at the time. The opinions, predictions and forecasts contains in this document are subject to change without notice in response to evolving market conditions. Business Aspect - Software Procurement Practice Guide Page: 25

REFERENCES 1 Griffith, Chris (June, 2011), Software boom ahead for local market. See http://www.theaustralian.com.au/australianit/software-boom-ahead-for-local-market/story-e6frgakx-1226070446084 2 Hammond Jeffrey (January, 2010), Forrester DataByte: Spending On Custom Software in 2010. See: http://blogs.forrester.com/application_development/2010/01/forrester-databyte-spending-on-custom-software-in-2010.html 3 ARN Staff Writers (April 2010), Statistics: Analyst outlook on business software: Gartner takes readers through software spending. See http://www.arnnet.com.au/article/349965/statistics_analyst_outlook_business_software/ 4 This type of ICT investment principle is actively applied by various public and private sector organisations, including the Queensland and West Australian Government. See respectively: http://www.qgcio.qld.gov.au/sitecollectiondocuments/architecture%20and%20standards/qgea%202.0/qgea%20foundation %20Principles.pdf and http://www.publicsector.wa.gov.au/sitecollectiondocuments/ictbusinesscasecriticalfactorschecklistfinal28.10.08.pdf 5 The complete NIST definition can be found http://www.nist.gov/itl/cloud/index.cfm 6 Gartner (July 2011), Gartner Says Worldwide Software as a Service Revenue Is Forecast to Grow 21 Percent in 2011. See http://www.gartner.com/it/page.jsp?id=1739214 7 See Note 6 above. 8 Estimate based on the Review of the Australian Government s use of Information and Communication Technology, August 2008. 9 Expenditure levels exclude internal wages and salaries associated with software, and represent only the direct operating expenses associated with software or capital expenditure for acquisition of software calculated in accordance with the results of the Australian Bureau of Statistics report entitled 8119.0 - Government Technology, Australia, 2002-03. 10 Department of Finance and Deregulation Consolidated Financial Statements For the Year Ended 30 June 2009, Note 21, Page 92. See http://www.finance.gov.au/publications/commonwealthconsolidated-financial-statements/2009.html 11 Hilvert, John (July, 2011), Canberra s open source policy stumbles on compliance. See http://www.itnews.com.au/news/262972,canberras-open-source-policy-stumbles-on-compliance.aspx 12 Tay, Liz (October, 2011), Department of Immigration revises open source tender. See http://www.itnews.com.au/news/277114,department-of-immigration-revises-open-source-tender.aspx 13 The Auditor General, Audit Report No.14 2010-11 Performance Audit Capitalisation of Software. See http://anao.gov.au/publications/audit-reports/2010-2011/capitalisation-of-software 14 These Better Practice Guides were draft when accessed as at November 2011. Readers are advised to check for the final versions when applying the Unified Software Procurement Framework. 15 Also commonly referred to as Shared Services. 16 Application Service Providers (ASP s) provided businesses with the service of hosting and managing specialized business applications, with the goal of reducing cost by central administration and through the solution provider's specialization in a particular business application. Software as a Service is often considered an extension of the idea of the ASP model, but differs significantly through features such as shared runtime code and cloud-based computing infrastructure. Business Aspect - Software Procurement Practice Guide Page: 26