DEV Community: Said Olano

AWS DynamoDB: Mastering NoSQL Database Patterns (2026-08-27 02:21)

Said Olano — Thu, 27 Aug 2026 02:21:05 +0000

AWS DynamoDB: Mastering NoSQL Database Patterns

Amazon DynamoDB is a fully managed, serverless NoSQL database that delivers single-digit millisecond performance at any scale. However, unlocking its full potential requires a shift in mindset from traditional relational modeling. This post explores the core patterns that make DynamoDB applications fast, scalable, and cost-effective.

Understanding the Fundamentals

Before diving into patterns, it's essential to understand DynamoDB's building blocks:

Partition Key (PK): Determines the physical partition where data is stored.
Sort Key (SK): Enables sorting and range queries within a partition.
Items: Individual records, up to 400 KB in size.
Attributes: Fields within an item (schemaless beyond the keys).

Unlike SQL databases, DynamoDB rewards denormalization and modeling around your access patterns rather than your data's logical structure.

Pattern 1: Single-Table Design

The most powerful (and controversial) DynamoDB pattern is storing multiple entity types in a single table. This reduces round trips and leverages DynamoDB's partitioning efficiently.

Consider an e-commerce app with Users, Orders, and Products. Instead of three tables, use one with generic key names:

PK	SK	Attributes
USER#123	PROFILE	name, email
USER#123	ORDER#1001	total, status, date
ORDER#1001	PRODUCT#A9	qty, price

By overloading the partition and sort keys, you can fetch a user and all their orders in a single query:

response = table.query(
    KeyConditionExpression=Key('PK').eq('USER#123')
)

Pattern 2: Composite Sort Keys

Encode hierarchical relationships into sort keys to enable flexible range queries. For example, model a location hierarchy:

SK: COUNTRY#USA#STATE#CA#CITY#SF

You can then query with begins_with to retrieve all items under a given scope:

response = table.query(
    KeyConditionExpression=Key('PK').eq('LOCATIONS') &
        Key('SK').begins_with('COUNTRY#USA#STATE#CA')
)

Pattern 3: Global Secondary Indexes (GSIs)

GSIs let you query data using an alternate key structure. A common technique is index overloading, where a single GSI serves multiple access patterns.

# Create a GSI to query orders by status
response = table.query(
    IndexName='GSI1',
    KeyConditionExpression=Key('GSI1PK').eq('STATUS#SHIPPED')
)

Best practices for GSIs:

Project only the attributes you need to reduce cost.
Remember GSIs are eventually consistent.
Watch for hot partitions on low-cardinality keys.

Pattern 4: Write Sharding for Hot Partitions

When a single partition key receives disproportionate traffic (e.g., a trending item), you can distribute writes across synthetic shards:

import random

shard = random.randint(0, 9)
pk = f"PRODUCT#TRENDING#{shard}"

To read all data, query each shard in parallel and merge the results. This spreads throughput across multiple partitions.

Pattern 5: Time Series Data

For time-based data, use a partition key that includes a time bucket to avoid unbounded partitions:

PK: SENSOR#42#2024-01
SK: 2024-01-15T10:30:00Z

Rolling the bucket monthly (or daily for high volume) keeps partitions manageable and supports efficient time-range queries.

Pattern 6: Adjacency List for Many-to-Many

Model graph-like relationships using the adjacency list pattern. Both entities and their relationships live in the same table:

PK: USER#1    SK: GROUP#10   (user 1 belongs to group 10)
PK: GROUP#10  SK: USER#1     (reverse lookup via GSI)

A GSI that swaps PK and SK enables bidirectional queries.

Cost and Performance Tips

Use on-demand capacity for unpredictable workloads; provisioned with auto-scaling for steady traffic.
Enable DynamoDB Accelerator (DAX) for read-heavy, microsecond-latency needs.
Batch operations (BatchGetItem, BatchWriteItem) to reduce network overhead.
Leverage TTL to automatically expire stale items and reduce storage costs.

Conclusion

DynamoDB shines when you design backward from your application's access patterns. Embrace single-table design, exploit composite keys and GSIs, and plan for scale with write sharding and time bucketing. Master these patterns, and you'll build systems that scale effortlessly from prototype to planet-scale.

Start by listing every query your application needs—then model your table to satisfy them with the fewest requests possible.

Artifactory: Repository Management for Modern DevOps (2026-08-26 19:53)

Said Olano — Wed, 26 Aug 2026 19:53:28 +0000

Artifactory: Repository Management

In modern software delivery, managing binary artifacts is just as critical as managing source code. JFrog Artifactory has emerged as a leading universal repository manager, providing a single source of truth for all your binaries—from Docker images and npm packages to Maven JARs and Helm charts.

This post explores the fundamentals of repository management in Artifactory and shares practical guidance for structuring your repositories effectively.

Why a Repository Manager?

Before diving into specifics, it's worth understanding what problems Artifactory solves:

Centralized storage for build artifacts across teams and technologies
Caching of remote dependencies to reduce external network calls and improve build reliability
Access control and security scanning for binaries
Promotion workflows that move artifacts through environments (dev → staging → production)

The Three Repository Types

Artifactory organizes storage into three fundamental repository types. Understanding these is key to a healthy setup.

1. Local Repositories

Local repositories host artifacts that your organization produces. These are your internal builds, releases, and snapshots.

libs-release-local
libs-snapshot-local
docker-local

A common best practice is to separate release and snapshot artifacts to enforce different retention and promotion policies.

2. Remote Repositories

Remote repositories act as caching proxies for external sources like Maven Central, npmjs, or Docker Hub. When a dependency is requested, Artifactory downloads and caches it locally.

maven-central-remote  ->  https://repo1.maven.org/maven2
npm-remote            ->  https://registry.npmjs.org

This reduces reliance on external services and protects you from upstream outages.

3. Virtual Repositories

Virtual repositories aggregate multiple local and remote repositories under a single URL. Consumers point to one endpoint, and Artifactory resolves artifacts across the underlying repos.

maven-virtual
├── libs-release-local
├── libs-snapshot-local
└── maven-central-remote

This abstraction is powerful: you can reorganize backend repositories without changing client configuration.

A Recommended Naming Convention

Consistent naming prevents chaos as your instance grows. A widely adopted pattern is:

<team>-<technology>-<maturity>-<type>

For example:

payments-docker-release-local
payments-maven-snapshot-local
frontend-npm-virtual

Include the repository type suffix (-local, -remote, -virtual) so it's immediately clear how a repository behaves.

Managing Repositories via REST API

Automation is essential at scale. Artifactory exposes a comprehensive REST API for creating and configuring repositories.

curl -u admin:password -X PUT \
  "https://artifactory.example.com/artifactory/api/repositories/docker-local" \
  -H "Content-Type: application/json" \
  -d '{
    "rclass": "local",
    "packageType": "docker",
    "dockerApiVersion": "V2"
  }'

For infrastructure-as-code enthusiasts, the official Terraform provider lets you declare repositories declaratively:

resource "artifactory_local_docker_v2_repository" "docker_local" {
  key             = "docker-local"
  tag_retention   = 3
  max_unique_tags = 5
}

Cleanup and Retention

Binary storage grows quickly. Without a strategy, disk usage becomes unmanageable. Consider:

Retention policies that limit the number of snapshots or Docker tags kept
Scheduled cleanup jobs using AQL (Artifactory Query Language) to identify stale artifacts
Storage quotas to trigger alerts before you run out of space

Here's an AQL example that finds artifacts not downloaded in 90 days:

items.find({
  "repo": "libs-snapshot-local",
  "stat.downloaded": {"$before": "90d"}
})

Security Best Practices

Repository management isn't complete without access control:

Use permission targets to grant least-privilege access per repository
Enable JFrog Xray to scan artifacts for vulnerabilities and license violations
Restrict anonymous access on production-facing repositories
Rotate access tokens regularly and prefer them over passwords in CI pipelines

Conclusion

Effective repository management in Artifactory rests on a few core principles: understand the three repository types, adopt a consistent naming convention, automate provisioning, and enforce cleanup and security policies from day one.

Get these fundamentals right, and Artifactory becomes a reliable backbone for your entire software supply chain—scaling cleanly as your organization and its binaries grow.

Arquitectura Tradicional vs AI-Native: La Evolución que Necesitas Entender

Said Olano — Wed, 26 Aug 2026 18:50:23 +0000

Arquitectura Tradicional vs AI-Native: La Evolución que Necesitas Entender

Introducción

Durante los últimos 20 años, hemos construido sistemas backend siguiendo una arquitectura relativamente consistente: usuario → frontend → backend → base de datos. Este modelo ha funcionado bien y sigue siendo válido. Pero algo fundamental cambió en 2023-2024.

Hoy, si ignoras cómo integrar capacidades de IA en tu arquitectura de software, estás quedando obsoleto. No es hype—es evolución arquitectónica real.

En este artículo, exploro las diferencias críticas entre la arquitectura tradicional y la arquitectura AI-Native, cómo Spring AI cambia el juego para desarrolladores Java, y por qué tu próximo proyecto debería pensar en LLMs desde el inicio, no como un anexo.

La Arquitectura Tradicional: El Modelo que Conocemos

Usuario → Frontend → Backend → Base de Datos

Este diagrama ha gobernado el desarrollo de software empresarial por 15+ años:

Frontend: Interfaz de usuario (web, móvil, desktop)
Backend: Lógica de negocio en Java/Spring, Python, Node, etc.
Base de Datos: PostgreSQL, MySQL, Oracle, etc.

Limitaciones de este modelo:

Sin contexto inteligente: El backend ejecuta lógica predefinida, sin capacidad de razonar sobre contexto
Clasificación binaria: Si → No. Sí → Tabla X o Tabla Y. Sin matices
Requiere reglas explícitas: Cada escenario debe codificarse manualmente
No escala con complejidad: Añadir nuevos casos requiere nuevo código y testing

¿Cuándo funciona aún?

La arquitectura tradicional es perfecta para:

Operaciones CRUD básicas
Lógica transaccional determinista
Sistemas de reporting
APIs REST simples

Pero falla cuando necesitas:

Recomendaciones personalizadas
Clasificación inteligente de datos
Procesamiento de lenguaje natural
Decisiones basadas en contexto complejo

La Arquitectura AI-Native: El Nuevo Paradigma

Usuario → Frontend → Backend → Spring AI ↔ LLM → Enterprise APIs
                         ↓
                   Vector Database

La arquitectura AI-Native introduce componentes nuevos en la pila:

1. Spring AI: Tu Abstracción Estratégica

Spring AI es la capa de abstracción que conecta tu backend Java tradicional con modelos de lenguaje (LLMs). Piénsalo como java.net.HttpURLConnection fue para HTTP hace 15 años.

@Autowired
private ChatClient chatClient;

public String processComplexQuery(String userInput) {
    String response = chatClient.prompt()
        .user(userInput)
        .call()
        .content();
    return response;
}

Por qué importa:

Agnóstico de modelo: Cambia entre OpenAI, Claude, Llama sin refactorizar código
Integración con tu stack: Funciona nativamente con Spring Boot, Spring Security, etc.
Gestión de tokens: Maneja limite de contexto automáticamente
Retrieval Augmented Generation (RAG): Conecta a bases de datos vectoriales

2. LLM: Tu Inteligencia Contextual

Un Large Language Model no es un "chatbot". Es una máquina de razonar que:

Lee y comprende contexto complejo
Genera texto, código, análisis
Toma decisiones basadas en matices
Se alimenta de ejemplos y patrones en sus 7-70B parámetros

String prompt = "Analiza este fraude potencial: " + transactionData + 
                "\nReglas de negocio: " + businessRules +
                "\n¿Es fraude? Justifica con 2-3 razones.";

String analysis = chatClient.prompt()
    .user(prompt)
    .call()
    .content();

3. Vector Database: Tu Motor de Memoria

Una base de datos vectorial (Pinecone, Weaviate, Milvus) almacena documentos como embeddings numéricos. Permite búsqueda semántica:

"¿Cuál es nuestra política de cancelaciones?"
        ↓
    Embeddings
        ↓
    Vector DB (busca similitud)
        ↓
    Retorna política relevante → LLM → Respuesta precisa

Ventaja crítica: No necesita palabra exacta. Entiende significado.

4. Enterprise APIs: Tu Contexto en Tiempo Real

El LLM no funciona en vacío. Necesita datos vivos:

Estado de cuenta del cliente
Inventario disponible
Políticas de compañía
Datos de mercado en tiempo real

String loanDecision = chatClient.prompt()
    .user("Cliente " + customer + " solicita préstamo de " + amount)
    .system("Usa datos de creditScoreAPI y complianceDB para decidir")
    .call()
    .content();

Diferencias Clave: Punto a Punto

Aspecto	Tradicional	AI-Native
Decisiones	Determinísticas (if/else)	Contextual + razonada
Escalabilidad de lógica	Lineal (una regla = un if)	Exponencial (el LLM generaliza)
Errores	Binarios (funciona o no)	Graduales (respuesta parcialmente correcta)
Actualización	Redeploy + testing	Prompt engineering (minutos)
Latencia	ms	500-2000ms (LLM call)
Costos	Hardware + ops	Tokens * precio/1M

Casos de Uso: Dónde Brilla AI-Native

1. Análisis de Riesgos Financieros

Tradicional: 47 reglas hard-coded
AI-Native: LLM analiza contexto transaccional completo + historial + señales de mercado

2. Atención al Cliente

Tradicional: Chatbot con 500 reglas pre-escritas
AI-Native: Agente que lee base de conocimiento, entiende contexto, genera respuestas coherentes

3. Clasificación de Documentos

Tradicional: Regex + NLP simple
AI-Native: LLM entiende semántica real, maneja idiomas, detecta fraudes documentales

4. Recomendaciones

Tradicional: Filtrado colaborativo
AI-Native: LLM + vector DB genera recomendaciones explicables ("Te recomendamos X porque...")

Implementación: Spring AI en Acción

Setup Básico

@Configuration
@EnableSpringAI
public class AiConfig {

    @Bean
    public ChatClient chatClient(ChatModel chatModel) {
        return ChatClient.builder(chatModel).build();
    }
}

Consulta Avanzada con RAG

@Service
public class DocumentAnalysisService {

    @Autowired
    private ChatClient chatClient;

    @Autowired
    private VectorStore vectorStore;

    public String analyzeWithContext(String query) {
        // 1. Busca en vector DB
        List<Document> relevantDocs = vectorStore.search(
            new SearchRequest(query).withTopK(5)
        );

        // 2. Construye contexto
        String context = relevantDocs.stream()
            .map(Document::getContent)
            .collect(Collectors.joining("\n---\n"));

        // 3. Llama LLM con contexto
        return chatClient.prompt()
            .user("Pregunta: " + query)
            .system("Contexto relevante:\n" + context)
            .call()
            .content();
    }
}

Migración: No Es Todo o Nada

No necesitas reescribir tu backend. La arquitectura AI-Native es aditiva:

Fase 1: Mantén tu stack actual
Fase 2: Agrega Spring AI para casos de uso específicos
Fase 3: Integra vector DB donde agregue valor
Fase 4: Expande gradualmente

Ejemplo: Mantén tu backend Java Spring Boot intacto, pero agrega un servicio de análisis de riesgos con LLM.

Costos Reales

Preocupación común: "¿No será caro?"

Respuesta: Depende, pero generalmente no.

OpenAI API: ~$0.0005-0.002 por 1K tokens
Consulta típica: 1000-2000 tokens = $0.001-0.003
vs. ing. tradicional: Una consulta = 2-4 horas de dev time

ROI: Una consulta ML = ~10 líneas de lógica tradicional.

Limitaciones: Sé Honesto

Dónde AI-Native falla:

Transacciones críticas sin explicabilidad (pagos, créditos)
Sistemas embebidos con latencia crítica (control en tiempo real)
Datasets ultra-pequeños (<1000 ejemplos)
Donde el hallucination es inaceptable

Solución: Híbridos. Usa AI-Native para análisis, backend tradicional para ejecución.

Conclusión: La Pregunta Ya No Es "Si", Sino "Cuándo"

En 2024, la arquitectura AI-Native no es un experimento de IA. Es infraestructura empresarial.

Si diseñas una nueva aplicación hoy sin considerar cómo AI + LLMs pueden mejorar tu propuesta de valor, estás dejando dinero y capacidad en la mesa.

Siguientes pasos:

Experimenta con Spring AI en un caso de uso no crítico
Mide latencia y costos reales en tu stack
Expande a producción donde agregue valor

El futuro no es "AI o Backend Tradicional". Es ambos, integrados inteligentemente.

¿Te gustaría explorar un caso específico en tu dominio? Fintech, e-commerce, seguros—cada industria tiene oportunidades únicas donde AI-Native cambia el juego.

Keycloak: A Deep Dive into Open Source Identity and Access Management (2026-08-26 14:42)

Said Olano — Wed, 26 Aug 2026 14:42:04 +0000

Keycloak: Open Source IAM Solution

Managing authentication and authorization across modern applications is a complex challenge. Building these capabilities from scratch is error-prone and time-consuming. Keycloak, an open source Identity and Access Management (IAM) solution maintained by Red Hat, solves this problem by providing a robust, standards-based platform out of the box.

What Is Keycloak?

Keycloak is a self-hosted IAM server that centralizes authentication and authorization for your applications and services. Instead of each application implementing its own login logic, they delegate that responsibility to Keycloak.

Key features include:

Single Sign-On (SSO) and Single Sign-Out across applications
Identity Brokering with social login (Google, GitHub, Facebook, etc.)
User Federation with LDAP and Active Directory
Standard protocol support: OpenID Connect, OAuth 2.0, and SAML 2.0
Fine-grained authorization with role-based and attribute-based access control
Admin Console and Account Console for management

Core Concepts

Understanding a few key concepts is essential before working with Keycloak.

Realms

A realm is an isolated space that manages a set of users, credentials, roles, and clients. Realms are completely separated from one another. The master realm is used to administer Keycloak itself, while you create dedicated realms for your applications.

Clients

A client is an application or service that wants to use Keycloak for authentication. Clients can be:

Confidential: Backend services that can securely store a secret.
Public: Frontend apps (SPAs, mobile) that cannot keep secrets confidential.

Roles and Groups

Roles define permissions, and can be realm-level or client-level. Groups allow you to organize users and assign roles collectively, simplifying permission management at scale.

Getting Started with Docker

The fastest way to try Keycloak is via Docker. The following command starts a development instance:

docker run -p 8080:8080 \
  -e KEYCLOAK_ADMIN=admin \
  -e KEYCLOAK_ADMIN_PASSWORD=admin \
  quay.io/keycloak/keycloak:latest \
  start-dev

Once running, access the admin console at http://localhost:8080 and log in with the credentials above.

Note: start-dev mode uses an in-memory database and disables HTTPS. Never use it in production.

Integrating an Application

Here's a typical OpenID Connect flow for a web application:

The user requests a protected resource.
The application redirects the user to Keycloak's login page.
After successful authentication, Keycloak redirects back with an authorization code.
The application exchanges the code for access and ID tokens.
The application validates the token and grants access.

Example: Verifying a Token in Node.js

const jwksClient = require('jwks-rsa');
const jwt = require('jsonwebtoken');

const client = jwksClient({
  jwksUri: 'http://localhost:8080/realms/myrealm/protocol/openid-connect/certs'
});

function getKey(header, callback) {
  client.getSigningKey(header.kid, (err, key) => {
    callback(null, key.getPublicKey());
  });
}

function verifyToken(token) {
  return new Promise((resolve, reject) => {
    jwt.verify(token, getKey, { algorithms: ['RS256'] }, (err, decoded) => {
      if (err) return reject(err);
      resolve(decoded);
    });
  });
}

Production Considerations

When deploying Keycloak to production, keep these best practices in mind:

Use a proper database (PostgreSQL, MySQL) instead of the dev default.
Enable HTTPS/TLS to protect tokens in transit.
Run in cluster mode for high availability and horizontal scaling.
Configure token lifespans appropriately to balance security and UX.
Set up regular backups of your realm configuration and database.
Harden the admin console by restricting network access.

Production Startup Example

docker run -p 8443:8443 \
  -e KC_DB=postgres \
  -e KC_DB_URL=jdbc:postgresql://db:5432/keycloak \
  -e KC_DB_USERNAME=keycloak \
  -e KC_DB_PASSWORD=secret \
  -e KC_HOSTNAME=auth.example.com \
  quay.io/keycloak/keycloak:latest \
  start --optimized

Advantages and Trade-offs

Advantages:

Free and open source with no licensing costs
Standards-compliant, avoiding vendor lock-in
Highly extensible via custom providers and SPIs
Strong community and enterprise backing from Red Hat

Trade-offs:

Requires operational effort to host and maintain
Steeper learning curve compared to managed SaaS alternatives
Scaling and upgrades demand careful planning

Conclusion

Keycloak is a powerful, mature IAM solution that brings enterprise-grade authentication and authorization to any organization without licensing fees. By offloading identity management to a dedicated, standards-based platform, development teams can focus on building features rather than reinventing security infrastructure. While it requires operational commitment, the flexibility and control it offers make it an excellent choice for teams that want to own their identity stack.

PI Planning & Strategic Alignment: How to Drive Roadmaps That Actually Deliver

Said Olano — Tue, 25 Aug 2026 22:27:41 +0000

PI Planning & Strategic Alignment: How to Drive Roadmaps That Actually Deliver

Keywords: PI Planning, Program Increment, Agile Leadership, Stakeholder Management, SAFe, Strategic Alignment

The Challenge: Misaligned Roadmaps and Frustrated Stakeholders

You've built great engineering teams. Your developers are shipping features. Your sprints are on track.

But something's wrong.

The roadmap your teams built doesn't match what your stakeholders expected. The features you're shipping don't align with business priorities. And by the time you realize it, you're three months in and the damage is done.

This is the PI Planning problem.

Program Increment (PI) Planning isn't just another meeting. It's where strategy becomes execution, where business intent meets technical reality, and where stakeholder alignment either happens or falls apart.

What is PI Planning (And Why It Matters)

PI Planning is a quarterly event where the entire engineering organization—managers, architects, product leaders—aligns on:

Business objectives for the next quarter
Technical capabilities needed
Dependencies across teams
Realistic commitments
Risk mitigation strategies

Without PI Planning:

Teams build in silos
Roadmaps drift from business goals
Stakeholders are surprised by what ships
Dependencies aren't discovered until mid-sprint
Technical debt accumulates unchecked

With strong PI Planning:

Everyone knows why they're building what
Business and engineering are aligned
Dependencies are surfaced early
Roadmaps stay predictable
Technical decisions serve business goals

The Framework: How to Drive Effective PI Planning

Phase 1: Pre-Planning (2 weeks before)

Before the meeting, you do the homework:

1. Gather business context

What are this quarter's top 3-5 business priorities?
Which customer problems are we solving?
What revenue impact are we targeting?
What competitive threats are we addressing?

2. Inventory current capabilities

What's our actual capacity? (Don't guess—measure)
What technical debt are we carrying?
What's in flight from last quarter?
What skills do our teams have?

3. Identify constraints

Are there hard dependencies on other teams?
Do we need external resources?
What infrastructure limitations exist?
What regulatory or compliance issues matter?

4. Draft strategic themes

A strategic theme is a business-level objective that multiple teams contribute to.

Example themes:

"Improve API response time by 50% (customer experience + competitive advantage)"
"Reduce onboarding friction (customer retention + revenue growth)"
"Build compliance reporting (regulatory requirement)"

Each theme has a clear business outcome. Not a technical output.

Phase 2: The Planning Meeting (1 day, structured)

Morning: Context Setting (3 hours)

The business stakeholders present:

Quarter strategy (15 min)
Customer feedback (15 min)
Competitive landscape (10 min)
Success metrics (10 min)

Then the hardest part: Open questions.

Your engineering leadership asks:

"If we only shipped 3 things this quarter, which would matter most?"
"What's the minimum viable capability for each priority?"
"Where do we need to invest in technical foundation vs. features?"

This is where misalignment gets discovered. And better now than in August when stakeholders realize you built the wrong thing.

Afternoon: Team Planning (3 hours)

Teams take the strategic themes and break them into:

Features (what customers see)
Enablers (technical foundation to support features)
Infrastructure (platform reliability and tools)
Defect fixes (bugs affecting customers)

For each item, teams commit to:

Estimated capacity (stories, points, or t-shirt sizes)
Dependencies (which other teams matter)
Assumptions (what has to be true)
Risks (what could go wrong)

The commitment is realistic. Not aspirational. Real.

Phase 3: Roadmap Validation (Post-meeting)

After the meeting, as the engineering leader, you do a final validation:

Does the roadmap actually address the business priorities?
- If not, realign immediately
Are the dependencies manageable?
- If Team A depends on Team B depends on Team C, that's risk
- Identify and mitigate early
Do we have the people and skills?
- A plan that requires a skill you don't have is just fiction
- Identify training or hiring needs now
What could derail us?
- External dependencies, unknown unknowns, team changes, technical surprises
- Plan for each

The Key to Success: Ruthless Prioritization

Here's the uncomfortable truth: You cannot do everything.

The best PIs don't have the most ambitious plans. They have the most ruthlessly prioritized plans.

I watched an organization plan to build 30 features in a quarter. They got 6 done. Another organization planned 8 features and delivered 8. Same engineering team, same capacity.

The difference? The second organization said "no" to 90% of requests.

How to prioritize ruthlessly:

Use business impact as the primary filter
- Not "cool tech", not "customer niceness"
- Impact: revenue, retention, competitive advantage, risk mitigation
Apply the "drop-off" test
- Rank your priorities 1-10
- Cut everything ranked 4+
- Focus on 1-3
- It's painful. That's the point.
Get stakeholder buy-in on the cuts
- If stakeholders don't agree with priorities, something's wrong
- Better to fight about it in planning than in August
- Build trust by saying "no" early

Stakeholder Alignment: The Real Work

PI Planning isn't just an engineering exercise. It's a stakeholder alignment ceremony.

Your job as engineering leader is to make sure business leaders and engineering teams speak the same language about:

What are we building?

Not "refactor the auth service"
But "reduce login failures from 2% to 0.1% (improves retention by 5%)"

Why are we building it?

Not "to avoid technical debt"
But "because customers report login frustration in NPS surveys"

What does success look like?

Not "code is deployed"
But "customers can reliably log in under 300ms, 99.9% uptime"

How do we know we're on track?

Not "sprint velocity"
But "weekly login success rate + customer satisfaction"

This translation between "business language" and "engineering language" is your job as the liaison between stakeholders and teams.

Common PI Planning Mistakes (And How to Avoid Them)

Mistake 1: Overly Ambitious Planning

You commit to 50 points worth of work. You always have 25 left over.

Solution: Track your actual capacity. If you finish 25 points in a sprint, your capacity is 25. Plan for 20 (account for unknowns).

Mistake 2: Ignoring Dependencies

Team A builds Feature X. Team B builds Feature Y. They need each other. You didn't realize it until week 6.

Solution: Explicitly map dependencies. If Team A blocks Team B for 2 weeks, Team B plans for that.

Mistake 3: Zero Technical Debt Work

"We'll get to refactoring the database later."

Later never comes. And that database becomes a crisis in Q4.

Solution: Allocate 20-30% of capacity to "enablers"—technical foundation, debt, infrastructure. It's not optional. It's survival.

Mistake 4: Forgetting About Incidents

You plan a perfect quarter. Then a customer-critical bug appears. Your best engineers spend 2 weeks on it. The plan falls apart.

Solution: Reserve 10-15% of capacity for "buffer"—unplanned incidents, urgent bugs, customer escalations. Not wasted capacity. Insurance.

Mistake 5: No Stakeholder Participation

Engineering teams plan alone. Then they show stakeholders the roadmap. Stakeholders hate it.

Solution: Have stakeholders in the room during PI Planning. Conflict early, when it's cheap to fix. Not in August.

Real-World Example: Scaling Across Multiple Squads

I led PI Planning for a 30-person engineering org (3 squads of 10). Here's what worked:

Pre-Planning (Week 1-2):

Product leadership: 3 business priorities
Architecture: platform constraints and opportunities
Each squad lead: realistic capacity assessment

Planning (Day 1 - Morning):

Business leader: "This quarter we're improving payment reliability (15% of failed transactions) and reducing onboarding time"
Architecture: "We need to migrate off the legacy payment system (3-week project)"
Finance: "New regulatory requirement for audit logging"

Planning (Day 1 - Afternoon):

Squad 1: "We'll own the payment migration + regulatory logging"
Squad 2: "We'll own onboarding UX improvements + APIs"
Squad 3: "We'll own internal tools + technical debt"

Post-Planning:

Reality check: All dependencies documented, capacity matches reality
Dependencies surfaced: Squad 2 needs Squad 1's API changes by week 3
Risk: Payment system provider outage during migration. Plan: dual-deployment approach
Validation: All 3 business priorities addressed

Result:

Payment reliability improved 40% (saved $500K in chargebacks)
Onboarding time reduced by 30% (boosted conversion)
Technical debt halved (reduced future incidents)
All three squads hit their commitments

Measuring Success: Beyond Velocity

You'll know PI Planning is working when:

✅ Stakeholders understand the roadmap - Not because you told them again, but because they helped build it

✅ Roadmaps stay stable - 80%+ of PI committed work actually ships

✅ Dependencies are surfaced early - Problems discovered in planning, not mid-sprint

✅ Technical debt gets addressed - Enablers are 20-30% of capacity

✅ Business outcomes materialize - Features shipped actually move the needle

✅ Teams feel ownership - Engineers understand why they're building

The Bottom Line

PI Planning isn't about processes or ceremonies. It's about creating alignment between what business needs and what engineering builds.

When PI Planning works:

Engineers aren't surprised by pivots
Stakeholders aren't surprised by delays
Business outcomes improve
Teams feel ownership
Technical foundation stays healthy

When PI Planning doesn't happen:

Roadmaps drift
Stakeholders are frustrated
Teams are frustrated
Technical debt explodes
Quarters feel chaotic

The investment? One intense day every quarter.

The return? A quarter of coordinated, aligned, high-impact engineering.

That's the trade. And it's worth it.

Your Action Items

This quarter:

Gather your stakeholders - What are the 3-5 business priorities? What constraints exist?
Set capacity realistically - Don't guess. Measure. Look at last quarter's actual throughput.
Map dependencies - Which teams need to coordinate? What's the critical path?
Run PI Planning - Half-day: Stakeholders present. Half-day: Teams plan.
Communicate the roadmap - Not just the what, but the why and the how.

The best quarter isn't the busiest one. It's the most aligned one.

PI Planning makes that alignment happen.

PI Planning & Strategic Alignment: Driving Roadmaps That Deliver

Said Olano — Tue, 25 Aug 2026 22:25:41 +0000

PI Planning & Strategic Alignment: Driving Roadmaps That Deliver

Keywords: PI Planning, Program Increment, Agile Leadership, Stakeholder Management, SAFe, Strategic Alignment

The Challenge: Misaligned Roadmaps and Frustrated Stakeholders

You've built great engineering teams. Your developers are shipping features. Your sprints are on track.

But something's wrong.

This is the PI Planning problem.

What is PI Planning (And Why It Matters)

PI Planning is a quarterly event where the entire engineering organization—managers, architects, product leaders—aligns on:

Business objectives for the next quarter
Technical capabilities needed
Dependencies across teams
Realistic commitments
Risk mitigation strategies

Without PI Planning:

Teams build in silos
Roadmaps drift from business goals
Stakeholders are surprised by what ships
Dependencies aren't discovered until mid-sprint
Technical debt accumulates unchecked

With strong PI Planning:

Everyone knows why they're building what
Business and engineering are aligned
Dependencies are surfaced early
Roadmaps stay predictable
Technical decisions serve business goals

The Framework: How to Drive Effective PI Planning

Phase 1: Pre-Planning (2 weeks before)

Before the meeting, you do the homework:

1. Gather business context

What are this quarter's top 3-5 business priorities?
Which customer problems are we solving?
What revenue impact are we targeting?
What competitive threats are we addressing?

2. Inventory current capabilities

What's our actual capacity? (Don't guess—measure)
What technical debt are we carrying?
What's in flight from last quarter?
What skills do our teams have?

3. Identify constraints

Are there hard dependencies on other teams?
Do we need external resources?
What infrastructure limitations exist?
What regulatory or compliance issues matter?

4. Draft strategic themes
A strategic theme is a business-level objective that multiple teams contribute to.

Example themes:

"Improve API response time by 50% (customer experience + competitive advantage)"
"Reduce onboarding friction (customer retention + revenue growth)"
"Build compliance reporting (regulatory requirement)"

Each theme has a clear business outcome. Not a technical output.

Phase 2: The Planning Meeting (1 day, structured)

Morning: Context Setting (3 hours)

The business stakeholders present:

Quarter strategy (15 min)
Customer feedback (15 min)
Competitive landscape (10 min)
Success metrics (10 min)

Then the hardest part: Open questions.

Your engineering leadership asks:

"If we only shipped 3 things this quarter, which would matter most?"
"What's the minimum viable capability for each priority?"
"Where do we need to invest in technical foundation vs. features?"

This is where misalignment gets discovered. And better now than in August when stakeholders realize you built the wrong thing.

Afternoon: Team Planning (3 hours)

Teams take the strategic themes and break them into:

Features (what customers see)
Enablers (technical foundation to support features)
Infrastructure (platform reliability and tools)
Defect fixes (bugs affecting customers)

For each item, teams commit to:

Estimated capacity (stories, points, or t-shirt sizes)
Dependencies (which other teams matter)
Assumptions (what has to be true)
Risks (what could go wrong)

The commitment is realistic. Not aspirational. Real.

Phase 3: Roadmap Validation (Post-meeting)

After the meeting, as the engineering leader, you do a final validation:

Does the roadmap actually address the business priorities?
- If not, realign immediately
Are the dependencies manageable?
- If Team A depends on Team B depends on Team C, that's risk
- Identify and mitigate early
Do we have the people and skills?
- A plan that requires a skill you don't have is just fiction
- Identify training or hiring needs now
What could derail us?
- External dependencies
- Unknown unknowns
- Team changes
- Technical surprises
- Plan for each

The Key to Success: Ruthless Prioritization

Here's the uncomfortable truth:

You cannot do everything.

The best PIs don't have the most ambitious plans. They have the most ruthlessly prioritized plans.

I watched an organization plan to build 30 features in a quarter. They got 6 done. Another organization planned 8 features and delivered 8. Same engineering team, same capacity.

The difference? The second organization said "no" to 90% of requests.

How to prioritize ruthlessly:

Use business impact as the primary filter
- Not "cool tech"
- Not "customer niceness"
- Impact: revenue, retention, competitive advantage, risk mitigation
Apply the "drop-off" test
- Rank your priorities 1-10
- Cut everything ranked 4+
- Focus on 1-3
- It's painful. That's the point.
Get stakeholder buy-in on the cuts
- If stakeholders don't agree with priorities, something's wrong
- Better to fight about it in planning than in August
- Build trust by saying "no" early

Stakeholder Alignment: The Real Work

PI Planning isn't just an engineering exercise. It's a stakeholder alignment ceremony.

Your job as engineering leader is to make sure business leaders and engineering teams speak the same language about:

What are we building?

Not "refactor the auth service"
But "reduce login failures from 2% to 0.1% (improves retention by 5%)"

Why are we building it?

Not "to avoid technical debt"
But "because customers report login frustration in NPS surveys"

What does success look like?

Not "code is deployed"
But "customers can reliably log in under 300ms, 99.9% uptime"

How do we know we're on track?

Not "sprint velocity"
But "weekly login success rate + customer satisfaction"

This translation between "business language" and "engineering language" is your job as the liaison between stakeholders and teams.

Common PI Planning Mistakes (And How to Avoid Them)

Mistake 1: Overly Ambitious Planning

You commit to 50 points worth of work. You always have 25 left over.

Solution: Track your actual capacity. If you finish 25 points in a sprint, your capacity is 25. Plan for 20 (account for unknowns). That's a successful PI.

Mistake 2: Ignoring Dependencies

Team A builds Feature X. Team B builds Feature Y. They need each other. You didn't realize it until week 6.

Solution: In planning, explicitly map dependencies. If Team A blocks Team B for 2 weeks, Team B plans for that. Better than discovering it mid-quarter.

Mistake 3: Zero Technical Debt Work

"We'll get to refactoring the database later."

Later never comes. And that database becomes a crisis in Q4.

Solution: Allocate 20-30% of capacity to "enablers"—technical foundation, debt, infrastructure. It's not optional. It's survival.

Mistake 4: Forgetting About Incidents

You plan a perfect quarter. Then a customer-critical bug appears. Your best engineers spend 2 weeks on it. The plan falls apart.

Solution: Reserve 10-15% of capacity for "buffer"—unplanned incidents, urgent bugs, customer escalations. Not wasted capacity. Insurance.

Mistake 5: No Stakeholder Participation

Engineering teams plan alone. Then they show stakeholders the roadmap.

Stakeholders hate it. It doesn't match their priorities. You replan. Twice.

Solution: Have stakeholders in the room during PI Planning. Conflict early, when it's cheap to fix. Not in August.

Real-World Example: Scaling Across Multiple Squads

I led PI Planning for a 30-person engineering org (3 squads of 10). Here's what worked:

Pre-Planning (Week 1-2):

Product leadership: 3 business priorities
Architecture: platform constraints and opportunities
Each squad lead: realistic capacity assessment

Planning (Day 1 - Morning):

Business leader: "This quarter we're improving payment reliability (15% of failed transactions) and reducing onboarding time (critical for Q4 launches)"
Architecture: "We need to migrate off the legacy payment system (3-week project)"
Finance: "New regulatory requirement for audit logging"

Planning (Day 1 - Afternoon):

Squad 1: "We'll own the payment migration + regulatory logging"
Squad 2: "We'll own onboarding UX improvements + APIs"
Squad 3: "We'll own internal tools + technical debt"

Post-Planning:

Reality check: Migration is 3 weeks, leaves 3 weeks for enhancements. Onboarding can land 2 features + 1 research spike. Tools team can refactor the data layer.
Dependencies surfaced: Squad 2 needs Squad 1's API changes by week 3. Squad 3 needs data layer before Squad 2 can optimize queries.
Risk: Payment system provider outage during migration. Plan: partner with Platform team, dual-deployment approach.
Validation: All 3 business priorities are addressed. All dependencies are documented. Capacity matches reality.

Result:

Payment reliability improved 40% (saved $500K in chargebacks)
Onboarding time reduced by 30% (boosted conversion)
Technical debt halved (reduced future incidents)
All three squads hit their commitments

Measuring Success: Beyond Velocity

You'll know PI Planning is working when:

✅ Stakeholders understand the roadmap

Not because you told them again
But because they helped build it

✅ Roadmaps stay stable

80%+ of PI committed work actually ships
Surprises are rare
Plans adjust, but rarely pivot

✅ Dependencies are surfaced early

Problems discovered in planning, not mid-sprint
Handoffs are smooth
Teams can explain why they depend on each other

✅ Technical debt gets addressed

Enablers are 20-30% of capacity
Infrastructure investments happen
Technical health improves quarter over quarter

✅ Business outcomes materialize

Features shipped actually move the needle
Stakeholders see ROI
Customers notice improvements

✅ Teams feel ownership

Engineers understand why they're building
Squads commit to realistic goals
Celebrations happen when milestones hit

The Bottom Line

PI Planning isn't about processes or ceremonies. It's about creating alignment between what business needs and what engineering builds.

When PI Planning works:

Engineers aren't surprised by pivots
Stakeholders aren't surprised by delays
Business outcomes improve
Teams feel ownership
Technical foundation stays healthy

When PI Planning doesn't happen:

Roadmaps drift
Stakeholders are frustrated
Teams are frustrated
Technical debt explodes
Quarters feel chaotic

The investment? One intense day every quarter.

The return? A quarter of coordinated, aligned, high-impact engineering.

That's the trade. And it's worth it.

Your Action Items

This quarter:

Gather your stakeholders
- What are the 3-5 business priorities?
- What constraints exist?
- What's the one metric we should optimize for?
Set capacity realistically
- Don't guess. Measure.
- Look at last quarter's actual throughput
- Factor in buffer (10-15%) for unknowns
Map dependencies
- Which teams need to coordinate?
- What's the critical path?
- What could block us?
Run PI Planning
- Half-day: Stakeholders present
- Half-day: Teams plan
- Follow-up: Validation and de-risking
Communicate the roadmap
- Not just the what (features)
- But the why (business outcomes)
- And the how (dependencies, risks, assumptions)

The best quarter isn't the busiest one. It's the most aligned one.

PI Planning makes that alignment happen.

AWS S3: Storage Strategy and Best Practices (2026-08-25 22:14)

Said Olano — Tue, 25 Aug 2026 22:14:17 +0000

AWS S3: Storage Strategy and Best Practices

Amazon Simple Storage Service (S3) is one of the foundational services in the AWS ecosystem. While it's easy to get started—create a bucket, upload an object—building a cost-effective, secure, and performant storage strategy requires deliberate planning. This post covers the practices that matter most in production environments.

Understanding S3 Storage Classes

Choosing the right storage class is the single most impactful decision for controlling cost. Each class trades off availability, retrieval latency, and price.

Storage Class	Use Case	Retrieval	Min. Duration
S3 Standard	Frequently accessed data	Instant	None
S3 Intelligent-Tiering	Unpredictable access patterns	Instant	None
S3 Standard-IA	Infrequent access, fast retrieval	Instant	30 days
S3 One Zone-IA	Infrequent, non-critical data	Instant	30 days
S3 Glacier Instant Retrieval	Archives needing millisecond access	Instant	90 days
S3 Glacier Flexible Retrieval	Archives, minutes to hours	Minutes–hours	90 days
S3 Glacier Deep Archive	Long-term cold storage	Up to 12 hours	180 days

Recommendation: If your access patterns are unknown or variable, use S3 Intelligent-Tiering. It automatically moves objects between tiers based on usage without retrieval fees, and the monitoring cost is negligible for most workloads.

Lifecycle Policies for Automated Cost Optimization

Rather than manually managing object transitions, define lifecycle rules to automate them.

{
  "Rules": [
    {
      "ID": "ArchiveAndExpireLogs",
      "Filter": { "Prefix": "logs/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 365 }
    }
  ]
}

This rule keeps logs in Standard for 30 days, moves them to Standard-IA, then to Glacier, and finally deletes them after a year. Also configure AbortIncompleteMultipartUpload to clean up failed uploads that silently accumulate storage costs.

Security Best Practices

Security misconfigurations are the leading cause of S3 data exposure. Apply defense in depth.

1. Block Public Access

Enable S3 Block Public Access at both the account and bucket levels unless you have a documented reason to serve public content.

aws s3api put-public-access-block \
  --bucket my-secure-bucket \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

2. Enforce Encryption

Enable default encryption using SSE-KMS for sensitive data. Enforce it with a bucket policy that rejects unencrypted uploads:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-secure-bucket/*",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "aws:kms"
    }
  }
}

3. Enforce TLS in Transit

Deny any request not made over HTTPS using the aws:SecureTransport condition key.

4. Least Privilege IAM

Grant access via IAM roles scoped to specific prefixes and actions. Avoid wildcard s3:* permissions and prefer bucket policies plus IAM over legacy ACLs (which AWS now disables by default).

Data Durability and Protection

Enable Versioning to protect against accidental deletion and overwrites. Combine it with lifecycle rules to expire old versions.
Enable MFA Delete on critical buckets to require multi-factor authentication for permanent deletions.
Use Object Lock in compliance mode for WORM (write-once-read-many) requirements such as audit logs and regulatory data.
Replicate critical data using Cross-Region Replication (CRR) for disaster recovery or Same-Region Replication (SRR) for compliance and log aggregation.

Performance Optimization

S3 automatically scales to high request rates—3,500 PUT/COPY/POST/DELETE and 5,500 GET/HEAD requests per second per prefix. To maximize throughput:

Parallelize across prefixes. Distributing objects across multiple prefixes multiplies your request ceiling.
Use multipart uploads for objects larger than 100 MB to improve resilience and throughput.
Enable S3 Transfer Acceleration for fast long-distance transfers over Amazon's edge network.
Front frequently accessed content with CloudFront to reduce latency and offload requests from S3.

Note: Modern S3 no longer requires random hash prefixes for performance. The scaling is now automatic per prefix, so organize keys for logical clarity rather than performance hacks.

Cost Visibility and Monitoring

Enable S3 Storage Lens for account-wide visibility into usage and activity trends.
Use cost allocation tags to attribute spend to teams and projects.
Set up S3 Inventory reports to audit objects, encryption status, and replication

How Clear Performance Frameworks Beat Engineering Heroics Every Time

Said Olano — Tue, 25 Aug 2026 21:49:14 +0000

How Clear Performance Frameworks Beat Engineering Heroics Every Time

Keywords: Engineering Leadership, Team Performance, Delivery Management, Sprint Management, Engineering Culture

The Problem: Chaos Disguised as High Performance

When I took over my engineering teams, we had a productivity problem masquerading as "high performance."

Teams were shipping features, sure. But the process was chaotic:

Sprint goals were vague narratives, not measurable outcomes
Code commits were sporadic — bursts of activity followed by silence
No one could predict when things would actually ship
Developers worked long hours to meet artificial deadlines
Burnout was creeping in, though no one said it out loud

The worst part? Leadership kept calling this "hustle culture" and "heroic delivery."

I realized we had confused motion with momentum.

The Turning Point: Getting Boring

The breakthrough came when I stopped looking for heroics and started building systems.

Here's what happened:

1. Defined What "Done" Actually Means

Before: "Sprint goal: deliver the user profile feature"
After: Clear Definition of Done (DoD)

✓ Code passes peer review (minimum 2 approvals)
✓ Unit tests pass (minimum 80% coverage)
✓ Integration tests pass on staging
✓ Code is merged to main branch
✓ Feature is deployable (not just developed)
✓ Documentation updated or created
✓ No known bugs or technical debt added

This simple document transformed everything. Teams stopped debating what "done" meant. No more surprises at sprint review.

2. Established Sprint Goal Criteria

Every sprint, we asked three questions:

1. Is the goal measurable?

❌ Bad: "Improve API performance"
✅ Good: "Reduce API p99 latency from 500ms to 200ms"

2. Can it be verified by sprint end?

❌ Bad: "Start the refactor"
✅ Good: "Complete refactoring of payment service, all tests passing"

3. Does it deliver customer value or reduce risk?

❌ Bad: "Upgrade libraries"
✅ Good: "Patch critical security vulnerability in dependency, no breaking changes"

Teams went from vague aspirations to clear, achievable outcomes. Sprint planning became 30 minutes instead of 2 hours of circular discussion.

3. Tracked Code Commit Cadence

This was the big one: steady code flow, not panic pushes.

We implemented daily commit tracking:

Metrics we tracked:
- Commits per day per team member (target: 1-2)
- Commits per day per team (target: 8-12 for a 4-5 person team)
- Days without commits (target: max 1 per week)
- Commit message quality (linked to story, clear description)
- Code review turnaround (target: <24 hours)

What changed immediately:

Predictability skyrocketed — We could see progress in real time
Work-in-progress bottlenecks disappeared — Commits flowing daily meant reviews weren't stacking up
Quality improved — Smaller commits are easier to review and less likely to introduce bugs
Developer confidence went up — They could see their work moving forward

The commit cadence became our heartbeat. Missing a day wasn't catastrophic, but a pattern of inactivity meant we had a blocker to resolve.

4. Set Transparent Expectations

Every team member got a simple document:

Performance Expectations for Engineering Teams

You are performing well if:

Your sprint goals are achieved 85%+ of the time

Your team ships consistently within estimated complexity

You contribute meaningful code commits 4-5 times per week

Your pull requests get reviewed within 24 hours

You're mentoring or being mentored on something challenging

We help if:

Sprint goals slip repeatedly (we remove blockers together)

Code reviews are stalling (we improve process)

You're stuck on a problem (pair programming, research time)

You feel overwhelmed (we rebalance work)

No surprises. No hidden criteria. No "performance evaluation" that comes out of nowhere in July.

The Results (In Numbers)

Before the frameworks:

Sprint goal attainment: ~60%
Code review turnaround: 2-3 days
Bug escape rate: 12% (bugs found in production)
Developer satisfaction: 6.2/10
Unplanned overtime: 15-20 hours/week (team-wide)

After implementing frameworks (3 months):

Sprint goal attainment: 88%
Code review turnaround: 12-18 hours
Bug escape rate: 3%
Developer satisfaction: 8.1/10
Unplanned overtime: 2-3 hours/week (team-wide)

The financial impact:

3 fewer critical incidents per quarter (no heroic firefighting = less context switching)
40% faster feature time-to-market (predictable velocity = better planning)
Zero unplanned quits (clarity and consistency matter)

Why This Works (The Psychology)

Humans thrive under clarity, consistency, and control.

Clarity — "I know what success looks like"
Consistency — "I know what to expect every day"
Control — "I have agency in reaching the goal"

Performance frameworks give all three.

When developers know:

✓ What done means
✓ What the sprint goal is
✓ How their work will be reviewed
✓ What performance looks like

They don't need heroics. They just need to show up and do the work.

The Mistake Most Teams Make

"We don't need frameworks — our team is smart and self-organizing."

I get it. Frameworks sound bureaucratic. But here's the truth:

Self-organization without frameworks is just chaos.

The best teams I've worked with had tight systems and clear guidelines, not loose collaboration and "vibes."

Think about sports:

❌ No playbook, just "go out there and play hard"
✅ Clear plays, positions, metrics, and objectives

Engineering is the same.

Implementation Checklist: Start This Week

Week 1: Definition of Done

[ ] Gather your team (1 hour)
[ ] Ask: "What does 'done' mean to us?"
[ ] Write it down (8-10 criteria)
[ ] Make it visible (Slack, Confluence, somewhere everyone sees it)

Week 2: Sprint Goal Criteria

[ ] Draft the "measurable, verifiable, valuable" template
[ ] Retrospective: Review last 3 sprint goals through this lens
[ ] Use it for next sprint planning

Week 3: Commit Tracking

[ ] Set up a simple dashboard (GitHub, GitLab, or manual tracking)
[ ] Track daily commits per person, per team
[ ] Report in standup (30 seconds)

Week 4: Transparent Expectations

[ ] Write a 1-page "Performance Expectations" doc
[ ] Share it with your team
[ ] Use it for 1:1s and feedback

Time investment: 4-6 hours upfront. Time savings: 10-15 hours per week in clarification, rework, and firefighting.

What Happens Next

Once you have frameworks:

Sprint planning becomes predictable — You're not starting from zero each sprint
Team confidence goes up — Everyone knows what success looks like
Code quality improves — Clear expectations drive consistent standards
Morale improves — No surprises, no "heroic all-nighters"
Turnover drops — Clarity and consistency reduce burnout
Leadership gets visibility — You can see progress in real time

The Real Secret

High-performing teams don't work harder. They work smarter.

And they work smarter because someone invested time in clarity.

Not complex frameworks. Not heavyweight processes.

Just:

One clear definition of done
Measurable sprint goals
Visible progress tracking
Transparent expectations

That's it.

The irony? The teams that implement these frameworks often look "boring" from the outside. No drama, no late-night commits, no "we shipped despite impossible odds" stories.

Just consistent delivery. Week after week.

And that's exactly the point.

What performance challenge is your team facing right now? Drop a comment — I'd love to share more specific tactics based on what you're working with.

Read more:

engineering #leadership #agile #devops #teammanagement #javadeveloper #softwarearchitecture

Metro Web Services: High-Performance SOAP (2026-08-25 18:44)

Said Olano — Tue, 25 Aug 2026 18:44:09 +0000

Metro Web Services: High-Performance SOAP

While REST dominates modern API design, SOAP remains firmly entrenched in enterprise systems—particularly in finance, healthcare, telecommunications, and government sectors where contract-first design, strong typing, and standardized security matter. When you need SOAP on the Java platform, Metro is one of the most capable and performant stacks available.

This post explores what Metro is, how to build high-performance SOAP services with it, and the tuning strategies that separate a sluggish endpoint from a production-grade one.

What Is Metro?

Metro is a comprehensive web services stack that combines two major components:

JAX-WS (Jakarta XML Web Services) — the reference implementation of the Java API for XML-based web services.
WSIT (Web Services Interoperability Technologies) — support for WS-* standards like WS-Security, WS-ReliableMessaging, WS-AtomicTransaction, and WS-Policy.

Together they provide a full-featured, standards-compliant SOAP platform that interoperates cleanly with .NET (WCF) and other WS-* implementations.

Setting Up a Basic Service

Metro embraces a contract-first or code-first approach. Here's a minimal code-first service endpoint:

import jakarta.jws.WebService;
import jakarta.jws.WebMethod;

@WebService(serviceName = "QuoteService")
public class QuoteService {

    @WebMethod
    public double getQuote(String symbol, int shares) {
        double pricePerShare = lookupPrice(symbol);
        return pricePerShare * shares;
    }

    private double lookupPrice(String symbol) {
        // lookup logic
        return 142.75;
    }
}

Publishing it for a quick test is trivial:

import jakarta.xml.ws.Endpoint;

public class Publisher {
    public static void main(String[] args) {
        Endpoint.publish(
            "http://localhost:8080/quotes",
            new QuoteService()
        );
    }
}

Metro auto-generates the WSDL, available at http://localhost:8080/quotes?wsdl.

The Performance Challenge

SOAP's reputation for being "slow" is largely a matter of configuration. The primary bottlenecks are:

XML parsing and serialization overhead
JAXB (un)marshalling of large object graphs
Verbose message payloads consuming bandwidth
Repeated schema validation
Security processing (signing, encryption)

Metro provides mechanisms to address each of these.

Optimization 1: Fast Infoset

The single biggest win for high-throughput scenarios is Fast Infoset (FI)—a binary encoding of XML that dramatically reduces message size and parse time. When both client and server support it, Metro negotiates FI automatically via content negotiation.

Enable it on the client via the FastInfosetFeature:

import com.sun.xml.ws.developer.FastInfosetFeature;

QuoteService port = service.getPort(
    QuoteService.class,
    new FastInfosetFeature()
);

Or through a system property for pessimistic negotiation:

System.setProperty(
    "com.sun.xml.ws.client.ContentNegotiation",
    "optimistic"
);

In benchmarks with document-heavy payloads, Fast Infoset commonly reduces payload size by 40–60% and parse time by a similar margin.

Optimization 2: MTOM for Binary Data

If your service transfers binary content (images, PDFs, documents), base64-encoding it inline bloats messages by ~33%. MTOM (Message Transmission Optimization Mechanism) streams binary attachments alongside the SOAP envelope instead.

import jakarta.xml.ws.soap.MTOM;

@MTOM(threshold = 1024)
@WebService(serviceName = "DocumentService")
public class DocumentService {

    @WebMethod
    public byte[] fetchDocument(String id) {
        return loadBytes(id);
    }
}

The threshold attribute means only payloads above 1 KB use MTOM optimization—small values stay inline to avoid attachment overhead.

Optimization 3: HTTP Persistent Connections and Streaming

Metro's stream-based architecture avoids buffering entire messages in memory where possible. On the client, reuse the Service and port instances—they're expensive to create but safe to reuse across threads when configured properly.

Enable HTTP connection pooling and set timeouts to prevent hung threads:

import jakarta.xml.ws.BindingProvider;
import java.util.Map;

Map<String, Object> ctx = ((BindingProvider) port).getRequestContext();
ctx.put("com.sun.xml.ws.connect.timeout", 5000);
ctx.put("com.sun.xml.ws.request.timeout", 10000);

Optimization 4: JAXB Tuning

JAXB marshalling can dominate CPU time for complex types. Key strategies:

Reuse JAXBContext — it's thread-safe and costly to build. Metro caches this internally, but custom marshalling code should too.
Avoid unnecessary schema validation in production; validate at the boundary during testing instead.
Prefer flat, well-designed schemas over deeply nested polymorphic hierarchies.

// Build once, reuse everywhere
private static final JAXBContext CONTEXT =
    JAXBContext.newInstance(Quote.class);

Optimization 5: Secure Without Sacrificing Speed

WS-Security is inherently

Enterprise JavaBeans (EJB): Still Relevant in 2024? (2026-08-25 14:42)

Said Olano — Tue, 25 Aug 2026 14:42:41 +0000

Enterprise JavaBeans (EJB): Still Relevant in 2024?

Enterprise JavaBeans (EJB) has been a cornerstone of enterprise Java development for over two decades. But with the rise of Spring Boot, microservices, and cloud-native architectures, many developers wonder: does EJB still have a place in the modern stack? Let's take an honest, technical look.

A Brief History

EJB debuted in 1998 as part of J2EE, promising a standardized component model for distributed, transactional, secure enterprise applications. Early versions (EJB 1.x and 2.x) were notoriously heavyweight, requiring verbose XML descriptors, home/remote interfaces, and cumbersome deployment.

The EJB 3.0 release (2006) was a turning point. It embraced annotations, convention over configuration, and dependency injection—dramatically reducing boilerplate. Today, EJB lives on within Jakarta EE (formerly Java EE), now stewarded by the Eclipse Foundation.

What EJB Still Does Well

Despite its reputation, EJB provides several genuinely valuable features out of the box.

1. Declarative Transaction Management

Container-managed transactions remain one of EJB's strongest selling points. You annotate a method and let the container handle transaction boundaries.

@Stateless
public class OrderService {

    @PersistenceContext
    private EntityManager em;

    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public void placeOrder(Order order) {
        em.persist(order);
        // If an exception is thrown, the container rolls back automatically
        updateInventory(order);
    }
}

2. Pooling and Concurrency

Stateless session beans are pooled and managed by the container, giving you thread-safe, scalable components without manual lifecycle handling.

3. Built-in Security and Asynchronous Processing

Role-based method security and asynchronous invocation are available with simple annotations.

@Stateless
public class ReportService {

    @RolesAllowed("MANAGER")
    @Asynchronous
    public Future<Report> generateReport(long id) {
        Report report = buildExpensiveReport(id);
        return new AsyncResult<>(report);
    }
}

The Case Against EJB

To be fair, the criticisms are real.

Ecosystem momentum: Spring dominates job postings, tutorials, and community support.
Heavyweight application servers: Traditional EJB deployment on servers like WildFly or WebLogic feels dated next to embedded runtimes.
Microservices mismatch: EJB's roots are in monolithic, server-centric deployments.
Cognitive overhead: Many developers simply never learned it, raising onboarding costs.

The Modern Comeback: Jakarta EE and MicroProfile

Here's where the story gets interesting. Jakarta EE and MicroProfile have reinvented enterprise Java for the cloud era. Lightweight runtimes such as Quarkus, Open Liberty, and Payara Micro offer fast startup and low memory footprints—directly addressing the "bloat" complaint.

CDI (Contexts and Dependency Injection) has also absorbed much of what EJB once uniquely offered. In many new projects, developers reach for CDI beans with @Transactional rather than full EJBs:

@ApplicationScoped
public class InvoiceService {

    @Inject
    private InvoiceRepository repository;

    @Transactional
    public void save(Invoice invoice) {
        repository.persist(invoice);
    }
}

This achieves EJB-like transactional behavior with a lighter, more flexible model.

So, Is EJB Still Relevant?

The honest answer is nuanced:

Scenario	Recommendation
Maintaining legacy Jakarta EE apps	Yes — EJB knowledge is essential
Greenfield microservices	Prefer CDI + MicroProfile or Spring Boot
Teams standardized on Jakarta EE servers	EJB remains a reasonable, supported choice
Cloud-native, container-first workloads	Lightweight alternatives usually win

Conclusion

EJB is not dead—but its role has shifted. As a distinct, must-use technology, it has been largely superseded by CDI and modern Jakarta EE features. However, the concepts EJB pioneered—declarative transactions, managed lifecycles, and container-provided cross-cutting concerns—are more relevant than ever, just delivered through leaner abstractions.

If you're maintaining enterprise Java systems, EJB literacy remains a valuable skill in 2024. If you're building something new, understand what EJB does, then choose the lightest tool that meets your needs. Relevance, it turns out, is less about the technology itself and more about the problem you're solving.

AI-Assisted Coding Tools: How to Boost Developer Productivity by 40% While Reducing Defects

Said Olano — Mon, 24 Aug 2026 22:20:18 +0000

Organizations are drowning in manual code reviews, repetitive testing, and time spent on defect triage. But what if your development pipeline could get smarter every day?

I just published a comprehensive guide on operationalizing AI-assisted coding tools and intelligent QA automation in your engineering workflow. This isn't theoretical—it's practical, battle-tested strategies for engineering leaders, CTOs, and DevOps teams.

Here's what's inside:

✅ Why AI coding assistants increase productivity by 40% (with real metrics)

Documented performance gains from real-world implementations
ROI calculations based on industry benchmarks
Cost-benefit analysis for your organization

✅ How to implement intelligent test automation without replacing human judgment

Best practices for AI-augmented QA processes
Maintaining code quality while reducing testing time
Balancing automation with manual testing expertise

✅ CI/CD pipeline optimization with AI quality gates

Intelligent pipeline gates that catch issues early
Automated code quality checks at each stage
Real-time feedback loops for developers

✅ Code review automation that actually catches bugs before production

AI-powered static analysis tools
Pattern recognition for common vulnerabilities
Integration with existing review workflows

✅ Defect prediction models that prevent issues before they start

Machine learning models for bug prediction
Proactive issue identification
Historical data analysis for pattern recognition

✅ Team adoption playbook: getting engineers excited (not scared) of AI tools

Change management strategies
Training programs for development teams
Overcoming resistance and building trust

✅ ROI calculation framework: proving the business case to your leadership

Metrics that matter to stakeholders
Cost tracking and savings calculation
Presentation templates for executives

Production-Ready Implementation

The guide includes production-ready Java examples featuring:

Spring Boot Integration: Complete examples showing how to integrate AI tools into your Spring Boot applications
Jenkins Pipeline Automation: CI/CD pipeline configurations with AI-powered gates
JUnit/TestNG with AI-powered test generation: Automated test creation and optimization
Complete metrics collection: Track and measure your productivity gains

// Example: AI-Assisted Test Generation with JUnit
@Testpublic void testAIAssistedCodeReview() {
    // AI automatically generates relevant test cases
    CodeAnalyzer analyzer = new AICodeAnalyzer();
    ReviewResult result = analyzer.analyzeCode(sourceCode);

    assertEquals(0, result.getCriticalIssues());
    assertTrue(result.getQualityScore() > 85);
}

Getting Started

Whether you're starting from scratch or already experimenting with AI tools, this guide provides the roadmap to unlock 40%+ productivity gains while reducing defects across your engineering organization:

Assess your current state - Evaluate existing development processes
Select appropriate tools - Choose AI solutions that fit your tech stack
Implement incrementally - Start with pilot projects before organization-wide rollout
Measure and optimize - Track metrics and continuously improve

Key Metrics to Track

Code review time reduction
Bug detection rate improvement
Test coverage increase
Developer productivity gains
Time to market acceleration
Quality improvements

Conclusion

Time to move beyond "pilot mode" and operationalize AI across your development stack. The tools exist, the ROI is proven, and your engineering teams are ready. Start today and transform how your organization builds software.

Have you implemented AI-assisted coding tools in your organization? Share your experiences and lessons learned in the comments below!

AWS CloudFront: Content Delivery Network Optimization (2026-08-24 22:14)

Said Olano — Mon, 24 Aug 2026 22:14:08 +0000

AWS CloudFront: Content Delivery Network Optimization

Amazon CloudFront is AWS's globally distributed content delivery network (CDN) that caches content at edge locations close to your users. While spinning up a basic distribution is straightforward, extracting maximum performance and cost efficiency requires deliberate optimization. This post covers practical techniques to get the most out of CloudFront.

Why CloudFront Optimization Matters

An unoptimized CDN can result in low cache hit ratios, high origin load, inflated data transfer costs, and slower response times for end users. The goal of optimization is simple: serve more requests from the edge, reduce origin round-trips, and control costs.

1. Maximize Your Cache Hit Ratio

The single most impactful metric is your cache hit ratio—the percentage of requests served from the edge instead of the origin.

Normalize Cache Keys

By default, every unique combination of query strings, headers, and cookies can create a separate cache entry. Fragmenting your cache reduces hit ratios. Use Cache Policies to include only the values that actually affect the response.

{
  "CachePolicyConfig": {
    "Name": "OptimizedPolicy",
    "DefaultTTL": 86400,
    "MaxTTL": 31536000,
    "MinTTL": 1,
    "ParametersInCacheKeyAndForwardedToOrigin": {
      "QueryStringsConfig": {
        "QueryStringBehavior": "whitelist",
        "QueryStrings": { "Items": ["version"], "Quantity": 1 }
      },
      "HeadersConfig": { "HeaderBehavior": "none" },
      "CookiesConfig": { "CookieBehavior": "none" }
    }
  }
}

Set Appropriate TTLs

Control caching duration through origin Cache-Control headers, or override them with CloudFront TTL settings:

Cache-Control: public, max-age=86400, s-maxage=604800

Use s-maxage to instruct CloudFront (a shared cache) to cache longer than browsers.

2. Enable Compression

CloudFront can automatically compress objects using Gzip and Brotli, dramatically reducing transfer size for text-based assets (HTML, CSS, JS, JSON).

Set Compress: true in your cache behavior.
Ensure the viewer sends Accept-Encoding: gzip, br.
Only objects between 1,000 and 10,000,000 bytes are compressed.

Brotli typically achieves 15–25% better compression than Gzip for text content.

3. Use Origin Shield

Origin Shield adds an additional caching layer between edge locations and your origin. All edge caches funnel misses through a single regional cache, which collapses duplicate requests and further protects your origin.

Enable it in the region closest to your origin:

Origin Shield Region: us-east-1

This is especially valuable for origins with limited capacity or high request volumes.

4. Optimize with Cache and Origin Request Policies

Separate what's used for the cache key from what's forwarded to the origin. You might not want to vary the cache by an Authorization header but still need to forward it to the origin. Use an Origin Request Policy for this.

aws cloudfront create-origin-request-policy \
  --origin-request-policy-config file://origin-request-policy.json

5. Leverage Edge Functions

Move logic to the edge to reduce origin load and latency:

Feature	Use Case	Runtime
CloudFront Functions	Header manipulation, redirects, URL rewrites	Lightweight JS (sub-ms)
Lambda@Edge	Complex logic, auth, origin selection	Node.js/Python

Example CloudFront Function to add security headers:

function handler(event) {
  var response = event.response;
  response.headers['strict-transport-security'] = {
    value: 'max-age=63072000; includeSubDomains; preload'
  };
  return response;
}

6. Control Costs

Choose the right price class. If your audience is regional, use PriceClass_100 (North America and Europe only) to avoid paying for expensive edge locations.
Monitor data transfer. Origin-to-edge transfer over CloudFront is often cheaper than direct S3 or EC2 egress.
Use Savings Bundles if you have predictable, high-volume traffic.

7. Monitor and Iterate

Enable real-time logs and CloudWatch metrics to track:

CacheHitRate — aim for 85%+ on static content
OriginLatency — spikes indicate origin bottlenecks
4xxErrorRate / 5xxErrorRate — configuration or origin issues

aws cloudwatch get-metric-statistics \
  --namespace AWS/CloudFront \
  --metric-name CacheHitRate \
  --dimensions Name=DistributionId,Value=EXXXXXX \
  --statistics Average --period 3600

Conclusion

CloudFront optimization is an iterative process. Start by normalizing cache keys and setting sensible TTLs to boost your hit ratio, enable compression and Origin Shield to reduce origin load, and push logic to the edge with functions. Continuously monitor your metrics and refine your policies. These changes compound into faster user experiences and meaningful cost savings.