Navigating Software Procurement in An "As-A-Service" Industry

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 whole-
of-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.

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, end-
user 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
SaaS
Occasionally
Proprietary
Open Source
Rarely
Custom/Bespoke
Very rarely
Never
0 1 2 3 4
Source: Business Aspect
Figure 1 - Software procurement models in Australian Government Agencies

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 Build4
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
computing5. 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 20156.
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 widespread7.
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

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 software9. When considered in terms of replacement value, existing software
represents a core infrastructure investment of nearly $3 billion10.
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).

Source: Commonwealth Procurement Guidelines
Figure 2 - Commonwealth Procurement Process
The nine procurement procedures

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

Procurement Guideline, but ICT specific policies and guidelines during a typical ICT project
(see Figure 3).
Case for Change
CPG - Core Principles

1. Value for Money
 Enhanced by “encouraging competition”
 Promoting efficient, effective and ethical use
 Making decisions accountable and transparent
Transition & Manage Four Phases of Sourcing Strategy 2. Non Discrimination
ICT Sourcing Lifecycle  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
Procurement
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).

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).

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 non-
discrimination. 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 Computing14.

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.
Source: Business Aspect
Figure 6 - The Unified Software Procurement Framework
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

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 & Definitions to assist in identifying “all Phase 2
Engagement types” of available software.
Whole-of- Alignment & Checklist for ensuring alignment of Phase 2
Government Compliance procurement strategy with CPGs
Whole-of- Alignment & Checklist for ensuring procurement Phase 3
Government Compliance compliance with AGIMO ICT policies.
Agency Review & Assessment Checklist for ensuring completeness of Phase 3
tender non-functional requirements
Agency Review & Assessment Tender clauses to ensure invitations Phase 3
are inclusive of all software types.
Agency Review & Assessment High level risk assessment for various Phase 3
software types.
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.

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.

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 Provision16
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).

Software Procurement Model Definition
Proprietary Software 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 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 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.

ENSURING ALIGNMENT OF PROCUREMENT STRATEGY WITH CPGs
(PHASE 2)
Does your procurement approach/strategy:

Need to Procure
1. Foster value for money by encouraging Software
competition?
Yes / No Procurement
Strategy/Approach
2. Promote efficient, effective and ethical use of

software capabilities?
Yes / No Does Procurement
Strategy encourage No
competition?
3. Allow you to make decisions which are
accountable and transparent? Yes
Yes / No
Promote efficient,
4. Discriminate against a particular software effective & ethical use No
of software
model or vendor?
Yes
Yes / No
5. Allow all suppliers the same opportunity to Accountable &
No
transparent
compete?
Yes / No Yes
Seek advice from
6. Incorporate a rigorous risk management AGIMO or the
Does not Procurement
discriminate against No Division of the
approach, enabling issues to be identified particular vendor or
Department of
software model
Finance &
early in the process? Degreulation
Yes
Yes / No
NB: Refer to Assess Software Type Risk below. All vendors
opportunity to No
compete
7. Demonstrate the process is open and sound?
Yes / No Yes
8. Allow decisions to be justified and

Incorporates rigorous
No
risk assessmrent
defensible?
Yes / No Yes
If you have answered “No” to any of these

questions, it is recommended that you seek Process open & sound No
guidance from the Procurement Division of the
Department of Finance & Deregulation.
Yes
Allows decisions
to be justified & No
defensible

ENSURING COMPLIANCE WITH AGIMO ICT POLICIES (PHASE 3)
If you have answered “Yes” 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 A public invitation issued via AusTender or other

market equivalent such as public print media.
NB: The above applies unless a direct procurement is

applicable.
2. Comprehensive request A comprehensive RFT for the software acquisition is

documentation (see para 8.42) 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 Specification written around required features and does
describe the features required and not prescribe a particular software model.
not prescribe any conformity
assessment procedure 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.
4. Conditions of participation limited Conduct a review of the RFT’s non-functional

to legal, commercial, technical and requirements to determine any capabilities that should be
financial abilities to fulfil the specified as being required using the Non-Functional
requirements (see para 8.54) Requirements Checklist provided below.
5. Invitations to be open for a Ensure invitations are open for a minimum of 25 working
minimum of 25 days days.

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)?

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  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?
Architecture  Does the offering meet the Australian Government Architectural

Framework (AGA)?
 Are there particular business process or information handling
needs?
Business Continuity  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?
Contract Period  How long is the contract being undertaken for?

 What is the likely lifecycle of the solution given marketplace
evolution and trends?
Data Locale  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?
Funding Model  What type of funding is available to support the contract? i.e.
Capital versus operational expenditure.
Intellectual Property  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?
Legal & Regulatory  Does solution comply with Australian legislative and regulatory
Compliance requirements, including Privacy Act, FOI Act, and Archives Act?

Manageability  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?
Performance & Conformance  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?
Privacy  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?
Reputation  Is there potential for the agency’s reputation to be damaged as a

result of a service failure, breach of security or privacy?
Scalability  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?
Security  Do the offerings satisfy Protective Security Policy Framework, the

Australian Government Information Security Manual (ISM) and
Privacy Act 1988?
Service Provision  Reputation, history and sustainability of the vendor?

 Portability of the application and data in case of a vendor failure?
Skills Requirements  Can the software be supported by the current resource levels?
 Are new skills required to manage, operate, support and
maintain?
Standards  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?
Support and Maintenance  Are external maintenance and support services available?
 Are there the necessary skills available to support the solution
internally? E.g. Level 1 support teams?
Transferability  Are the licenses transferable – under machinery of government

changes?
 What about the application and data?
Vendor Capability  Local capability/skilled resources available?
 Capacity to service and meet obligations?

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?

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 Software Types

Custom Proprietary Open Source Software-as-a-
Service
Agency Under your Under your Under your Under service
Reputation control. control. control. providers control.
Business Under your Under your Under your Under service

Continuity control. control. control. providers control.
Data Security Under your Under your Under your Provided by data
control. control. control. escrow
arrangements.
Data Total control. Total control. Total control. May be limited as

Sovereignty service provider
has control of
execution or
compute platform.
Development Under your Under vendor’s Under Under service

Roadmap control. control. communities provider’s control.
control.
Funding Up front for Up front for Ongoing internal Ongoing fees to

Requirement project, then licence, then support staff or the service
ongoing internal ongoing support and provider.
support staff or maintenance and maintenance costs
support and support. to a vendor.
maintenance costs
to a vendor.

Service
Intellectual Agency owns, but Vendor owns. Community owns. Service provider
Property may be shared owns.
with developer(s) A potential risk is
depending on the liability for an A potential risk is
contractual intellectual the inability to run
arrangements. property the software if the
infringement due service provider
to the number of becomes insolvent
contributors and or ceases to trade.
the fact that they
do not need to
give any
assurances about
their contribution.
Intended Use Designed and Designed to be As is or modified As is or with pre-

developed for used as-is, but similar to custom defined
specific deployed into the or bespoke configurations
application. agency’s preferred development. only.
environment.
Customisation is
intended to be
avoided in favour
of configuration.
Interoperability Degree of Dependent on Dependent on Dependent on the

interoperability standards standards interfaces offered
dependent on employed by employed by by the service
design and vendor and/or community and/or provider.
standards achieved through achieved through
employed. local local
customisation. customisation.
License Type Exclusive. Restrictive. General Public Subscription. No

License (GNU) actual licence is
with or without provided. Instead
restrictions. this is covered by
a contract or
terms of services /
usage.
Outage Your Your Your Service provider

Management responsibility. responsibility. responsibility. responsibility.
Security Under your Vendor provides As it is community Vendor provides

control. some assurance developed there some assurance
Considered as part there are no are no assurances there are no
of the design and security as to whether security
development. vulnerabilities or there are any vulnerabilities or
when discovered security when discovered
they will be vulnerabilities. they will be
corrected. corrected.

Service
Service Level Nil or defined by Depending on Open source High level SLA’s
Agreements the agency. level of support licenses do not typically provided
(SLAs) purchased from contain the kinds but this area is
vendor. of representations evolving and
and warranties of specific SLA’s can
quality or fitness be negotiated
for a particular with vendors.
purpose that
commercial
software vendors
sometimes
incorporate into
agreements.
Support and Typically provided Provided by Partly provided by Provided by the

Maintenance by internal vendor. community, service provider.
resources. mainly provided
by internal
resources or
contracted third
parties.
Upgrade Cycles Under your Under your Under your Under control of
control. control, but control, but the service
influenced by the influenced by the provider.
vendor communities
development development
roadmap and roadmap.
support options.
Vendor Typically Usually purchased Nil. Application

Support. negotiated as part as an adjunct to support not
of the the software Support required. User
development license. Typically a arrangements support usually
contract. % of the total need to be made included as part of
license cost. separately with service provision.
third party who
offers support
services.
Contract Medium to long Medium to long Medium to long Short to medium
term. term. term. term.

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.

REFERENCES
1
Griffith, Chris (June, 2011), Software boom ahead for local market. See http://www.theaustralian.com.au/australian-
it/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.

Navigating Software Procurement in An "As-A-Service" Industry

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Navigating Software Procurement in An "As-A-Service" Industry

Hochgeladen von

Copyright:

Verfügbare Formate

Navigating Software Procurement in

A Practice Guide for ICT and Procurement Professionals

In response to this increasing array of procurement choices, Australian government

Business Aspect - Software Procurement Practice Guide Page: 2

Part A An Inventory of Federal Procurement Requirements

Part B Establishing a Unified Approach to Software Procurement

Part C Practical Tools & Checklists

Business Aspect - Software Procurement Practice Guide Page: 3

How often does your organisation use different software

Figure 1 - Software procurement models in Australian Government Agencies

Business Aspect - Software Procurement Practice Guide Page: 4

Share before Buy, Buy before Build4

Share before Rent, Rent before Buy,

The importance of considering “as-a-Service” models as part of any modern software

Business Aspect - Software Procurement Practice Guide Page: 5

CHARTING THE SOFTWARE PROCUREMENT LANDSCAPE

Recent examples of this scrutiny include:

The Four Procurement Principles

Australian Government Procurement Principles

1. Value for Money

Business Aspect - Software Procurement Practice Guide Page: 6

Figure 2 - Commonwealth Procurement Process

The nine procurement procedures

Australian Government Procurement Procedures

The procurement lifecycle’s four stages

Business Aspect - Software Procurement Practice Guide Page: 7

Case for Change

CPG - Core Principles

CPG - Mandatory Procurement Procedures (Division

Source: Business Aspect based on AGIMO’s ICT Sourcing Lifecycle and

The seven most critical directives

Business Aspect - Software Procurement Practice Guide Page: 8

Figure 4 - Core Australian Government ICT Sourcing Policies relating to software

The impact of AGIMO Circular Number 2010/004

Business Aspect - Software Procurement Practice Guide Page: 9

Figure 5 - Evolution of Australian Government stance on software procurement models

Business Aspect - Software Procurement Practice Guide Page: 10

Source: Business Aspect

Figure 6 - The Unified Software Procurement Framework

The objective of the definitions, processes and checklists is to provide an actionable

Business Aspect - Software Procurement Practice Guide Page: 11

Perspective Dimensions Tool Lifecycle

Applying the Unified Software Procurement Framework is as simple as:

Business Aspect - Software Procurement Practice Guide Page: 12

APPLYING THE UNIFIED SOFTWARE PROCUREMENT FRAMEWORK

Business Aspect - Software Procurement Practice Guide Page: 13

 Implement an on-premise solution by:

5. Application Sharing (between Agencies both Commonwealth and State)15

Software Procurement Model Definition

Custom/Bespoke Software Custom or bespoke software solutions are those developed by a

Business Aspect - Software Procurement Practice Guide Page: 14

Software-as-a-Service Software-as-a-Service are software solutions which can be rented

Business Aspect - Software Procurement Practice Guide Page: 15

Does your procurement approach/strategy:

2. Promote efficient, effective and ethical use of

8. Allow decisions to be justified and

If you have answered “No” to any of these

Business Aspect - Software Procurement Practice Guide Page: 16

Procedure Required Action

1. Requires an open approach to A public invitation issued via AusTender or other

NB: The above applies unless a direct procurement is

2. Comprehensive request A comprehensive RFT for the software acquisition is

The RFT documentation should comply with Open Source