Solution Design#
Overview#
Solution Design is the critical phase where your finalized requirements are transformed into a comprehensive technical blueprint. This phase bridges the gap between business needs and implementation, resulting in detailed architecture documentation and formal approval through the Technical Design Authority (TDA) process.
What you will learn#
After completing this chapter, you will understand how to:
- Transform requirements into detailed technical architecture designs
- Create comprehensive data models that support scalable data products
- Design robust data contracts and lineage mechanisms for NNDM integration
- Navigate the Technical Design Authority approval process effectively
- Document architectural decisions using Architecture Decision Records (ADR)
- Plan integration patterns and data governance frameworks
- Prepare detailed implementation blueprints for development teams
Key Personas & Stakeholders - RACI Matrix#
| Activity | Solution Architect | Data Engineer | Data Product Manager | Business Analyst | GDAI Architecture Team |
|---|---|---|---|---|---|
| Low-Level Design Creation | R | R | C | I | C |
| Data Modeling | A | R | C | C | C |
| Data Contract Design | C | R | A | C | C |
| ADR Documentation | A | R | C | I | C |
| TDA Submission | A | C | C | I | C |
| TDA Review & Approval | A | R | I | I | A |
| Design Updates Post-TDA | A | R | C | I | C |
R = Responsible, A = Accountable, C = Consulted, I = Informed
Prerequisites#
- Completed: Finalized Requirements Specification with stakeholder approval
- Available: Feasibility Assessment outcomes and high-level architecture
- Access: Solution Architecture Template
- Knowledge: Understanding of ingestion patterns and medallion architecture principles
- Tools: Access to design tools, ADO/Git for ADR management, and documentation platforms
- Access to enterprise reference models and Erwin tool. Refer to Enterprise Data Model Hub for instructions to install and access Erwin
Key Foundation Documents
Ensure you have access to the high-level architecture from feasibility assessment and the detailed requirements specification before beginning solution design work.
Step-by-Step Process#
Step 1: Architecture Foundation Setup#
Objective: Establish the architectural foundation by refining high-level designs into detailed technical specifications.
-
Review and Refine High-Level Architecture:
- Take the high-level architecture from feasibility assessment
- Identify areas requiring detailed specification
- Map requirements to architectural components
-
Define Solution Components:
- Data Sources: Detailed specifications of all source systems
- Integration Layer: APIs, connectors, and data ingestion mechanisms
- Processing Layer: Transformation engines, compute resources, and orchestration
- Storage Layer: Data lakes, warehouses, and persistence strategies
- Consumption Layer: APIs, dashboards, and output interfaces
-
Apply Architectural Patterns:
- Implement medallion architecture (bronze, silver, gold layers)
- Define microservices boundaries where applicable
- Plan for scalability and fault tolerance
Architecture Best Practice
- Use the Solution Architecture Template as your starting point to ensure consistency with organizational standards.
- Use Design Document Template to update key design discussions and steps
Expected Outcome: Detailed architecture diagram with component specifications and integration flows.
Step 2: Data Modeling and Schema Design#
Objective: Create comprehensive data models that support your data product requirements while enabling future scalability.
Logical Data Modeling:
- Import the approved conceptual model into Erwin
- Expand entities with attributes, data types, and business rules
- Define primary and foreign key relationships and cardinality
- Document assumptions and design decisions for traceability
- Determine level of normalization needed in each layer (bronze, silver or gold). Typically bronze is a straight dump from source, silver follows more ER style modelling while Gold has more dimensional modelling to cater to different needs.
- If the data product can have multiple Gold Products, then consider silver to have the dimensional modelling.
Learn more about logical data modeling here.
Physical Data Modeling:
- Define partitioning strategies for performance
- Plan indexing and optimization approaches
- Design for incremental processing patterns for example control tables.
Learn more about about physical modelling here.
Data Model Documentation:
- Entity relationship diagrams
- Attribute definitions and business rules
- Data lineage mapping
- Scalability considerations
- EDM Learning & Support Page – Refer to this page for foundational knowledge on data modelling concepts and step-by-step guidance on navigating the Erwin tool
Model Validation:
- Review with business stakeholders for accuracy
- Validate against source system capabilities
- Ensure compliance with data governance standards
Critical Success Factor
Reference the Data Modeling Best Practices document to ensure your models follow organizational standards and can accommodate future requirements.
Expected Outcome: Complete logical and physical data models with comprehensive documentation
Step 3: Data Contract and Lineage Design#
Objective: Design robust data contracts and establish mechanisms for tracking data lineage throughout the data product lifecycle.
-
Input Data Contracts
-
Processing Data Contracts:
- Define transformation rules and business logic
- Specify quality validation requirements
- Document error handling procedures
-
Output Data Contracts:
- Define consumer interface specifications
- Establish SLA commitments
- Document usage patterns and limitations
-
Lineage Mechanism Design:
- Plan automated lineage capture points
- Design metadata storage strategy
- Define lineage visualization approaches
Expected Outcome: Comprehensive data contracts covering all pipeline stages with automated lineage tracking design
Step 4: Integration and Security Architecture#
Objective: Design secure, efficient integration patterns and implement comprehensive security measures.
-
Integration Architecture:
-
Source System Integration:
- API specifications and authentication methods
- Batch vs. streaming ingestion patterns
- Error handling and retry mechanisms
-
Internal Integration:
- Service-to-service communication patterns
- Event-driven architecture considerations
- Data synchronization strategies
-
-
Security Architecture
-
Compliance Design:
- GDPR/privacy regulation compliance
- Industry-specific compliance requirements
- Audit trail and logging strategies
Expected Outcome: Detailed integration patterns with comprehensive security and compliance measures
Step 5: Requesting assistance from GDAI Architecture Team or suggesting improvements based on design (optional)#
In case the Data Product Technical Team encounters a platform related problem or is having difficulty selecting a tool for a particular use-case or has figured out a smarter solution to existing platforms' restrictions, an ADR can be raised to GDAI Architecture as outlined here
Step 6: Architecture Decision Record (ADR) Creation#
Objective: Document all significant architectural decisions with rationale and alternatives considered.
-
ADR Structure Setup: Follow the GDAI Architecture ADR process for consistency.
-
Key ADRs to Create
-
Document Design Decisions:
- Technology stack selections
- Architecture pattern choices
- Security approach decisions
- Performance optimization strategies
Expected Outcome: Complete set of ADRs documenting all major architectural decisions
Step 7: Technical Design Authority (TDA) Preparation and Submission#
Objective: Prepare comprehensive documentation for TDA review and successfully obtain architectural approval.
-
Pre-TDA Review:
- Validate design against TDA template requirements
- Conduct internal review with solution architects
- Address any obvious gaps or inconsistencies
-
TDA Submission Package:
- Executive Summary: High-level overview and business justification
- Detailed Architecture: Complete technical specifications
- ADR Collection: All architectural decision records
- Risk Assessment: Identified risks and mitigation strategies
- Implementation Plan: High-level delivery approach
-
TDA Presentation Preparation:
- Create clear, concise presentation materials
- Prepare for common TDA questions
- Have technical deep-dive materials ready
TDA Success Tips
Review previous successful TDA submissions for similar projects. Focus on clearly articulating the business value and technical rationale for your architectural choices.
Expected Outcome: TDA submission package ready for formal review
Step 8: TDA Review and Design Refinement#
Objective: Successfully navigate the TDA review process and incorporate feedback into final design.
-
TDA Review Process:
- Present design to TDA board
- Address questions and concerns
- Provide additional clarification as needed
-
Incorporate TDA Feedback:
- Update architecture based on TDA observations
- Revise ADRs to reflect approved changes
- Update requirements specification if needed
-
Final Design Approval:
- Obtain formal TDA approval
- Document any conditions or recommendations
- Update project documentation with approved design
-
Post-TDA Activities:
- Communicate approval to delivery team
- Update project plans based on final design
- Begin detailed implementation planning
Expected Outcome: TDA-approved solution design ready for implementation
Success Metrics & Checkpoints#
- Architecture Completeness: All system components and integrations fully specified
- Data Model Validation: Logical and physical models reviewed and approved by stakeholders
- Data Contract Definition: Complete contracts covering all pipeline stages
- Security Compliance: All security and compliance requirements addressed in design
- ADR Documentation: All major decisions documented with clear rationale
- TDA Approval: Formal architecture approval obtained from TDA board
- Design Traceability: Clear mapping from requirements to architectural components
Common Challenges & Solutions#
-
Challenge: Requirements changes during design phase affecting architectural decisions
Solution: Implement change control process with formal approval for scope modifications
Prevention: Ensure requirements are thoroughly validated before beginning detailed design -
Challenge: TDA feedback requiring significant architectural changes
Solution: Engage with GDAI Architecture team early for informal review and guidance
Prevention: Use established patterns and reference architectures as starting points -
Challenge: Complex integration requirements with legacy systems
Solution: Design abstraction layers and implement staged migration approaches
Prevention: Conduct thorough analysis of existing systems during feasibility assessment -
Challenge: Balancing performance requirements with governance and security needs
Solution: Work closely with governance and security teams to find acceptable compromises
Prevention: Include all stakeholders in early design discussions
Next Steps#
After obtaining TDA approval and finalizing your solution design:
- Update Project Documentation: Ensure all project artifacts reflect the approved design
- Begin Detailed Implementation Planning: Break down the design into specific development tasks
- Set Up Development Environment: Configure infrastructure and tools based on approved architecture
- Initiate Data Marketplace Registration: Begin the process to register your data product for discoverability
The next phase will focus on Building the Data Product based on your approved solution design.
Additional Resources#
- Solution Architecture Template
- GDAI TDA Process Guide
- ADR Creation Guidelines
- Data Modeling Best Practices - link to come
- Ingestion Patterns Reference - link to come
- Unity Catalog Security Patterns - link to come