AI-003·AI Track·Advanced·3–12 hrs saved

Find the Architecture Weaknesses Before They Become Outages, Rewrites, and 2 A.M. Pages

An AI-assisted, evidence-based architecture review that evaluates whether a system's structure actually supports its business goals — without recommending a redesign nobody asked for.

3Phases

7Prompts

3–12Hours saved

6Deliverables

Executive Brief

Your Challenge

Your application meets every functional requirement and is still expensive to change. Deployments are fragile, one service can't ship without three others, the database is a shared choke point, and nobody can say where the first scaling wall is. The system works — you just can't evolve it, scale it, or prove it's safe. Architecture drifted there reactively, one deadline and one integration at a time, and now the structure itself is the constraint.

Common Obstacles

Architecture reviews fail in two predictable ways. They turn into taste debates — someone recommends microservices, cloud-native, or a rewrite because it's fashionable, not because the evidence demands it. Or they judge the system from isolated code snippets and framework choices instead of boundaries, coupling, data ownership, and failure modes. Both produce recommendations you can't defend to the business: change for its own sake, or findings with no measurable justification behind them.

The ABME Approach

This workflow forces the review in the right order: summarize the system and its assumptions first, then evaluate boundaries, data, scalability, security, reliability, and operations against the actual business goals. Every finding carries severity, confidence, evidence, and business impact — and confirmed findings stay separate from assumptions and open questions. Recommendations are ranked by business value and risk, not novelty. The output is an executive summary, a risk register, an architecture scorecard, and a prioritized roadmap you can hand to a review board and defend line by line.

Insight Summary

Good architecture is not defined by the technologies it uses, but by how effectively it lets the business ship reliable, secure, maintainable software over time. Judge the structure against goals, not against the tech-stack fashion of the quarter.

phase-1

Summarize the system and name its assumptions before evaluating a single weakness. A review that skips the context step is grading a system it hasn't actually understood yet.

phase-2

A finding without severity, confidence, and evidence is an opinion. The whole value of the review is that confirmed findings stay separate from assumptions and open questions.

phase-2

Architecture smells only count when evidence backs them. 'Shared database' is a smell; 'three independently deployed services write the same transactional tables' is a finding.

phase-3

Measure before you redesign. Recommending horizontal scaling for load that doesn't exist is the same mistake as ignoring the bottleneck that does — both skip the measurement step.

tactical

Never recommend architectural change without measurable justification, and always explain the tradeoff behind it — simplicity vs flexibility, consistency vs availability, cost vs resilience.

The Journey

Three phases; each lists the tools you'll use there.

Gather Context and Frame the Review

Collect architectural inputs and define the questions the review must answer before evaluating anything.

Gather diagrams, requirements, code, and operational context
Define the review objectives the analysis must answer
Identify the review categories relevant to this system
Establish which architectural principles apply
Sanitize secrets and sensitive infrastructure details before sharing

Prerequisites Checklist

Run the Evidence-Based Review

Use the prompt pack to evaluate boundaries, data, scalability, security, and technical debt with severity, confidence, and evidence on every finding.

Run the primary prompt with the full architectural context
Apply follow-up prompts for boundaries, data, scalability, security, deployment, and debt
Separate confirmed findings from assumptions and open questions
Document tradeoffs behind each recommendation
Cross-check findings against the common architecture smells

Architecture Review Prompt Pack Review Dimensions Matrix

Prioritize, Score, and Validate

Rank recommendations by business value, score the architecture, and validate the review before accepting it.

Rank recommendations using the prioritization framework
Build the architecture scorecard and roadmap
Run the validation checklist against the completed review
Validate recommendations through load testing, ADRs, and proofs of concept
Complete human architectural review

Architecture Scorecard Validation Checklist Recommendation Validation Plan

What's Inside the Execution Layer

Numbered deliverables grouped by phase. Membership unlocks every tool.

2. PHASE 2Prompt Packprotected

Architecture Review Prompt Pack

One primary prompt and six targeted follow-ups that drive an evidence-based architecture review with severity, confidence, and business impact on every finding.

Use this to

Run a full evidence-based architecture evaluation
Drill into service boundaries, data, scalability, security, deployment, and debt
Keep confirmed findings separate from assumptions and open questions

Included with membership — $20/mo

Primary Prompt

Start here with the full architectural context.

You are a senior enterprise software architect conducting an evidence-based architecture review.

I will provide:
• Business objectives
• Functional requirements
• Non-functional requirements
• Architecture diagrams
• Source code
• Infrastructure diagrams
• Deployment architecture
• Data models
• APIs
• Technology stack
• Existing documentation
• Operational constraints
• Security requirements
• Performance expectations
• Scalability expectations

Your task is to evaluate whether the current architecture appropriately satisfies both present and future requirements.

Before evaluating weaknesses:

1. Summarize the system.

2. Identify:
• Business capabilities
• Primary components
• Responsibilities
• Data stores
• External dependencies
• Trust boundaries
• Deployment topology
• Communication patterns

3. Identify architectural assumptions.

4. Identify architectural constraints.

5. Identify missing information.

Then evaluate:
• Component boundaries
• Coupling
• Cohesion
• Data ownership
• Transactions
• Security
• Scalability
• Availability
• Reliability
• Performance
• Testability
• Deployment
• Monitoring
• Configuration
• Operational complexity
• Technical debt

For every finding include:
• Finding ID
• Category
• Severity
• Confidence
• Evidence
• Business impact
• Technical impact
• Recommended improvement
• Estimated implementation complexity
• Architectural tradeoffs

Clearly distinguish:
• Confirmed findings
• Assumptions
• Questions
• Future considerations

Do not recommend architectural change without measurable justification.

Provide:
1. Executive summary
2. Strengths
3. Risks
4. Improvement roadmap
5. Quick wins
6. Long-term recommendations
7. Remaining unknowns

Review Service Boundaries

To evaluate whether decomposition aligns with business capabilities.

Evaluate whether service boundaries align with business capabilities.

Identify:
• Overloaded services
• Shared ownership
• Cyclic dependencies
• Incorrect decomposition
• Missing boundaries
• Excessive coupling
• Opportunities for simplification

Recommend improvements only when justified.

Review Data Architecture

To assess data ownership, consistency, and recovery.

Review the data architecture.

Assess:
• Ownership
• Consistency
• Transactions
• Replication
• Reporting
• Analytics
• Schema evolution
• Backups
• Disaster recovery
• Multi-region considerations

Review Scalability

To evaluate scaling limits before any redesign.

Evaluate scalability.

Review:
• CPU scaling
• Memory scaling
• Storage
• Database growth
• Queue depth
• Caching
• Session management
• Horizontal scaling
• Statelessness
• Cost implications

Recommend measurement before redesign.

Review Security Architecture

To assess the security model and trust boundaries.

Review the application's security architecture.

Assess:
• Authentication
• Authorization
• Secret management
• Encryption
• Network segmentation
• Trust boundaries
• Tenant isolation
• Logging
• Identity providers
• Administrative access

Do not recommend weakening security controls.

Review Deployment Architecture

To evaluate release safety and operational resilience.

Review deployment architecture.

Analyze:
• CI/CD
• Rollback
• Blue/Green
• Canary
• Infrastructure dependencies
• Configuration
• Secrets
• Monitoring
• High availability
• Disaster recovery

Review Technical Debt

To catalog and rank architectural debt by impact.

Identify architectural technical debt.

Separate:
• Immediate operational risks
• Maintainability debt
• Scalability debt
• Security debt
• Documentation debt

Rank by business impact.

3. PHASE 2Matrixprotected

Review Dimensions Matrix

A checklist of architectural areas paired with the decisive question each one must answer during the review.

Use this to

Work through every architectural dimension systematically
Anchor each area to a single decisive question
Confirm no major review category was skipped

Included with membership — $20/mo

Reference rows from the blueprint — downloads ship as an empty skeleton

Area	Questions
Business	Does the architecture support business goals?
Components	Are responsibilities clearly separated?
Data	Is ownership clear?
APIs	Are contracts stable?
Security	Are trust boundaries enforced?
Scalability	What is the first scaling bottleneck?
Reliability	What happens when dependencies fail?
Operations	Can operators diagnose failures quickly?
Deployment	Can releases be safely rolled back?
Maintenance	Can engineers change one area independently?

4. PHASE 3Matrixprotected

Architecture Scorecard

A per-category rating grid that summarizes the review's evidence into an at-a-glance architecture health picture.

Use this to

Summarize review findings by category
Communicate architecture health to stakeholders
Track category ratings across successive reviews

Included with membership — $20/mo

Reference rows from the blueprint — downloads ship as an empty skeleton

Category	Rating	Notes
Business Alignment	A	Strong alignment
Security	B	Minor improvements recommended
Scalability	B	Database bottleneck emerging
Reliability	B+	Good redundancy
Maintainability	C+	Increasing coupling
Observability	B	Missing distributed tracing
Documentation	C	Significant gaps

RubricScores should summarize evidence—not replace it.

6. PHASE 3Checklistprotected

Recommendation Validation Plan

The set of empirical validations that confirm an architectural recommendation before it becomes a commitment.

Use this to

Validate recommendations with real measurement
Choose the right validation method per finding
Avoid acting on unproven architectural claims

Included with membership — $20/mo

Validate recommendations through:

🔒 The full execution layer — every checklist, matrix, and the prompt pack — is included with ABME membership.

Unlock Full Blueprint

Full Playbook

Overviewpublic

An application can meet every functional requirement and still be difficult to scale, maintain, secure, deploy, monitor, or evolve because of architectural weaknesses.

Architecture review is not about coding style—it evaluates whether the structure of a system supports its long-term operational and business objectives.

This workflow uses AI to perform a structured architecture review by analyzing:

Business objectives
Functional requirements
Non-functional requirements
System boundaries
Component interactions
Data flows
Deployment architecture
Security model
Operational characteristics
Technical debt
Scalability constraints
Future changeability

The review focuses on identifying architectural strengths, weaknesses, tradeoffs, risks, and opportunities without recommending unnecessary redesign.

The objective is to determine whether the architecture appropriately supports the system's current and future business goals.

Business Problempublic

Many systems become difficult to maintain because architecture evolves reactively.

Common causes include:

Incremental feature additions
Short delivery deadlines
Multiple development teams
Inconsistent design decisions
Framework migrations
Cloud migrations
Legacy integration
Acquisitions
Missing documentation
Technical debt
Lack of ownership
Changing business priorities

Poor architecture often produces:

Slow development
Fragile deployments
High operational cost
Difficult testing
Security weaknesses
Performance bottlenecks
Deployment coupling
Poor scalability
Large outages
Developer frustration
Inconsistent user experience
Vendor lock-in
Excessive maintenance cost

Architecture reviews help identify structural issues before they become organizational problems.

Typical Use Casespublic

Use this workflow when:

Designing a new application
Reviewing an existing system
Planning a cloud migration
Modernizing a legacy application
Evaluating a vendor solution
Preparing for significant growth
Investigating recurring outages
Planning a microservices migration
Reviewing event-driven systems
Evaluating scalability
Performing technical due diligence
Preparing an acquisition
Reducing technical debt
Improving platform engineering
Preparing for regulatory review
Establishing engineering standards

Do NOT Use This Workflow Whenpublic

This workflow is not intended to:

Review individual coding style
Replace code reviews
Replace penetration testing
Replace load testing
Replace threat modeling
Recommend microservices without justification
Require cloud migration for every application
Declare one architectural style universally superior
Ignore business constraints
Optimize prematurely
Rewrite functioning systems without measurable benefit
Judge architecture from isolated code snippets
Recommend technologies based solely on popularity

Architecture should solve business problems—not demonstrate technical sophistication.

Expected Outcomepublic

After completing this workflow, you should have:

Executive architecture summary
Business alignment assessment
Context diagram
Component inventory
Dependency analysis
Data-flow assessment
Deployment review
Scalability assessment
Security architecture observations
Availability assessment
Reliability assessment
Performance observations
Maintainability assessment
Technical debt inventory
Architectural risks
Recommended improvements
Prioritized roadmap
Areas requiring deeper investigation

🔒 The complete playbook — reference models, worked examples, and operational guidance — is included with ABME membership.

Unlock Full Blueprint

Architecture Review Objectivesprotected

A complete review should answer:

What business capability does the system provide?
What are the major architectural components?
How are responsibilities divided?
Are responsibilities appropriately separated?
Are dependencies well managed?
How does data flow?
What are the trust boundaries?
Where are the scalability limits?
What are the operational risks?
How resilient is the design?
What assumptions exist?
What technical debt exists?
How difficult is future change?
What failure modes exist?
How observable is the system?
Does the architecture support future growth?

Architecture Review Categoriesprotected

Business Alignment

Review whether the architecture supports:

Business goals
Expected growth
User workflows
Delivery velocity
Regulatory requirements
Budget constraints
Operational maturity
Staffing model

System Structure

Review:

Layers
Modules
Services
Boundaries
Coupling
Cohesion
Responsibilities
Shared components
Public interfaces
Internal abstractions

Data Architecture

Review:

Data ownership
Storage
Replication
Consistency
Transactions
Event flow
Reporting
Analytics
Lifecycle
Archiving
Backup
Recovery

Security Architecture

Review:

Authentication
Authorization
Trust boundaries
Secret management
Encryption
Network segmentation
Identity
Audit logging
Tenant isolation
Compliance requirements

Scalability

Review:

Horizontal scaling
Vertical scaling
Statelessness
Queue usage
Caching
Database scaling
Load balancing
Rate limiting
Partitioning
Capacity planning

Reliability

Review:

Failure isolation
Retry behavior
Circuit breakers
Timeouts
Redundancy
High availability
Disaster recovery
Recovery objectives
Deployment resilience

Maintainability

Review:

Code ownership
Module independence
Documentation
Testability
Complexity
Dependency management
Build process
Release process
Configuration management

Observability

Review:

Logging
Metrics
Tracing
Dashboards
Alerting
Correlation IDs
Health checks
Operational visibility

Architectural Principlesprotected

Principles to Evaluate

Evaluate adherence to principles such as:

Single Responsibility
Separation of Concerns
Loose Coupling
High Cohesion
Least Privilege
Defense in Depth
Idempotency
Fail Fast
Immutable Infrastructure
Explicit Contracts
Backward Compatibility
Observability by Design
Secure by Default

Architectural Tradeoffsprotected

Tradeoffs to Weigh

Good architecture always involves tradeoffs. A review should explain tradeoffs rather than assume one answer is always correct.

Simplicity vs flexibility
Consistency vs availability
Performance vs maintainability
Centralization vs autonomy
Cost vs resilience
Speed vs governance
Shared services vs duplication

Common Architecture Smellsprotected

Smells to Review For

Review for the following. Architecture smells should be supported by evidence.

God services
Shared databases
Circular dependencies
Excessive synchronous communication
Chatty APIs
Hidden coupling
Large transactions
Duplicate business rules
Mixed responsibilities
Hardcoded configuration
Environment-specific code
Tight deployment coupling
Shared mutable state
Missing observability
Security implemented inconsistently

Example Findingprotected

ARCH-001 — Shared Database Creates Deployment Coupling

Category: Data Architecture

Severity: High

Confidence: High

Evidence: Three independently deployed services update the same transactional tables directly.

Business Impact: Independent releases become difficult because schema changes require synchronized deployments.

Technical Impact: Schema evolution becomes increasingly risky, increasing outage probability.

Recommendation: Move toward service-owned data where appropriate or introduce explicit API ownership for shared data access.

Tradeoff: This increases implementation complexity but significantly improves deployment independence over time.

Prioritization Frameworkprotected

Ranking Factors

Rank recommendations using the following factors. Not every architectural improvement should be implemented immediately.

Business value
Risk reduction
Operational improvement
Delivery complexity
Time to implement
Organizational readiness

Review Deliverablesprotected

The final review should include:

Executive summary
Architecture overview
Component inventory
Dependency map
Risk register
Technical debt register
Architecture scorecard
Prioritized roadmap
Open questions
Recommended follow-up reviews

Automation Opportunitiesprotected

Architecture review boards
Technical due diligence
Cloud migration planning
Quarterly architecture reviews
Technical debt initiatives
Engineering governance
Platform modernization
Solution design approvals
Enterprise architecture programs

Pro Tipsprotected

Evaluate architecture against business goals first.
Separate structural problems from implementation issues.
Look for recurring operational pain points.
Measure before redesigning.
Prefer incremental improvement over wholesale rewrites.
Review deployment, operations, and security together.
Document architectural assumptions explicitly.
Identify technical debt that creates measurable business risk.
Balance simplicity, flexibility, and operational cost.
Always explain the tradeoffs behind every recommendation.

Common Mistakesprotected

Recommending microservices for every application
Optimizing for scale that does not exist
Ignoring business constraints
Focusing on frameworks instead of architecture
Treating technology choices as architecture
Ignoring operational realities
Assuming cloud-native always means better
Ignoring developer productivity
Confusing coupling with reuse
Recommending large rewrites instead of incremental improvement

Security Considerationsprotected

Remove secrets
Remove credentials
Remove sensitive infrastructure details
Remove internal IP addressing if unnecessary
Sanitize customer identifiers
Follow organizational architecture-classification policies
Architecture diagrams often contain sensitive operational information

Brian Diamond

Founder, BrianOnAI

Twenty-five years designing, operating, and governing enterprise infrastructure — from MSP operations across dozens of client environments to enterprise infrastructure leadership. This blueprint codifies the operating model he's implemented in production, not theory.

Related Blueprints

Perform an AI-Assisted Code Review Analyze and Diagnose a Software Defect Generate Unit and Integration Tests Refactor Code Safely Generate API and Developer Documentation Identify and Prioritize Technical Debt Review a Technical Design Modernize a Legacy Application Build and Maintain Development Prompts

⚠ Normalization Warnings — 12 for review

RESTRUCTURE: 'Primary Prompt' and 'Follow-Up Prompts' (two source H1s) combined into one prompt_pack tool with 7 prompts; 'when' guidance lines are editorial additions, prompt text preserved verbatim (whitespace/line breaks reconstructed from the run-together source extraction — confirm exact spacing).
CLASSIFICATION TO CONFIRM: 'Prerequisites' classified as a checklist TOOL (gather-before-start items are completable). Alternative: body/prose.
CLASSIFICATION TO CONFIRM: 'Example Review Dimensions' (a two-column Area/Questions table) classified as a matrix TOOL named 'Review Dimensions Matrix'. It reads partly as reference (consulted questions) but the columnar table + per-area completion intent tips it to tool. Alternative: body/reference. Display name changed from source heading — confirm.
CLASSIFICATION TO CONFIRM: 'Architecture Scorecard' classified as a matrix TOOL (practitioner fills in ratings per category). Source presented an 'Example' table; example rows preserved verbatim, skeleton_rows: 0. Alternative: body/example.
CLASSIFICATION TO CONFIRM: 'Testing Recommendations' classified as a checklist TOOL named 'Recommendation Validation Plan' (all items are performable validations). Alternative: body/reference. Display name changed from source heading — confirm.
CLASSIFICATION TO CONFIRM: 'Architectural Principles', 'Architectural Tradeoffs', 'Common Architecture Smells', and 'Prioritization Framework' classified as body/reference (lists the practitioner consults during review). Each is a single flat list rendered as one tier — confirm reference over prose.
GROUPING: 'Architecture Review Categories' (8 H2 subsections) kept as a body GROUP rather than flattened; each category is a prose child.
MATRIX RUBRIC: 'Review Dimensions Matrix' has no scoring scheme in the doc; rubric left empty (not fabricated).
PLAYBOOK: 'Security Considerations' mapped to playbook.security_considerations (flat list of sanitization actions), NOT a body group as in PS-006 — this doc's version is a short flat list. Trailing note sentence appended as a list item.
AI-003 has no Quick Wins or Roadmap sections; playbook.quick_wins and roadmap intentionally empty.
STATS: deliverables counted as 6 tools; prompts = 7 (1 primary + 6 follow-ups). Confirm deliverable count convention.
frameworks in taxonomy (ChatGPT/Claude/Gemini/Copilot) inferred — the doc lists platforms/technologies but no AI assistant list; confirm or trim.

SEO Block

Title tag: AI-Assisted Application Architecture Review | ABME (50 chars)
Meta: Run an evidence-based AI architecture review — boundaries, data, scalability, security, and technical debt — with a prioritized roadmap and no unjustified rewrites. (164 chars)
Schema: HowTo · noindex: false
Related: ai-001, ai-002, ai-004, ai-005, ai-006, ai-007, ai-008, ai-009, ai-010
Keywords: application architecture review, software architecture assessment, ai architecture review, technical debt assessment, architecture scorecard, microservices architecture review, scalability assessment, architecture decision records, system design review, enterprise architecture review

Copied