Skip to content

Implementation Flow

Go to Playbook Main Page
Prev: Design
Next: Validation

Implementation#

Hold "Alt" / "Option" to enable Pan & Zoom
lifecycle

Key Ideas

  • Ensure the Requirements Specification is aligned and the Delivery Team is allocated.
  • Secure the Technical Prerequisites for every team member.
  • Align on and adhere to branching, review, release, and other SDLC strategies; stick to best practices.
  • Unit Testing: Test each component of the solution independently (e.g., match/merge logic, transformation rules).
  • Plan for Acceptance(validation, sign-off criteria).
  • Plan for Launch (go-live readiness).
  • Plan for the Support Period (post-launch maintenance and monitoring).

Roles Involved Involved#

  • Accountable: Solution Architect
  • Responsible: Data Engineer
  • Consulted: Business Analyst, Data Governance Lead,Product Owner

1. Input#

What’s needed to start building the solution

Category Input
Design Documents - Solution Design Document
- Logical & physical data models
- Design Specification documents must be prepared for the key components of the MDM solution, including Ingestion, Match/Merge logic, and Publish mechanisms.
- Integration design document
Source System Metadata - Field mappings
- Data ingestion formats
- Transformation logic
Business Rules and Workflows - Data validation rules
- Enrichment logic
- Stewardship task flow definitions
Security Requirements User roles, access controls
Technical Environment - Dev/Test environments provisioned
- Installed Informatica MDM Hub/MDM SaaS, CAI,CDI, CDQ modules
- Access to TIMS
Access to leap work
Onboarding Details
Naming Conventaions Naming Conventions
Test Plan Test strategy and test plan document

2. Process#

Key Build Activities using MDM Platform

Step Description
MDM SaaS Configuration - Define entities, attributes, relationships, business rules, events, reference data, connections, and hierarchies.
Match/Merge Rule Development - Implement match paths, key generation logic, merge rules, and survivorship strategies.
Data Ingestion Workflows - Build CAI or CDI pipelines to ingest data from source systems into the Hub staging area.
Data Transformation and Cleansing - Clean, format, and enrich data using CDQ, CDI, or CAI.
Business Rule Configuration - Set up validation rules, dropdowns, lookups, and transformation logic.
Workflow Implementation - Configure user task flows to support data stewardship and exception handling.
Security Setup - Define user roles, assign permissions, and configure record- and attribute-level access.
API and Integration Development -Enable REST APIs and configure integrations using real-time messaging (e.g., Kafka, MQ).
Unit Testing - Test each component (e.g., match rules, ingestion jobs, workflows). IDMC-Unit-Testing
Test Scripts and Test Data - Update test cases as needed and prepare sample data for validation.
Regression Test Cases and Test Bed - Update test cases if required based on the build
- Update regression test bed to be used in the validation phase
---

3. Output#

Tangible deliverables and working components produced during this phase

Output Description
Configured MDM microservice - All data model objects, match/merge rules, validation logic implemented
Data Integration Jobs - CAI/CDI jobs built and tested for data ingestion/export
Matching/Survivorship Configs - Validated and optimized match rules and survivorship strategies to ensure accurate golden record creation
Business Rule Engine Configs - CDQ rule sets, exception handling, scorecards
Stewardship Workflows - User interface and task flow logic for data approval/curation
User Roles and Access Config - Role-based access to entities, fields, and stewardship actions
Working APIs - Configured REST/SOAP endpoints and integration points
Unit Test Results - Pass/fail status for all build components with test data logs
Test Bed - Test data created for System validation and Regression Testing

For further detail on supporting components and system behaviors, see the following sections:

What Happens Next?#

After the implementation phase , the Validation Phase kicks in
- OQ activities begin, including functional, data quality, and workflow validation.
- Business users and data stewards perform PQ to confirm data accuracy and rule enforcement.
- Approval workflows and governance checkpoints are executed to confirm readiness for production.
- Deployment is planned and executed, transitioning the solution into a live, governed production environment.

Next: Validation

Backlog Shaping#

Implementation begins with Backlog Shaping. The person responsible for delivery, typically the Product Owner or a lead Data Engineer, prepares the tickets based on the Requirements Specification.

Each ticket must be clearly justified by referencing definitive documentation, such as: - The Requirements Specification - Corporate, line-of-business, or platform-level policies and standards

These references serve as the source of truth for: - Testing and quality assurance - Acceptance criteria

Because documented requirements may evolve over time, the following best practices are recommended:

  • Include the relevant requirement text directly in the ticket body.
  • Any changes to a ticket or its underlying requirements must be accompanied by a clear explanation for historical traceability.

All tickets should be reviewed by the delivery team - both leads and contributing members. These reviews serve two key purposes:

  1. Clarify ambiguities: Any uncertainties must be resolved, and both the ticket and Requirements Specification should be updated accordingly.
  2. Assess delivery effort: Estimating the capacity required for each ticket supports more accurate sprint or milestone planning.

Development#

Development follows established Software Development Life Cycle (SDLC) best practices and aligns with the company’s adopted strategies for:

  • Versioning and branching
  • Code styling and standards
  • Code review procedures
  • Automated and manual testing
  • Release management
  • CI/CD processes
  • And other relevant practices

Typically, development is supported by isolated environments for: - Development - Validation(Testing) - Production

Once a developer completes a ticket and marks it as ready for testing, the feature is deployed, either automatically via CI/CD or manually, to the Testing environment. There, it is validated against the requirements. Based on the outcome:

  • If successful, the feature progresses to the Validation environment.
  • If not, it is returned to development with comments for refinement.

Once accepted in PQ, the ticket is marked Ready for Production and is propagated according to the defined release policies and CI/CD workflows.


MDM SaaS Application Initialization: Best Practices#

Best Practices for Application Initialization#

  • Ensure all Business 360 processes under Application Integration are in published state.
  • Org should be upgraded to the latest release of Business 360.
  • Org state should ideally be "ORG_PROVISIONED" (optional).
  • Activate the Admin user via CSM, and:
  • Assign the admin role
  • Assign a group to users who will set up the application
  • Create new projects for additional assets like:
  • Mappings
  • Mapping tasks
  • Taskflows
  • Other MDM SaaS assets
  • Avoid using predefined projects like:
  • Business360
  • Reference360
  • Customer360
  • Do not add permissions to predefined projects in the Explorer page in MDM SaaS.

Unit Testing in IDMC#

Unit testing in Informatica Intelligent Data Management Cloud (IDMC) ensures that individual components/functions of the system work as expected and meet business requirements. Below are detailed steps for performing unit testing in IDMC's key modules: CDI (Cloud Data Integration), CAI (Cloud Application Integration), MDM (Master Data Management), and CDQ (Cloud Data Quality).

1. Unit Testing in IDMC Cloud Data Integration (CDI)#

CDI involves workflows (mappings, tasks, pipelines) for extracting, transforming, and loading (ETL) data.

Steps to Perform Unit Testing:#

  1. Identify Testable Components: - Focus on mappings, workflows, and transformation logic. Examples:

    • Data mappings from source to target.
    • Transformation rules (e.g., aggregation, filtering, lookup functionality).
    • Parameterized mappings (testing both default and dynamic values).

  2. Prepare the Test Data: - Create small, controlled datasets that represent various cases (valid, invalid, and edge cases). For example:

    • Test null values, invalid formats, or outliers for a numeric column.

  3. Isolate and Execute the Mapping: - Run the mapping task with test data in isolated test environments.

  4. Validate Outputs: - Compare the output with the expected results for all transformations, combinations, and data movements. - Areas to test:

    • Filter: Verify that correct rows are filtered.
    • Lookup: Check that lookups return the correct matches (or nulls for non-matches).
    • Aggregator: Validate grouping and aggregation counts/sums.
    • Joiner: Check join conditions (inner, outer, etc.).

  5. Error Handling and Logs: - Test how errors (e.g., null pointer, system unavailability) are handled. - Review the logs to ensure descriptive error messages with traceability.

  6. Automation of Tests: - Use reusable test scripts in advanced testing tools or custom scripts to validate ETL results.

2. Unit Testing in IDMC Cloud Application Integration (CAI)#

CAI handles workflows, API integrations, and real-time event-driven processing across systems.

Steps to Perform Unit Testing:#

  1. Test Individual APIs: - Use tools like Postman or SoapUI to test individual API endpoints for:

    • Response formats (e.g., JSON, XML).
    • Status codes (e.g., 200 OK, 404 Not Found, 500 Internal Server Error).
    • Query parameters or payload validations.
    • Example: Test whether a "GET Customer API" retrieves correct details based on Customer_ID.

  2. Simulate Workflows: - Execute processes in CAI using test input data and validate:

    • Correct sequence of process steps.
    • Expected data transformations at each step.
    • Handling branching conditions (decision-based flows).

  3. Mock External Systems: - For systems not yet available or dynamic integration layers, use mock services to simulate external API responses. - MockAPI or WireMock can be used for mocking external system responses.

  4. Error and Timeout Testing: - Simulate scenarios where external systems are unavailable or slow. - Verify that retry mechanisms and error messages work correctly.

  5. Performance Testing (Optional): - While not strictly a unit test, check execution times of lightweight API requests to ensure they fall within expected limits.

3. Unit Testing in MDM SaaS#

MDM solutions focus on creating and maintaining golden records.

Steps to Perform Unit Testing:#

  1. Test Matching Rules: - Run test cases with both matching and non-matching records to verify:

    • Accuracy of exact matching (e.g., Customer_ID).
    • Accuracy of fuzzy matching (e.g., customer names like "John Doe" vs. "J. Doe").

  2. Validate Survivorship Rules: - Submit conflicting records from two or more sources. - Verify that survivorship rules (e.g., source trust scores, latest update) resolve conflicts correctly.

  3. Golden Record Creation: - Create edge cases with incomplete, duplicate, or conflicting data and test if the MDM system creates golden records as expected.

  4. Hierarchy and Relationships: - Test parent-child relationships (e.g., Account → Customer). - Validate multi-level hierarchies and ensure relationships are being represented accurately.

  5. Integration with Upstream/Downstream Systems: - When ingesting data from sources (upstream systems), validate if the correct golden records are published to downstream consumers .

  6. Data Governance & Audit Logs: - Test data stewardship workflows for acceptance/rejection of records. - Ensure logs provide adequate visibility into changes (e.g., source versions, update timestamps).

4. Unit Testing in IDMC Cloud Data Quality (CDQ)#

CDQ focuses on profiling, cleansing, and validating the quality of data.

Steps to Perform Unit Testing:#

  1. Data Profiling: - Perform profiling on small datasets with known data distributions. - Validate profiling outputs:

    • Percent nulls.
    • Unique/duplicate values.
    • Pattern analysis (e.g., phone numbers, email formats).

  2. Rule Validation: - Test data quality rules against specific data sets. Examples:

    • Validate that Email meets a pattern rule (e.g., abc@domain.com).
    • Enforce minimum completeness thresholds (e.g., >90% of Address fields must be populated).

  3. Data Cleansing: - Test transformations like:

    • Standardizing case (e.g., converting names to uppercase).
    • Splitting, concatenating, and trimming text values.
    • Validate outputs against the expected formats.

  4. Exception Handling: - Insert invalid data (e.g., malformed emails, phone numbers) and test:

    • If the rules catch and log the errors.
    • How invalid records are handled (e.g., flagged, rejected, or passed downstream).

  5. Threshold Validations: - Simulate scenarios violating thresholds (e.g., below 80% product name accuracy) and validate exception handling rules.

Best Practices for Unit Testing in IDMC:#

  1. Isolate Components: - Test components individually to ensure issues are contained and isolated early.
  2. Use Mock Data: - Create small, controlled datasets that cover edge cases, invalid data, and realistic scenarios.
  3. Automate Tests: - Leverage testing tools and frameworks to automate repetitive tests (e.g., regression testing across mappings, APIs, or golden record creation).
  4. Validate Logs & Metrics: - Verify detailed logs for tracing issues when processing fails. - Monitor execution times to ensure configurations are optimized.
  5. Document Test Cases: - Clearly define expected inputs and outputs for each case. - Log defects found during testing for traceability.

Migration Guidelines#

Pre-requisites#

  1. Org Version Compatibility
    - The import file and the target organization must have the same org version.
    - To determine the org version of the import file:

    • Extract the import file and open exportMetadata.v2.json.
    • This file contains the org versions of business applications.
    • To check the org version of the target org:
    • Log in to the application and click on About from the ? (Help icon).

  2. User Access and Roles
    - Ensure you have user accounts in both source and target organizations.
    - The user roles must have export/import privileges, such as:

    • Administrator
    • Or a combination of Designer and MDM Designer roles.

  3. Business Applications Setup
    - Set up licensed business applications (e.g., Multidomain MDM, Customer 360) in the target organization before importing assets.
    - Importing assets before setup may corrupt the organization during initialization.

Initial Code Deployment#

1. Environment Setup (Administrator)#

  • Configure the target environment on the Informatica MDM SaaS platform:
  • Set up connections
  • Configure security settings
  • Ensure readiness for initial deployment

2. Package Creation (Developer)#

  • Create an initial deployment package that includes:
  • Mappings
  • Workflows
  • Custom components
  • Configurations
  • This should represent the baseline state of the codebase.

3. Deployment Plan (Developer)#

  • Develop a plan including:
  • Deployment sequence
  • Rollback strategy
  • Pre- and post-deployment tasks
  • Consider dependencies and impact on data and processes.

4. Deployment Execution (Platform Support)#

  • Deploy the package to the target environment.
  • Validate the deployment to ensure it's functional in SaaS.

5. Testing and Validation (Tester)#

  • Perform comprehensive testing:
  • Functional testing
  • Integration testing
  • Performance testing

Incremental Code Deployment#

1. Change Management#

  • Implement a formal process to:
  • Capture and prioritize changes
  • Track enhancements, bug fixes, and features

2. Development and Testing (Developer)#

  • Develop/test incremental changes in dev or sandbox.
  • Includes:
  • Unit testing
  • Peer review
  • Functional testing

3. Deployment Package Creation (Developer)#

  • Create packages with only the relevant artifacts.
  • Exclude target-specific configurations (e.g., connections) to avoid overrides.

4. Incremental Deployment Execution (Platform Support)#

  • Deploy the incremental changes to the target environment.

5. Validation and Post-Deployment Activities (Tester)#

  • Validate changes are integrated and functioning.
  • Execute post-deployment tasks:
  • Data migration
  • Config updates
  • System checks

6. Monitoring and Feedback (Tester)#

  • Monitor the deployment for stability and performance.
  • Collect feedback from end-users and stakeholders for improvements.

Go Up

Go to Playbook Main Page
Prev: Design
Next: Validation