The core deliverables of this programme are Data Migration from legacy systems and Master Data Management aligned to an Enterprise Data Model. The solution will provide for the monitoring and ownership of data quality within the organisation as aligned to key performance indicators and governance frameworks. The objective of the GPAA Modernisation Programme EDM deliverable is to establish and operationalise the management of information during the entire life cycle, including data creation, processing, consumption, storage, archiving and disposal.

The scope of the project includes the following services:

• Profiling of data in order to classify information and capture data quality rules for the identified data sets
• Identification and prioritisation of data sets to be cleaned
• Creation of data quality reports, data cleansing mechanisms and remedial plans
• Data cleansing and enrichment execution
• Migrate information from legacy systems
• Implementation of Master Data Management to provide a single view of information and to provide the GPAA with data maintenance and monitoring capabilities
• Automation of ETL processes of information from external sources
• Creation of an Enterprise Data Model with common taxonomy for business and data rules
• Definition of a strategy to sustain/embed/operationalize data maintenance within the GPAA
• Definition of a data and information architecture that delivers operational, tactical and strategic quality information for analysis and decision making
• Exposing and dissemination of migrated information to operational, strategic and corporate domains

The following strategic benefits will be delivered:

• To provide a single view of the customer
• To pay the right person, the correct amount, at the right time
• To administer funds at an economically acceptable cost per member

• Functional Requirements
  • • Data Migration

      • The migration of information from the current systems will include data analysis, profiling, classification, cleansing and transformation. The current information producers are a combination of internal and external sources. Internally the GPAA stores information on Oracle databases, as well as on a mainframe system that runs on a Z/OS operating system with Natural programs connecting to an Adabas database version 8.2.6.

        • Infomet shall provide a migration strategy and approach
        • Data should be cleansed according to the GPAA administrative rules, statutes, policies and business rules
        • On-going data audits shall be conducted against all identified data sources during the cleansing process
        • A data analysis report shall be provided from the data audit (e.g. description of problem, data source, number of occurrences, impact on production data, type of fix that was applied, number of records fixed, and number of records unable to be fixed)
        • Provide reconciliation reports to ensure counts and totals between source and target
        • Infomet shall retain history (audit trail) of all data elements that are changed through
        • cleansing (before and after)
        • Infomet shall provide the testing process, including the test plan, test cases, test scenarios and expected results for the migration
    • Master Data Management

      • Business critical data is fragmented and spread across various departments, functions, processes and systems. To enable data ownership and stewardship, GPAA requires all the critical data entities in a central repository from which a single or 360-degree view of the data is created so that the business owner does not have to go from one system to another to verify its accuracy, completeness, conformity and integrity of the data.

        • The solution should be able to manage multiple business entities.
        • Support best practice data governance policies and processes including control and auditing capabilities.
        • Integrate to the GPAA security and reporting tools to provide fine-grained access to data and reliable data quality metrics.
        • Provide a workflow capability including the creation and authorisation of reference data and data definitions, and automatic notification of data quality issues.
        • Automatically generate changes to data services whenever the data model is updated with new attributes, entities, or sources.
        • Should support a combination of matching techniques (deterministic, probabilistic, heuristic, phonetic, linguistic, empirical, etc.) with each able to address a particular class of data matching.
        • The solution should be able to automatically create a golden record for any data entity and provide a robust unmerge functionality in order to rollback any manual errors or exceptions.
        • The history of all changes to data and the lineage of how the data has changed needs to be captured as metadata.
        • Reference data should be managed and maintained in a central repository to enable reuse across processes and applications.
    • Enterprise Data Model

      • The enterprise data model is simply a canonical or standard model of the common data objects or entities and their key attributes that are required to run GPAA. In order to have a central repository (MDM), especially where data is fragmented and spread across various systems, it is important that stakeholders speak a common language. The EDM solution should facilitate this via an Enterprise Data Model around which common business and technical terminology can be created and linked together. The GPAA requires a defined metadata function to manage the technical, operational, and business metadata. Technical metadata should include legacy platform fields and definitions. Operational metadata should include data transfers, movement, and mapping, while business metadata encompasses business glossary and the common vocabulary.

    • Data Quality Monitoring

      • Quality of data has a direct impact on how well GPAA performs. The GPAA needs to monitor data quality metrics which is linked to key organizational and individual performance indicators. The EDM solution should provide reports and dashboards that reflect these data quality metrics and known data issues so that stakeholders can perform the required data quality monitoring and react appropriately. Information should be available for trending and forecasting.

• Achitectural Requirements
  • • Operational Requirements
      • • System stability and availability should adhere to the GPAA requirements and Service Level Agreements
        • Solution should support full redundancy.
        • Solution should expose sufficient and useful instrumentation to perform system monitoring, debugging and performance tuning.
        • Solution should be deployed on-site.
        • Solution should be able to handle increases in load without impact on the performance of the system, and provide the ability to be readily enlarged.
    • Authentication and Authorisation
      • • Integrate into the Oracle Identity and Access Management system for all identity management and role-based access functionality.
        • Ensure Role-based Access Management is applied using single sign on (SSO)
    • Integration
      • • Solution must provide the ability to communicate and exchange information with other systems.
        • Architecture should enable seamless integration of applications within the landscape.
        • Applications, as providers should be decoupled from consumers based on SOA principles to promote the introduction of new applications.
        • Real-time / messaging integration should be completed using the ESB.
        • Services should encompass business functions. These services should be available for application and process consumption.
        • Services should be discoverable to enable business process management.
        • Application interfaces and services should be reusable. They should contain a sufficient level of isolation to enable versioning.
    • Data Architecture Requirements
      • • Solution must allow integration of OBIEE for MIS
        • Bulk data movements should be visible within the Business Activity Monitoring component of the ESB.
        • Utilise data integration monitoring tool to view data transfers across batch and real-time messaging. This is necessary to create a single and consolidated view of data flows across a process.
        • Business process management requires real-time data in order to drive process optimisations.
        • The architecture should contain a repository of transactions and events that are in flight, completed, cancelled and failed.
        • Valid and accurate data sources such as Excel and Word documents should be accepted as data sources to the Reporting Architecture.
        • Consolidate financial information to a single repository for accurate and timely financial reporting.
        • Structured and unstructured content should be integrated to the overarching correspondence and administration processes.
        • Data should be available and understandable for discovery.
        • Historic information should be available for extraction into other tools for trending and forecasting.
        • Architecture should integrate into a centrally maintained user authorisation and authentication component. User access to data should be controlled within central location and not managed within reporting solution.
        • Information integrity should be maintained, while information should be guarded against improper modification or destruction. This must be underpinned with non-repudiation and authenticity within the architecture.
        • Information should remain confidential when required due to either member preference or legislation. Implies, preserving authorised restrictions on access and disclosure, including means for protecting personal privacy and proprietary information. Information classification should be enabled within the architecture to control user access.
        • All access to member information should be tracked and logged for auditing purposes.