Taxonomy Review - Architecture
Reducing taxonomy development & implementation
costs through a simpler taxonomy architecture
Michael Leditschke
22 May 2013
Presentation Overview
› SBR business drivers & barriers
› Taxonomy simplification work & benefits
› Proposed architecture changes
› Specific issues, before and after change
› Future vision per stakeholder
› Transition principles
2
SBR Business Drivers
› SBR has delivered
– A definitional taxonomy with over 8000 items
– 50 reporting taxonomies from several agencies
– Thousands of lodgements from dozens of SW packages
› And that is just the beginning
– The SBR board has endorsed an expansionary roadmap
– We aim for 1000’s of reports from 100’s of agencies
– Billions of lodgments and $billions of savings
3
SBR Business Drivers
› But progress is very slow and very costly
– The 50 SBR reports have taken considerable effort to develop
– The agency implementations have consumed even more effort
– SWD uptake has been slow and required a lot of support
› So we will be unable to scale without change
– SBR cannot reach it’s goals for B2G reporting at this cost level
– Much of the cost is driven by complexity so simplification is our
key objective
4
Taxonomy Simplification Work
›
›
›
Treasury Taxonomy Review Oct 2012 recommended 17 changes
Five project concept briefs resulted, we are currently focussed on the first two
The ultimate goal is significant cost reduction and simplification
Project
Goal - Strategy
1 - Architecture
To reduce the cost of taxonomy development – by significant
reductions in complexity
2- Versioning
To reduce the cost and increase agility of taxonomy change –
by reducing the impact of change
3 - Governance
To increase capacity to deliver – by federating development to
agencies and the market
4 - Tooling
To increase adoption – by allowing agencies and SWD to use
their own familiar tooling
5 – Information
Management
To increase business value – by asking for natural business
data rather than automating paper forms
5
Target Benefits
› Significant Cost Reductions
– Of taxonomy development for SBR
– Of service implementation for Agencies
– Of instance production & consumption for SWD
› Improved Agility
– To adopt new agencies and reports
– To accommodate Agency legislative changes
– To deploy changes and bug-fixes
– Significantly less impact on SWD implementations
6
Target Benefits
› Increased Business Value (brief 5 only)
– By imposing fewer reporting obligations (tell us once)
– By providing complete solutions (aggregating related
interactions)
– By a focus on natural business data (give us what you have)
7
Proposed Changes - Definitions
› Definitional Taxonomy is for simple fact definitions
– Primary value is as a semantic standard for report builders
– ICLS hierarchy has been removed from instances, and becomes
just one of many category schemes used to classify and discover
items in the Australian Reporting Dictionary (ARD)
– Definitional versioning is at the item level and is not in namespace.
Item version still present in the taxonomy import/include structure
– All items are in a single namespace. XML namespace is only for
name collisions, not for versioning
– No “common modules”
8
Proposed Changes - Definitions
› Enumerations managed as first order items
– Data type file is just xbrli types and any that xbrl.org add. Very
stable. No enumerations in data type schema
– Enumerations managed separately as code tables
– Each “code point” (i.e. table row) can have multiple representations
of a code (eg “AU”, “AUS”, “Australia”)
– Allowed value sub-sets managed as document level business rules
(eg master list of payment methods can have 7 values whilst BAS
can limit to 3)
9
Proposed Changes - Reports
› Mixed “dimensionalised/hierarchical contextualisation no
longer used. Intention is to choose one or the other and
adopt a small set of “business patterns” to decide which
is most appropriate.
› Easy transform between fully dimensional and
hierarchical models to facilitate use of non-XBRL tooling
on client side
› No message semantics in taxonomy (lodge, prelodge,
etc) means less mappings (eg prefill response is reusable as lodge request)
› iXBRL easier to use with fully dimensionalised
taxonomies
10
Proposed Changes - Reports
› Separate business process level validation rules
– Process level validation rules managed outside of document
taxonomy
– Rules (Optionality, enumerations, cross field rules, cross
instance rules, etc ) modelled as information to allow reuse in
multiple rule validation technologies
– Automated transforms to schematron for rule validation. Formula
also under consideration
– Common drivers for change managed as separate artefacts
outside of document taxonomy and so do not impact taxonomy
release cycle
– Rule updates easily deployed out of cycle
11
Proposed Changes - Release
› Report level packaging only
– Implementers download reports and get ONLY the related
definitions (not an 8000 element taxonomy)
– Federated development allows agencies to manage release of
reports and rules in accordance with their needs
– Automated delivery of all current MIG content in a machine
readable format (M-MIG) apart from high level context and
process/interaction models
– Highly backwards compatible. New report versions have almost
no impact on existing implementation mappings and on-the-wire
instances
– Simpler test data & test suite management
– No definitional entry points
12
Proposed Changes - Release
› SWD Release and Tooling
– SWD can layer report taxonomies and will only get incremental
element definitions
– SWD can choose to work with (simplified) XBRL directly or
leverage familiar XML tools where no native XBRL option exists
– Clean validation sequencing allows bulk of rules to be
automatically produced as executable artefacts – many current
changes become replacement of targeted rule sets.
– Rule information more readily integrated into rule validation
technologies
13
Scenario – Adding a code value
A new report needed a value “cancelled” added to the allowed list of
paymentStatusCodes (“Failed”, “Paid”, & “Pending”).
Impact before changes
Impact after changes
Add new enumeration value to dtyp.xsd
and re-release entire schema
Add the new value to the definitional code
table
Release new version of all definitional
taxonomy items that use this type
Update and release the M-MIG, from which
updated validation formats can be
automatically produced. New value can
easily be incorporated into UI/validation
tables.
Release new reporting taxonomy for all
impacted messages (prelodge lodge etc)
Can be done at anytime without impact on
any other taxonomies or reports
Release new test instances in new
namespaces and update test suite
Release updated MIG & schematron
packages
Requires full SBR taxonomy release
14
Scenario – Item reclassification
A number of financial definitions were moved from one ICLS classification to
another, without changing their meaning.
Impact before changes
Impact after changes
Deprecate old definitions in published
XBRL definitional taxonomy
Change the category value in the
definitional repository
Publish all reclassified definitions in a
new schema and new namespace
No impact on developers as on-the-wire
delivery is not affected
Update and republish all impacted
reporting taxonomies
Republish all MIGs, schematron rules,
test instances, test cases
Update and re-test agency service
All existing implementers change their
mappings and re-release products
15
Scenario – Update Guidance/Label
An item guidance or label text is updated to provide additional clarification,
without changing the meaning of the item.
Impact before changes
Impact after changes
Update linkbase and linkbase references. Change the guidance or label value and
Release new item version in new
publish updated item in same namespace
namespace
(but with incremented version attribute)
Deprecate old definition in published
XBRL definitional taxonomy
No other impact
Republish reports, MIGs, schematron
rules, test instances, test cases
Update and re-test agency service
All existing implementers change their
mappings and re-release products
16
Scenario – Change optionality
CTR IEE report had a mandatory item that should have been optional.
Impact before changes
Impact after changes
Update reporting taxonomy for each
impacted message and re-release in a
new namespace
Update relevant rule information in the MMIG, and generate equivalent validation
formats from this
Republish reports, MIGs, schematron
rules, test instances, test cases
Publish at any time without effect on
mapping layers
Update and re-test agency service
All existing implementers change their
mappings and re-release products
Wait for taxonomy release cycle
17
Scenario – Agency Release Clash
Delays cause one agency to not be ready for a release resulting in the delay
of the release o another agency’s reports.
Impact before changes
Impact after changes
Significant co-ordination effort to manage
releases
Agency reports can be released as soon
as they are ready
Tension between release schedule and
agency readiness
Simplified item representation in instances
allows greater flexibility in harmonisation
processes
Negotiating agreement on definitions
must be completed before shared
elements appear in published reports
Balance between agency publication
timelines and program timelines
18
Scenario – High Volume of Reports
A single taxonomy release includes changes to 10s of reports.
Impact before changes
Impact after changes
Significant effort to understand what has
changed
Easy to identify changes affecting a
particular report
Standard differencing tools not usable
given size of taxonomy
Reports sufficiently granular that file based
differencing tools can be used to determine
changes
Output of XBRL difference report tools
more targeted
Reports “pick up” unrelated changes to
items e.g. spelling corrections
Easier to incorporate cosmetic updates to
items as they largely affect the taxonomy,
not instances and mappings.
19
Scenario – Taxonomy Size
The size of the current taxonomy makes its distribution to clients problematic.
Impact before changes
Impact after changes
Taxonomy has a large disk footprint
Developer can “mix and match” the set
of taxonomies required.
Taxonomy can’t be incrementally updated Individual report updates can be shipped
to clients
Developer need only ship report version
they use
Taxonomies can now be more conveniently
located on the same area of the web site
as other related artefacts such as MIGS
20
Change Metrics (before & after)
›
›
›
The chart shows the count of changes that will affect on-the-wire instance formats and mapping layers.
3800 changes (red/back row) with current architecture reduce to around 900 (blue/middle row) with
proposed architecture
Possibility of further reductions to around 200 (green/front row) after Information Management changes
(i.e. better modeling & design)
1200
1000
800
600
400
200
0
Current
After with Arch
After with IM
21
Stakeholder View – the SWD
Current vs future experience for the Software Developer
Impact before changes
Impact after changes
Downloads a report – and gets 8000
definitional elements, 7800 of which are
irrelevant
Downloads a report and gets just the data
elements needed
Needs a deep understanding of XBRL
including positive hypercubes
Needs little to no understanding of XBRL
upfront, but can “up-skill” as need
demands
When importing the schema into normal
tooling, gets chaos so has to learn new
tooling
Can choose to use own familiar tooling and
gets a clean document object model
Frequent changes from SBR impact onthe-wire instances and so require remapping and re-release to customers
Fewer changes from SBR, much lower
percentage affect on-the-wire formats and
are easily accommodated by rule update
Very high participation costs
Lower cost of participation
22
Stakeholder View – the Agency
Current vs future experience for the SBR Participating Agency
Impact before changes
Impact after changes
Complex FA/IA process distracts from real
data & process analysis
Clean design methodology focuses on the
business process and data requirements
No visibility of existing taxonomy and totally
reliant on central team to “harmonise” –
without SME
Direct access to definitional repository from
agency’s preferred information management
tooling. SME drives re-use
Reliant on central team to produce reporting
taxonomy, MIGs, etc
Federated development allows agencies to
develop their own reports – and publish to
central repository
All changes are slow and expensive and go
through TAC approval and often wait for
release cycle
Most changes do not impact taxonomy and
can be released by agency as rule changes in
alignment with agency legislative schedule
High implementation cost to manage
transforms from XBRL to agency structure
and frequent changes requiring re-mapping
XBRL to agency transforms are much simpler
and very few changes require re-mapping
Very high participation costs
Low costs of participation
23
Transition Principles & Implications
› Switching to the new architecture will require the
regeneration and release of a completely new taxonomy
– Existing SWD implementations should not be forced to switch
immediately
– New SWD implementers should not be forced to support two
architectures
› Semantic equivalence between old and new
– Possible solution seen in provision of transforms / tooling that
allow conversion between architectures at minimal cost
– Transformation can occur either on business side, or agency
side, or both
24