Minimum Viable Architecture: From Project Thinking to Platform Thinking

Every technology leader knows the pressure. A new product needs to be launched. A channel expansion can’t wait. The business case demands results this quarter, not next year. So, you do what’s reasonable: you build what you need to make this work, in this channel, on this timeline.

That’s sound thinking. Control investment. Prove value. Move fast. The problem isn’t any single decision; it’s what happens when dozens of these decisions accumulate across teams, products, and years.

Download PDF

The Accumulation Problem

Here’s the pattern you’ll recognize: Your mutual fund distribution architecture works well. Then you add ETFs, and they need different data structures. Then SMAs require their own attribution rules. Then, interval funds arrive with unique reporting requirements. Each time, you solve the immediate problem. Each solution works in isolation.

McKinsey calls this result the “complexity tax,” where asset managers spend 60 to 80 percent of their technology budgets just maintaining what they’ve built, leaving almost nothing for innovation. You’re not investing in capability; you’re paying interest on architectural debt.

Ask yourself: When you launched your last new product, how much time was spent building new capability versus retrofitting existing architecture to accommodate it?

Three years of reasonable decisions made by reasonable people create unreasonable constraints. Not because anyone chose poorly, but because five teams made five locally optimal decisions that weren’t coordinated at an architectural level. The result is legacy systems that nobody designed; they just emerged from accumulated shortcuts.

A Different Question

Minimum Viable Architecture (MVA) asks a different question than Minimum Viable Product (MVP). Where MVP asks, “What’s the smallest product that validates our hypothesis?”, MVA asks, “What’s the smallest architectural investment that prevents tomorrow’s constraints while enabling today’s delivery?”

This isn’t “big design up front”. That’s the opposite extreme, leading to analysis paralysis as business units build their own workarounds. MVA identifies which decisions create optionality and which create lock-in, then invests appropriately in each.

The practical application breaks into three areas:

Standardize your interfaces. How data enters your ecosystem and how downstream systems consume it should be as predictable and consistent as possible. When you differentiate at the edges with custom formats and proprietary integrations, you create the integration nightmares that consume your maintenance budget.

Differentiate your transformation. How you construct your client view, reconcile data streams, and apply your market strategy, that’s where competitive advantage lives. This is your secret sauce, not your data ingestion patterns.

Preserve extension points. Every architecture embeds assumptions about what might change. MVA makes those assumptions explicit and ensures future products can connect without rebuilding what exists.

The Organizational Dimension

Here’s what gets understated: MVA isn’t primarily a technical discipline. It’s an organizational one.

The shift from “How do we support this product?” to “How do we build architecture that supports continuous product evolution?” requires coordination across teams that are each under pressure to deliver their piece quickly. Research, including studies by McKinsey and others, consistently shows that 70 percent of digital transformation failures are attributed to organizational resistance, not technology limitations.

Teams naturally optimize for their immediate deliverable. That’s rational behavior given how most organizations measure performance. MVA requires someone asking, “What architectural decisions are we making implicitly?” before those implicit decisions become explicit constraints.

The firms that succeed don’t just implement MVA as a technical practice. They embed architectural thinking into how product decisions get made, ensuring that someone at the table represents the future products that don’t exist yet.

Where to Start

MVA doesn’t require a massive architectural overhaul. It requires changing how you approach your next decision or initiative. Three starting points:

Audit your implicit decisions. Before your next project starts, ask “What architectural assumptions are we baking in?” and document them. Decide which are intentional constraints and which are accidental ones you’ll regret in eighteen months. Most firms discover they’re making significant architectural commitments without realizing it, and that awareness alone changes behavior.

Pick a beachhead. Select one high-value initiative with executive sponsorship and apply MVA thinking to it. Prove that the model works—not just the technology, but also the cross-team coordination—before expanding. MVA doesn’t mean boiling the ocean; it means defining and realizing a long-term vision while demonstrating continuous value. Visible success with each successive use case builds the credibility to scale the approach.

Inventory your interfaces. Map where data enters and exits your ecosystem. Identify the two or three integration points causing the most rework with each new product. Standardizing those first delivers disproportionate returns and creates the template for standardizing the rest over time.

The Strategic Imperative

The firms addressing architectural debt now will set the standard for what’s possible in an AI-driven market. Those still patching? They’ll discover they can’t operationalize it—not because AI doesn’t work, but because their architectural foundation can’t support it.

The question isn’t whether to invest in your architecture. You’re already investing mostly in maintenance and retrofitting. The question is whether that investment creates optionality or consumes it.

Minimum Viable Architecture isn’t about building less. It’s about building what matters: the foundation that turns each new product from an architectural crisis into an architectural extension. Project thinking asks how to deliver this quarter. Platform thinking asks how to deliver this decade.

You already know which approach your competitors are taking. The question is what you’re going to do about yours.