Implementation checklist

The checklist in the table below is to guide digital service providers (DSPs) through the steps from initial engagement to delivery of an SBR-compliant product to the marketplace. These steps are illustrative only - each DSP should adopt their own variations to suit specific needs.

See also:

Table: Implementation checklist

Steps

Item

Who

Description

Supporting materials

1.AssessProduct managementGain a high level understanding of the SBR program and its scope with a view to assessing the value that SBR can provide to your customer base.http://www.sbr.gov.au
2.Decision pointExecutiveProceed to business case developmentN/A
3.RegisterProduct managementRegister with the SBR program as a DSP to receive further information and support.Complete the entity registration process and email to SBRservicedesk@SBR.gov.au
4.Understand the work required to have your software support SBRProduct management and business management/strategyCovered above N/A
5.Define form scopeProduct managementReview the SBR forms in scope and select which ones you will support in your product.  Use the Message Implementation Guides (MIGs) to gain a good understanding of how to implement each form.SBR forms in scope Common MIGS and agency specific MIGs are available on each form page
6.Solution blueprintProduct management and lead developer

Prepare a high level solution blueprint for implementing SBR within your product.

Define key features and identify which government SDK components can be re‑used, such as:

  • data mapping solution
  • forms rendering solution
  • XBRL processor
  • authentication and keystore
  • web Service messaging
  • SBR taxonomy

The SBR SDK Guide will advise you how to access

  • authentication and keystore tooling
  • Web Service Specifications (WSDL).

The SBR taxonomy will provide you with form structure and validation rules.

You will need to develop the mapping and rendering capability.

7.Implementation planProduct managementBuild an implementation plan and schedule with approximate costs. Include capacity building, design, build, and test of solution components, transformation and mapping for selected forms.  Use the SBR master schedule to determine when you will implement support for specific forms.
  • SBR DSP sample implementation plan
  • SBR program master schedule
8.Business caseProduct managementDevelop a business case for implementation of SBR services within your product. Prioritise forms to be implemented.SBR DSP business case template
9.Decision pointExecutiveProceed to detailed design and prototypeN/A
10.Capacity buildingArchitect and developersDevelop the capacity within your organisation (or via outsourced providers) in XBRL, the SBR taxonomy and how to leverage it, and other SBR technical services.
  • SBR training curriculum  
  • SBR knowledgebase and forum
11.PrototypeDevelopers and product managerDevelop a prototype implementation to test mapping and lodgement of one form - typically one for which your product can already create a printed version.SBR SDK, documentation, knowledgebase and support services
12.DesignLead developer and product managerDevelop a detailed design for commercial implementation of the SBR solution within your product suite.Reference client implementation
13.Decision pointExecutiveProceed to implementationN/A
14.Solution buildArchitect / developerBuild production quality solutionSDK and support services
15.MappingDeveloper / business analystDevelop transformation and mappings necessary to create valid XBRL report instances.  Effort depends on complexity of form and level of alignment between the taxonomy and your product data store.
  • Message Implementation Guides
  • SBR AU Taxonomy
16.Rendering / user interfaceDeveloper / business analystDevelop report presentations (to allow user to review / edit before lodgement).  The level of effort depends on complexity of form and extent to which you leverage government provided templates.Form presentation templates
17.TestProduct management and QATest solution against SBR test services
  • SBR testing
  • Self assessment and compliance program
18.DocumentProduct management, tech writerPrepare administrator and user documentation.N/A
19.OperationsProduct management, support staffDefine and implement operational support process. Typically this will include a server-based mechanism to automate distribution of taxonomy updates to your customers - alongside other product updates.
  • SBR taxonomy architecture and version / release strategy
  • SBR knowledge repository & taxonomy server
20.Decision pointExecutiveRelease to marketN/A
21.ReleaseProduct managementMarket the 'SBR compliant' version of your product and release to your customers.SBR marketing support
22.SupportSupport staff

On-going support including:

  • bug fix and patches
  • new forms and mappings
  • new reference data (eg tax tables)
SBR customer support

Last updated: 16 Feb 2018
Page ID: 14050