Solution Design Document Template#
- Solution Design Document Template
- 1. Introduction
- 2. High-Level Architecture
- 3. Business Architecture Context
- 4. Data Architecture Context
- 5. System Context
- 6. Security and Governance
- 7. Abbreviations
- 8. References
- 9. Revision History
1. Introduction#
1.1 Purpose#
Provide a high-level overview of the solution — purpose and functionality,what it aims to solve, which domain is covered, and the business value it brings.
Example
This document outlines the solution design for the implementation of a centralized Customer Master Data Management (MDM) - Application ID ( Provide Service Now ID). The solution aims to create a single, trusted source of truth for Health Care Professionals (HCPs) and Health Care Organizations (HCOs), enabling consistent, high-quality customer data across geographies. This master data will serve as a foundation for the Salesforce CRM , powering use cases across sales, marketing, and field operations.
1.2 Scope#
Define the boundaries of implementation in terms of functionality, geography, and systems.
Example
Addresses will be maintained as a dependent child entity of the Customer master. They will not be mastered as a standalone domain or shared across customers. The solution will not resolve, deduplicate, or consolidate address records across systems.
2. High-Level Architecture#
The high-level architecture provides a comprehensive overview of the Solution, illustrating its journey from origin to consumption.Describe the technical landscape, including how Informatica IDMC components interact with source and target systems. Include a visual architecture diagram.
Example
2.1 Implementation Constraints & Assumptions
This section captures specific design and implementation decisions that intentionally deviate from the Architectural Decision Record (ADR) defined in the MDM Platform Document. These deviations are based on current project requirements and pragmatic considerations at the time of design.
Scope of Constraints
-
Records all solution-level choices that differ from the platform’s reference architecture.
-
Highlights trade-offs and rationale to support future impact assessments.
Example Deviation
Eventing Approach:
ADR Recommendation: Build a downstream integration using a Kafka-based event solution to enable publish/subscribe scalability. Current Design Decision: Implement a point-to-point interface instead of Kafka. Rationale: At present there is only a single known consumer for the data feed. The additional complexity and operational overhead of a Kafka event solution is not justified for this use case.
Assumptions
Downstream consumption patterns will remain limited to a single consumer in the foreseeable future. If multiple downstream consumers emerge, the team will revisit the event-driven approach and realign with the platform architecture.
3. Business Architecture Context#
Capture how the system aligns with the organization’s business architecture.Outline the key business processes that will be supported by the solution . This section can include the User groups - Key teams, departments, or business units that rely on the system.
Example
The MDM solution acts as the central source of truth for external Healthcare Professionals (HCPs) and Healthcare Organizations (HCOs), enabling consistent, accurate, and compliant data across all Commercial systems and processes.
4. Data Architecture Context#
Capture how the system aligns with the organization’s data architecture.Detail the master entities, their relationships, and key attributes to ensures a shared understanding of the core data structure.
4.1 Data Model#
Physical Data model for all the components/areas, such as MDM Model, error model, publish data model.
4.2 Master Data Domains#
List and define key domains(Customer, product, location etc.) and clarify the scope for each domain (global, regional, LOB specific) and the Data standards followed by the domain (example - Product follows the IDMP standard)
Example
| Data Domain | Description |
|---|---|
| Health Care Organization(HCO) | Any legal entity that is a healthcare, medical or scientific association or organization (irrespective of the legal or organizational form) such as a hospital, clinic, foundation, university or other teaching institution etc. through which one or more Professionals provide services.Includes Legal entities, departments, locations and HCO-HCO affiliations. |
| Health Care Professional(HCP) | Any natural individual or person that is a member of the medical, dental, pharmacy or nursing professions or any other person who, in the course of his or her professional activities, may prescribe, purchase, supply, recommend or administer a medicinal product.Includes profile, specialty, licenses, address and HCP - HCO affiliations. |
List all the reference data used within the system.
Example
| Reference Data Domain | Description |
|---|---|
| Country Codes | ISO 3166 (e.g., US, IN, DE). |
| Specialties | Mapped to internal codes and EMA SPOR where available. |
4.3 Data Source#
Source Systems and the data entity provided by them.
Example
| Data Source | Data Domain | Volume |
|---|---|---|
| IQVIA One Key | HCO and HCP data and their affiliations | HCP - 6 million , HCO - 3 million |
| MedProd | HCP Specialty | HCP - 1 million |
4.5 Data Consumers#
Consumer Systems and the data entities consumed by them
Example
| Data Source | Data Domain |
|---|---|
| IO Engage | HCO and HCP data and their affiliations |
5. System Context#
5.1. High-Level Solution Architecture Overview#
This section will provide a high-level design solution overview, highlighting all actors, applications, and interfaces involved, with detailed descriptions and data flow outlined in the subsequent sections.
5.1.1 Roles :#
Detail out the roles created as a part of this Solution and the access and permission for the roles
Example
| MDM Role Name | Novo Access Role Name | Description | Privileges | Responsibilities |
|---|---|---|---|---|
| HCP Data Steward | OneHCP Data Steward | Resolve match exceptions, validate attribute changes, manage reference data | The Data Steward can add , edit data. | Data Steward |
| Country Data Reader | OneHCP Data Reader | Read and search for data | The Country Reader can navigate through its country Customer universe only. | Data Reader |
5.1.2 Key Process :#
This section should cover the key flows in the Solution . * Flows from ingestion to publishing * Key processing points (DQ, match, workflows) * Triggers or decision points * Use arrows and labels clearly * The diagram can either be in the form of Swimlanes or a Sequence diagram
Example
Note - This is just a sample simplified flow
The key flows of the solution are:
6.1.1.3. Daily Data Load of Workplace and Individuals from Onekey to MDM
Then describes each of the following flows
6.1.1.3. Daily Data Load of Workplace and Individuals from Onekey This flow aims to synchronize Customer MDM with daily updates from IQVIA Onekey for HCP and HCO. Scheduled once daily, the flow retrieves all delta data for from Iqvia Onekey F14 Files . The delta data in identified from the last ingestion date which is stored in an audit table. The data is loaded into landing tables which is then transformed via CDI mapping to the logical Data format and the data is extracted to files in an S3 system . Data is then loaded via Ingress jobs into MDM.
5.1.3 Data Quality Management :#
The Data Quality Management section should cover how data is validated, monitored and remediated to ensure accuracy, completeness, and readiness for mastering.
!!! example
* Data Quality rules and Standards implemented during ingestion.
* How the solution identifies and remediates poor-quality records.
* Any stewardship workflows for correction.
* KPI s created on Data Quality if any .
* Tool Used (e.g., Address Verification using Informatica DaaS)
5.1.4 Match and Merge :#
Describe the purpose and logic used in the Solution to identify duplicate records and create golden records,this may include
- Overview of match rules
- Matching techniques used (deterministic, probabilistic)
- Match thresholds and review rules
- Survivorship rules and attribute-level logic
- Handling of Potential Match
- Unmerge
!!! example
Overview of match rule
| Rule Type | Entity | Rule Logic | Threshold | Auto-Merge | Steward Review | Survivorship Rule |
|---|---|---|---|---|---|---|
| Exact | HCP | Exact match on NPI | 100% | Yes | No | Refer to survivorship matrix in appendix for more details. |
| Fuzzy | HCP | Full Name Fuzzy Logic + exact email + Address match using fuzzy logic | > 90% | Yes | No | Refer to survivorship matrix in appendix for more details. |
| Fuzzy | HCO | Fuzzy match on name + postal code | 85-90% | No | Yes | Refer to survivorship matrix in appendix for more details. |
**Blocking Strategy**: Match only within same country
Business Events are created for the potential matches, routed for review to data stewards to
- Approve and merge
- Reject and keep separate
To manually reverse an incorrect or unintended merge of records,unmerge option is provide to data stewards to restore the original source record and publish to re-align downstream data consumers .
5.1.5 Workflows :#
Outline the workflows available in the Solution
- Types of workflows implemented (e.g., match review, attribute approval)
- Trigger mechanisms (e.g., auto-rule failure, steward action)
- SLA, notifications and task escalation logic
- Include who triggers workflows, what forms they see, and how tasks flow.
!!! example
| Workflow Name | Trigger | Steps | Roles Involved | SLA/Escalation |
|---|---|---|---|---|
| Duplicate HCP Review | Match score 85–94 (not auto-merged) | Notify steward → review candidates → merge or mark as false positive | Data Steward | 3 days / auto-escalate to Reviewer |
| Attribute Change Approval | Request to update Specialty or License | User submits → Steward reviews → Commit | Data Steward | 5 days / auto-close if no response |
| Reference Data Addition | New Specialty not found in lookup table | Steward request → Governance council reviews → Approves and adds | Steward, Governance Council | 7 days |
5.1.6 UI configuration :#
Provide an overview of screens available ,who uses the screens (roles),is the screen editable or read-only and the view configurations for different personas.
!!! example
* **Search & View HCP**: Search by name, NPI, location. View golden record, lineage, match group.
* **Task Management Dashboard**: Prioritized task queues for stewards with filters and batch operations
* **Golden Record Edit Screen**: Editable fields with role-based access, change tracking, and audit logs
* **DQ Dashboard**: Summary view of data quality scores, trends, and rule failures
* **Relationship Viewer**: Hierarchial UI to display HCP–HCO, HCO–HCO relationships
* **Localization**: UI configured for multi-language support and localized field values
5.1.7 Reference Data Management :#
Describe how standardized reference values are governed, maintained, and used in the Solution.
!!! example
List of reference data used , where it is sourced from and the governance.
| Reference data Domain | Source System | Authoritative System | Governance |
| ------------------------ | ------------- | -------------------- | ---------------- |
| Medical Specialty | IQVIA ,Medpro | R360 (Reference 360) |R360 Workflows |
| Country Codes | ISO 3166 | R360 (Reference 360)| R360 Workflows |
5.2. Interfaces#
An Interface defines the data and technical integration points between two or more application components, detailing how components communicate, exchange data, or provide functionality to enable seamless processes and workflows. It captures the technical communication layer between applications and components, including protocols, integration methods, and data flows.
5.2.1 Inbound Interfaces#
| Attribute | Example |
|---|---|
| Interface ID or Name | - ID or name of the interface that can be used to map it with the Solution design diagram |
| Purpose | - The business or technical need the interface fulfills, for example: Enable real-time customer data ingestion from Onekey. |
| Interface Pattern | - The integration pattern utilized, for example: Batch - File-based, Event - Kafka, or API - MuleSoft. |
| Protocol/Format | - Specifies the data transfer method, such as REST API, SOAP API, Secured File Transfer Protocol (SFTP), Message Queues, etc. |
| - The format in which data is shared, for example: JSON, XML, CSV/Flat File, or Parquet. | |
| Frequency | - Specifies how often the interface is used for communication, such as Real-time, Daily, Weekly Batches, or Ad-Hoc. |
5.2.2 Outbound Interfaces#
| Attribute | Example |
|---|---|
| Interface ID or name | - ID or name of the interface that can be used to map it with the Solution design diagram |
| Purpose | - The business or technical need the interface fulfills, for example: Enable real-time customer data ingestion from Onekey. |
| Interface Pattern | - The integration pattern used, for example: Batch - File-based, Event - Kafka, or API - MuleSoft. |
| Protocol | - Specifies the data transfer method, such as REST API, SOAP API, Secured File Transfer Protocol (SFTP), Message Queues, etc. |
| - The format in which data is shared, for example: JSON, XML, CSV/Flat File, or Parquet. | |
| Frequency | - How often the interface is used for communication, for example: Real-Time, Daily, Weekly Batches, or Ad-Hoc. |
5.3 Dependency#
Dependencies refer to the relationships and interactions between various application components, systems, or technologies. These dependencies help users identify which applications rely on one another for functionality, data, or integration. Understanding these dependencies is crucial for tracing impacts if a dependent application becomes unavailable or is decommissioned, as well as for identifying unnecessary dependencies or redundancies across systems.
| Attribute | Description |
|---|---|
| Dependency Type | Specify the type of dependency: Upstream, Downstream, or Platform. |
| Description | Describe the nature of the dependency (e.g., data flow, API interaction, manual sync). |
| Criticality | Classify how critical the dependency is: "High", "Medium", "Low". |
| Data/Integration Type | Specify the method of integration: Batch, Real-Time, API-based, Files, etc. |
| Business Dependency | Identify the business processes or functions relying on this dependency (e.g., Compliance Reports). |
6. Security and Governance#
The purpose of this section is to define how the MDM solution ensures data protection, access control, compliance, and auditability across the data lifecycle. Mention how compliance requirements if any including GDPR, GxP, and PII handling is covered either using platform-native capabilities (such as role-based access and encryption) or customized solution.
7. Abbreviations#
8. References#
| Documents | Reference | Owner |
|---|---|---|
| Infrastructure Architecture /Platform Document | - Link to Infrastructure document that would cover the describe the underlying infrastructure that supports the solution | -- |
| Business Glossary | - Link to document | --- |
| URS | - Link to URS | --- |
| Functional Specification | - Link to document | --- |
| Source to Target Mapping Document | - Link to document | --- |
| Reference Data Mapping Document | - Link to document | --- |
| DQ Rules Template | - Link to document | --- |
| Trust Score Matrix | - Link to URS | --- |
| Data migration plan | - Link to document | --- |
| Requirements traceability Matrix | - Link to document | --- |
| Notification Approach | - Link to document | --- |
| Job Scheduling | - Link to document | --- |
9. Revision History#
Keep track of changes to the document and the contributors.