Data Management Tooling · UK public procurement notice

Lot 1 – Data Modelling - The tool must be either a SaaS tool or one which will run in our cloud data-centre and must allow us to produce different types of models:

Concept Models – The purpose - Entity-relationship that conceptualize the FCA (no data attributes for entities).

Logical Models – The purpose - Logical data models (entity-relationship diagrams – entities are attributed).

Physical Models – The purpose - Data models defining the physical schema for a relational database

Lot 2 – Data Mapping - A Data Mapping tool is required by the FCA for the integration of data models. The acquisition of such a tool will provide a new capability for the FCA as previous work has been in spreadsheets conduction manual mapping between pairs of models. The mapping of models through spreadsheets does not provide a wholistic, navigable view of the interrelationships between models so an appropriate tool is required.

The models that are to be mapped include:

oEntity-relationship diagrams for working IT systems,

oReference models (no underlying IT systems) both internal to the FCA and with external stakeholder organizations

oModels of interfaces with services

oModels of dataset definitions

Some of the models are conceptual models; there is no corresponding IT system and thus no physical repository which could form the basis for a mapping. This highlights the importance of your tool’s ability to import data models held in data modelling tools. Furthermore, it is crucial that we can map data models of our IT systems to our Enterprise Logical Data Model (ELDM). The ELDM is a reference model for the FCA; there is no corresponding IT system. The ELDM is at the heart of our desire to unify our data through the meaning of our data.

The tool should be able to deal with large scale models. The smallest model to be mapped is expected be a dataset definition composed of a single object with circa 50 attributes. The largest model to be mapped is expected to be composed of circa 500 entities where each entity could have up to around 650 attributes. Similarly, the tool should be able to scale in terms of the number of models it can handle. It is currently believed that there will be fewer than 10 large models.

Lot 3 – Data Catalogue - The FCA requires a tool that will provide a fully integrated data catalogue to assist users to identify, locate and use data more efficiently and understand the data that already exists within the FCA (including key characteristics pertaining to that data). The FCA expect the Data Catalogue to support implementation of our data governance capability, including, but not limited to:

oMetadata Management (including Data Lineage)

oData Ownership

oData Quality

Lot 4 – Data Quality - The FCA requires a dedicated Data Quality Tool that will integrate across all data pipelines to assess the quality of data. The tool will support the remediation of identified issues where appropriate and provide business users with scorecards and indicators to report the quality of our data. We expect the Data Quality tool to support implementation of, but not limited to:

Data Quality Profiling

Data Quality Rules (validation)

Data Quality monitoring (through dashboard, with the functionality to integrate with our visualisation tool i.e. Tableau)

Lot 5 – Salesforce Model Reverse Engineering – The FCA wishes to take the structural and descriptive metadata from a Salesforce instance (Production or Sandbox) and create an analogous relational data model for use within a relational data modelling tool. The Salesforce Model Reverse Engineering Tool should also be able to process the Salesforce metadata. For example, we would like to be able to have rich facilities to filter out objects based on naming conventions. The main use cases envisaged for this tool include:

Reverse-engineering of a Salesforce instance’s metadata to create a relational data model of the instance suitable for use in a data modelling tool. This requirement is fundamental.

Comparing Salesforce instance metadata so we can identify differences, similarities between two instances.

The creation of Subject Areas (i.e. views of a subset of the Objects and Relationships of a Salesforce instance) prior to the creation of the corresponding relational data model.