Case study: Australian Bureau of Statistics

Preface to most recent update (2011.1)

The previous major update to this case study occurred in the first half of 2009. As recorded in the document entitled A Brief History of Metadata (in the ABS) (referenced simply as BHM hereafter), which is attached to this Case Study, the second half of 2009 saw fundamental decisions made by the ABS leading to initiation of the ABS Information Management Transformation Program (IMTP) in February 2010. While IMTP designates a specific program within the ABS, including a specific top level unit within the organisation chart, the aim is for the ABS to achieve IMT (Information Management Transformation). All staff within the ABS have a role in achieving IMT. 

IMT will include fundamental reshaping of policies and strategies related to metadata management developed by the ABS over the past two decades. At this stage, however, IMT remains an early "work in progress". 

IMT can be seen as focused on the "to be" environment for the ABS, in terms of business architecture, data/information architecture and other elements of enterprise architecture, as well as on the process for achieving the transformation (including business process re-engineering) required to realise the "to be" state. At this time many details contained in the previous version of this case study continue to accurately describe the "as is" environment for metadata management within the ABS. 

In the initial update for 2011 it has been decided to focus the main body of the case study on the "to be" state and initial steps toward that state. Many details of the "as is" environment have been moved into supporting documents. Other aspects can be found by referring to the 2009 version of the case study. It is possible within the wiki to view earlier versions of each page. For convenience, also, PDF versions of the 2009 edition of this case study and 2009 edition of BHM have been made available. 

The result of this approach is that the Case Study document is now shorter than the 2009 edition. Additional details will be added to the documentation as IMT progresses, including its new approach to statistical information management, including metadata management. 

It should also be noted that, as with all content in the METIS wiki maintained by ABS practitioners, this is an informal working document shared with colleagues in the field of statistical information management. Unless unambiguously indicated otherwise, no content accessed via these wiki pages should be considered to represent a formal statement on behalf of the Australian Bureau of Statistics.

Metadata Strategy

Ultimately any strategy exists to support the ABS mission and objectives as set out in the organisation's corporate plan. In particular, the availability of appropriate metadata and the application of sound statistical information management practices are critical to supporting informed use of statistics and the quality of the statistical services we deliver to the nation. 

BHM provides information on the evolution of ABS strategies related to metadata over time, including extensive information in regard to Strategy for End-to-End Management of ABS Metadata established in 2003. 

IMT can be seen as superseding the 2003 strategy, although at this stage there is no "direct replacement" strategy focused specifically on metadata and its management. IMT focuses instead on strategies related to "statistical information" management which spans metadata (in its broadest sense) and data. 

Although IMT supersedes the 2003 strategy, most of the fundamental ideas contained in the 2003 strategy remain relevant. For example, none of the twelve cornerstone principles outlined in the 2003 strategy have been disavowed as irrelevant or inappropriate. In this example, however, IMTP seeks principles 

• focused on statistical information management rather than simply metadata management
• rationalised where relevant with principles underpinning other frameworks applied within the ABS (eg enterprise architecture, quality management of statistical processes)
• that take account of relevant standards and frameworks associated with the global and national "industry" of producing official statistics, as well as standards and frameworks relevant to data providers and to users of official statistics
• expressed concisely in terms meaningful, and motivating, to business staff
• supported by relevant guidelines and training to assist in them being applied appropriately to specific design processes and decision making

This process of rationalisation is underway currently and it is expected the updated set of principles will be added to the case study once available. 

More generally, strategic planning for IMT can be seen as learning from experience with the 2003 strategy (eg much slower progress, and much more mixed success, in putting the strategy into effect than had been anticipated). 

Well defined, corporately accepted and supported, governance for information management is much more of a foundation consideration for IMT. This includes clearly established norms/principles/expectations, clearly established authority and accountability and clearly established processes for assessing compliance and actively managing non-compliance. The corporate positioning of IMTP (eg reporting directly to the head of the organisation and independent of any one operational or support division) promotes its ability to address governance requirements successfully compared with the implementation of the 2003 strategy. 

The IMT strategy of starting with the Metadata Registry Repository (MRR) as the key enabling infrastructure, including its integration with Statistical Workflow Management capabilities, can be seen as establishing a "central nervous system" to support the new environment – including supporting its relationship with "legacy" applications and repositories – where the 2003 strategy primarily targeted developing new repositories and redeveloping existing repositories without such a well developed strategy for achieving "business integration" in practice. 

Compared with the 2003 strategy, IMT work on the Statistical Information Management Framework also includes much greater integration with external frameworks such as GSBPM (Generic Statistical Business Process Model andGSIM (Generic Statistical Information Model) as well as wiith other frameworks applied within the ABS (eg Enterprise Architecture). 

In October 2009, the ABS Executive formally agreed on Statistical Data and Metadata Exchange (SDMX) and Data Documentation Initiative (DDI) as the standards that will form the core of the ABS's future directions and developments with regard to statistical information management. This means strategic engagement with the two standards communities, including encouraging them to co-ordinate their work in order to support NSIs and others who seek to use both standards, is a high priority. 

Participation in the Statistical Network strategy is the primary, but far from only, example of IMT's strategic focus on collaboration (internationally and/or nationally) when it comes to statistical information management. 

More detailed formal statements of IMT strategy in regard to statistical information management are still being reviewed within the ABS. Any encapsulation of strategies which is agreed for general release beyond the ABS will be added to this case study once available.

BHM describes how the current situation has evolved within the ABS. Documentation of IMT outlines the current situation. 

The majority of data collection and input processing activities for business and household surveys have moved toward implementation of high level metadata frameworks informed by ISO/IEC 11179. These frameworks were developed over the past decade and postdate the ABS specific metadata framework which was implemented for the corporate output data warehouse which was developed during the 1990s. 

Key elements of current metadata infrastructure, which predate initiation of IMTP in 2010, include major repositories related to 

• statistical activities
  • Termed "collections" by the ABS, these activities include surveys, censuses, statistical analysis of administrative data sources and statistical "compilation" activities such as preparing the national accounts.
• datasets
  • These are specific structured data files, data cubes and tables associated with statistical activities. Examples include various "unit record files" and aggregate outputs.
• classifications
  • This is a "legacy" system based on an ABS specific data model.
• data elements
  • This is a more recent development based on the metamodel found in ISO/IEC 11179 Part 3.
• questions and question modules
  • This was developed more recently for household surveys with an aim to generalise the facility in future.
• collection instruments
  • This was developed more recently for household surveys with an aim to generalise the facility in future.

The more recent developments also incorporate an approach to metadata registration based on ISO/IEC 11179 Part 6. Even if some of the older repositories cannot be completely replaced in the next few years it is anticipated that a common high level metadata registration framework, harnessing the MRR, can be implemented across the ABS for all classes of metadata. This does not imply that all classes of metadata will undergo exactly the same registration workflow, but the workflows for each class of metadata will be consistent with a higher level "metamodel" for registration. 

Interoperability of the current ABS metadata models, including the legacy "output" model, with third party software (eg SAS, Blaise, SuperCROSS) continues to be an issue. 

The increasing focus of the ABS and other agencies on the National Statistical Service (NSS) requires development of metadata models and capabilities which are usable beyond the ABS. The NSS needs to interoperate with agencies whose data content is more "administrative", "geospatial" or "research oriented" than "statistically" oriented. This provides additional challenges and issues in regard to metadata modelling. 

While many of those agencies are at least as passionate about metadata as the ABS - but from a different "school" - the NSS also needs to support content producers and users for whom metadata is much less of an interest and priority. This raises questions about minimum metadata content and quality standards. 

Understandably, metadata is a particular area of focus for the NSS. This includes a simplified and generalised set of principles for managing metadata. 

Challenges associated with the current situation, such as achieving a coherent "end to end" metadata driven environment(s) within the ABS and better supporting the NSS, underpin IMT.

The ABS doesn't have a formal "taxonomy" of metadata. One was proposed early in development of the 2003 metadata strategy but it wasn't included in the final document. It was found that discussions about how to "class" particular instances of metadata (in borderline cases rather than all cases) could become very protracted without that discussion seeming to generate any real value. 

In general ABS concurs with the findings of Bo Sundgren in regard to Classification of Statistical Metadata, namely that multiple valid approaches exist, with the optimum depending on why classification is being attempted. 

One form of categorisation sometimes used within the ABS relates to purpose/use of metadata. This means a particular "piece" of metadata may (and often should) support more than one type of use. The categories are

1. (Search and) Discovery - Help users find data (or a metadata object in its own right, such as a classification) of relevance to their needs and interests
2. Definition - Help users understand data (or a metadata object in its own right, such as the definition of a data element)
3. Quality - Help uses assess the fitness of associated data for their specific purpose
4. Process - Apply metadata to run processes, such as using a classification to drive an aggregation process or to provide a list of valid encoding values for editing purposes. It also includes defining other parameters that drive a process as metadata, such as the choice of which imputation method to use for which data element.
5. Operational - These are metrics on the results of the operation of processes such as edit rates, imputation rates etc. These can feed into internal decisions on managing and improving survey processes and into external "quality" decisions. This metadata is sometimes termed "paradata".
6. System - Low level information about files, servers etc that helps allow the physical IT environment to be updated without end user processes needing to be respecified.

The ABS also recognises "objects" in regard to which metadata can be assembled and registered. These include

• high level end to end statistical activities ("collections")
• individual datasets
• data elements
• classifications
• individual processes
• terms
• questions
• question modules
• collection instruments

These "objects" can be further broken down (eg data elements into properties, object classes, value domains etc). 

The main way forward from the ABS perspective at this time is work toward GSIM (Generic Statistical Information Model). This should (among other things) provide a reference classification (or taxonomy) of "information objects" (including "metadata objects") that is shared in common beyond just the ABS. 

Work on the Metadata Census within the ABS is also providing a "bottom up" approach to classifying/grouping "information objects" based on the requirements of existing systems and processes (including seeking to harmonise the sets of requirements and align them with constructs described within SDMX and DDI). As described in Section 4.1, this work (together with GSIM) will input to classing the objects supported by the MRR and also provide a use based checklist for testing the GSIM "taxonomy".

There are currently many systems within the ABS that encompass significant metadata definition and management aspects. 

The MRR (Metadata Registry/Repository) associated with IMT is by far the most significant metadata system currently under development. The MRR's Registry capabilities will act as a "central nervous system" for systems across the ABS that define, manage and use metadata. At this stage the MRR is at the Proof of Concept phase. 

An early activity associated with IMT was the first phase of a "metadata census". As suggested by selection of the term "census" it was originally hoped that this activity would provide a much clearer and more comprehensive "as is" picture of metadata management at a local level within the ABS as well as at a corporate level. GSBPM was an important point of reference for indicating what phases and sub-processes each system was supporting with which metadata. 

An early issue encountered was the ability for those responsible for systems to describe in a clear and consistent manner the "types" of metadata managed within their systems. For example, if one system was said to work with "variables", another with "data items" and another with "data elements" were all three systems talking about the same "type" of metadata, or about different "types" of metadata (that maybe related to each other in some way)? Work associated with GSIM and the MRR should lead to this issue being more tractable in future. 

The "as is" picture is also complicated the fact that many local systems currently need to "replicate", possibly in a specialised format with local content additions, metadata held in existing corporate repositories. The issue about consistently typing metadata compounds the issue of being able to establish which systems are managing which metadata simply because they currently can't source it from elsewhere – as opposed to managing metadata for which that system should be considered an authoritative source within the ABS. A significant number of processing systems currently have a secondary role as a "metadata system" only because – for a variety of reasons - they can't source the metadata they need systematically from elsewhere. 

The second phase of the "metadata census" focused in more depth on metadata associated with core corporate stores and systems. The outputs have already contributed to the design of the Proof of Concept for the MRR and will contribute more broadly to the development of the MRR in future as well as being used as one practical test of the scope and nature of metadata requirements addressed by GSIM. 

Early work on the metadata census confirmed that some current metadata systems are 

• fully corporate.
• "shadow systems" which extend corporate systems to supplement the standard content with attributes of local interest.
  • The need for "shadow systems" should be eliminated once, via the MRR, modelling of information objects, attributes and relationships address the needs of the organisation as a whole.
    • Some systems may still not be able to only use "standard" metadata but the metadata actually used by these systems will be able to be described, and registered, together with the relationship of that metadata to "standard" metadata..
  • Some of the "shadow systems" have been designed and maintained to ensure they can be easily reintegrated with corporate systems in future while others have not.
• truly "local" systems
  • These exist for a variety of legitimate and not so legitimate reasons.
  • The best of them source relevant content from the Corporate Metadata Repository (CMR) as a properly maintained snapshot but then reformat that content to meet local needs (eg to support systems that cannot "read" the metadata directly and require it to be translated/packaged in a special way).
  • The worst of these update, evolve and create new metadata for local use independently of the CMR.
  • Others deal with classes of metadata (eg methodological parameters to drive specific processes) which are not currently managed within the CMR.

Information about key existing corporate metadata systems, documented previously in this section of the case study, has been moved to a supporting page. 

In regard to systems envisaged for the future, the Statistical Workflow Management (SWM) facility designed to work with the MRR is expected to provide a source for information related to, for example,

• reusable process specifications
• the assembly of processes into specific workflows
• results from executing defined workflows
• reusable business rules for driving and chaining processes and workflows

Earlier conceptual and exploratory work identified seven types of "process metadata" from "configuration" metadata about the IT environment and the user running the process, through to metadata which is a formal "input to", or "output from" the process, through to metadata which describes the process itself and which describes how chains of processes fit together. (None of these seven types of process metadata corresponded to "process metrics" as described below. Given there are already more than enough types of "process metadata", the ABS tends not to favour using the term to also denote "process metrics".) 

Achieving a clearer path forward in regard to structuring and managing "process" metadata is seen as an important enabler to having other metadata (eg the structural definition of data elements) actively drive statistical processes. 

It is intended that the work related to structural definition and description of processes harness appropriate standards such as BPMN (Business Process Model and Notation) and BPEL (Business Process Execution Language). 

It is anticipated that, through SWM working with the MRR, it will become possible to specify and analyse detailed information related to the statistical information used by, and produced from, specific process steps. 

A further priority is to better capture and store (for automated and interactive analysis and reporting) "process metrics" related to how statistical processes are performing (eg response rates, imputation rates, edit rates etc). Such data about the outcomes of processes is sometimes referred to as "process metadata", "operational metadata" or (typically in specific circumstances) "paradata" by others. Process metrics can be useful for internal monitoring, management and tuning of processes as well as generating data quality indicators for external dissemination.

Initiation of IMTP in February 2010 led to significant adjustment of roles and responsibilities within the ABS. 

The 2003 metadata management strategy had stated that, in terms of governance 

Metadata management becomes part of every project and each project ensures that they consider and budget for resources to handle metadata development and maintenance. 

It is sometimes suggested that by making something "everyone's business" it becomes nobody's business. 

The Data Management Section (DMS) within the ABS was to be "consulted" and had a co-ordinating and advisory role. The aim was that the Corporate Metadata Repository (CMR) and its services would be progressively extended to meet the needs of new application developments. DMS developed guidelines to assist project planners, project managers, business analysts and IT staff in understanding the practical meaning and intentions of the principles and how they might apply in the context of a specific project. DMS also provided direct interactive advice to planners, analysts and IT staff. 

In practice, however, the design and development of new metadata repositories and services were driven by the initiatives that required them, and paid for them, such as BSIP and ISHS (see BHM). Given input from DMS, architectural design panels and other sources the designs were notionally left open for use by other projects, and for integration within the CMR, but these outcomes were given relatively low priority in practice. 

DMS also continued to fulfil roles it had prior to the 2003 strategy. DMS has been responsible for Data Management Policy within the ABS and maintaining the ABSDB and selected other infrastructure such as CMS and ClaMS described in the supporting page for Section 4.1 of this case study. The maintenance role includes 

• managing IT maintenance and minor new developments
• acting as database administrators
• supporting end users including providing content design advice and training

While DMS ensured necessary "repository infrastructure" was provided, and that the infrastructure remained "fit for purpose" in a changing organisational and technical environment, it is not responsible for the quality of the content held within each repository. That responsibility rests with the subject matter areas and others who provide the content and have an ongoing custodianship responsibility, including ensuring the content remains up to date and answering any enquiries its definition might generate from others. 

Data Management Policy mandates use of the corporate facilities for various purposes and subject matter areas are responsible for making use of the facilities in accordance with those policies. 

The Standards and Classification Section (SCS) has a number of leadership roles in regard to metadata content within the ABS. SCS develop and support "standard" classifications and variables which are cross domain in nature (eg industry, occupation, language). Many of these are recognised standards for Australia as a whole, not just the ABS. SCS also provide guidelines and advice to help subject matter areas ensure their "collection specific" metadata is well defined and curated. 

DMS and SCS form the Data Management and Classifications Branch (DMCB) within the Methodology and Data Management Division (MDMD). DMCB brings together specialists in metadata modelling and systems with specialists in metadata content, in order to reinforce each other's work and to provide strong integrated support to the ABS and the broader National Statistical Service. 

With announcement of the IMTP, an early matter to be clarified was the nature of the new program's relationship with MDMD - and DMCB in particular. The conclusion was that IMTP would assume leadership at the strategic level in regard to (Statistical) Information Management. The Program Board for IMT, for example, consists of the head of the ABS and his four deputies. This Board is therefore able to address organisational governance and alignment issues, including in regard to Statistical Information Management, that the approach to implementing the 2003 strategy had been unable to address in practice. 

Naturally the IMTP leadership role entails working closely with MDMD. It is recognised, also, that IMTP is leading a transformation process (which, from July 2011, is expected to take at least six years to complete). At the conclusion of that transformation process IMTP is not expected to continue as an organisational unit in its current form. Strategic leadership therefore needs to transition to a sustainable arrangement within the "post IMT" organisational structure. 

As described in IMT, this leadership role is reflected in activities such as development of the Statistical Information Management Framework, design work associated with the MRR and leadership of the international OCMIMF collaboration. A team of information management specialists, and business analysts specialising in information management systems, exists within IMTP. At the current time (July 2011) this team comprises half a dozen staff. It is expected to approximately double in size during the coming year.. 

DMS staff have been seconded to IMTP on a rotating basis to assist with its IM work program. 

In addition, DMS has notionally divided its work program between maintenance of existing infrastructure (as described above) and supporting IMTP through 

• detailed assistance to "pathfinder" projects in applying standards such as SDMX and DDI as well as sound data management practices more generally
• providing input to the IM related projects and initiatives that IMTP is undertaking
• undertaking practical research projects on behalf of IMTP

There are around a dozen staff within DMS currently, with their duties split fairly evenly between maintenance of existing infrastructure and supporting IMTP. 

A third key area (beside IMTP and DMCB) is SISD (Statistical Infrastructure and Solutions Design) unit within the technology oriented division of ABS. One role of SISD is to provide technical leadership and support in regard to Enterprise Architecture, including data/information architecture. SISD also leads and supports the "solutions design" process within the ABS, ensuring that new developments (particularly those that are classed as "Architecturally Significant) are designed with due regard to agreed architectural principles and practices. Alignment with the "to be" business and data/information architectures, whose definition is emerging from IMT, is a key consideration in this regard. The "Metadata Building Code" developed by DMS during 2010 currently provides guidance in this regard. 

The solution design process culminates with a formal Design Review that comprises senior executives from Technical Services Division, IMTP and relevant business stakeholders. Where an appropriately consultative solution design process has been followed prior to the formal Design Review, however, key "architectural concerns" from various perspectives should already have been identified by stakeholders and addressed in the design proposal. The Design Review should serve as a formal gate to confirm the solution design process has been conducted appropriately, and confirm high level support for the solution proposed, rather than result in fundamentally new concerns being identified. 

In addition to these key organisational units (IMTP, DMCB and SISD) there are a range of governance, reference and advisory groups that include participants from across the ABS. These groups assist in steering and informing ABS priorities and directions related to Statistical Information Management. 

Phase 5 of IMT will focus on extending facilities to support the discovery of and access to data within the NSS. In the meantime, however, the Data Leadership Initiative (DLI) is being sponsored by NSSLB (National Statistical Service Leadership Branch). DLI aims to promote within the NSS best practice standards to help ensure data is 'fit for purpose' for statistical use. This includes best practice in application of exchange standards such as SDMX and DDI. NSSLB is working closely with IMTP and DMS in regard to these aspects of DLI. 

The following table contains a list of specialists in metadata management in the ABS:

6.1 Lessons Learned 

1. While technology is a vital enabler, metadata management should be driven, governed and presented as primarily a business issue rather than a technical issue.
   • This requires proponents of metadata management focus first on business outcomes and benefits (eg improved productivity, increased utility of statistical outputs) rather than on metadata management itself.
     • Metadata management as a topic in its own right is of interest to very few, and is typically viewed as a technical specialisation. Its potential as one (of a number of) means to achieve business process improvement is generally acknowledged. A key challenge is to demonstrate, in practical terms meaningful to business areas, that it should be one of the preferred means - and one that is supported through investment and through business practices and culture. Within reason, the less the term "metadata" and the names of various metadata standards are used in discussions with senior management and business areas the better - the focus should be on what will be different, and what outcomes will be achieved, from a business perspective.
   • "Metadata projects" should not be designed and promoted as "IT system developments" but rather focus on the development and deployment of new and improved capabilities, business processes etc. Such projects will often include new or extended IT systems but they should not be "about" IT systems. Among other drawbacks, narrowing the focus to IT systems will mean business areas - at best - see themselves as relatively remote stakeholders with some interest in the results of the project rather than feeling they are active participants with direct roles to play in ensuring the success of the project.
2. All high level organisational units need to be engaged by the metadata management program and have defined responsibilities in relation to it.
   • Some units' primary responsibilities may simply be to contribute to corporate sign off on the objectives, strategies, policies and high level design of deliverables (systems and processes) and then to acceptance test, take up and apply the outputs in an agreed manner to contribute to the achievement of the corporate outcomes sought from the project.
   • Other units will have a much more extensive role in terms of leadership, co-ordination, business analysis, design, development, implementation and ongoing management of systems and processes.
   • If only a few specific organisational units are seen to have a direct stake in the project then it's much less likely to achieve overall success.
3. It's become more and more apparent over time that applying externally recognised and supported standards, in regard to design of data models for example, has a lot of benefits - including as a means of building upon a wealth of intellectual efforts and experiences from others.
   • At the same time, application of standards must be driven, and moderated, by the organisation's particular context and needs. The underlying effectiveness of the infrastructure should not be sacrificed in favour of complying "to the letter" with a standard, although the business case and the management arrangements for any divergence need to be defined and agreed.
4. In addition to developing and deploying infrastructure, a metadata management project should be understood, and managed, as a "cultural change" initiative for an organisation. Metadata management aims to make information explicit, visible and reusable (in whole or in part) - with these aims requiring a somewhat standardised and structured approach. This can be a "culture shock" for some business areas who are used to operating in a more autonomous and self contained and often a less structured manner.
   • It needs to be acknowledged there were sometimes benefits from the former approach and there will be some overheads with the changed approach. If at all possible, however, it needs to be demonstrated - or at least plausibly posited - there will be net positive benefits in practice (not just notionally) from the changed approach even if, eg, many of those benefits accrue over time - rather than being immediate - and/or accrue to users of the content rather than producers of the content.
   • Sharing and re-use can lead to concerns about loss of absolute "control" over metadata. It is important to ensure practical processes and governance around content use and change management (eg stakeholder consultation, ease of resolution/divergence if a required content change isn't tenable for one of the users of the existing content) address legitimate concerns in this regard
   • Note also the cultural change aspects discussed in Section 5.5 in terms of moving from "local optimisation" to a paradigm of "global optimisation".
5. Sufficient attention needs to be focused, by the project team and by other areas, on ensuring the metadata management infrastructure (systems and processes) is fully integrated with other business processes and IT infrastructure rather than being a "stand alone" development.
   • This needs to factored in from high level design onwards. This, in turn, requires that as part of the initial requirements gathering, analysis and sign off phase there is detailed attention focused on practical matters related to implementation, including uptake and ongoing use as part of end to end business processes.
   • This is also a reason why acceptance testing of deliverables by a fully representative selection of the business areas expected to use them is essential. The aim of this testing is not so much to confirm the specifications have been implemented faithfully (detailed system testing should already have been completed) but that the results meet practical business needs, including integrating with other workflows and systems and meeting performance and other usability requirements.
     • "Acceptance" testing should mean just that. If (for whatever reason) what has been delivered is not yet at a stage where it is fundamentally fit for purpose from a business perspective then it should not be deployed in its current form. (On the other hand, if the deliverable is imperfect but basically "fit for purpose" then the remaining issues may be held over to be addressed in a later release.) The phase ends either with business agreement the deliverable is fit for use within the broader production environment - possibly with some caveats - or else no release occurs.
       • Sound project management and engagement with business stakeholders in earlier phases should minimise the risk of failure at the Acceptance Testing stage. That said, it is counterproductive for all concerned if software that is not fit for purpose is forced on business areas.
6. In addition to allowing sufficient time and resources for the business analysis, design and development process it is crucial there is sufficient resourcing focused on
   • implementation of the new infrastructure
     • includes training, best practice advice and technical troubleshooting support for business users
   • maintaining and upgrading the infrastructure as business requirements, and as other elements of the IT environment, evolve over time
   • co-ordinating and promoting "outcome realisation" from the investment
7. Business areas must be able to engage with implementation processes.
   • In many cases there may need to be scope for business areas to negotiate and agree (not decide unilaterally) short term or longer term exemptions from, or variations on, the standard implementation process.
     • Exemptions and variations should be actively managed and reviewed with the aim of achieving convergence over time wherever practicable
     • Metadata systems should clearly identify preferred and non preferred definitions and structures, so that - wherever practicable - areas with a need to diverge from standard practices and definitions remain "within the system" while at the same time those practices/definitions are clearly identified as non preferred.
   • Feedback from business areas needs to be able to influence the details of the implementation process. For example, if it appears too many exemptions and variations will be required it may be that the design of the implementation process doesn't properly reflect business needs and realities.
   • If business areas are not provided with a genuine opportunity to "work with" a change process they are more likely to covertly "work around" that process in a manner which undermines the business objectives of the change.
8. Metadata management is largely about connections of various forms, such as
   • between documentation of agreed processes, methodologies, definitions and structures and what happens systematically
   • between producer and consumer perspectives on statistics
   • similarities and differences between different sets of data, different structures and definitions etc
9. Due to the wide variety of roles it must perform, and perspectives it must support, there is not one particular structure/format for metadata that is, in itself, ideal for all purposes.
   • The key appears to be modelling and managing metadata in way that can support the different views, and preserve the integrity of the connections underlying these different views.
     • The ideal appears to be a relatively simple, robust, standards aligned but highly extensible core model, together with well defined and managed means to map and transform locally required metadata into and out of that core model and, where necessary, to define, manage and integrate local specialised extensions to that common core.
     • A single central metadata model that aims to span all content for all purposes is likely to be too complex, too unwieldy and too static.
10. "Statistical metadata management" is increasingly expected to interoperate with metadata management as practised in other communities (eg geospatial, academic/research) and sectors (eg use of XBRL by businesses and by regulatory agencies). This provides a huge opportunity (as well as a challenge) in being able to efficiently and effectively open up and harness (from statistical and other perspectives) a vastly increased suite of information resources. It also provides a practical affirmation that other communities and sectors recognise the value of metadata and standards, although because their primary purposes vary the details of their schemas and standards also vary.
    • This reinforces the previous point. It appears both impractical and undesirable to establish a single approach that supports the primary purpose of each different community and sector. On the other hand, statistical agencies are strategically placed to provide a simple core that might be used to bring together information across communities/sectors and to exchange it across them.
    • It also reinforces the value of international standards and collaborations. Most of the community and sector specific standards are internationally based. Rather than each NSO needing to work out mappings "from scratch" there is a lot of opportunity to share a core of analysis and mapping between NSOs.