Total Portfolio Approach: The Plumbing Beneath the Philosophy

Investment industry attention is increasingly turning to the Total Portfolio Approach (TPA). The case for it is, by now, familiar: improved performance and closer alignment with investor goals.

However, less has been said about what must be true inside an asset owner’s or wealth manager’s organization before that uplift can be fully captured. In this article we look at TPA through an unexpected lens: software development.

The Question for an Investor

The question for an investor is not whether TPA works in principle. It is whether your organisation can capture the benefits that TPA offers, and what must be true internally before it can.

This article argues the TPA uplift, like the software uplift of Agile’s before it, depends on specific technical and operational practices that make the philosophy possible. With those in place, the same teams can produce measurably better outcomes.

What is the Total Portfolio Approach?

The core idea of TPA is that investment decisions are focused on the investor’s actual goals, rather than beating a benchmark or adhering to a pre-set Strategic Asset Allocation (SAA). The industry has spent decades using SAA, tracking error and relative performance as shorthand proxies for those goals; however, the proxy is not the goal.

TPA is often described as a philosophy, but in practice ideas only deliver value when the technical capabilities and operating models are in place.

A View from Software Development

Investor portfolios today look structurally like software development looked in the 1990s. At that time, software teams worked on their components in parallel and integrated them only when each piece was complete.

The integration step was where most of the bugs hid: interfaces drifted, assumptions diverged, and defects accumulated at the seams between components. None of it was visible until someone tried to merge it all together. The industry called it “integration hell”.

Today, investor portfolios have their own version of integration challenges. Asset class teams manage their pieces in parallel, and that specialisation is correct. You want credit experts running credit, equity experts running equities, and interest‑rate specialists managing duration and curve risk.

The investment committee “integrates” the portfolio quarterly (sometimes monthly). They aggregate exposures and net risks and evaluate the whole portfolio; sometimes for the first time since the previous meeting.

Between meetings, the seams between asset classes are often unowned, untested, and invisible. For example, consider a situation where the listed equity team tilts towards quality and low volatility and, separately, the hedge fund team’s diversification strategy does the same but without either team realizing the duplication.

In that context, SAA is the integration plan all teams agreed to at the start of the year, while the investment committee meeting is the periodic merge. The issue is that you can only act on the portfolio you can see; and for many investors that means a detailed view only once a quarter.

What fixed the issues caused by infrequent integrations in software development was not just the Agile philosophy. When investors hear that Agile transformed software, they typically picture the philosophy: short iterations, working software, responsiveness to change.

But what made those practices effective was a set of technical practices that took hold alongside the Agile Manifesto. Chief among them: continuous integration. Automated builds, automated tests, and version control are intended to run on every change. The cost of integration collapsed from a quarterly event into a background process running automatically.

It is that cost collapse that contributed to the Agile philosophy’s effectiveness. Responding to change means little if changing course leads to a six-week integration cycle.

This is the part of the software story that is most instructive for investors considering TPA.

What is TPA’s Equivalent of Continuous Integration?

TPA’s equivalent is what we will call live Whole Portfolio Analysis (WPA). Many institutions already produce a whole portfolio in slide form every quarter, but that is not what is meant here. WPA is a continuously integrated, priced, and testable view of every exposure expressed in a single shared language that every desk in the organisation can act on simultaneously.

TPA requires factor-based decomposition across a wide range of investments in public and private markets, including equity, credit, real estate, infrastructure, hedge funds, other real assets, and derivative exposures. This enables asset owners to translate diverse portfolio holdings into a common risk language of equity, interest rates, inflation, credit, and currency.

Meaningful TPA analysis requires the ability for cross-asset comparison, stress testing, and factor-based portfolio construction. It depends on having a common language for every investment.

WPA is to investor portfolios what continuous integration was to software development. A reference portfolio, a unified risk model, and a shared exposure language do for portfolio integration what version control and automated tests did for code integration. As a result, asset class specialisation is preserved; what changes is the seams between asset classes become continuously testable, priced, and exploitable.

Here is where WPA smooths the seams between asset classes:

• Investment opportunities held to a common standard. Every asset is assessed on the same basis against its contribution to the portfolio objectives, not a policy-weight bucket or bespoke benchmark, so it becomes visible where capital should move. Competition for capital can be objectively measured and evaluated.

• Cross-asset opportunity capture. With every exposure expressed in the same language, decisions that span asset classes (such as certain hedge-fund or FX strategies) can be compared like-for-like instead of falling between teams.

• Faster reallocation. WPA ‘merges’ the whole portfolio continuously rather than quarterly, so a change in conviction can be acted on the moment it forms, not at the next investment committee meeting.

This is primarily a data architecture and analytics problem; asset class specialisation needs to integrate continuously.

It is worth noting where the analogy stops. A portfolio is not a codebase, so whilst WPA can reduce the cost of acting more frequently, it doesn’t oblige anyone to do so.

Why the Technical Layer Alone is Not Enough

Even with continuous integration in place, software teams structured around component silos kept producing component-shaped products. The technical breakthrough was necessary but not sufficient. American computer scientist and programmer Melvin Conway in 1967 observed why: “Organisations which design systems are constrained to produce designs which are copies of the communication structures of these organisations.”

Among investors, a TPA philosophy declared on top of an asset-class-siloed organisation produces the appearance of TPA without the means to act on it. Capital still flows through asset class committees, performance still rolls up by silo, and the seams remain unowned. Even with WPA in place, no one feels empowered to make investment decisions outside of their silo.

Investors that genuinely benefit from TPA tend to restructure as well as re-platform. That means unified investment teams, incentives aligned to investment goals, central decision rights, and performance measurement at the whole-portfolio level. Many organisations have found this to be the hardest part about full TPA adoption.

The technical layer makes the philosophy cheap to execute; the organisational and governance layer empowers the team to execute it.

Where Does This Leave Investors?

The practices outlined in the Agile Manifesto took a decade to become mainstream, and another decade to scale through DevOps and platform engineering.

TPA is beginning its mainstream adoption phase. A small number of leading funds have demonstrated the model, formalized governance frameworks, and built tools.

Whilst full adoption is the destination for some investors, it is not the only option. For many investors, the right destination is not TPA-versus-SAA but an SAA framework with TPA principles operationalised within.

The path in Exhibit 1 can be climbed one step at a time, and each step incrementally collapses the cost of integration. The point is not to declare a philosophy, but to build (even partially) the approach. Incremental TPA is still TPA.

The above ideas can be combined into a grid to provide investors with a readiness assessment for TPA. Two questions are:

1. Do we have a live Whole Portfolio Analysis or only a quarterly one?

2. Does our operating/governance model match the portfolio we are trying to manage?

The lesson from software is the benefits of a philosophy only accrue when the underlying technical and operational capabilities are delivered. In the case of TPA, the technical layer is the ability to run WPA, and the operational layer is the operating model to act on it.

After all, you can only act on the portfolio you can see.

To Learn More

FactSet's whole portfolio solution is multi-asset class by design, providing institutional investors with a single, market data-enriched platform that spans public and private markets. The platform supports the entire investment lifecycle, from portfolio planning, research, and pre-investment due diligence through to post-investment risk monitoring, performance measurement, and reporting, making it a true consolidation play for complex portfolios. Try it yourself with our interactive demo.

Additional reference/source: WTW "Total Portfolio Approach (TPA), CAIA, 2025.

This blog post is for informational purposes only. The information contained in this blog post is not legal, tax, or investment advice. FactSet does not endorse or recommend any investments and assumes no liability for any consequence relating directly or indirectly to any action or inaction taken based on the information contained in this article.