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.

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.

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.

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

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.

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

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.

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

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.

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