solution-architecture — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited solution-architecture (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
This skill enforces rigorous, evidence-based SAP solution architecture so that no design is produced without documenting integration points, passing a clean core compliance check, and addressing performance at design time — the three shortcuts that cause production failures.
| Agent Will Try To... | Why It Seems Reasonable | Why It Fails | Counter |
|---|---|---|---|
| Skip interface documentation | "The integrations are well-known" | Undocumented interfaces get missed during testing, cutover, and upgrades. Every interface needs a data flow diagram. | Iron Law 1: Every integration point named with protocol, direction, volume, and error handling before design is approved. |
| Defer clean core assessment | "We'll refactor later if needed" | Technical debt from clean core violations compounds with every SAP update. Retrofit during upgrade costs 3-5x initial build. | Iron Law 2: Clean core tier assigned to every extension at design time. Tier 3 requires written justification and architect sign-off. |
| Design without volume data | "Architecture works regardless of scale" | A design valid for 100 users fails for 10,000. SAP HANA in-memory architecture, buffering, and partitioning decisions are volume-dependent. | Iron Law 3: Transaction volumes and peak concurrency must be documented before architecture is finalized. |
| Recommend BTP reflexively | "BTP is the modern way" | BTP adds latency, licensing cost, and operational complexity. For simple extensions, key user extensibility or in-app customization is faster, cheaper, and safer. | Iron Law 4: Document BTP vs. on-premise trade-off table before recommending BTP. |
| Reuse architecture from previous projects | "This is the same landscape as [client X]" | Every SAP landscape has unique data volumes, org structures, integration ecosystems, and legacy constraints. Reused templates miss client-specific risks. | Verification: Architecture must reference this client's specific systems, modules, and entity counts. |
| Skip disaster recovery design | "DR is an infrastructure decision" | SAP application-layer DR (system replication, backup frequency, RTO/RPO for SAP-specific objects) is an architecture concern, not just infrastructure. | Checklist Step 6: RTO, RPO, and backup strategy are architecture deliverables. |
| Combine data architecture with process design | "Data flows from the process" | Data architecture (master data governance, data residency, archiving strategy, GDPR) is a separate discipline. Conflating it with process design produces gaps in both. | Checklist Step 5: Data architecture section is mandatory and separate from process flows. |
Watch for these phrases in your own reasoning — each one signals you are about to violate an Iron Law:
<HARD-GATE> DO NOT produce a solution architecture document until ALL of the following exist:
</HARD-GATE>
Document the full technical landscape before designing anything:
Evidence: Landscape diagram with all systems named and connection lines drawn. Gate: Every system that appears in scope or integration discussions is on the diagram before proceeding.
For every system-to-system connection, document:
Evidence: Integration register table with all 8 attributes per interface. Gate: No interface listed as "TBD" or "to be determined" — every interface fully specified before architecture is signed off.
Classify every requirement that cannot be met by SAP standard configuration:
Clean Core Tiers:
For every Tier 3 extension:
Evidence: Extension register with tier classification and justification for all Tier 3 items. Gate: Zero Tier 3 extensions without written justification and architect sign-off.
For every capability requiring evaluation between BTP and on-premise:
Assess each option against:
BTP Service Categories to Evaluate:
Evidence: BTP decision table with assessment scores per capability. Gate: Every BTP recommendation has a documented on-premise alternative that was rejected with reasons.
Define data design decisions that affect system architecture:
Evidence: Data architecture section with all 6 categories addressed. Gate: Data migration architecture specifies source systems and load sequence — not "TBD."
Define security design before any build begins:
Evidence: Security architecture section with all 6 categories defined. Gate: Role concept approach is defined — "will follow standard SAP roles" is not a concept.
Assemble all sections into the deliverable template below.
Evidence: Complete solution architecture document with all sections populated. Gate: All Hard Gate conditions met.
# SAP Solution Architecture Document
## Document Control
- **Project:**
- **Client:**
- **Version:**
- **Author:**
- **Review Date:**
- **SAP Product:** [S/4HANA Cloud GROW / RISE / On-Prem / BTP / etc.]
- **Activation Phase:**
## 1. Landscape Overview
### System Inventory
| System | Product | Version | Deployment | Owner | Status |
|--------|---------|---------|------------|-------|--------|
### Landscape Diagram
[Insert architecture diagram — all systems and connections]
## 2. Integration Architecture
### Integration Register
| # | Interface Name | Direction | Protocol | Trigger | Volume/Day | Error Handling | PII? | Integration Suite? |
|---|----------------|-----------|----------|---------|------------|----------------|------|--------------------|
### Integration Platform Decision
[SAP Integration Suite / middleware choice with justification]
## 3. Extensibility Strategy
### Clean Core Position
[Statement of clean core commitment for this engagement]
### Extension Register
| # | Extension Name | Business Requirement | Tier | Justification | Upgrade Risk | Owner |
|---|----------------|---------------------|------|---------------|--------------|-------|
### Tier 3 Justifications
[Detailed justification for every Tier 3 extension — if none, state "None — all extensions are Tier 1 or Tier 2"]
## 4. BTP Architecture
### BTP Services in Scope
| Service | Use Case | Alternative Considered | Decision Rationale |
|---------|----------|----------------------|-------------------|
### BTP Tenant Strategy
[Subaccount structure, environments, landscape segregation]
## 5. Data Architecture
### Master Data Governance
[MDG approach, ownership, distribution model]
### Data Migration Architecture
| Data Object | Source System | Extraction Method | Load Sequence | Volume (est.) |
|-------------|---------------|------------------|---------------|----------------|
### Analytics Architecture
[Reporting layer: SAC / embedded analytics / BW / third-party]
### Data Privacy and GDPR
[PII objects, consent handling, erasure approach]
## 6. Security Architecture
### Authentication Model
[IdP, SSO protocol, SAP IAS configuration]
### Authorization Concept
[Role design approach, SoD matrix, GRC integration]
### Transport and Network Security
[TLS, certificate management, network zones]
## 7. Performance Design
### Volume Requirements
| Process Area | Daily Transactions | Peak/Hour | Concurrent Users | Response Time SLA |
|--------------|-------------------|-----------|------------------|--------------------|
### Performance Architectural Decisions
[HANA partitioning, buffering, batch scheduling, archiving triggers]
## 8. Disaster Recovery and Business Continuity
| Metric | Target | Approach |
|--------|--------|----------|
| RTO | | |
| RPO | | |
| Backup Frequency | | |
| Failover Approach | | |
## 9. Architecture Decisions Log
| ID | Decision | Options Considered | Rationale | Date | Owner |
|----|----------|--------------------|-----------|------|-------|
## 10. Open Architecture Risks
| # | Risk | Impact | Mitigation | Owner | Due Date |
|---|------|--------|------------|-------|----------|
## Sign-Off
| Name | Role | Signature | Date |
|------|------|-----------|------|This skill is complete ONLY when ALL of the following are true:
Evidence required: Complete solution architecture document with all sections populated. No sections containing only "TBD" or placeholder text.
If any verification item is not met, the skill is NOT complete. Do not claim completion.
After completing this skill, invoke one of:
estimation — When the architecture needs to be decomposed into detailed effort estimatestesting-strategy — When moving into Realize phase and the architecture drives test scopedata-migration — When the data migration architecture requires detailed migration planningConditions for handoff: Solution architecture document is reviewed and approved, and the project is moving from Explore into Realize phase design and build activities.
brainstorming — For exploring solution options before finalizing architecturefit-gap-analysis — For identifying the gaps that drive extensibility decisionsestimation — For converting architectural components into effort estimatessecurity-grc — For detailed GRC and authorization design beyond the architecture conceptbtp — For BTP service-specific design patterns and implementation guidanceclean-core-strategy — For detailed clean core governance and extension lifecycle management~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.