Literature review
AuraScore 81/100

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.

Template

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

  1. Formulate 3-4 primary research questions (RQs) decomposing performance, fault-tolerance, maintainability, and migration trade-offs.
  2. Construct parameterized Boolean search strings tailored to {{search_databases_scope}} with controlled vocabulary and keyword variations.
  3. Define a two-tier screening pipeline (Title/Abstract screening followed by Full-Text eligibility) incorporating {{inclusion_exclusion_criteria}}.
  4. Design a standardized data extraction rubric capturing empirical metrics, system scale, failure modes, and benchmark methodologies.
  5. Establish a quality assessment framework (e.g., Dybå and Dingsøyr criteria) to grade empirical rigor across academic and industry sources.
  6. Detail a thematic synthesis process to categorize findings across architectural trade-off dimensions.
  7. Structure a weekly milestone schedule across {{synthesis_timeline_weeks}} weeks detailing resource allocation and screening checkpoints.
  8. 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:

  1. Research Questions & Search Strategy (including exact Boolean query strings)
  2. Selection & Screening Protocol (with inclusion/exclusion matrix and PRISMA-aligned screening workflow)
  3. Quality Assessment & Data Extraction Schema (tabular data fields and scoring rules)
  4. Synthesis & Thematic Mapping Framework (classification taxonomy for {{stakeholder_engineering_teams}})
  5. 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.
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

research-analysis
research-literature
technology-software
software-architecture
systematic-review
evidence-synthesis