Skill Hub — Architecture

Solution Architecture Review

Review a proposed solution design against requirements, constraints, risks, and non-functional needs before commitment.

What this skill is for

This skill provides a structured method for evaluating a proposed solution design before build or procurement begins. It checks whether the design satisfies known requirements, respects constraints, handles identified risks, and meets non-functional needs. The output is a review report with findings classified as blocking, major, minor, or informational, plus actionable recommendations. It prevents projects from committing to designs that contain hidden integration failures, scalability bottlenecks, or unverified assumptions.

When to use this skill

A vendor has submitted a solution design and the project team must validate it before contract signature.
An internal team has produced a high-level design for a new integration, module, or platform, and you need an independent review.
A design was created six months ago and the requirements have changed; you need to revalidate it.
A proof-of-concept succeeded in a sandbox and now must be reviewed for production readiness.
You are the architect responsible for a design review gate in a gated project methodology.

Real work situations

Example 1: SAP BTP integration design review

A team proposes using SAP Integration Suite to connect S/4HANA with a third-party logistics platform. The design shows synchronous API calls for every shipment event. The review reveals that the logistics platform has a 99.5% uptime SLA while the business requires 99.9% order visibility. The synchronous design creates a single point of failure. The review recommends event-driven asynchronous messaging with a local queue and retry mechanism.

Example 2: Data warehouse platform selection

A project selects a cloud data warehouse for SAP analytics. The design focuses on query performance and storage cost. The review finds that the design omits data lineage, master data synchronization with SAP MDG, and GDPR deletion workflows. These are classified as blocking findings because they are required by compliance and cannot be retrofitted without significant rework.

Example 3: Custom Fiori app approval workflow

A development team designs a custom Fiori application for purchase order approval with mobile support. The review checks against the existing SAP S/4HANA authorization concept, Fiori launchpad configuration, and mobile device management policy. It finds that the app requires custom OData services that bypass standard approval logic, creating a maintenance and audit risk. The review recommends using standard workflow APIs with extension points instead.

Example 4: Consolidation of two CRM systems

A merger project designs a consolidation of two CRM systems into one. The review checks data migration, user access, integration with SAP SD, and historical reporting needs. It discovers that one CRM contains contractual data with 10-year retention requirements that the target CRM does not support natively. The review adds a data archiving and retrieval requirement to the design.

Inputs required

The solution design document, diagram set, or architecture proposal under review.
Requirements brief or specification that the design claims to satisfy.
Non-functional requirements (performance, availability, security, scalability, maintainability).
Constraints list: budget, timeline, technology standards, compliance requirements, vendor lock-in limits.
System context map or integration landscape showing what the new solution must connect to.
Risk register or known issues from previous phases.
Stakeholder list: who produced the design, who must approve it, who will operate it.

Questions to ask

Which requirement is not covered by this design? Which design element does not trace to a requirement?
What happens if the primary component fails? Is there a failover, and has it been tested?
Which integration points are new, which are reused, and which are assumed to work without change?
What data volume is the design sized for, and what happens at 2x or 10x that volume?
Who will operate this solution, and do they have the skills and tools to monitor and troubleshoot it?
What is the rollback plan if the design fails during implementation or after go-live?
Which decisions in this design are irreversible or expensive to reverse?
Does the design introduce new single points of failure or new critical dependencies?

Working method

Establish the review scope. Define what is in scope (components, decisions, interfaces) and what is out of scope. Confirm the review authority: advisory, gate, or final approval.
Gather inputs. Collect the design, requirements, constraints, NFRs, and context maps. If any input is missing, record it as a review limitation.
Trace requirements to design elements. For each requirement, identify which design element satisfies it. Flag orphan requirements with no design coverage and orphan design elements with no requirement.
Check non-functional requirements. Verify that each NFR is addressed with a specific mechanism, not just a general statement. For example, "high availability" must become "active-passive cluster with 30-second failover."
Evaluate integration points. For each interface, check direction, protocol, data format, error handling, ownership, and monitoring. Reference the Interface Ownership Matrix template if one exists.
Assess risks and constraints. Check each known risk against the design. Does the design mitigate, accept, or ignore the risk? Does it violate any stated constraint?
Identify assumptions. List all assumptions embedded in the design (for example: "the API will be available by Q3," "users will adopt the new process immediately"). Classify each as validated, pending, or unverified.
Classify findings. For each issue found, assign a classification: Blocking (must resolve before proceed), Major (significant impact, needs plan), Minor (should fix, not blocking), Informational (noted for awareness).
Produce recommendations. For every Blocking and Major finding, provide one or more specific, actionable recommendations. Avoid vague advice like "consider alternatives."
Write the review report. Structure: Executive summary, Review scope, Requirements traceability, NFR assessment, Integration review, Risk and constraint check, Assumptions register, Findings with recommendations, Next steps.
Conduct review meeting. Present findings to the design team and stakeholders. Record agreements, disputes, and action items.

Decision rules

If a requirement has no corresponding design element, classify as a Blocking finding unless the requirement is explicitly deferred.
If a design element has no corresponding requirement, classify as a Major finding unless it is a standard platform capability that does not need project-level justification.
If an NFR is stated but not measurable, require the design team to provide metrics before the review can pass.
If an integration point lacks error handling or retry logic, classify as Major for external interfaces and Blocking for critical business flows.
If the design depends on an unverified assumption that affects feasibility, classify as Major and require validation before proceed.
If the design introduces a new single point of failure with no mitigation, classify as Blocking.
If the design reuses an existing component with known technical debt, flag as Major and require a debt remediation plan.

Deliverables

Solution Architecture Review Report — Structured document with scope, traceability, assessments, findings, and recommendations.
Requirements Traceability Matrix — Table mapping each requirement to design elements, with coverage status.
Findings Register — Classified list of issues with severity, evidence, recommendation, and owner.
Assumptions Register — List of design assumptions with validation status and risk if the assumption is wrong.
Review Meeting Minutes — Record of presentation, disputes, agreements, and action items.

Templates

Findings Register (Markdown table)

| ID | Finding | Category | Severity | Evidence | Recommendation | Owner | Due Date |
|----|---------|----------|----------|----------|----------------|-------|----------|
| SAR-001 | Synchronous API calls to logistics platform with 99.5% SLA | Integration | Blocking | Design doc v2.3, section 4.2 | Replace with event-driven messaging and local queue; define retry policy | Solution Architect | YYYY-MM-DD |
| SAR-002 | GDPR deletion workflow not addressed in data warehouse design | Compliance | Blocking | NFR-07, design doc v2.3 | Add data lifecycle management with deletion API and audit log | Data Architect | YYYY-MM-DD |
| SAR-003 | Custom OData service bypasses standard PO approval logic | Maintainability | Major | Design doc v2.3, section 5.1 | Use standard workflow APIs with BAdI extension points | ABAP Lead | YYYY-MM-DD |
| SAR-004 | Design assumes API v3 will be available by Q3; vendor roadmap unconfirmed | Assumption | Major | Vendor communication dated YYYY-MM-DD | Confirm API v3 GA date with vendor; define fallback to v2 if delayed | Project Manager | YYYY-MM-DD |

Assumptions Register

| ID | Assumption | Source | Validation Status | Risk if Wrong | Mitigation |
|----|------------|--------|-------------------|---------------|------------|
| ASM-001 | Logistics platform API v3 available by Q3 | Vendor roadmap slide | Unconfirmed | Delayed integration, fallback rework | Confirm in writing; design v2 fallback | Project Manager |
| ASM-002 | 10,000 orders/day peak volume | Business forecast 2026 | Pending | Performance failure at go-live | Load test at 2x forecast before UAT | Performance Lead |
| ASM-003 | Operations team trained on new monitoring tools | HR training plan | Validated | Incident response delays | Training complete by go-live minus 4 weeks | Operations Manager |

Quality checklist

Every requirement is traced to at least one design element or explicitly marked as deferred.
Every NFR has a measurable target and a specific mechanism in the design.
Every integration point is checked for protocol, error handling, ownership, and monitoring.
Every finding has a severity classification and a specific recommendation with an owner.
All assumptions are listed and at least one unverified assumption is flagged as a risk.
The review report has been shared with the design team before the review meeting.
Review meeting minutes record all disputes and whether they were resolved or escalated.
No Blocking finding remains unresolved without an explicit management decision to accept the risk.

Common mistakes

Mistake: Reviewing the design without the requirements. Consequence: The review becomes an opinion on aesthetics rather than a validation of fitness for purpose.
Mistake: Classifying everything as Major because the reviewer is uncertain. Consequence: The design team loses trust in the review process and ignores legitimate findings.
Mistake: Focusing only on functional coverage and ignoring NFRs. Consequence: The solution works in demo but fails under production load or compliance audit.
Mistake: Accepting vendor claims without independent verification. Consequence: The design assumes capabilities that do not exist, and the project discovers this too late.
Mistake: Producing a report but not conducting a review meeting. Consequence: Disputes and misunderstandings are not surfaced, and the design team proceeds with unchallenged flaws.

Agent instructions

When using this skill, an AI agent must:

Request all inputs before reviewing. Do not review a design without access to requirements, constraints, and NFRs. If inputs are missing, state what is missing and how it limits the review.
Trace requirements explicitly. Produce a Requirements Traceability Matrix as a Markdown table. Do not claim coverage without citing specific design sections or elements.
Classify findings rigorously. Use the four severity levels. Provide evidence for every finding. A finding without evidence is an opinion.
Make recommendations actionable. Every recommendation must name a specific action, a responsible role, and a target outcome. Avoid generic advice.
Surface assumptions. Extract assumptions from the design text and list them in the Assumptions Register. Flag unverified assumptions that affect feasibility or risk.
Do not invent requirements. If the design appears to miss something the agent considers important, flag it as a question or observation, not as a Blocking finding, unless it violates an explicit stated requirement.
Link to Atlas diagnostics. If integration or data architecture issues are found, reference API Contracts, Data Contracts, or Event-Driven Architecture for deeper context.

Related skills

Non-Functional Requirements — Define the measurable quality attributes the review checks against.
Architecture Decision Record — Capture the significant choices made during or after the review.
System Context Mapping — Define the boundaries and dependencies the review evaluates.
API Integration — Deep-dive skill for reviewing API-centric integration designs.
Change Impact Analysis — Assess how design changes affect existing systems and processes.

Related Atlas pages

API Contracts — Diagnostic context for reviewing API integration designs.
Data Contracts — How data agreements constrain solution design.
Event-Driven Architecture — Patterns for asynchronous integration reviewed in solution designs.
SAP Clean Core Strategy — How clean core principles constrain extension and customization designs.

Verification status and limitations

This skill is a public working interpretation of solution architecture review practice. It is not an official SAP, TOGAF, or IEEE review standard. It focuses on the practical subset used during enterprise and SAP project design gates. It does not cover detailed code review, security penetration testing, or infrastructure capacity planning. Use it as a structured review method for design documents and proposals, not as a substitute for specialized technical audits.