Extreme A

"I'm not your rolling wheels, I'm the highway."

The conference is running June 23–27 with a great mix of virtual sessions, workshops, and live events.

platformcon.com/sessions/str...

Thrilled to be part of #PlatformCon2025!

This year, I’m sharing a session titled “Strategic PlatformOps with Wardley Maps”. The talk explores the often-overlooked strategic layer of platform engineering. We’ll use Wardley Mapping to visualize the landscape of internal platforms.

It should offer powerful capabilities behind clean, intuitive interfaces. It should reduce friction, not increase it.

Easier said than done.

This is where Gregor Hohpe’s insight is so important: build abstractions, not illusions. The value of a platform lies in its ability to abstract away the messy, intricate details of infrastructure and tooling, so teams can focus on delivering business value.

Not because they want to rebel, but because the official platform no longer meets their needs. It has become an obstacle, not a support structure.

And then comes the inevitable workaround what I call the "shadow platform" movement. Talented engineers, trying to get things done, start building their own tools and workflows on the side, often out of sight from the official platform team.

The result? Teams lose motivation. Innovation slows. Engineers spend more time negotiating exceptions than building value.

The rules, meant to ensure consistency and security, often go too far, dictating not just what should be done, but how it must be done, down to the smallest details.

I’ve seen many internal platform initiatives start with ambition and good intentions, only to fall under the weight of rigid processes and overly strict governance. These platforms, instead of becoming enablers, turn into bottlenecks.

It should empower teams to move faster, with confidence, while still aligning with security, compliance, and operational excellence. In short, your platform should feel like a power-up, not a penalty.

It should give an ability to deliver bigger value with less friction, not introduce more bureaucracy. A good platform removes cognitive load from developers, abstracts away infrastructure complexities, and provides clear, reusable paths to production.

It does not matter if you build an internal delivery platform for a small company or a big corporation, the principle that platform should be an enabler, not the blocker still stands.

If a team can survive an emotional and behavioral calibration of its members over time, it will become unbeatable.

First time presenting and helping host a developer event in Singapore - DeveloperXperience Summit 2025.

It was a great opportunity to connect with the local tech community and get a feel for the developer landscape here.

I find Martin Fowler's Technical Debt Quadrant especially useful. It categorizes debt based on whether it's intentional or unintentional, and whether it’s taken thoughtfully or carelessly.

What’s your relationship with technical debt?

Many teams fail to recognize just how many impediments they’ve created for themselves by ignoring technical debt.

Like financial debt, technical debt can be a reasonable trade-off when taken deliberately to support growth or seize opportunities.

The discussion of technical debt should be taken seriously by development teams. Every change has the potential to add to the debt.

Like financial debt, technical debt can grow over time due to the "interest" that accumulates when it's not addressed.

If there’s no trust in the socio-technical system, delivering value takes more time than in a trust-enabled one. That's it. That's the post.

Notice I haven’t used the word “microservice.” You can start with small services from day one, but that assumes you already have a mature deployment platform and a deep understanding of your domain structure. Often, that’s not the case early on.

Option B offers simplicity in debugging and reasoning. But to scale effectively, it still demands strong subdomain boundaries and ongoing investment in intelligent build and deployment systems to maintain team velocity.

Option A gives you a strategic advantage: you can continue splitting services as needed. With good domain boundaries and a mature deployment/monitoring platform, these transitions are straightforward.

When done well, it allows a growing team to operate autonomously within their respective subdomains.

Option B: Keep the monolith, but invest in smarter tooling - incremental builds, partial regression testing, etc. This path still requires enforcing strong domain boundaries to enable distributed ownership across the team.

However, you’ll still need to invest in the deployment platform to ensure the new application is delivered as seamlessly as the original monolith. The benefit is that teams can now work more independently on separate services.

Option A: Identify stable parts or logical domains within the codebase and extract them - either as shared libraries or separate applications/services. If the domain boundaries have been well-maintained, this becomes easier.

Over time, however, the monolith tends to grow. Build and test times increase, and deployment queues begin to pile up. Eventually, the team is faced with a strategic decision.

Most teams begin with a monolith. It’s convenient: easy to reason about, straightforward to deploy, and simple to spin up locally. Designing pipelines for a single application is also much easier at this stage.

What truly matters are two factors:
- Clear domain boundaries
- A mature deployment platform

During my career, I’ve had the opportunity to examine several large codebases and observe how they evolve over time. One key conclusion I’ve drawn is that the number of deployable units doesn't matter that much.