Recommendations

A Recommendation is the mode Catio uses when it found the change rather than you asking for it. It leads with the case for action: the gap, why it matters, and what closing it is worth. For the artifact both modes produce and how it gets reviewed, see Blueprints.

A Recommendation is a type of blueprint. Recommendations identify specific opportunities to improve your architecture. They explain what should change, why it matters, and what action could improve cost, performance, reliability, scalability, security, or modernization outcomes.

Types of Recommendations

Recommendations vary in scope and complexity:

• Single atomic actions (e.g., swap database X for database Y)
• Sequential related actions
• Coarse-grained architectural changes (e.g., implementing a data warehouse)
• Composite actions that decompose into smaller recommendations

Structure of a Recommendation

A Recommendation is a type of blueprint, so it carries the canonical seven-part blueprint structure: Summary, Benefit, Impact, Target State, Gap Analysis, Business Impact, and Implementation Plan. See Structure of a Blueprint for what each section holds.

What distinguishes a Recommendation is where the substance sits. Three of those sections carry the argument:

Target State

Defines the optimal architecture state:

• Proposed target state for your system
• Technical rationale for the recommendation
• Expected benefits from implementation

Gap Analysis

Evaluates the delta between current and target states:

• Current architecture assessment
• Identified issues or limitations in existing implementation
• Specific differences between current and target architectures
• Technical and business impact of addressing gaps

Implementation Plan

Specifies the implementation approach:

• Required actions (add, swap, replace, or reuse components)
• Priority classification (adopt now, adopt later, or hold)
• Technical justification for recommended actions
• Expected outcomes and impact metrics

Example Recommendation

Section: Data Architecture

Recommendation: Choice of database type

Target State: Column-oriented DBMS. Moving to such a data store has significant cost and performance advantages for companies using append-only OLAP data.

Gap Analysis: While you use MongoDB, which is an excellent NoSQL database, it is generally not efficient for append-only OLAP use cases due to the high cost in lookup times as well as the more limited compression levels available for data sets stored as NoSQL.

Implementation Plan: Moving from MongoDB to a Column-oriented DBMS could yield significant cost and performance improvements. Considering your company's highly intensive append-only data volume and reliance on accurate analytics for product features, this improvement could be captured across a very material portion of your total cost and performance envelope.