Enterprise architecture for portfolio management starts by deciding which system is authoritative source for each type of data. Financial actuals sit in the ERP. Work state sits in Jira or Azure DevOps. Engineering change sits in code repositories. Service management data sits in platforms such as ServiceNow. Portfolio management tooling has to join these sources without rewriting them.

Centralizing portfolio data into a single tool usually strips context: workflow state, audit trails, and the identifiers that make figures defensible. Centralization can help basic reporting, but it does not create trust on its own. Trust comes from keeping source systems authoritative while building a portfolio view where the data shown can be traced back to spend, work state, and delivery sources systems.

This article defines the seven layers of a typical portfolio architecture and the integration rules that keep the strategic view aligned with delivery reality.

The Modern Enterprise Stack:

If we were to map out a high-functioning architecture for a modern enterprise, it typically involves seven distinct layers. The goal isn’t to force one tool to do everything. That’s a recipe for thin functionality. Each system should remain authoritative for its own domain.

image:borderless

image:medium

1. ERP: The System of Financial Record

Whether it’s Oracle, SAP, or Workday, the ERP is the ultimate arbiter of money. It handles the "un-fun" but essential realities: capitalization rules, cost centers, and the controls that keep auditors happy.

Treat the ERP as authoritative for actuals. Avoid duplicating the chart of accounts in the portfolio tool.

Rule: If it doesn't reconcile to the ERP, it isn't real.

2. Delivery & Execution: The System of Work

For technology delivery, work state typically lives in Jira or Azure DevOps. This is where backlogs live and teams manage their daily cadence.

This layer is operational, not strategic. The architectural challenge is mapping the high-level portfolio "Epic" to the "User Stories" and "Tasks" that developers actually touch.

3. Code Management: The Engineering Audit Trail

GitHub, GitLab, or Bitbucket. This is where engineering truth resides. It’s the record of every commit, pull request, and release.

The highest-leverage relationship in your stack is the line between a code commit and the work item that justified it. Without this link, "progress" is just a narrative; with it, progress is an observable fact.

4. Service Management: The "Run" Layer

ServiceNow is the heavy hitter here. However, a common trap is "overbuying"—procuring peripheral modules like it’s SPM or Project modules simply because they are "on the platform."

ServiceNow is world-class at Incident and Change management. But forced adoption of its secondary modules often leads to a "lowest common denominator" experience. If you aren't using ServiceNow, you’re likely looking at BMC Helix or Jira Service Management, but the same rule applies: integrate with the best, don't settle for the "included."

5. The Strategic Portfolio Management Platform: The Orchestrator

This is the connective tissue. It sits between strategy, finance, and execution. Its job isn’t to manage tasks, it’s to orchestrate decisions: prioritization, funding, and capacity.

Consideration: You have legacy giants like Planview, which offer deep complexity, and modern players like Kiplot, which focus on high-velocity orchestration, user experience, and visibility. The goal of this layer is to enable portfolio decisions in the context of strategy, by reconciling delivery reality with budget and capacity constraints.

6. BI & Visualization

Power BI is a common executive reporting layer. Depending on the enterprise stack, this role is also filled by platforms such as Tableau or Looker.

BI is only impactful when it sits on a stable semantic layer. If every department defines "Project Health" differently in their own dashboard, you haven’t solved reporting; you’ve just decentralized the argument.

7. The Data Warehouse

Finally, the "long-term memory" of the organization: Snowflake, BigQuery, or Databricks.

This is where you answer the "big" questions. Not just "What is happening now?" but "Do teams that link work items to pull requests actually deliver 20% faster?"

The Interfaces That Matter

A diagram of seven boxes looks great on a slide, but the architecture lives or dies by the connections between them. There are two "golden threads" that determine the credibility of your portfolio view.

The "Execution-to-Code" Link

When a developer opens a Pull Request in GitHub, it should ideally reference a Jira/ADO ticket. This creates a "Straight Through Processing" (STP) model for data.

When this link is automated, governance becomes a byproduct of the work, rather than an administrative tax on the engineer. It builds credibility with leadership because they can see that "Done" actually means "Delivered."

image:borderless

image:medium

Portfolio to ERP, and Portfolio to Delivery

This is the most critical interaction.

• SPM to ERP: The SPM platform should pull the "Actuals" from the ERP so that managers aren't manually typing in spend.
• SPM to Delivery: The SPM platform should pull "Status" and "Estimates" from Jira/ADO.

If the SPM layer requires manual, "double-entry" updates from project managers, it will always lag behind reality. People will stop trusting it, and eventually, they’ll stop using it.

image:borderless

image:medium

You can see how this works in practice on our Jira and Azure DevOps Integration pages.

The Golden Rule: One System, One Domain

The best-in-class architectures are the ones with the clearest rules.

They operate on a simple principle: One system is authoritative per domain. Financial actuals and controls are managed in the ERP. Work state is managed in Jira or Azure DevOps. Engineering record is tracked in Git. The portfolio layer should join these sources so an initiative view can be traced back to financial actuals, delivery status, and release record.

Architecture is about making sure that when an executive asks, “How is this initiative going?”, the answer is clear, complete, and traceable back to ERP actuals and delivery tooling, without contradictions.