I want to share, with honesty and transparency, my experiences, feelings, and challenges since the very beginning of my career as a Software Engineer.

Looking back, I have to admit something: when I started my career 17 years ago, I didn’t know I was neurodivergent.

Actually, I didn’t even know that word existed.

What I did know was that I had learned to adapt myself very well to different contexts and people. I used to mask a lot—sometimes consciously, but most of the time without realizing it. It was almost automatic.

I had this tendency to categorize people in my mind, to build a kind of profile for them. Then, without thinking too much about it, I would “put on” the mask that best fit that profile.

It sounds strange when I explain it like this, and honestly, back then I wasn’t even aware I was doing it.

The truth is that this strategy worked quite well for my career. It helped me adapt, grow, and eventually move into leadership roles. I achieved many things that I’m proud of.

Of course, this is just one neuroatypical trait among many others. Another one that has shaped my professional life is hyperfocus. When a topic truly interests me, I can dive deeply into it and understand it very quickly—sometimes in just days or even hours.

This can sound like a superpower, and in many ways, it is. But it also has a darker side. When motivation is missing, the opposite happens: a complete lack of interest. Learning or doing something that doesn’t resonate with me can become incredibly hard, even if it’s something I have to do.

The key to addressing this—and something I’m still working on today—is building the habit of doing things I don’t want to do.

Things that are uncomfortable by nature.

Simple examples: taking cold showers, meditating, exercising, or deliberately participating in social events.

Maybe the hardest challenge I’ve had to face was accepting that I think differently from neurotypical people. And, even more importantly, learning to consciously manage my masking—choosing when to apply it and when not to.

This is not easy at all. It’s a constant challenge.

But paradoxically, it’s also something I find deeply interesting. It genuinely fascinates me.

There’s another important thing I want to mention.

Looking back, I realize that this way of thinking has also pushed me to go after what I truly enjoy. Not because I had everything figured out, but because I felt it was the right direction for me.

I’ve always tried to take responsibility for my career. To make decisions consciously, even when they were uncomfortable. To stay honest with myself about what I want—and what I don’t.

That’s allowed me to work on things I actually like. And, trying to stay modest here, it has also helped me do my job well and sometimes even stand out.

One thing I’ve learned along the way is this: if you want to grow as a leader, you first have to lead your own life.
Not perfectly. Just consciously.

For me, that means not staying still out of fear. And when I do stop, making sure it’s a choice, not a reaction.

I’ve also had to learn to make space for emotions. Even the uncomfortable ones. Especially those. Instead of fighting them, I try to understand them and use them as signals to move forward.

And honestly, I’ve failed many times. But I keep trying. Because practice matters. And persistence matters even more.

Not long ago, I told a friend that I see myself as a dreamer. He paused for a second and then told me something that stuck with me: that’s a good thing.
He said it allows me to think big—and to build a life that’s aligned with who I am.

Okay, so when you’re starting out with big language models(LLM), you might think that if you write one really long and smart prompt, it will give you a perfect answer.

Sometimes it works, but often, it doesn’t.

When prompts get complicated, the results can be hit or miss, cost more, and be tough to control. The model can start missing the point, make things up, or blur the lines between what it should and shouldn’t be doing.

But here’s another way to think about it:

Instead of trying to make prompts super smart, just make them smaller and simpler.

This is where the Decomposed Prompt Pattern comes in. It’s like breaking down a big prompt into smaller chunks, where each chunk has its own job and doesn’t need a ton of background info.

Context

Today’s AI uses LLMs for a lot, like:

• Thinking through tricky problems

• Making good content

• Doing things step by step

• Teaming up with other tools

But, we also know some things about LLMs that aren’t so great:

• The longer a prompt, the more it costs.

• Big prompts can lead to the model making stuff up.

• If a prompt tries to do too much, it gets confused.

• Trying to do everything in one go usually doesn’t work out.

Think of it like this: If you ask one thing to do too much, it’s going to crack under the pressure.

Problem

A prompt often has to:

• Get what you’re asking.

• Figure out how to solve it.

• Write something.

• Check if it’s good.

• Fix any mess ups.

This can cause:

• Answers that aren’t consistent.

• Trouble figuring out what went wrong.

• It’s not clear where things failed.

• Prompts that are hard to change.

If something messes up, you won’t know what part caused the issue.

Forces

When you’re making complex things with LLMs, you’ll notice these things:

• A single prompt can be easy to break. The longer they are, the harder they are to manage and test.

• You need to check the quality more than once. Just checking the answer isn’t enough. It’s good to check the thinking process along the way.

• One ask from a user can mean a lot of different tasks. It might need planning, writing, checking, and using other tools. Trying to do it all at once in one prompt can be a headache.

• There’s only so much space in a prompt, and it costs money. Cramming everything in makes it expensive and can confuse the model. Smaller prompts tend to work better.

• You need steps that you can expect and test. Splitting things up lets you check each part, try again if one fails, and see where things went wrong.

All of this makes you want to move away from one huge prompt and toward a system where each part has one job and isn’t overwhelmed with context.

Solution — The Decomposed Prompt Pattern

The Decomposed Prompt Pattern is all about taking one big ask and splitting it into smaller or specialized prompts that each has its own thing to focus on.

Sometimes, this looks like a pipeline, but the point isn’t just to make a pipeline.

The real win is that you’re cutting down a complex prompt into smaller, more focused prompts, where each one has:

• A small goal

• Only needs a bit of context

• Knows what it’s putting in and getting out

How it’s put together (one after the other, at the same time, or a mix) doesn’t really matter.

You’re changing how it thinks, not always the words of the prompt itself.

Responsibility should be separated.

Dependent Prompts

When following prompts, each step uses what came before it.

This is helpful when:

• What comes later needs the thinking from what came earlier.

• Things get better each time around.

• You want to fine tune as you go.

Example

I’ve applied this pattern in a small experiment (available in my GitHub repo) where a service receives a prompt and processes it through three specialized components:

1. Planner: breaks the request into a sequence of steps.

2. Writer: Produces a first draft based on the plan.

3. Reviewer: Reviews the draft and improves clarity, structure, and quality.

Each prompt is simpler, and more focused than a single “mega-prompt”.

The result is not just better output —
it’s a system that is easier to reason about, debug, and evolve.

Independent Prompts

Sometimes, prompts don’t need to rely on each other.

Prompts that aren’t connected are good when:

• You want a few different points of view.

• You can compare the results.

• Steps can happen at the same time.

Examples:

• Making a few drafts

• Checking results against different things

• Running safety or quality checks

This means you can do things at the same time, get better speed, and try some parts again without having to start over.

Benefits

Using the Decomposed Prompt Pattern gives you:

• Outcomes you can expect

• Smaller prompts that cost less

• Less chance of the model making stuff up

• Responsibilities that are obvious

• Easier way to fix things

• Better success as the system grows

It also goes well with things like Guardrails and RAG.

Trade-offs

It’s not all easy.

You’ll have to deal with:

• More complicated steps

• More things to keep track of

• Figuring out how the prompts connect

• Deciding what should rely on what

But the alternative is a crazy big prompt that becomes a nightmare real quick.

From my experience, it’s a good deal to make once things get past the testing phase.

Closing Thoughts

Large prompts feel powerful — until they don’t.

Breaking a problem into smaller prompts may feel slower at first, but it gives you something far more valuable: control.

The Decomposed Prompt Pattern treats prompting as architecture.

And once you see prompts as components, everything starts to click.

If you’ve tried similar approaches — or struggled with overly complex prompts — I’d love to hear about it.

In demos, that could be funny. In production? It’s a risk technical, operational, and yes, even legal.

That’s why Guardrails should be treated as an architectural pattern. They deserve a seat next to the classic patterns we already know.

Context

Today’s AI systems mix:

• LLMs that “reason”

• RAG pipelines retrieving domain knowledge

• MCP tools for real actions

• Agents orchestrating multi-step workflows

And all of that sits in an environment where people expect:

• correctness

• consistency

• safety

• traceability

• reliability

The problem?
LLMs are probabilistic. Our systems are not.

Problem

The moment you plug an LLM into a real workflow, you inevitably face:

• unpredictable output

• fabricated details

• dangerous or unauthorized tool usage

• schema inconsistencies

• harmful or ambiguous user input

• non-deterministic behavior across model versions

These aren’t theoretical.
They break workflows. They cost money.
And sometimes, they spill into the real world.

A real case: Air Canada (2024)

In early 2024, Air Canada lost a legal dispute after its chatbot gave a grieving customer incorrect refund guidance.
The model confidently described a policy that didn’t exist.
The customer relied on it, spent real money, and later discovered that the “bereavement refund” the chatbot promised was fiction.

The Canadian tribunal was clear:
Air Canada was responsible for what its AI said, just as if it had published the statement on a static page.

Result: compensation, public scrutiny, and a clear message for the rest of us.

Without guardrails, generative AI isn’t just unreliable —
it’s a liability.

Forces

Building AI-enabled systems means navigating tensions between:

• LLM creativity vs safety

• flexibility vs compliance

• speed vs correctness

• user expectations vs model unpredictability

• cost vs latency (LLM calls aren’t cheap)

Guardrails exist to stabilize these forces.

Solution — The Guardrails Pattern

Guardrails aren’t a single technique.
Here I explain two kinds of strategies:

Input Guardrails (before the LLM)

From a security perspective, we need to be aware of, and handle, two types of input risks:

• private or sensitive information

• malicious or manipulative prompts that could compromise the LLMs or the system

The first case can be addressed by identifying and masking private or sensitive data before sending anything to the LLM, RAG or any other API.

Imagine an employee using an internal HR AI assistant and sending a request like:

“Write an email to John Poh congratulating him on his recent salary increase to 120,000.”

Before this prompt reaches the LLM, a guardrails layer should mask sensitive information — in this case:

• the employee’s name

• the specific salary amount

So the model actually receives something like:

“Write an email to <EMPLOYEE_NAME> congratulating him on his recent salary increase to <SALARY_AMOUNT>.”

After the LLM generates the email template, the system can safely unmask the values and reinsert the real data before sending the final output to the user.

This keeps the model from storing or training on sensitive data, reduces compliance risk, and ensures private information never leaves safe boundaries.

For the second case, we must actively defend against things like SQL injection, prompt-based attacks (“forget your policies…”, “ignore all previous instructions”), or attempts to push the LLM into tasks outside its scope or specialization.

Output Guardrails (after the LLM)

We find at least three types of output guardrails:

• unmasking private or personal information

• qualifying and filtering the response

• retrying or forwarding policies

As we’ve seen before, if our input guardrails mask the prompt, the response must be unmasked to stay consistent with the original user request.

Using the HR example:

The LLM receives:

“Write an email to <EMPLOYEE_NAME> congratulating him on his recent salary increase to <SALARY_AMOUNT>.”

It might answer with:

“Dear <EMPLOYEE_NAME>,
I wanted to personally congratulate you on your recent salary increase to <SALARY_AMOUNT>...”

An output guardrail will:

1. Unmask the placeholders:

   • <EMPLOYEE_NAME> → John Poh

   • <SALARY_AMOUNT> → 120,000

2. Qualify and filter the response (tone, policy alignment, no extra sensitive data).

3. Retry or forward to a human if something looks off (for example, if the model adds details it shouldn’t).

This way, the LLM never sees the raw sensitive data, but the final email that the user receives is still correct and personalized.

Guardrails Through Embeddings

Here’s where things get interesting.

Recently, I’ve been experimenting with a tool called Semantic Router, and it surprised me.

In complex architectures, especially those using multiple MCP tools, cost and latency grow quickly.
Why?
Because the LLM is deciding which tool to call.

Every decision implies a new LLM inference then slower, more expensive, more unpredictable.

Semantic Router flips that idea.

Instead of asking the LLM to choose a tool,
you represent each tool with embeddings
and route the request without calling the LLM at all.

The impact is huge:

• millisecond routing

• near-zero cost

• more deterministic decisions

• far safer tool selection

This has cut tool-selection cost in my experiments by 80–95%, depending on the workflow.

And yes: this fits inside the Guardrails Pattern.
Semantic routing becomes an input guardrail that prevents unsafe or expensive decisions before they ever reach the model.

Benefits

Some of the benefits of applying this patterns are:

• fewer hallucinations

• more predictable workflows

• safer tool invocation

• better user trust

• stable behavior across model updates

• easier auditing

• with embeddings, reduced cost

Trade-offs

Guardrails add:

• engineering effort

• some complexity

• validation overhead

• the risk of over-restricting creativity

• higher cost-to-serve

But the alternative, no guardrails, is how you end up in the news like Air Canada.

Closing Thoughts

We’ve passed the stage where generative AI is just a novelty.
It’s becoming part of the core architecture of our systems.

Guardrails aren’t about limiting the model.
They’re about protecting users, organizations, and the system itself.

Tools like Semantic Router make those guardrails not only safer,
but faster and cheaper to implement.

This is just the beginning.
In the next posts, I’ll dig into how guardrails interact with agents, RAG pipelines, and MCP tooling to build safer, scalable AI architectures.

If you’ve implemented guardrails, or struggled without them, I’d love to hear your experience.

Every few years, something arrives that forces us to rethink the way we design systems.

Microservices changed how we structure complexity.
Event-driven architecture changed how we communicate.
Cloud changed how we deliver and scale.

And now AI is disrupting—again—but with far more noise, confusion, and buzzwords than any shift we’ve seen before.

LLMs.
RAG.
Agents.
Guardrails.
MCP.
Vector DBs.
Tool-use.

Everyone talks about these things, but very few explain how they actually fit into a real software architecture—not a demo, not a toy notebook, but a true system with bounded contexts, SLAs, budgets, observability, failure modes, and users who will complain when something breaks at the worst possible time.

This post aims to do just that:
Give you a mental map of the AI layer from the perspective of a software architect.
No hype. No magic. No unicorn dust.

Just architecture.

Let’s dive in.

LLMs: A New Probabilistic Component in Our Architecture

A Large Language Model isn’t magic.
From an architectural perspective:

An LLM is a probabilistic function with expensive inference and unpredictable output.

It does reasoning.
But not like a rules engine.
Not like code.
And definitely not like a deterministic microservice.

This is why you don’t put an LLM inside your core workflows.
Instead, you isolate it behind:

• an LLM Gateway (OpenAI, Bedrock, Vertex AI, etc.)

• a Prompt Library

• safety filters

• rate limits

• logging/observability

The LLM layer becomes a boundary, not a dependency.

RAG: The Pattern That Gives LLMs Real Knowledge

LLMs know a lot… about the public internet.
But they don’t know your domain:

• your internal APIs

• your codebase

• your architecture

• your business rules

• your documentation

• your support tickets

• your catalog

• your incidents

That’s where Retrieval-Augmented Generation (RAG) comes in.

RAG enriches the model with context retrieved from your knowledge sources.

The architecture consists of:

1. Embedder — converts text into vectors

2. Vector Database — stores embeddings (Pinecone, Weaviate, Qdrant)

3. Retriever — finds the most relevant pieces at runtime

4. LLM — uses retrieved knowledge to generate grounded answers

RAG is not “just” a technique—it’s a full architectural pattern of knowledge retrieval.

Agentic Patterns: When the LLM Doesn’t Just Answer… It Acts

RAG gives an LLM memory.
Agents give an LLM capabilities.

An agent is:

An LLM that can choose tools and perform actions autonomously within defined boundaries.

Tools can be:

• APIs

• functions

• calculations

• database queries

• workflow steps

• MCP tools

Agents can:

• take multiple steps

• plan

• decide

• execute tasks

• correct themselves

This is powerful—and dangerous—if not constrained.

Good agents behave like smart assistants.
Bad agents behave like unsupervised interns with admin privileges.

Agents are a full architectural pattern: autonomous reasoning with tool execution.

MCP: The Enabler That Makes Tool-Use and Agentic Workflows Actually Scalable

There’s a piece of this whole story that isn’t an architectural pattern by itself, but has quickly become one of the most important enablers in modern AI systems:

MCP — Model Context Protocol.

If LLMs are the reasoning layer,
and RAG is the memory layer,
and agents are the autonomy layer,

MCP is the interface layer — the part that allows models and agents to interact with real systems in a standardized, safe and introspectable way.

Before MCP, integrating tools into an LLM or an agent was fragile and inconsistent:

• Each provider (OpenAI, Anthropic, local models) had its own API format.

• Tool definitions lived inside prompts (yes, really).

• Schema mismatches caused silent failures.

• There was no discovery mechanism: you had to “tell” the model what it could do.

• Tool-use was tightly coupled to specific model vendors.

• Security controls were improvised and scattered.

MCP changes this dynamic completely.

It introduces a unified contract describing:

• what tools exist

• what actions they expose

• what parameters they require

• what schemas they follow

• what capabilities are allowed

With this, an LLM or an agent can discover tools, understand their structure, and use them safely — without relying on brittle prompt instructions.

In other words:

MCP is not an architecture pattern — it’s the enabler that makes agentic systems, tool-use, automation and safe AI orchestration actually viable.

It becomes a clean, vendor-independent bridge between:

• your microservices

• your automations

• your data sources

• your business actions

• and the AI layer

A Real Use Case Where I Applied MCP (High-Level View)

To make this more tangible, here’s a simplified real scenario I implemented.

Imagine a user asks the system:

“Send the list of payments due today to Charles Sant.”

An LLM alone cannot perform this task — it needs real system capabilities.

Through MCP, the LLM can:

1. discover which tools exist

2. inspect their schemas

3. call the right tool with structured data

4. use the result to perform a follow-up action

The diagram below shows a high-level view of how this actually works end-to-end:

This flow represents how an LLM, an MCP Client, and multiple MCP Tool Servers coordinate to fulfill a real user request:

1. The LLM discovers available tools

It doesn’t “guess” or rely on a prompt description.
It asks the MCP Client:

• “What tools do I have?”
  The MCP Client replies:

• payments-query

• people-notifier

These tools are introspectable because MCP provides structured schemas.

2. The LLM chooses the right tool based on schema

It selects payments-query first, sending structured data (JSON compliant with the tool’s schema).

The MCP Client calls the appropriate MCP Tool Server, which returns the required payments.

3. The LLM composes a second action

Now that it has the list of payments, it prepares a second structured request:

• a call to people-notifier

Again, the MCP Client relays the request, and the MCP Tool Server returns the execution status.

4. The LLM returns the final result to the user

All tool interactions are chained through the MCP Client, keeping:

• your microservices safe

• your API surface clean

• your tool definitions standardized

• your agentic workflow predictable

Additional Tips for Real-World AI Architecture

Before closing, here are a few high-impact recommendations that can help you design AI-enabled systems that remain safe, predictable and maintainable as they grow:

1. Always validate input and output

LLMs produce probabilistic output, not guaranteed structure.
Add lightweight validation to avoid malformed requests reaching your internal systems.

2. Version everything

Prompts, embeddings, RAG pipelines, tool schemas, agent behaviors.
Treat these assets like code — because they are.

3. Keep agents narrow and supervised

A “general-purpose agent” is a nice idea, but in practice, small task-specific agents with well-defined tools behave far better.

4. Apply caching everywhere

Embedding cache, retrieval cache, and generation cache reduce latency and cost dramatically.

5. Don’t forget security

AI introduces new attack surfaces.
Instead of going deep here, I’ll simply recommend this:
study the OWASP Top 10 for LLM Applications when designing any generative AI feature.
It provides practical guidance for avoiding prompt injection, unsafe tool execution, and other real-world risks.

(You don’t need to memorize every item—but awareness goes a long way.)

6. Separate deterministic logic from AI logic

Critical flows should not depend entirely on an LLM.
Build fallbacks, guardrails, and human-in-the-loop paths for sensitive operations.

7. Measure what your AI layer is actually doing

Logging tool calls, recording decisions, tracking latency and cost — this turns the AI layer from a “black box” into something observable.

These small practices compound over time and make a massive difference in production.

Conclusion

This was a high-level introduction to how LLMs, RAG, agents, and MCP fit together into a modern software architecture.
My goal wasn’t to go deep on every topic, but to give you a mental map that helps you reason about the AI layer with clarity — without hype, magic, or hand-waving.

If this topic interests you, stay tuned.
The next posts in this series will go deeper into individual patterns, starting with Guardrails, and I’d love for you to join the discussion, share your experiences, and challenge the ideas here.

Thanks for reading — and let’s keep building better systems together.

The “right” advice depends on who you are… and where you are.

We love books.
We love patterns, best practices, principles, and models.
They make us better.

But every book was written from a specific place:
a certain team, a certain culture, a certain moment in time.

And that place is not yours.

That’s why two people—or two companies—can read the same chapter and walk away with completely different needs.

When mentoring, I’ve learned that people don’t need the same advice

I’ve mentored engineers who seem to face the same situation but need totally different guidance.

For example:

• One engineer over-engineers because they’re afraid of making mistakes.

• Another cuts corners because they’re overwhelmed.

• One applies best practices like if they were laws.

• Another avoids patterns because they were burned before.

• Some need more structure.

• Others need more freedom.

Same challenge on paper.
Different human on the other side.

So the advice changes.

And that’s normal.
That’s good.
That’s mentorship.

Books explain concepts.
Mentors understand people.

The same thing happens when advising companies

As architects, companies expect us to give them “the best solution.”

But the best solution is always contextual:

• team skills

• deadlines

• pressure

• risks

• legacy systems

• culture

• business priorities

You can design the most elegant architecture…
but if the company can’t maintain it, it’s not a good architecture.

Sometimes the “ideal” design creates more pain than value.

So what do we do?

• We simplify when teams are stressed.

• We make things more opinionated when alignment is weak.

• We prefer incremental changes when risk is high.

• And sometimes, we break the rules—on purpose—because the real world demands it.

Books describe perfect worlds.
Architects work in real ones.

The common thread: context changes everything

Whether advising a junior developer or helping a business decide its next architecture step, the pattern is the same:

Good decisions come from understanding context, not from memorizing best practices.

Patterns are tools.
Principles are guides.
Books give us a starting point.

But judgment…
that’s where the real craft is.

Because the perfectionist may need to relax.
And the rushed team may need to slow down.
And the company obsessed with speed may need a more solid foundation.
And the company stuck in analysis may need to ship something now.

Same problem.
Different system.
Different answer.

The human side of technical leadership

At the end of the day:

Books teach us what can work.
Architects and mentors help people find what will work for them.

That’s why context matters.
And that’s why our role exists.

Because technology moves fast, but humans and companies grow through understanding.

That’s what inspired me to create the CLEAR Architecture framework. It’s not a rigid process or a silver bullet. It’s a simple mental model that helps me—and my team—stay grounded, collaborate better, and focus on what really matters.

C – Context: Understand the real problem

So many of my early mistakes as an architect had nothing to do with tech—and everything to do with assumptions. I once led a system redesign for a logistics flow… only to realize weeks later that we’d misunderstood the real bottleneck. No amount of clean code or fancy layers could fix that.

Albert Einstein captured it perfectly:

“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”

These days, I slow down. I ask more questions. I dig into the context before writing a single line of code. It makes all the difference.

L – Layout: Draw a simple, big‑picture vision

Before diving into patterns, stacks, or services, I sketch. Literally—on a whiteboard, notebook, or digital board. I draw boxes and arrows, map flows, ask for feedback. It’s not meant to impress—it's meant to align.

Simon Sinek reminds us:

“Those who are able to inspire give people a sense of purpose or belonging that has little to do with any external incentive or benefit to be gained. Those who truly lead are able to create a following of people who act not because they were swayed, but because they were inspired.”

A clear, shared layout helps your team understand where things are going—and why. It turns confusion into direction.

E – Execute: Pick a good-enough path and go

I used to overthink everything. “What if we need to scale later?” “What if this isn’t future-proof?” Guess what? Most of those fears never happened—and the delay cost us more than any wrong choice.

Now I ask: Is this approach viable? Can we deliver something useful soon? If the answer is yes, we go.

As General Patton said:

“A good plan, violently executed now, is better than a perfect plan next week.”

Software is built through action—not endless planning.

A – Adapt: Change early, change often

Sometimes the thing you thought would scale… doesn’t. Or the way services interact becomes a mess. That’s okay. What matters is noticing it early—and being willing to change course.

In my experience, it’s often my teammates who help me see what I’ve missed. A backend dev notices a bottleneck. A product owner challenges a core assumption. Architecture improves when everyone feels safe to speak up—and I try to actively invite that input.

One of my favorite quotes from Kent Beck is:

“Optimism is an occupational hazard of programming. Feedback is the treatment.”

CLEAR isn’t about sticking to the initial plan. It’s about noticing what’s working—and what’s not—and adapting before the cost of change explodes.

R – Reflect: Learn from every experience

We all make calls that don’t go as expected. That doesn’t make us bad architects—it makes us human. What matters is pausing to ask: What did I learn? How can I do better next time?

John Dewey once said:

“We do not learn from experience… we learn from reflecting on experience.”

I try to write down my lessons—but I don’t do it alone. I actively ask my team: What would you have done differently? What looked weird to you?

Often, the most valuable architectural feedback comes from someone who wasn’t even “in the room” when the decision was made. That’s why I believe reflection is a team sport.

Conclusion, be CLEAR, not Clever

There’s no perfect architecture. No universal answer. But there is clarity. And when you build it together—with your team, not just for them—things tend to fall into place.

So next time you're facing a complex decision, try keeping it CLEAR:

Context — Understand the real problem

Layout — Share a simple, high-level vision

Execute — Choose a path and move

Adapt — Change fast when it makes sense

Reflect — Learn and grow from each decision

What helps you bring clarity to your work as an architect?

Being totally honest, even though I've held leadership roles for the past 10 years, I still sometimes feel a bit like an impostor. It's surprising—and even a little funny—to look back at how I've handled certain situations in the past.

Right now, for example, I'm remembering an incident from about a year ago when I totally failed at preventing my boss from seeing me as a threat or potential replacement. That sparked envy and insecurity from his side, pushing him to make my job way harder than necessary. Today, I'm sure that if I'd approached him in a humbler, less stubborn way, I would have achieved a much better outcome. But you know what? That experience taught me something valuable—as every situation always does.

Why Does Continuous Learning Matter?

Here's the bottom line: if you genuinely feel every decision you've ever made was perfect, you're probably doing something wrong. Think about it this way: if you're truly growing, your current knowledge and skills should be miles ahead of your past self. Every experience—whether it feels like success or failure—shapes you. As long as you're learning from each situation, you're winning.

One of the most important lessons I learned about 7 years ago was changing my mindset from an Individual Contributor to a Leader. This shift was essential for feeling true progress in my career. Even now, I still have so much to learn about this paradigm, and honestly, that's fantastic—I love that hunger for growth.

If you’re a Senior Software Engineer looking to advance your career, improving your leadership skills is crucial. So, let me share three fundamental aspects that can help you do exactly that:

Your New Goal: Aligning Goals

I used to be a highly competitive professional focused on delivering maximum value by shipping features—always pushing myself to be the absolute best. However, I’ve learned something important: becoming a true leader involves shifting your goal from personal performance towards aligning your team members' goals with the team's goals.

What exactly does this mean? It means deeply understanding each of your teammates' individual goals, motivations, and expectations, and then finding ways to align these personal ambitions with your team’s overall objectives.

Here’s a quick example of what I mean: A team member once expressed frustration about always working with legacy banking systems rather than exploring new technologies. Recognizing his frustration, I proposed an idea to leverage our team's downtime (when blocked or workloads were lighter) into something valuable—I called it "InnoLab" (Innovation Laboratory). Each team would propose innovative ideas and test them as proof-of-concepts, validating real value for our business and customers. Fortunately, most leaders embraced the concept, creating opportunities for innovation and personal growth.

Make Yourself “Dispensable”

Learning this lesson was pretty tough for me. To really succeed as a leader, you need to trust your team. You have to empower each member so they can handle tasks—even when you're not around.

But how? Push your team members to take responsibility and let them shine. Treat people as superheroes, and that's exactly how they'll start to act.

It’s common knowledge among colleagues who've worked with me that I often encourage my team members to present our results directly to leaders or customers. Why? Because it empowers them, makes their efforts visible across the company, and provides valuable experience handling pressure—all of which helps them grow.

Another effective way is to let your team propose their own ideas and guide conversations towards solutions. Depending on the situation, I usually allow my team to express their perspectives and lead discussions. Only if I notice they need a bit of guidance to stay on track or get unstuck, I step in to gently steer the conversation.

Train Your Influence Skill

A lot of books, blogs, and videos talk about influencing people. I'd like to share two of my all-time favorite books on leadership and influence: How To Win Friends And Influence People and The Art Of War. I've learned—and honestly, I’m still learning—a lot from these classics.

Let me start by saying that I'm naturally altruistic and idealistic. By default, this shapes me into a helpful leader. I usually trust that people mean well and have good intentions, so I focus on supporting their personal goals while aligning them with the team's objectives.

However, sometimes decisions aren't optimal or context-appropriate, and you'll need to influence the outcome. The tricky part? Everyone usually believes they're right. Becoming influential combines several skills that reinforce one another: you listen to understand, identify motivations, map personalities, adapt your leadership style, and constantly practice.

• Listen first. Truly listen and understand before responding. You might discover valuable insights and show your teammates their perspectives genuinely matter.

• Identify motivations. Understanding what motivates your team lets you align your proposals with their priorities, increasing acceptance.

• Understand personalities. Different personalities respond better to different communication styles. I recommend reading Surrounded By Idiots to adapt effectively.

• Be a "chameleon". Sometimes leadership requires flexibility, even strategic toughness, to align goals and achieve objectives. As we say in Spanish: "Al son que me toquen bailo."

• Practice. You’ll inevitably fail sometimes, but each failure is a lesson. Keep practicing your influence skills; mastery comes with experience.

Remember, leadership isn't about having all the answers; it's about guiding your team toward finding the best solutions together. Keep practicing, stay humble, and never stop learning. You've got this!

I have been working as a software engineer for the past 15 years. Like many, I began my journey as a Practitioner Software Engineer (a level just below junior) and have spent the last 10 years working as a Software Architect. Before diving into my key lessons, I highly recommend reading "The Art of War," as its principles frequently appear throughout this post.

First Lesson: The squeaky wheel gets the grease

The first lesson I learned can be summarized by the Spanish saying: "El que no llora no mama." In other words, if you want something to happen, you have to actively pursue it and explicitly request it.

For instance, if you're interested in advancing your role—such as obtaining a promotion or receiving better compensation—you must clearly communicate this desire to your manager. Expressing your goals explicitly ensures that your efforts align with your aspirations, giving you greater control over your professional life.

The first time I asked for a promotion, I was very nervous—and honestly, I still get nervous today. Initially, my request came purely from a position of need. When I asked for a salary increase, my manager surprised me by immediately asking for justification. I was unprepared for that question and ended up honestly saying I needed it to improve my quality of life. It may sound simplistic or even naïve, but that was my reality at that moment. Although my justification wasn't very strong professionally, my honesty created a genuine connection, and I learned the importance of clearly articulating my value.

Second Lesson: Prepare the Field for Negotiations

When you request a salary increase or a promotion, your manager needs to justify their decision—either to approve or deny your request. Essentially, they must assess whether your work provides sufficient value to justify your request.

Given this reality, it’s crucial to prepare the ground for negotiations. How can you do this effectively? By consistently demonstrating your achievements and showcasing the tangible value you deliver to the company. This can be done in several ways, including:

• Successfully completing important tasks and projects.

• Positioning yourself as a trusted reference within your team.

• Actively building trust with your colleagues and supervisors.

By proactively demonstrating your worth, you make it easier for your manager to justify your requests, significantly improving your chances of success.

It's important to understand that the ways you demonstrate your value and career progress depend greatly on your circumstances, particularly your seniority level. The expectations for a Junior developer differ significantly from those of a Senior developer. For instance, I expect Seniors on my team to mentor Juniors, serve as technical references, and lead by example. Conversely, Juniors should focus on completing smaller tasks effectively, displaying eagerness to learn, and consistently seeking opportunities to enhance their skills.

Third Lesson: Know Yourself and Have a Life Plan

I know this may sound cliché, but it's genuinely impactful—so powerful, in fact, that it requires careful thought. Having at least a basic idea of your life plan gives you a compass to guide professional decisions effectively.

I began my journey in software engineering at the age of 16. Back then, I wanted to be either a scientist or a math teacher. However, due to my circumstances at the time, that wasn't immediately feasible. Instead, I had the chance to study as a Systems Technician—a qualification considered slightly below an engineer—and I embraced the opportunity I had available.

By age 20, I was working as a Web Administrator and Cybersecurity Practitioner. After two years in this role, I paused to reflect on what I truly wanted to do. I realized I enjoyed networking and security, but my true passion was in creating and coding solutions. Recognizing this, I actively sought opportunities within the same company to transition into software development. After being evaluated as a Practitioner Software Engineer, I discovered not only that I was good at coding—I was great at it, something that remains true even today!

This experience taught me the value of periodically reflecting on who I am, what excites me, and where I want to go next. Doing this helped me identify the roles aligned with my passions and skills, enabling me to actively shape my career rather than merely following wherever the circumstances took me.

Fourth Lesson: Win before negotiating

This advice might seem controversial or even taboo to some people, but I genuinely believe it’s crucial if you want to achieve your professional goals.

When someone asks me for advice on what to do when their salary or working conditions don't align with their expectations, my recommendation is straightforward: first, communicate your desires openly and directly with your manager.

However, it's also wise to have a backup plan—explore alternative opportunities or job offers. This doesn't mean you're determined to leave immediately, but securing other options can give you stronger leverage and confidence when negotiating.

Importantly, being ambitious is not negative; in fact, ambition is highly beneficial and can significantly enhance your life and career, provided your ambitions align with your values and life goals. Clearly expressing your professional aspirations helps your manager understand your motivations. Always request conditions that genuinely fulfill your needs and values, ensuring alignment between your ambition and personal well-being. This alignment helps avoid negative feelings and supports your long-term satisfaction and growth.

Fifth Lesson: Don’t let a position defines you

Finally, and equally as important as the previous four lessons, don’t let your job title define or limit you.

Remember, your position or title does set expectations, but it shouldn't restrict your growth or identity. You don’t become valuable or skilled because of your job title—you bring value through who you are, what you do, and how you contribute. Your worth is determined by your capabilities, your attitude, your leadership, and the quality of your relationships with teammates—not by your official position alone.

I understand this might sound idealistic or even altruistic. However, adopting this mindset has allowed me to grow tremendously, both professionally and personally. Today, I'm genuinely happy with my progress and believe strongly that not allowing myself to be limited by titles was essential in achieving that satisfaction.

Remember, when you refuse to be defined solely by your position, you open yourself to greater opportunities, flexibility, and growth. Ambition aligned with your values and authenticity creates a path to recognition beyond titles and traditional boundaries.

But there’s one critical issue: no one checked if the bridge was actually needed. There's no traffic, no demand, and no real purpose. Despite the team’s incredible technical work, the project fails to deliver any value. The client regrets the investment, and the team feels frustrated, wondering, "Why did we even build this?"

The same thing happens in software engineering when we make architectural decisions without considering Business Value. We get caught up in buzzwords like microservices, complex patterns, or the latest tech trends, forgetting to ask the essential question: "Does this actually solve a business problem?"

What is Business Value?

In simple terms, business value is anything that brings measurable benefit to our stakeholders. It's not always about delivering a new feature or deploying a completed product. Sometimes, it’s about gathering insights or validating a hypothesis that enables the business to make informed, data-driven decisions. This, too, is business value.

According to scrum.org, there are five types of value: commercial value, efficiency value, market value, customer value and future value. Each of these focuses on a different area that almost every business prioritizes.

For instance, optimizing a microservice to use fewer resources could reduce costs to serve customers without impacting their experience. This is an example of efficiency value.

Why is Business Value important?

You might be asking yourself, “Is Business Value important for a Software Architect?” The answer is simple: absolutely. As a Software Architect, the decisions you make should always be justified by the business value they bring.

For example, if you choose a microservices architecture for your system, it’s likely because you’re aiming to provide extensibility. This enables your team—and ultimately the business—to grow its capabilities over time, supported by the modularity and scalability of microservices. In this case, your decision is driven by future value, as it considers the long-term growth of both the system and the business.

Here’s my personal tip: as a Software Architect, especially in an agile environment, make business value an architectural driver. Let it guide and motivate every—or at least almost every—decision you make. This approach keeps your work aligned with what truly matters to the business.

How can I address this driver?

Great question! One of my go-to tools is Value Stream Mapping (VSM). Traditionally, VSM is used to analyze and optimize the flow of value in a process. In this case, I use it to trace the flow of value through software systems and their components, connecting actors, business capabilities, and technical systems. Here’s how you can create one, in summary:

1. Identify the actors or users of your system.

2. Select the processes or business capabilities your system supports.

3. Map the actors to the business capabilities they interact with.

4. Trace the business capabilities to the systems that support them.

5. Decompose your system into software components—for example, microservices or serverless cloud functions like AWS Lambdas.

6. (Optional) Map to the object or data model.

7. (Optional) Map to the infrastructure.

This layered diagram makes it easy to identify the impact and value of modifying a specific software component. You’ll clearly see what business capabilities and users will be affected, allowing you to make informed, value-driven decisions.

Balancing Cost and Value

Another key approach that complements VSM is Cost-Driven Architecture. This method emphasizes balancing the cost of a decision with the value it delivers. For example:

Using a built-in cloud service might seem more expensive than developing your own solution. However, building custom code also brings hidden costs, such as ongoing maintenance, technical debt, and operational risks. Delegating these responsibilities to third-party services could align better with business goals in the long term.

As Software Architects, it’s our responsibility to identify these trade-offs and present them to the business. We must balance technical efficiency with strategic value, ensuring every decision aligns with the overarching objectives.

Getting hidden requirements from the business

I firmly believe that a Software Architect is not the smartest person in the room or team. Instead, we are the ones who empower others to shine by guiding the team toward the best decisions. Our primary role is to ask the right questions—questions that steer meetings and decisions in the right direction.

The people who hold the key to making decisions based on Business Value are usually on the business side. When I listen to my team asking questions to the Product Owner, I pay attention to what might be missing. If I notice important questions left unasked, I step in to ensure we gather all the necessary information to make well-informed decisions.

Tools for Extracting Requirements

Even tasks like resolving technical debt or deploying a new feature come with risks in production environments. These risks demand that our systems be resilient enough to meet business expectations. For example, understanding how resilient or fault-tolerant a system needs to be can be guided by defining two key metrics:

• Recovery Time Objective (RTO): How quickly the system should recover from a failure.

• Recovery Point Objective (RPO): How much data loss is acceptable in the event of an outage.

Both RTO and RPO are directly tied to the business’s non-functional requirements, which makes uncovering these requirements crucial.

Another tool I use to extract hidden requirements is the Quality Attribute Workshop. This workshop helps teams explore hypothetical scenarios, often edge cases, to uncover the information needed from the business. For example: Imagine you’re tasked with designing a URL shortening service. During the workshop, you could ask:
"If there’s a performance issue, is it equally critical to ensure the capability of registering a new URL as it is to forward requests using short URLs?"

The business’s answer to this question might lead you to implement a CQRS pattern or another architectural strategy. By using tools like this, we can ensure our technical decisions align with business priorities and deliver real value.

Business Value Changes as Requirements Evolve

In the first post of this series of Agile Software Architect, I mentioned the importance of being open to change—and this applies equally to Business Value, which evolves over time.

For example, I recently encountered a situation where the business decided to pause all production deployments for a specific period due to a critical and high-profile event. Their risk appetite was practically zero during that time. From IT, we had already developed a small change that could reduce resource costs, but deploying it carried risks that the business was unwilling to accept. In that moment, their non-functional requirements shifted to:
"We need system stability above all else; any improvements can wait."

After the event passed, their requirements shifted again, and we resumed delivering improvements. This experience reinforced a key lesson: Business Value is not static. It changes as priorities and circumstances evolve.

As architects, we must understand that requirements will always change. To maximize value and meet expectations, we need to actively listen to the business and ensure we remain aligned with their needs. Strong communication and collaboration between IT and business are essential to achieving this alignment and ensuring success.

Final Thoughts

As Software Architects, our primary responsibility is to align technical decisions with the evolving needs of the business. This means being adaptable, asking the right questions, and ensuring that every decision we make delivers the maximum possible value. Whether it’s uncovering hidden requirements, balancing trade-offs, or responding to changing priorities, our role is to bridge the gap between IT and business, fostering collaboration and trust.

Business Value is not static—it’s a moving target influenced by circumstances, priorities, and risks. By maintaining open communication, leveraging tools like Value Stream Mapping and Quality Attribute Workshops, and understanding non-functional requirements, we can ensure that our architecture decisions are always grounded in what truly matters: delivering value to stakeholders.

Ultimately, being an Agile Software Architect isn’t about following a rigid blueprint—it’s about staying aligned with the business, embracing change, and helping the entire team succeed. Remember: the best architectures are not just technically sound—they’re designed to support and adapt to the ever-changing goals of the business.

What Is This Trap?

Choosing the wrong workplace isn’t just about ending up in a job with poor management or culture. The real trap lies in overlooking the deeper drivers of long-term satisfaction and success: the company’s culture, strategy, and the problems they are tackling. While factors like salary and technology stack are important, they shouldn’t overshadow these foundational elements.

In one of my early roles, I worked on a challenging project with another junior engineer. Together, we overhauled a system, tackling both functional and non-functional issues. While this was a tremendous learning experience, the lack of mentorship made our growth slow and challenging. Later, I worked under a senior engineer who provided mentorship and explained the rationale behind decisions. This taught me how much a workplace’s culture of learning and collaboration impacts your development.

Why It’s a Common Mistake?

This trap is particularly common in software engineering for several reasons:

1. Emphasis on Immediate Rewards

Early-career engineers often prioritize salary or perks without considering the long-term impact on their skills and career trajectory.

2. Misjudging Culture

During interviews, it’s easy to miss potential red flags about team dynamics and leadership. However, asking pointed questions can reveal much about a company’s culture. For example:

• How does the company handle disagreements between team members and leadership?

• What steps are taken to balance business pressures with maintaining quality in deliverables?

These responses can help identify whether the organization supports collaboration, respects differing viewpoints, and fosters a healthy working environment.

3. Ignoring Problem Space and Strategy

Joining a company whose mission and challenges don’t resonate with you can lead to disengagement, even if other factors like pay seem attractive.

4. Absence of Mentorship

Lack of senior engineers who can guide your growth deprives you of essential opportunities to learn and improve.

For example, I once observed a small company hire an external lead for an agile transformation despite having senior engineers with over a decade of experience. The management didn’t trust them to lead due to their lack of exposure to modern practices, stemming from a stagnant culture that resisted change. For years, the company had operated with processes that seemed sufficient, but several engineers suggested modernizing through agile practices, automation, and updated technology stacks. Unfortunately, the leadership ignored these suggestions, and the engineers themselves didn’t take the initiative to learn or upskill independently. They justified this by saying the company should provide training, but when the need for modernization became urgent, the leadership decided to bring in external leaders instead of investing in their internal staff. This resulted in the internal engineers feeling overlooked and stuck in their careers.

This scenario underscores a critical lesson: if you, as a software engineer, don’t prioritize your own growth, neither the company nor the market will. Continuous self-investment is essential for staying relevant and ready for opportunities.

Spotting the Signs

How do you know if you’re in the wrong workplace? Pay attention to these warning signs:

• Lack of Growth Opportunities: The company doesn’t offer clear paths for learning, mentorship, or development.

• Misaligned Work: Your tasks feel disconnected from your interests or fail to challenge you.

• Unclear Strategic Vision: The organization struggles with direction, hindering innovation and alignment.

• Toxic Culture: Micromanagement or a lack of trust makes collaboration frustrating and stifling.

• Outdated Tools or Practices: The company is resistant to adopting modern tools or methodologies, limiting your growth.

• Lack of Recognition: Your contributions and professional growth aren’t acknowledged through feedback or compensation.

How to Choose the Right Workplace

1. Clarify Your Objectives

Define your professional goals clearly by evaluating at least three key aspects:

• Salary: Determine the level of compensation you need to feel financially secure and motivated, keeping in mind your desired lifestyle and future savings goals.

• Culture: Reflect on the type of work environment you thrive in. Do you value collaboration, innovation, or a specific leadership style?

• Clear Path Progression: Assess whether the company offers structured opportunities for career advancement and skills development.

By focusing on these elements, you can ensure your objectives align with a workplace that supports your growth and aspirations.

2. Consider Adapting Your Role

Changing companies isn’t always the only answer. Sometimes, the key is identifying what aspects of your current position need to change to align with your goals. Speak up and make suggestions for adjustments that could make your role more fulfilling. For instance:

• Propose taking on projects that align with your interests.

• Suggest training or mentorship programs to develop your skills.

As the saying goes, “El que no llora no mama”—or as it’s said in English, “The squeaky wheel gets the grease”—if you want something, you need to take action to achieve it. Don’t be afraid to communicate your needs and ideas.

3. Research Problem Space and Strategy

Evaluate the company’s mission and challenges. Do these align with your interests and aspirations?

Define your professional goals, whether they involve mastering specific technologies, advancing into leadership, or contributing to impactful projects.

4. Conduct In-Depth Research

Use platforms like Glassdoor or connect with current employees to understand the company’s culture, growth opportunities, and decision-making processes.

5. Ask Insightful Questions During Interviews

• What mentorship or training opportunities does the company offer?

• How does the team approach technical decisions?

• What career progression paths exist here?

• What is the company’s long-term vision?

6. Prioritize Culture and Growth

Choose companies that invest in employee development, foster collaboration, and encourage innovation.

Takeways

Your workplace isn’t just a job; it’s where you build your skills, grow your network, and define your future. Choosing the right environment sets the stage for a fulfilling and impactful career. Align your goals with a company’s culture, strategy, and challenges to ensure you’re not just working—you’re thriving.

What’s one piece of advice you’d share about choosing the right workplace? Let’s swap lessons and ideas in the comments!

Before diving into technology stacks or new frameworks, it’s crucial to recognize that digital transformation depends on more than just the tools at hand. It requires a cultural shift that empowers everyone to embrace change, align with a shared vision, and scale successes across the entire organization. From cultivating the right mindset to breaking down departmental silos and expanding successful pilots beyond a handful of teams—addressing these three areas can make the difference between a stalled initiative and a truly agile, future-ready digital enterprise.

Expanding the Organizational Mindset

Digital transformation isn’t just about adopting new technologies or frameworks—it’s about embracing a culture and mindset that truly support agility. A Harvard Business Review report notes that 70% of digital transformation failures stem from cultural resistance and poor change management (Decentralizing Strategic Portfolio Management by Empowering Project Teams to Execute Digital Transformation). This aligns with my experience: without a shared understanding of Agile principles and a commitment to change at all levels, even the best-laid plans will falter.

In my previous article, The Problem with Being Agile, is Not Being Agile, I dive deeper into how adopting Agile for the wrong reasons, or without proper guidance, can derail the entire effort. It’s not enough to say you’re Agile; teams and leadership must internalize the principles that enable speed, flexibility, and continuous improvement. Only then can digital transformation thrive and deliver meaningful, sustainable results.

Breaking Down Departmental Silos

Another major challenge lies in departmental silos, where each team strives for its own objectives, often disconnected from the company’s broader vision. According to the Harvard Business Review, silos hinder collaboration and alignment, which are critical for successful digital transformation.

Shifting this requires clarity about why change is needed, open communication about the goals, and a willingness to continuously learn. As Scott Wilder of Boston Consulting Group notes, early failures without proper change management can lead to skepticism and create a negative flywheel, undermining transformation efforts. When everyone understands the “why” behind the transformation, they can move forward together with purpose.

The solution? Make the overall strategy crystal clear. Tools like Objectives and Key Results (OKRs) can bring alignment across the board. After about a year of trial and error at one company I worked with, OKRs helped leaders and teams row in the same direction, fully committed to shared targets rather than isolated goals. This kind of alignment is essential to break down silos and foster a culture of collaboration across departments.

Scaling Beyond Proofs of Concept

Finally, it’s not enough to prove agility in small pockets of the organization. Many companies succeed with initial pilots or proofs of concept but struggle to scale these successes across the entire enterprise. The Harvard Business Review highlights that persistent, cross-functional teams focused on long-term value streams—rather than ad hoc project teams—are key to scaling transformation efforts effectively.

In my own experience, acquiring or forming small, independent teams dedicated to building and integrating digital solutions has been a powerful approach. For example, a retail company I worked with acquired several startups as part of its transformation strategy. These startups brought new capabilities that allowed the company to scale its digital initiatives and evolve beyond isolated experiments.

Persistent teams not only ensure that digital transformation projects succeed but also foster ongoing innovation, as they’re designed to adapt and grow alongside the organization’s needs.

Closing Thoughts

As software architects, we have a responsibility not just to design systems but to ask the right questions and challenge the status quo when necessary. I’ve seen firsthand how organizations can struggle with these three key areas. One example that stands out is a traditional, multinational company I recently worked with. Despite their ambitious digital transformation goals, they faltered due to siloed departments, a lack of alignment in their vision, and the inability to scale their pilot projects effectively.

Reflecting on this experience, it became clear to me how critical our role as architects is in guiding the organization’s strategy. By asking the right questions, ensuring alignment across teams, and fostering collaboration, we can prevent ourselves from becoming part of the problem—especially when it comes to breaking down silos.

Transformation is never easy, but with the right mindset, clear communication, and persistent teams, it is possible to turn even the most traditional organizations into agile, future-ready enterprises. Let’s commit to being the change-makers who drive this forward.

This common pitfall has a name: Cargo Cult Programming. It’s what happens when we follow practices, frameworks, or patterns without fully understanding the “why” behind them. And while it might seem harmless at first, it often leads to overly complicated, harder-to-maintain solutions.

In this post, I’ll share my own experience of falling into this trap, explain what Cargo Cult Programming is, and offer practical tips to help you avoid it.

What Is Cargo Cult Programming?

The term “Cargo Cult Programming” comes from a fascinating piece of history. During World War II, some island communities observed the military’s rituals—like building airstrips and using radios—and copied them in hopes of attracting the same “cargo” of supplies. But without understanding the systems behind those rituals, their efforts didn’t work.

In software engineering, it’s the same idea: following coding practices, applying design patterns, or adopting tools without really understanding their purpose. We mimic the surface behaviors but miss the underlying principles.

My Own Cargo Cult Moment

When I first learned about design and architecture patterns, I thought they were magic solutions. Singleton, Factory, MVC—I wanted to use them everywhere. But instead of looking at the problems I was solving, I focused on the patterns themselves, forcing them into places where they didn’t belong.

The result? My code was harder to maintain, full of unnecessary complexity, and confusing to my teammates. I learned the hard way that patterns are tools, not rules. A software engineer’s job is to understand the problem first, then decide if a pattern helps—or if it’s better avoided altogether.

Here’s what I realized: If you don’t understand the “why” behind a practice, you can’t adapt it—or recognize when to skip it entirely.

Why It’s a Common Mistake

Cargo Cult Programming often happens because:

• We Fear Doing It Wrong: Especially early in our careers, it’s easy to think following best practices blindly is safer than trying something different.

• Shiny New Syndrome: Tools and frameworks can feel like solutions in search of a problem.

• Time Pressure: When deadlines loom, copying what worked elsewhere can feel like a shortcut.

• Blind Trust in Authority: If an experienced dev used it, it must be the right choice—right?

• Working in Isolation: Without team input, it’s easy to miss alternative solutions or misunderstand the context.

The truth is, without understanding the context, even the best practices can lead to poor results.

Spotting the Signs

Here are a few red flags to watch for:

• Using a Singleton or Factory where simpler code would suffice.

• Reusing code without adapting it to your context.

• Adding layers of complexity that don’t deliver value.

• Following practices without questioning their relevance.

Avoiding Cargo Cult Programming

Here’s how to escape this trap:

1. Start with “Why?”

   Before reaching for a pattern or framework, ask:
   What problem am I solving? How does this help?

2. Be a Team Player

   1. Debate decisions with your team. They can provide viewpoints you might have overlooked.

   2. Collaboration fosters better solutions and prevents blind adherence to practices.

   3. Remember, being a team player isn’t just about sharing work—it’s about sharing ideas.

3. Learn by Collaborating

   1. Code reviews and pair programming are excellent ways to understand the reasoning behind choices.

   2. Ask questions like:

      • Why was this approach chosen?

      • What trade-offs were considered?

4. Focus on the Problem, Not the Pattern

   Design your solution around the problem. If a pattern helps, great. If not, don’t force it.

5. Simplify Where Possible
   Always ask: Can this be done more simply? Complexity is rarely a virtue.

6. Reflect and Share
   Write about your decisions, review them with others, and don’t be afraid to admit when something didn’t work.

Cargo Cult Programming is a stage we all go through, but the key is to grow beyond it. The more you understand the “why” behind your decisions, the better your solutions will be—not just for you, but for your team and the users who rely on your work.

What about you? Have you ever fallen into the trap of Cargo Cult Programming? How did you move past it? Let’s share our stories and learn together!

Hey there! Have you ever found yourself buried under a pile of tasks because you just couldn't say "No" to that extra request? Trust me, I've been there too. As software engineers, we're often eager to help out, take on new challenges, and be team players. But sometimes, this eagerness can lead us straight into the People-Pleasing Trap, where we say "Yes" to everything—even when we shouldn't.

Let's talk about what this trap is, why it's so common in our field, how to spot it, and most importantly, how to navigate it by saying "No" effectively and proposing alternatives.

What Is the "People-Pleasing Trap"?

So, what's the People-Pleasing Trap all about? Simply put, it's when we feel compelled to agree to every request, task, or favor asked of us, often at the expense of our own time, well-being, or priorities. This usually stems from a desire to be liked, to avoid conflict, or to not disappoint others.

While wanting to help isn't a bad thing, constantly putting others' needs before our own can lead to stress, burnout, and a drop in the quality of our work.

Have you ever felt tempted to accept a proposed deadline from your manager, even when you know you're not going to meet it, just because you want to be agreeable or avoid a possible conflict? Well, I've fallen into that behavior myself. It resulted in stressful situations with extended workdays—not just for me, but also for my team. From these experiences, I learned that I wasn't being professional or a true team player.

I realized I had to be brave enough to say something like:

"I appreciate the urgency of this project. Given the current scope and our team's workload, meeting that deadline will be challenging. However, we could prioritize the most critical features to deliver maximum value by that date. Alternatively, if we can extend the deadline slightly, we can ensure all features are implemented with high quality."

By communicating this way, I'm being honest, professional, and solution-oriented. I'm protecting my team's workflow and allowing the business to make better decisions—in other words, truly being a team player.

Why It's a Common Trap in Software Engineering

In the world of software engineering, this trap is especially sneaky. Here's why:

• Fast-Paced Environment: Tech moves quickly, and there's always something that needs to be done "ASAP."

• Collaborative Culture: We're often working in teams, and there's a strong emphasis on collaboration and support.

• Fear of Missing Out: With so many cool projects and technologies, we don't want to miss any opportunities.

• Performance Pressure: We might feel that saying "Yes" to everything will prove our dedication and value.

But here's the catch: by overloading ourselves or avoiding tough conversations about project realities, we might actually hinder our performance and growth.

Spotting the Signs

Not sure if you're caught in the People-Pleasing Trap? Here are some signs to watch out for:

• You're juggling so many commitments that you're struggling to keep up.

• Other people's requests always take precedence over your own work.

• You hesitate to speak up about unrealistic deadlines or project issues.

• You're exhausted, and there's no end in sight.

• You say "Yes" to avoid letting others down, even when it's impractical.

Avoiding the People-Pleasing Trap

Alright, so how do we get out of this trap? Here are some friendly tips focusing on how to say "No" and proposing alternatives:

1. Practice Saying "No" Gently

   It's okay to decline a request! The way you say it can make all the difference.

   • Express Appreciation First:

     "Thanks for considering me for this task!"

   • Be Honest and Direct:

     "I'm currently at full capacity with other projects."

2. Propose Alternatives

   Offering solutions shows you're still committed to the team's success.

   • Adjust the Scope:

     "Could we focus on the most critical features first?"

   • Extended Timelines:

     "Would it be possible to extend the deadline by a week?"

   • Suggesting Others:

     "Maybe Alex could assist; they have experience in this area."

   • Future Availability:

     "I can take this on next week when I have more bandwidth."

3. Be Honest About Your Professional Aspirations

   If a role or task doesn't align with your career goals, communicate it respectfully.

   Let me share a personal story. I once worked at a company that hired me as a backend developer, which was exactly where I wanted to focus my career. After some time, they asked me to transition into a frontend developer role. While they offered a very high salary, frontend development wasn't aligned with my professional objectives.

   I felt tempted to accept because of the benefits, but I realized that saying "Yes" would steer me away from my career path. So, I had an open conversation with my manager:

   "I appreciate the opportunity and the trust you've placed in me. However, my passion and expertise are in backend development. I believe I can contribute more effectively in that area. Is there a possibility to continue focusing on backend projects?"

   Unfortunately, the company needed someone in the frontend role, and we couldn't find a middle ground. So, I made the difficult decision to seek a position elsewhere that aligned with my goals.

   This experience taught me that saying "No" is sometimes necessary to stay true to your professional path. It's not just about declining a task—it's about making choices that shape your career in the long run

4. Set Clear Boundaries

   Let your team know your availability and workload limits. Being transparent helps manage expectations.

5. Prioritize Your Tasks

   As I mentioned in my post about the Four Cardinal Points to progress as a senior software engineer, prioritizing what delivers more value is essential. You can check that post to learn more about this.

6. Reflect on Your Motivations

   Ask yourself why you're saying "Yes." Is it out of genuine interest, or are you trying to avoid disappointing someone? Understanding your reasons can help you make choices that align with your goals and well-being.

7. Seek Support

   Asking for help is okay, and it demonstrates that you are strong enough to grow in your career! Talk to a mentor, manager, or trusted colleague about your workload. They can offer guidance and might help redistribute tasks.

8. Build Assertiveness Skills

   Being assertive doesn't mean being aggressive. It's about expressing your needs respectfully. Consider reading books or attending workshops on assertiveness to strengthen this skill.

9. Remember It's Okay Not to Please Everyone

   You can't make everyone happy all the time, and that's perfectly fine. Focus on delivering quality work and taking care of yourself; that's what truly benefits everyone.

Breaking free from the People-Pleasing Trap isn't easy, but it's definitely doable—and worth it! By focusing not just on saying "No," but on how you say it and the value of proposing alternatives, you'll enhance your professionalism and contribute more effectively to your team.

Next time you're faced with a request that stretches you too thin, take a moment to assess. Communicate your limitations honestly, and offer solutions that could work for everyone involved. Remember, being a true team player means ensuring that you're contributing sustainably and effectively.

What Is the Dunning-Kruger Effect?

Simply put, the Dunning-Kruger Effect happens when people with limited knowledge or skill in an area think they’re much more skilled than they really are. The less we know, the less we realize how much we don’t know. This can make us overly confident and prone to mistakes we wouldn’t make if we had a more realistic view of our abilities.

Why It’s a Common Trap in Software Engineering

In tech, it’s especially easy to fall into this trap. There’s always new technologies, frameworks, and languages popping up, and it’s tempting to jump in and assume we know enough to be dangerous—in a good way. But that overconfidence can lead to writing unstable code, skipping over best practices, or misunderstanding the requirements of a task.

I once worked with an engineering manager who exemplified this effect. He made decisions unilaterally, without consulting the team, because he considered himself the ultimate authority on a specific topic. Despite the team's expertise and willingness to contribute, he disregarded our input. This overconfidence led to numerous mistakes in the project. Instead of acknowledging his role in these errors, he blamed the team for the failures, ignoring the fact that he hadn't taken our ideas into account.

This situation not only resulted in technical setbacks but also eroded team morale and collaboration. It highlights how the Dunning-Kruger Effect can manifest not just at the individual level but also impact entire teams and projects.

Spotting the Signs

How do you know if you’re slipping into the Dunning-Kruger Effect? Here are a few red flags:

1. You stop asking questions because you “know enough.”

2. You avoid feedback—thinking it’s unnecessary or won’t offer anything new.

3. Your code feels perfect, even if you haven’t tested it in every situation.

4. Deadlines start slipping because you underestimated the task complexity.

Avoiding the Trap Without Falling into Impostor Syndrome

While it's important to be aware of the Dunning-Kruger Effect, we also need to be cautious about swinging too far in the opposite direction. Overcompensating can lead to Impostor Syndrome, where competent individuals doubt their abilities and fear being exposed as frauds. This can be just as detrimental, causing unnecessary stress and hindering performance.

Tips to Find a Healthy Balance

1. Seek feedback often. Ask for code reviews, and don’t be afraid of constructive criticism. Your peers can see gaps you might miss.

2. Stay curious. Make a habit of learning a little more each day. The more you know, the more you’ll see the gaps in your understanding.

3. Be honest with yourself about what you don’t know. Instead of guessing, take time to research or ask someone more experienced. Admitting you’re still learning is a strength, not a weakness.

4. Mentor others and ask for mentoring. Teaching and learning both expose the limits of what you know and push you to keep improving.

So next time you’re feeling extra confident about something new, take a step back and check in with yourself. Are you really as knowledgeable as you feel? Recognizing the Dunning-Kruger Effect is the first step toward becoming a stronger, more aware software engineer.

The More Flexible, the More Value

A flexible architecture allows you to deliver early and long-term business value more easily. One tip for your career as an Agile Software Architect is to prioritize decisions that enable you to delay defining specific architectural details. This includes delaying choices related to frameworks, protocols, databases, configurations, message brokers, and other external dependencies.

By delaying these decisions, you leave room for better choices when you have more information, avoiding premature commitments to technologies that could limit your solution’s adaptability in the future. Clean architecture, for example, helps you abstract these details and focus on core business logic without being tightly coupled to specific technologies early on.

The Simpler, the More Value

As Agile Software Architects, our goal is to deliver value in the simplest way possible. Design decisions should focus on reducing unnecessary complexity, especially early in a project. For instance, instead of diving straight into complex architectures like microservices, consider simpler solutions that meet current needs and allow for easy evolution over time.

In my experience, I’ve seen projects that started with microservices from the beginning and failed because this architecture introduced unnecessary complexity. Managing service coordination, network overhead, and data consistency added more challenges than benefits at that stage. A simpler approach, like a monolithic architecture, would have saved time and resources, allowing the team to focus on delivering value earlier.

While microservices are great for scaling when necessary, starting simple and evolving as your system grows keeps your architecture flexible and easier to manage. By avoiding premature decisions, you prevent technical debt and ensure smoother progress.

Let me know your thoughts about this.

“Leadership is not about a title or a designation. It's about impact, influence, and inspiration. Impact involves getting results, influence is about spreading the passion you have for your work, and you have to inspire teammates and customers.”

— Robin Sharma, The Leader Who Had No Title

As software engineers, one of the most important skills we need to develop is leadership, even if our job title doesn't explicitly reflect it.

While our primary responsibility may be to provide solutions to real-world problems, this role involves working closely with others. From understanding the problem to implementing a solution, we inevitably influence those around us. The best way to make that influence positive and effective is by embracing leadership.

Leadership Anti-Patterns

In this section, I highlight some common mistakes made by bosses or people trying to be leaders. The goal is to raise awareness so we can avoid falling into these traps:

It is not about authority

One of the biggest leadership mistakes is believing that people will follow your decisions just because you hold a title. Being a boss doesn't automatically make you a leader. Leadership is about influence, not authority. This is why it's important to distinguish between being a boss and being a true leader, even though a boss can also be a leader. In modern companies like Amazon or Google, the person who is right is the one who can provide valid reasoning and evidence for their decisions, regardless of their title. And often, multiple people can be right at the same time.

It is not about a fake interest or empathy

I believe this is a serious issue that many people fall into—myself included. Demonstrating genuine interest or empathy is not about appearances; it’s about truly caring for others. This means putting yourself in their shoes and really feeling their concerns to understand them. Fake interest is easily detected, and when people realize it, your influence and credibility will diminish significantly.

It is not about always being hard or certain

When I first decided I wanted to become a leader, I fell into this trap. This mindset is toxic and can lead to unnecessary pressure. The good news is that you don’t need to be perfect. In fact, when you show humility, those around you feel more comfortable interacting with you. Demonstrating transparency and sincerity turns your perceived weaknesses into strengths, earning you influence and respect.

How to become a leader

First, we must understand that there are several leadership styles. Essentially, every leader must be capable of influencing others, creating impact, and continuously improving.

This influence, often referred to as positive influence, should be executed with a mindset of creating win-win situations, where everyone benefits. It's important to remember that you won’t always know whether a decision or action will have a positive outcome until after the fact. However, my tip for you is to be genuinely empathetic—this demonstrates your good intentions and builds trust in your leadership.

Leaders generate impact within their sphere of influence, whether that’s a team, a company, a market, or even a country. We must always keep this in mind and take responsibility for the influence we have. Furthermore, as leaders, we have to keep one eye on the future and the goal, ensuring the team stays on the right path.

Finally, a leader must be aware that everything changes over time: priorities shift, new requirements emerge, markets reinvent themselves, and so on. As software engineers, we must take advantage of these changes and adapt to new realities. Always remember that we can improve our abilities and skills—real leaders seek and receive feedback as a gift to grow in their careers.

Choosing my leadership style

My advice to you is: don’t limit yourself from trying new things. I was inspired by a boss who had the ability to orchestrate people, communicating effectively and assertively. He was a charismatic leader who knew how to identify the strengths and weaknesses of others and leverage them effectively. After several attempts, I realized that the leadership style I resonate with most is servant leadership, at least in general terms.

I’ve also learned that a leader must be flexible enough to adapt their leadership style to the situation—one style isn’t effective in every case.

You can analyze and study the leadership styles of others. For example, Benjamin Franklin’s leadership was pragmatic and transformational. You can learn a lot from observing other leaders and practicing different styles.

Here’s a short list of common leadership styles to consider:

• Servant Leadership: Leaders prioritize the needs of the team, empowering others to grow and succeed.

• Laissez-Faire Leadership: Leaders take a hands-off approach, giving team members autonomy to make decisions.

• Transformational Leadership: Leaders inspire and motivate others by setting a vision and driving change.

• Democratic Leadership: Leaders involve team members in decision-making, promoting collaboration and creativity.

• Autocratic Leadership: Leaders make decisions unilaterally, focusing on control and authority.

Conclusion

Leadership is not defined by a title, but by the positive impact and influence we bring to others. As software engineers, we have the opportunity—and responsibility—to lead, adapt, and grow continuously. Whether through empathy, humility, or strategic vision, the key to becoming a great leader is recognizing that leadership is a journey of learning, not a fixed destination. Embrace change, empower those around you, and always seek to inspire through action and example.

I invite you to share your thoughts and experiences with leadership in the comments below. Whether you have insights, feedback, or a different perspective.

There is ample literature on this topic. Recently, I read “The Software Engineer’s Guidebook”, which I highly recommend if you are interested in learning more about this topic.

From both literature and experience, I have learned that, as juniors, we often expect to work in isolation, and some might even prefer it. However, as we gain experience, we realize the necessity of working with others to build something greater. Teamwork is crucial for achieving significant goals.

Achieving great goals comes at a cost, and companies have limited resources. Therefore, we must prioritize and focus on the most valuable goals that have a greater impact on the business. Teams that build these solutions consist of individuals with the knowledge to make better decisions and trade-offs. These decisions are usually made by seniors with accountability and ownership.

These teams are not composed solely of seniors; it is common to find juniors within them. These less experienced professionals require mentorship from seniors to improve their skills and ensure tasks are executed correctly (please, do not confuse this with micromanagement).

The Four Cardinal Points

Overall, we can abstract from the previous paragraphs these qualities required by every Senior Software Engineer:

• Teamwork

• Hard and Soft Skills

• Leadership

• Prioritization by business value

These qualities can be thought of as "The Four Cardinal Points." Just as the cardinal points guide us in the right direction, these traits are essential for navigating and advancing in your career. I know these are broad viewpoints, as I mentioned in the first paragraph, but I think this abstraction makes them easier to understand. Let’s dive a little deeper into each.

Teamwork

One person usually sees only a few viewpoints. For instance, UX designers are primarily concerned with user interactions and the impact of every color and UI component on the user experience. They might not be as concerned with performance, data protection, or the effort required to implement a feature. This is why modern teams are interdisciplinary, composed of programmers (both frontend and backend), designers, architects, product owners, quality assurance professionals, and more. Each person adds value and perspective to the work, ensuring better deliveries by covering more viewpoints and scenarios that the solution must address.

Recently, I learned about a case where an Engineering Manager often made decisions without considering the ideas or comments of other team members. In one project, this Manager made a decision with the best intentions, but it introduced a security vulnerability. When the team discovered this, they researched and proposed a better alternative. After several attempts to convince the Manager to consider the new information, the Manager fortunately reconsidered and decided to adopt the improved solution.

This example illustrates the importance of teamwork and collaboration. By leveraging the diverse expertise of team members, we can identify potential issues early and develop more robust solutions.

One can acquire and improve this quality through practice. Exercises like pair/mob programming, code reviews, debating ideas, and requesting/giving feedback will help you to progress in your career to a senior level.

Hard and Soft Skills

Senior Software Engineers need to make decisions, propose solutions, and listen to other opinions. To achieve this, they must have knowledge and experience in various technologies, methodologies, collaborative work, and more.

For instance, a modern Software Engineer should be familiar with OAuth, JWT, Architecture Patterns, Design Patterns, Cloud, CI/CD, etc. However, the ability to determine which of these tools to use in a specific situation is a crucial skill that every Senior must possess.

Of course, it's not just about technical skills. Six years ago, I joined a new project as a Software Architect, in a hybrid role with Engineering Manager responsibilities. In my team, there was a Tech Lead with an excellent background whom I trusted for the project's success. However, I noticed that although his work was outstanding, he was aggressive towards me, especially when I proposed ideas to the team.

This was the first time I encountered such a situation, and I didn't know how to handle it. I sought advice from other Seniors on how to manage it effectively. I didn't want to exclude this person from the team because he was an expert and passionate about his work, which was beneficial for the project. However, his aggressive behavior began to negatively affect team dynamics. Fortunately, with the guidance I received, I was able to address the situation and improve the team's collaboration.

As we can see, being a great technical engineer is not enough. We must also know how to communicate and collaborate with others to excel in our roles. As Seniors, we must address these challenges and help others develop these essential skills.

Leadership

Everyone starts as a junior, and as we work and experience different situations, we grow in our careers. This evolution process is different for each person. As Seniors, we have the responsibility to train and mentor juniors to make them better for the company. This benefits not only the company but also the Seniors and Juniors involved.

Companies' products are built by their teams. If the engineers are skilled, they will build better solutions and deliver more value to the business. On the other hand, when a Senior teaches, their own abilities are enhanced, and they often gain new knowledge from the process. Additionally, the juniors who receive this mentorship can progress in their careers to become Seniors. It’s a win-win situation.

Leadership is about influencing people, not just holding a title. It involves influencing others for the benefit of the individuals affected and the company’s mission. There are many books on this subject, but my focus is on the ability of Seniors to positively influence others. Writing blogs, teaching and mentoring juniors, listening to people, receiving feedback, knowing your team, feeling genuine empathy, building real connections, and collaborating to create a great environment are ways to develop and demonstrate leadership.

One of my favorite books that taught me how to begin being a leader is “The Leader Who Had No Title.” I strongly recommend it if you are interested in improving this ability.

Prioritization by business value

As software engineers, especially as seniors, we must always keep in mind the business value we are delivering. This focus helps us prioritize tasks and make better decisions.

Great senior software engineers usually make decisions rationally and pragmatically. This approach sometimes involves assuming technical debt to take advantage of time-to-market opportunities or validate an idea. At times, it may also mean discarding features, reducing scope, or delivering something more critical for the company at that moment.

We need to be flexible enough to accept changes over time because contexts and situations evolve, requiring us to reprioritize and make new decisions swiftly.

The following steps are those I usually follow in my daily work that help me to prioritize:

1. List tasks: Write down everything you need to do.

2. Identify value: Mark the tasks that will deliver the most value when completed. If unsure about the value, seek help.

3. Prioritize: Ask yourself, "If I could only complete one task from this list, what would it be?"

4. Focus: Start and concentrate on that most important task.

These tools and practices have also helped me:

• Request For Comments (RFC): This helps us get feedback from other team members, considering the pros and cons of a solution. It enables better decision-making based on data.

• Attribute-Driven Design (ADD): This methodology helps design solutions by making decisions based on the most critical factors.

• Quality Attribute Workshops (QAWs): These workshops help gather information about the quality attributes required for the solution or product.

Conclusion

In summary, to be considered a Senior Software Engineer or Architect, one must develop and master four key qualities, referred to as "The Four Cardinal Points":

1. Teamwork

2. Hard and Soft Skills

3. Leadership

4. Prioritization by Business Value

These qualities guide and support a Senior Engineer in navigating their role and driving success for themselves and their teams. By focusing on these Four Cardinal Points, you can advance your career and make a significant impact in your projects.

Thank you for reading. I hope you found this post insightful and helpful in your professional development. I invite you to share your thoughts and experiences. What qualities do you think are essential for a Senior Software Engineer? Let’s discuss in the comments!

DOP represents a significant mindset shift from OOP, bringing in a lot of new ideas and approaches. Given its depth, I am splitting this topic into five posts. This first post provides a general overview of DOP. In the subsequent posts, we will explore specific concepts with examples in Clojure and Java. Although examples will be in these languages, DOP principles are applicable across various programming languages.

In the following four posts, I will focus on explaining each of the four principles stated by Brian Goetz in his post “Data Oriented Programming in Java”:

1. Model the data, the whole data, and nothing but the data.

2. Data is immutable.

3. Validate at the boundary.

4. Make illegal states unrepresentable.

Example: Banking System User Stories

To understand DOP better, let’s first consider how we would design a banking system using OOP, focusing on these user stories. Please note that the following user stories and proposed solution are not intended to be the best or most critical analysis of OOP but are used here for illustrative purposes.

User Story 1: Create Freemium Customers

• As a bank, I want to create freemium customers so that they can open savings accounts only.

  • Acceptance Criteria:

    • Freemium customers can only have savings accounts.

    • Freemium customers have a name, address, and unique ID.

User Story 2: Create Premium Customers

• As a bank, I want to create premium customers so that they can open both savings and checking accounts.

  • Acceptance Criteria:

    • Premium customers can have both savings accounts and checking accounts.

    • Premium customers have a name, address, and unique ID.

User Story 3: Deposit Money

• As a customer, I want to deposit money into my account so that I can save or spend it later.

  • Acceptance Criteria:

    • Customers can deposit money into their accounts.

    • The deposited amount is added to the account balance.

User Story 4: Withdraw Money

• As a customer, I want to withdraw money from my account so that I can access my funds.

  • Acceptance Criteria:

    • Customers can withdraw money from their accounts up to the available balance.

    • For checking accounts, withdrawals can exceed the balance up to the overdraft limit.

User Story 5: Freemium Customer Savings Account

• As a freemium customer, I want to open a savings account so that I can earn interest on my deposits.

  • Acceptance Criteria:

    • Freemium customers can create savings accounts with an interest rate.

    • Savings accounts can calculate and apply interest to the balance.

User Story 6: Premium Customer Checking Account

• As a premium customer, I want to open a checking account so that I can have access to overdraft protection.

  • Acceptance Criteria:

    • Premium customers can create checking accounts with an overdraft limit.

    • Checking accounts allow withdrawals up to the balance plus overdraft limit.

User Story 7: Premium Customer Savings Account

• As a premium customer, I want to open a savings account so that I can earn interest on my deposits.

  • Acceptance Criteria:

    • Premium customers can create savings accounts with an interest rate.

    • Savings accounts can calculate and apply interest to the balance.

User Story 8: Interest Application for Savings Account

• As a savings account holder, I want my account to calculate and apply interest periodically so that my savings grow over time.

  • Acceptance Criteria:

    • Savings accounts can calculate interest based on the current balance and interest rate.

    • Savings accounts can apply the calculated interest to the balance.

User Story 9: Enforce Account Restrictions

• As a bank, I want to ensure that customers can only open accounts they are eligible for so that account restrictions are enforced.

  • Acceptance Criteria:

    • Freemium customers can only open savings accounts.

    • Premium customers can open both savings and checking accounts.

User Story 10: Search for Account Owners

• As a bank manager, I want to find the names of all account owners so that I can have an overview of who holds accounts in the bank.

  • Acceptance Criteria:

    • The bank can search through all accounts.

    • The bank can return the names of all account owners.

OOP Proposed Solution

These user stories can be addressed through an Object Oriented Design. Below is a proposed class diagram for this solution.

Implementation

The Bank class represents the data, behavior, and validations required to support the requirements listed above. The Customer class is abstract because we can have two types of customers: Freemium and Premium. These are implemented by the FreemiumCustomer and PremiumCustomer classes, which both implement the canHaveAccount method to determine if a new account can be created for that user. Remember, Freemium customers can only get Savings accounts, while Premium customers can get both Checking and Savings accounts.

The Bank class has two lists: one for storing all customers and the other for storing and managing bank accounts. The Account class is intended to represent all common attributes and behaviors of any account, such as the balance, owner, and methods for depositing money.

To keep the example simple and focused on illustrating the core concepts, we intentionally omit getters and setters (encapsulation) in the code. Here is the implementation in Java:

import java.util.ArrayList;
import java.util.List;

public class Bank {

    String name;
    List<Customer> customers;
    List<Account> accounts;

    public Bank(String name) {
        this.name = name;
        this.customers = new ArrayList<>();
        this.accounts = new ArrayList<>();
    }

    public void addCustomer(Customer customer) {
        customers.add(customer);
    }

    public void createAccount(Customer customer, Account account) {
        if (customer.canHaveAccount(account)) {
            accounts.add(account);
            account.ownerId = customer.id;
            customer.addAccount(account.id);
        }
    }

    public List<String> findAllAccountOwners() {
        List<String> accountOwners = new ArrayList<>();
        for (Account account : accounts) {
            for (Customer customer : customers) {
                if (customer.id.equals(account.ownerId)) {
                    accountOwners.add(customer.name);
                }
            }
        }
        return accountOwners;
    }
}

abstract class Customer {

    String id;
    String name;
    String address;
    List<String> accountIds;

    public Customer(String id, String name, String address) {
        this.id = id;
        this.name = name;
        this.address = address;
        this.accountIds = new ArrayList<>();
    }

    public abstract boolean canHaveAccount(Account account);

    public void addAccount(String accountId) {
        if (canHaveAccount(accountId)) {
            accountIds.add(accountId);
        }
    }
}

class FreemiumCustomer extends Customer {

    public FreemiumCustomer(String id, String name, String address) {
        super(id, name, address);
    }

    @Override
    public boolean canHaveAccount(Account account) {
        return account instanceof SavingsAccount;
    }
}

class PremiumCustomer extends Customer {

    public PremiumCustomer(String id, String name, String address) {
        super(id, name, address);
    }

    @Override
    public boolean canHaveAccount(Account account) {
        return account instanceof SavingsAccount || account instanceof CheckingAccount;
    }
}

abstract class Account {

    String id;
    double balance;
    String ownerId;

    public Account(String id) {
        this.id = id;
        this.balance = 0;
    }

    public void deposit(double amount) {
        if (amount > 0) {
            this.balance += amount;
        }
    }

    public void withdraw(double amount) {
        if (amount > 0 && amount <= this.balance) {
            this.balance -= amount;
        }
    }
}

class SavingsAccount extends Account {

    double interestRate;

    public SavingsAccount(String id, double interestRate) {
        super(id);
        this.interestRate = interestRate;
    }

    public void applyInterestRate() {
        this.deposit(interestRate * this.balance);
    }
}

class CheckingAccount extends Account {

    double overdraftLimit;

    public CheckingAccount(String id, double overdraftLimit) {
        super(id);
        this.overdraftLimit = overdraftLimit;
    }

    @Override
    public void withdraw(double amount) {
        double balanceAvailable = this.balance + this.overdraftLimit;
        if (amount > 0 && amount <= balanceAvailable) {
            this.balance -= amount;
        }
    }
}

Although this approach with OOP works fine it is complex to maintain, this complexity is led by:

• Behaviors and data structures are mixed

• Validations and behaviors are constraints by inheritance (which is the most coupled relationship)

• Unpredictable behavior in concurrency environments, since its mutability

• Since the behaviors are stateful the tests are harder

DOP Proposed Solution

DOP emphasizes modeling data as data and separating it from behaviors, making behaviors stateless. The following class diagram illustrates the data model for this approach:

As you can see, BankData has four fields: customersById, savingsAccountsById, checkingAccountsById, and name. The first three fields are maps, which act as dictionaries or indexes, facilitating efficient searching. Essentially, BankData is also a map, but depending on the programming language chosen, we can construct our data model accordingly.

In Clojure, which is a functional programming language adhering to many DOP principles like immutability, we can implement our model as follows:

(ns bank-data)

(def bank-data
  {:name ""
   :customersById {}
   :savingAccountsById {}
   :checkingAccountsById {}})

(defn create-customer
  [id name address isFreemium isPremium]
  {:id id
   :name name
   :address address
   :savingsAccountIds []
   :checkingAccountIds []
   :isFreemium isFreemium
   :isPremium isPremium})

(defn create-savings-account
  [id owner-id interest-rate]
  {:id id
   :balance 0.0
   :ownerId owner-id
   :interestRate interest-rate})

(defn create-checking-account
  [id owner-id overdraft-limit]
  {:id id
   :balance 0.0
   :ownerId owner-id
   :overdraftLimit overdraft-limit})

In Java, although primarily an OOP language, we can also implement our DOP model. Java has introduced new features in recent years to support DOP in a type-safe manner, such as records, sealed classes, pattern matching, lambdas, etc. Here’s the Java implementation of our design:

import java.util.Map;
import java.util.List;

record BankData(
    String name,
    Map<String, CustomerData> customersById,
    Map<String, SavingsAccountData> savingAccountsById,
    Map<String, CheckingAccountData> checkingAccountsById
) {}

record CustomerData(
    String id,
    String name,
    String address,
    List<String> savingsAccountIds,
    List<String> checkingAccountIds,
    boolean isFreemium,
    boolean isPremium
) {}

record SavingsAccountData(
    String id,
    double balance,
    String ownerId,
    double interestRate
) {}

record CheckingAccountData(
    String id,
    double balance,
    String ownerId,
    double overdraftLimit
) {}

On the other hand, we can model our behavior as stateless functions, which improves the testability of our code. The following diagram shows a first version of this solution with DOP:

Keep in mind that in the methods' parameters, the first parameter is always the dataset required to execute the process, ensuring that every function is stateless. Let’s describe each class in more detail:

• BankLogic:

  • Centralizes operations related to the BankData.

  • Includes methods for adding customers, creating accounts, finding account owners, and performing deposits and withdrawals.

• SavingsAccountLogic:

  • Handles specific operations related to savings accounts.

  • Includes methods for applying interest rates, withdrawing, and depositing money into savings accounts.

• CheckingAccountLogic:

  • Manages operations for checking accounts.

  • Contains methods for withdrawals and deposits specific to checking accounts.

• CustomerLogic:

  • Provides methods to check if a customer can have a specific type of account.

  • Ensures that the correct business rules are applied when handling customer-related operations.

Notice that we no longer have inheritance relationships. We will discuss more about relationships in DOP approaches in future posts. This approach provides the following benefits:

• Separation of Concerns:

  • Data and behavior are separated, making the system more modular and easier to maintain.

  • Changes in business logic do not affect the data structures and vice versa.

• Reusability:

  • Logic classes can be reused across different parts of the application without duplication.

  • Common operations are centralized, reducing the risk of inconsistent behavior.

• Testability:

  • Functions operating on plain data structures are easier to test in isolation.

  • Mocking data for unit tests is straightforward, and behavior can be verified independently of data structure changes.

I want to share a possible implementation of these behavior classes with you, but I believe it is a lot of information to digest at once. Therefore, we will go through it step by step in future posts to make it easier to understand.

Conclusion

This post has introduced a Data Oriented Programming (DOP) approach to implementing a banking system based on the given user stories. The separation of data and behavior enhances modularity, reusability, and testability. Immutability reduces errors in our system and improves concurrency capabilities. You might wonder how data can be immutable when we need to add data or deposit money into accounts, etc. It's similar to how git repositories work, and I will demonstrate this in the next posts.

In the upcoming posts, we will delve deeper into this example, exploring each aspect of Data Oriented Programming in more detail. We will examine the principles of DOP, how to implement them in Java, and how to handle complex scenarios within this paradigm. Stay tuned as we continue to unfold the power of Data Oriented Programming and its practical applications in software development. Please let me know if you have any questions or contributions to this discussion.

Improving Operational efficiency and Agility

In the world of platform engineering, efficiency and agility aren't just theoretical benefits; they have real-world impacts. Take my experience in a governmental entity, for example. Every year, this entity faced the monumental task of sending numerous documents to citizens for tax and other purposes. The process was heavily manual, involving a significant operational investment due to the large volume of citizens and the complexity of the cases. Their existing system, not developed in-house, was restrictive and misaligned with the entity's processes, leading to a considerable waste of effort and money.

The turning point came when we developed an in-house solution to automate these processes. Once this new system was implemented, the difference was stark. Not only did it save considerable effort and reduce errors, but it also expedited the entire process. The impact on the entity's efficiency was profound – a whopping 30% reduction in the time and effort required to execute these processes. Moreover, this change led to a substantial increase in revenue, about 20% more than previous years. This experience is a testament to how platform engineering can transform an organization's operational dynamics, slashing costs and boosting effectiveness. 

Furthermore, this success story is a shining example of digital transformation in action. By moving from a manual, cumbersome process to a digital, streamlined one, the governmental entity not only enhanced its operational efficiency but also significantly improved the experience for citizens. The ease of consulting and paying taxes online represented a leap forward in public service. This transformation wasn't just about internal benefits; it was also about making life easier for the citizens, demonstrating how platform engineering can have a far-reaching impact. It's not just about what happens inside an organization; it's also about how these changes are felt externally by the people you serve. In this case, the combination of platform engineering and digital transformation created a more responsive, efficient, and citizen-friendly public sector.

Innovation as a Driver for Market Leadership

“Ironically, in a changing world, playing it safe is one of the riskiest things you can do” - Reid Hoffman

In the fast-paced world of technology, innovation isn’t just a buzzword; it's the essence of market leadership. Amazon, a trailblazer in this arena, exemplifies how platform engineering and a relentless focus on innovation can drive a company to the pinnacle of its industry. Their approach, often dissected in studies like 'Think Like Amazon,' revolves around continuously experimenting and pushing the boundaries of what's possible. By building a robust, scalable platform, Amazon has not only streamlined its operations but also created a fertile ground for groundbreaking ideas to flourish – from cloud computing with AWS to revolutionizing retail and logistics.

Amazon’s journey underscores a crucial lesson: innovation through platform engineering extends far beyond mere product development; it's about reinventing customer experiences and operational models. Through their platform, Amazon offers a degree of customization and personalization in services that sets new industry standards. Utilizing data analytics and AI, they anticipate and adapt to customer needs, setting trends rather than following them. This commitment to innovation is what keeps Amazon at the forefront of its markets, continually evolving and redefining what's possible. It's a shining example for businesses aiming to not just compete but lead in their markets, proving that sustained innovation is key to long-term dominance and relevance in today's ever-changing business landscape.

Furthermore, the power of platform engineering extends to empowering individual teams within an organization. By providing a robust and flexible platform, companies like Amazon have demonstrated how teams can work with greater independence, free from the constraints of relying on other teams for resources or support. This autonomy is a catalyst for innovation. When teams can operate independently, they're more likely to experiment, take risks, and think outside the box. This environment is ideal for nurturing innovative ideas that can quickly evolve into practical, market-ready solutions.

This level of independence fundamentally changes the dynamics of how teams contribute to a company's innovation agenda. It allows for a more decentralized approach to innovation, where ideas and solutions can originate from various parts of the organization, not just the top. As a result, businesses can tap into a wider pool of creativity and expertise, accelerating the pace of innovation and staying ahead in competitive markets. In essence, platform engineering is not just a technical strategy; it's a business strategy that enables a culture of continuous innovation, driving a company towards market leadership.

Navigating the Challenges: Antipatterns in Platform Engineering

Building a successful platform engineering strategy is a journey fraught with challenges and learning experiences. Reflecting on my own journey, I've encountered several pitfalls that have reshaped my understanding of effective platform engineering.

Avoiding the 'Know-It-All' Trap

One critical mistake I've made was attempting to build a platform for every possible scenario, falling into the trap of thinking I had all the answers. This approach is fundamentally flawed. No one can fully anticipate the myriad of use cases across an entire company. A more effective strategy is to view platform development as an evolutionary process. It's essential to build the platform incrementally, focusing on specific domains or even subdomains. I've learned that creating boundaries based on business capabilities rather than attempting to cover every possibility is far more practical. This approach allows for a platform that evolves and adapts over time, aligning more closely with the company's changing needs.

Empowering Teams, Not Restricting Them

Another misstep was inadvertently turning the platform into a set of restrictions for teams. A platform should empower teams, not constrain them. It's about providing interfaces and standards that grant autonomy and enable teams to focus on strategy and delivering value. For instance, dictating a specific set of databases for every solution can stifle innovation and flexibility. Instead, offering standards for data communication protocols or guidelines for implementing patterns like event-driven architectures can foster a more decoupled and efficient system. These standards should facilitate creativity and efficiency, not hinder them.

From Paper to Practice

A significant hurdle I faced was the failure to effectively translate platform standards from paper to practice. Despite communicating new standards, teams struggled to follow them, often due to a lack of understanding of their application. This issue highlighted the importance of automation and tooling in platform engineering. Tools like Infrastructure as Code (IaC) can aid in implementing these standards by providing ready-to-use templates and self-service capabilities. Additionally, the rationale behind each standard – whether it's to mitigate risks, simplify processes, or cut costs – needs to be clearly communicated and understood. This understanding ensures that the standards are more than just rules; they are integral tools that contribute to the team's and the company's success.

Broadening the Perspective

Initially, I viewed platform engineering primarily as a technical endeavor – a collection of best practices, guidelines, and standards. However, this perspective is limiting. Platforms have a profound impact on solution teams and the business as a whole. They should be seen as a strategic asset that propels the business towards market leadership. Balancing the technical details with a broader business perspective is vital.

Assessing the Need for a Custom Platform

One of the greatest lessons I've learned is that not every company needs to build its own platform. Platform engineering demands significant investment and long-term commitment. It's essential for each company to assess its unique context to determine whether a custom platform is the right choice. This assessment can be aided by enterprise architecture, ensuring that the decision aligns with the company's long-term goals and capabilities. Testing and evaluating the platform in an agile manner can provide early feedback, helping to ascertain its effectiveness and fit within the business.

Conclusion

In conclusion, platform engineering is not just a technological journey but a strategic voyage towards market leadership. It represents the fusion of operational efficiency, innovative drive, and the wisdom gleaned from navigating complex challenges. This article has sought to illuminate the path by sharing real-world insights and experiences, highlighting the importance of an adaptive approach, team empowerment, and the integration of technical prowess with business strategy. Yet, the conversation around platform engineering is ever-evolving, and your perspectives and questions are invaluable. I invite you to enrich this discourse—share your experiences, raise questions, or offer your viewpoint. Together, let’s explore the vast possibilities of platform engineering and its impact on shaping agile, customer-focused, and forward-thinking businesses in our dynamic digital era.

So, what does this mean?

Imagine your company as a ship. The goals are your destination (like offering awesome services or making your products super affordable). EA is the captain that charts the best course, using tech and smart strategies as its compass and map.

Now, here’s where it gets interesting. To steer the ship right, we need to know two things: where we are now (the ‘As-Is’ state) and where we want to be (the ‘To-Be’ state). Sometimes, there might even be a few pit stops (intermediate states) along the way. The trick is spotting the gaps - like if we’re missing a piece of tech or need to tweak a process - and then planning how to fill them. Think of it as a treasure map, marking where the treasure (our goals) is and plotting a route to get there.

But hey, it’s not all about tech upgrades.

Sometimes, it’s about changing how we do things or shaking up the team structure. The roadmap we create isn’t just a tech shopping list; it's more like a travel itinerary that includes who's doing what, when, and what we need to pack for the journey.

And just to make this super relatable, imagine a café wanting to speed up their order process. Their ‘As-Is’ is taking orders manually. Their ‘To-Be’? A cool app where customers order ahead. The gap? They need the app and maybe a bit of a process change. The roadmap lays out how they’ll get there, step by step.

To wrap it up, Enterprise Architecture isn’t just some stuffy corporate speak; it’s a practical way to make sure your business and tech are BFFs, working together to get you where you want to go. It’s about having a plan, but also being ready to adjust the sails when needed.

How to Design an Enterprise Architecture: Making it Simple

Alright, let's dive into the nitty-gritty of designing an EA. You might be wondering, "How do we build this thing?" Well, it's a bit like baking a cake – there are different recipes (or frameworks) you can follow, but the essentials remain the same.

One popular recipe is TOGAF (The Open Group Architecture Framework). It's like the classic vanilla cake – versatile and well-liked. TOGAF is cool because it's kind of a one-size-fits-all framework, suitable for a wide range of companies. And guess what? The same folks behind TOGAF, The Open Group, came up with something called Open Agile Architecture. It's like adding sprinkles to your vanilla cake, making TOGAF agile-friendly and ready for fast-paced business environments.

But here's the thing – businesses change, like, all the time. So, your EA needs to be a bit like a chameleon, changing colors to match the environment. That's why I'm all for agility in EA design. By setting up 'checkpoints' in your EA, it's like having rest stops on a long road trip. You get to pause, reassess, and make sure you're still on the right track, ensuring your EA stays relevant and valuable.

What's in the Enterprise Architecture Box?

Now, what goes into your EA depends on your recipe (framework) and what your company is all about. I usually like to focus on four main ingredients:

1. Business Architecture: This is understanding the heartbeat of your company – its capabilities, processes, and how it ticks. It's crucial to know where you are now (the As-Is state) and where you're heading (the To-Be state). It's like having a map for your business journey.

2. Data Architecture: Here's where you get a grip on the data – what you need, how you're using it, and how it should flow in the future. It's all about making sure your data serves your business goals, both now and down the road.

3. Application Architecture: This is about the tools in your toolbox – the systems and software that power your business processes. It's about figuring out what you've got, what you need, and how to bridge that gap.

4. Infrastructure Architecture: Think of this as the foundation of your building. It's the hardware and other tech stuff that supports everything else. It's about making sure the physical and digital infrastructure aligns with your business needs.

And there you have it! But hey, if you're curious about diving deeper into each of these areas, or how to document and communicate them, let me know. I'd love to chat more about it!