The S.M.P Framework

Version: 1.0.0
Date Created: 07 August 2025
Date Last Modified: 07 August 2025
Created By: AfterZip
License: Creative Commons Attribution 4.0 International (CC BY 4.0)

Abstract

The S.M.P Framework (Storage, Manipulation, Presentation) is a fundamental mental model that describes how all software systems operate at their core. This framework posits that every piece of software, from simple command-line tools to complex AI systems, can be understood through three essential layers: how data is stored, how it's processed and transformed and how it's presented to users for interaction.

By understanding software through this lens, developers, architects and stakeholders can better conceptualise system design, identify bottlenecks and communicate about technical architecture using a shared vocabulary. The S.M.P Framework serves as both a teaching tool for newcomers and a strategic planning instrument for experienced professionals, providing clarity in an increasingly complex technological landscape.

Framework Overview

The Universal Software Pattern

At its essence, all software follows the same fundamental pattern:

┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│  ┌──────────┐      ┌──────────────┐      ┌──────────────┐       │
│  │          │      │              │      │              │       │
│  │ STORAGE  │ ───► │ MANIPULATION │ ───► │ PRESENTATION │       │
│  │          │      │              │      │              │       │
│  └──────────┘      └──────────────┘      └──────────────┘       │
│                                                                 │
│  Where data        Where data            Where data             │
│  lives             is processed          meets humans           │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

The Full Journey:

1. Storage → Where the data lives (PostgreSQL, Firebase, flat files)
2. Manipulation → Where the data is processed and made meaningful (code, logic, queries)
3. Presentation → Where the data is expressed so humans can understand and act

Core Principle: Every software application, regardless of complexity or purpose, can be decomposed into these three fundamental layers. Understanding this pattern provides a universal lens for analysing and building software systems.

From Storage to Action

Let's step back and understand the nature of each layer:

• Storage is passive — it's where the data lives
• Manipulation is active — it's what we do with that data
• Programming is the bridge — it gives us the power to control, query and transform data at scale

Once you understand this, you realise: Every app, tool or digital system you've ever used is just a smart way of moving, transforming and displaying data.

Layer 1: Storage - Where Data Lives

Definition

The Storage layer is the foundation of any software system: the persistent or temporary location where data resides. It's passive by nature, serving as the repository from which all operations begin.

Core Concepts

Think of Storage Like Different Types of Containers:

• SQL Databases (PostgreSQL, MySQL): Like a filing cabinet with labelled folders and strict organisation rules, where every document has a predefined place
• NoSQL Databases (MongoDB, Redis): Like flexible storage boxes where you can store items of different shapes and sizes without rigid compartments
• Data Lakes: Like a warehouse that stores everything in its raw form, ready to be organised when needed
• File Systems: Like basic shelving units, straightforward but limited in how you can search through them

Key Characteristics

1. Structure vs. Flexibility

   • Structured (SQL): Fixed schema, predefined relationships, ACID compliance
   • Semi-structured (NoSQL): Flexible schema, adaptable to changing requirements
   • Unstructured (Data Lakes): Raw storage, structure applied at read-time

2. Scale Considerations

   • Vertical scaling (traditional databases)
   • Horizontal scaling (distributed systems)
   • Cost vs. performance trade-offs

3. Access Patterns

   • Transactional (OLTP)
   • Analytical (OLAP)
   • Real-time streaming
   • Batch processing

Practical Application

When choosing a storage solution, consider:

• Data structure: Is your data highly relational or document-based?
• Scale requirements: Gigabytes or petabytes?
• Query complexity: Simple lookups or complex aggregations?
• Consistency needs: Immediate consistency or eventual consistency acceptable?

Layer 2: Manipulation - Where Data is Processed

Definition

The Manipulation layer is where data transforms from raw material into meaningful information. This is the active layer, the engine room of software where logic, calculations and transformations occur.

Now that we've established how data is stored, let's look at how we can manipulate it. At a high level, we can operate on data the same way we would in mathematics: add, subtract, multiply, divide. But we're not limited to numbers. We can also perform logical operations — like checking if something is true or false (boolean logic), or comparing values (is this greater than that?).

But we don't stop there. We can slice, dice, filter, group, sort and transform data — just like a chef preparing ingredients for a dish. This is where the real power of programming emerges. It's not just about storing data like a digital filing cabinet. It's about reshaping and extracting meaning from it. This process of taking raw data and making it useful is known as data transformation.

Core Operations

Mathematical Operations:

• Add, subtract, multiply, divide
• Aggregations (sum, average, min, max)
• Statistical calculations

Logical Operations:

• Boolean logic (AND, OR, NOT)
• Comparisons (greater than, equals, contains)
• Conditional branching (if-then-else)

Data Transformations:

• Filter: "Show me only users over 25"
• Map: "Convert all names to uppercase"
• Reduce: "Sum total revenue from all transactions"
• Group: "Count sales per month"
• Sort: "Order by profit margin descending"
• Join: "Combine customer data with purchase history"

From Simple to Complex

The power of manipulation emerges through composition:

Simple Operations:

Add two numbers
Compare two values
Loop through a list

Complex Logic Chains:

"If a user has not logged in within 30 days 
 AND they haven't made a purchase, 
 send them a reminder email"

"Take 10,000 products, 
 find the top 5 best-selling items 
 grouped by category, 
 sorted by profit margin"

Building Logic Machines

You're not just writing code — you're building logic machines.

Think of every program you write as a tiny logic machine. It takes in data as input, performs a series of transformations and outputs something meaningful. This is the heartbeat of software development: turning raw inputs into valuable outputs.

Every program is essentially a logic machine that:

1. Accepts input (data from storage or users)
2. Applies transformations (business logic, calculations)
3. Produces output (processed data ready for presentation)

This could manifest as:

• A list of recommended movies
• A graph of your monthly spending
• A sorted spreadsheet
• An alert that warns of a system failure
• A recommendation algorithm filtering and ranking content
• A financial system calculating compound interest
• An AI model processing natural language into structured commands
• A game engine computing physics and collision detection

Layer 3: Presentation - Where Data Meets Humans

Definition

The Presentation layer transforms invisible logic into visible experience. It's the difference between rows in a database and an app you can actually use. This layer makes data not just visible, but actionable and interactive.

Core Purpose

The presentation layer answers three critical questions:

1. What is happening? (Current state)
2. Why does it matter? (Context and meaning)
3. What should I do next? (Actions and decisions)

Beyond Aesthetics

While visual design matters, the presentation layer is fundamentally about:

Clarity Over Complexity:

• Transforming thousands of data points into a single meaningful metric
• Converting database timestamps into "5 minutes ago"
• Showing red/yellow/green instead of numerical thresholds

Actionability:

• Not just showing data, but enabling interaction
• Providing clear paths for user actions
• Immediate feedback on user inputs

Context:

• Comparing current vs. previous performance
• Highlighting anomalies and trends
• Providing drill-down capabilities

Presentation Patterns

Dashboard: High-level overview with key metrics

Critical: 5 Issues | Warning: 12 Items | Normal: 143 Systems

Detail View: Deep dive into specific entities

Customer Profile
├── Recent Activity
├── Purchase History
└── Support Tickets

Interactive Visualisation: Data exploration tools

[Filters] → [Graph] → [Insights] → [Actions]

UX as Data Storytelling

Great interfaces tell stories with data:

• Beginning: Current state and context
• Middle: Trends, patterns and insights
• End: Recommended actions and next steps

The best presentations make complex data feel simple without losing important nuance.

Framework Application Examples

Example 1: E-commerce Platform

Storage Layer:

• PostgreSQL for transactional data (orders, customers)
• Redis for session management
• S3 for product images

Manipulation Layer:

• Calculate shipping costs based on location
• Apply discount rules and tax calculations
• Generate personalised recommendations
• Process payment validations

Presentation Layer:

• Product catalogue with filters
• Shopping cart with real-time updates
• Order tracking dashboard
• Admin analytics panel

Example 2: Real-time Analytics System

Storage Layer:

• Time-series database for metrics
• Data lake for raw event logs
• PostgreSQL for configuration

Manipulation Layer:

• Aggregate metrics by time windows
• Detect anomalies using statistical models
• Calculate percentiles and distributions
• Generate alerts based on thresholds

Presentation Layer:

• Live-updating dashboards
• Alert notifications
• Drill-down reports
• Mobile app for on-the-go monitoring

Example 3: AI-Powered Application

Storage Layer:

• Vector database for embeddings
• Object storage for training data
• PostgreSQL for user data

Manipulation Layer:

• Neural network inference
• Natural language processing
• Similarity calculations
• Response generation

Presentation Layer:

• Chat interface
• Confidence scores visualisation
• Feedback collection UI
• Performance metrics dashboard

Implementation Guidelines

Architectural Considerations

Separation of Concerns:

• Keep layers loosely coupled
• Define clear interfaces between layers
• Enable independent scaling of each layer

Data Flow Patterns:

• Request/Response: Traditional web applications
• Event-Driven: Real-time systems
• Batch Processing: Analytics and reporting
• Streaming: Continuous data processing

Technology Selection Matrix:

Layer	Light Traffic	Medium Traffic	Heavy Traffic
Storage	SQLite, Files	PostgreSQL, MongoDB	Cassandra, BigQuery
Manipulation	Single server	Load-balanced servers	Distributed computing
Presentation	Static HTML	React/Vue SPA (Single Page Application)	CDN + Edge computing

Best Practices

Storage Layer:

1. Design for your access patterns
2. Plan for backup and recovery
3. Consider data retention policies
4. Implement proper indexing
5. Monitor storage growth

Manipulation Layer:

1. Write testable, modular code
2. Implement proper error handling
3. Use caching strategically
4. Profile and optimise bottlenecks
5. Document business logic clearly

Presentation Layer:

1. Prioritise user experience over aesthetics
2. Ensure accessibility compliance
3. Implement responsive design
4. Optimise for performance
5. Provide clear feedback for all actions

Validation and Success Considerations

Key Performance Indicators

When implementing the S.M.P Framework, consider monitoring these aspects:

Storage Layer:

• Query response times and database performance
• Storage efficiency and capacity planning
• Backup and recovery procedures
• Data integrity and consistency

Manipulation Layer:

• API response times and throughput
• CPU and memory utilisation
• Code quality and test coverage
• Business logic accuracy

Presentation Layer:

• Page load performance
• User interaction responsiveness
• Accessibility compliance
• User task completion rates

System-Wide Considerations:

• End-to-end latency
• System availability and uptime
• User satisfaction metrics
• Error rates and handling

These indicators help ensure each layer performs optimally and the system delivers value effectively.

Conclusion

The S.M.P Framework reveals that all software, regardless of complexity, follows the same fundamental pattern: Storage → Manipulation → Presentation. By understanding this pattern, we can:

1. Simplify Complexity: Break down any system into understandable components
2. Improve Communication: Use shared vocabulary across teams
3. Make Better Decisions: Choose appropriate technologies for each layer
4. Identify Bottlenecks: Pinpoint which layer needs optimisation
5. Teach Effectively: Provide newcomers with a mental model for all software

Final Thought

In the end, all software is just a lens for data.

What matters is not just how we store it or process it, but how we bring it to life for the people who use it. Great builders don't just write code; they craft experiences that make data meaningful, actionable and human.

Remember: Every app, tool or digital system you've ever used is just a smart way of moving, transforming and displaying data. Understanding this transforms how you think about software.

---

Appendix: Quick Reference

S.M.P At a Glance

Layer	Purpose	Key Question	Examples
Storage	Where data lives	"How do we persist this?"	Databases, files, caches
Manipulation	Where data is processed	"How do we transform this?"	APIs, algorithms, business logic
Presentation	Where data meets humans	"How do we show this?"	UIs, dashboards, reports

Decision Tree for Layer Design

Storage Layer:
├── Is data structured? 
│   ├── Yes → SQL Database
│   └── No → NoSQL or Data Lake
│
Manipulation Layer:
├── Is processing real-time?
│   ├── Yes → Stream processing
│   └── No → Batch processing
│
Presentation Layer:
├── Is interaction required?
│   ├── Yes → Interactive UI
│   └── No → Static reports

The S.M.P Mantra

"Store it right, process it smart, present it clear."

The Fundamental Question

Fundamentally, great software starts with this: "What problem are you solving?"

Every decision in the S.M.P Framework flows from this essential question. The problem defines your storage needs, determines your manipulation requirements and shapes your presentation approach.

---

Framework Notice: This document introduces the S.M.P (Storage, Manipulation, Presentation) Framework. While inspired by universal software patterns, this specific formulation and documentation is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). You are free to share and adapt this work, provided you give appropriate credit to AfterZip.com. Copyright AfterZip.com 2025.