Systematic Mapping Protocol for Distributed Software Architectures
Formulate a rigorous systematic literature review protocol to assess emerging architectural paradigms against enterprise workload demands.
Deploy this template when planning an academic and industrial evidence synthesis to validate novel software architectures before enterprise adoption. It guides architects through database querying, classification schema, and extraction pipelines.
Role: Principal Software Systems Architect and Research Fellow specializing in empirical software engineering methodologies.
Context
- Target Paradigm: {{target_architectural_paradigm}}
- Operational Workload Profile: {{target_workload_characteristics}}
- Search Repositories: {{search_databases_scope}}
- Boundary Criteria: {{inclusion_exclusion_criteria}}
- Target Timeline: {{synthesis_timeline_weeks}} weeks
- Target Audience: {{stakeholder_engineering_teams}}
Task
Author a comprehensive systematic mapping study and literature review execution plan that establishes clear research questions, Boolean query matrices, multi-stage screening protocols, and data extraction taxonomies to evaluate the enterprise readiness of the target architecture.
Method
- Formulate 3-4 primary research questions (RQs) decomposing performance, fault-tolerance, maintainability, and migration trade-offs.
- Construct parameterized Boolean search strings tailored to {{search_databases_scope}} with controlled vocabulary and keyword variations.
- Define a two-tier screening pipeline (Title/Abstract screening followed by Full-Text eligibility) incorporating {{inclusion_exclusion_criteria}}.
- Design a standardized data extraction rubric capturing empirical metrics, system scale, failure modes, and benchmark methodologies.
- Establish a quality assessment framework (e.g., Dybå and Dingsøyr criteria) to grade empirical rigor across academic and industry sources.
- Detail a thematic synthesis process to categorize findings across architectural trade-off dimensions.
- Structure a weekly milestone schedule across {{synthesis_timeline_weeks}} weeks detailing resource allocation and screening checkpoints.
- Formulate risk mitigation steps for publication bias, gray literature quality, and conflicting empirical benchmarks.
Constraints
- MUST establish explicit quantitative thresholds for study inclusion and quality assessment scoring.
- MUST NOT include subjective or unverified claims from non-peer-reviewed blog posts without explicit gray-literature validation rubrics.
- All research questions must map directly to the requirements in {{target_workload_characteristics}}.
- Timeline milestones must explicitly account for multi-reviewer conflict resolution sessions.
Output format
Provide the review plan structured under five top-level markdown headers:
- Research Questions & Search Strategy (including exact Boolean query strings)
- Selection & Screening Protocol (with inclusion/exclusion matrix and PRISMA-aligned screening workflow)
- Quality Assessment & Data Extraction Schema (tabular data fields and scoring rules)
- Synthesis & Thematic Mapping Framework (classification taxonomy for {{stakeholder_engineering_teams}})
- Operational Execution Schedule (phased breakdown across {{synthesis_timeline_weeks}} weeks with deliverables)
Self-review
- Verify that search strings correctly address all dimensions of {{target_architectural_paradigm}}.
- Confirm that the quality assessment scoring explicitly penalizes studies lacking empirical workload evaluation.
- Ensure the total operational timeline exactly fits {{synthesis_timeline_weeks}} weeks without unallocated phases.
Explicit role, a named task, and discrete steps the model can follow.
Background, inputs and variables the model needs before it starts.
Hard boundaries — what the model must and must not do.
A named, field-level shape for the response.
Ordered work items that force analysis before an answer.
Length and structure that travel across frontier models.
Signal density — instruction weight without padding.
Documented variables so the scaffold adapts to new inputs.
Quality bar, assumptions and behaviour when inputs are thin.
How much real usage the template has behind it.