Insight · Platform

Application Portfolio Management in Sparx EA: From Spreadsheet to Live Intelligence

By Sparx Services · August 23, 2025

Application portfolio management in Sparx EA means modeling applications as ArchiMate Application Components, relating them to the capabilities, services, projects, risks and costs around them, and connecting the systems that already hold the portfolio data so the view stays current. The repository holds the structure and the relationships. The values (lifecycle status, cost, risk, contract dates) stay in the project and portfolio management (PPM), IT service management (ITSM), governance, risk and compliance (eGRC) and IT financial management (ITFM) systems that own them, and AI connects them to the model. A spreadsheet cannot maintain live relationship data, and a portfolio built this way can.

Core APM elements in Sparx EA

APM in Sparx EA is built on a specific set of ArchiMate element types. Using the right types is what makes the portfolio queryable and the relationships traversable.

Application Component is the primary type for individual applications. Each distinct application is one Application Component. Do not use custom element types, UML classes, or freeform boxes. These break the structure that everything downstream depends on.

Application Service represents what an application exposes to other applications or to the business. The distinction matters: an Application Component is what the application is; an Application Service is what it does. For integration-heavy portfolios, Application Services are how you map which business services depend on which application capabilities.

Application Interface models the technical integration points: APIs, file transfers, event streams. For portfolios undergoing rationalization, interfaces reveal the dependencies that prevent decommissioning.

Data Object connects applications to the data they manage. Where data governance is a concern, and it usually should be, Data Objects linked to Application Components via Association relationships establish data ownership in the repository.

The portfolio data an application needs, and where it lives

An application needs a small set of values before it can support a portfolio decision. Each one already lives in a system that someone maintains. The minimum set for functional APM, with the system that typically owns each (yours may differ):

The portfolio data an application needs, and where it lives
Value	Type	Values	Typically held in
Lifecycle Status	Enumeration	Active, Planned, Phasing Out, Retired	ITSM, PPM
Business Criticality	Enumeration	Mission Critical, High, Medium, Low	ITSM, eGRC
Health Score	Integer (1-5)	1 = Critical risk, 5 = Fully fit for purpose	eGRC assessments, ITSM incident data
Application Owner	Text / Person reference	Name or directory reference	ITSM
Vendor	Text	Vendor name	ITFM
Contract Expiry	Date	ISO 8601 date	ITFM
Hosting Model	Enumeration	On-premise, Cloud-IaaS, Cloud-SaaS, Hybrid	ITSM
Last Review Date	Date	ISO 8601 date	eGRC

Mature portfolios add Annual Run Cost (ITFM), FTE Dependency, Replacement Candidate (as a linked element), and Architecture Review Status. The three that drive dashboard quality are Lifecycle Status, Business Criticality, and Health Score. Agree what each one means, which system is the source of record, and who owns it, and the portfolio view is useful. Leave the definitions loose and the sources unnamed, and the dashboard is theater: it looks structured, but it can’t be trusted.

The architecture model stores the structure that lets these values mean something: which application, which capability, which project, which risk. Nobody types the values in. A value that no system owns, such as an architect’s own assessment of fitness for purpose, is the exception, and the architect records it in the model with the date and the basis.

The MDG sets the standard; the source systems supply the values

An MDG turns a policy, “every application must have a lifecycle status”, into a rule the repository can check.

In Sparx EA, MDG profiles restrict the Application Component to designated APM packages, define the attributes an application carries, present controlled enumeration lists instead of free text, and block non-APM element types from APM diagrams. The values arrive from the source systems. When an application is missing one, the completeness check shows whether the gap is in the source system or in the matching between the source and the model, and the person who owns the record fixes it where it lives. Automation checks completeness, people own correctness.

The most common failure mode in APM is values keyed into the repository by hand that drift out of date. A lifecycle status entered two years ago looks as authoritative as one confirmed yesterday, and any dashboard built on that data is only as good as the least recent entry. Take each value from the system that owns it and the drift has nowhere to start. Clear definitions and a named source of record for every value are what separate useful APM from portfolio theater.

Live portfolio intelligence

The portfolio view comes from connected data, not periodic exports. The architect uses AI to connect to the PPM, ITSM, eGRC and ITFM systems that hold the data. The model relates what comes back, so one application shows its owner, its project, its open risks and its run cost together. Dashboards in Prolaborate or Power BI read that connected model, so the portfolio is a current data source rather than a last-month snapshot:

Dashboards that display the portfolio from the connected model, filtered by lifecycle status, criticality, domain, technology, or capability, with no manual exports behind them.

Natural-language queries that let portfolio managers and executives ask “which applications are mission critical and phasing out?”, “what’s our cloud vs on-premise split by domain?”, or “which contracts expire in the next 12 months?”, answered from current data.

The prerequisite for all of it is the same: a named source of record for every fact, and reliable matching of each source record to its Application Component. If a source has gaps, the dashboard shows gaps, and the fix belongs in that source.

Why portfolio theater happens, and what prevents it

Portfolio theater is what happens when a dashboard looks like governance but can’t be acted on: lifecycle statuses set two years ago and never updated, health scores that are an architect’s guess rather than an assessment, owner fields naming someone who left the organization.

The pattern that works:

Each value has one source of record, named in the portfolio standard.
AI reads the source systems on the refresh schedule you set and brings the values into the model, so nobody re-keys them.
The architect states the matching rules (which project record belongs to which application, what to do when two match) and reviews the exceptions the AI flags.
Completeness and staleness checks list the applications with missing or old values, for the owners who can correct them in the source.
Dashboards show when each source was last read, so stakeholders can see how fresh the data is.

That’s the difference between an APM practice and an APM spreadsheet with extra steps.

What your architects can now get done

A portfolio architect is asked which applications the organization has, what each costs and risks, and what to consolidate. The skill that decides the result is the architect’s.

Connecting the portfolio to the systems that hold the data

Today an architect keys status, cost and risk values into the repository application by application, and asks the owners of the PPM, ITSM, eGRC and ITFM systems for fresh exports each quarter.

AI-augmented, the architect says which questions the portfolio must answer and which system is the source of record for each fact, and AI connects to those systems and brings the values in.

The skill is knowing the portfolio questions well enough to name the source for each one, and describing the connection precisely.

Tools that help: Claude + AI Power Tools, GitHub Copilot + AI Power Tools or Kernaro AI Hub.

Letting the model stitch the data together

Today, relating an application to its project, its risks and its run cost means opening several spreadsheets and matching names by eye.

AI-augmented, the architect states the matching rules, such as what makes a project record belong to an application and what to do when it matches two, and AI relates the records in the model.

The skill is writing matching rules that reflect how your organization names things, and checking the exceptions.

Tools that help: Claude + AI Power Tools, GitHub Copilot + AI Power Tools or Kernaro Assist.

Giving leadership a dashboard that stays current

Today the portfolio slides are rebuilt each quarter from the spreadsheet and are out of date by the meeting.

AI-augmented, the architect starts from the decision a leader has to make, such as what to consolidate, and describes the view that would inform it. AI builds it in Prolaborate or Power BI on the connected data.

The skill is starting from the leader’s decision and describing the view in terms of that decision.

Tools that help: Prolaborate, Power BI, Microsoft 365 Copilot or Kernaro AI Hub.

Which tool helps depends on the job. Compare the AI options, or see the APM discipline page for the full set of portfolio jobs.

Frequently asked questions

What element type should I use for applications in Sparx EA?

ArchiMate Application Component. Custom types, UML Classes, or freeform boxes prevent MDG governance from applying and break the consistent identification of portfolio elements that downstream reporting depends on.

What tagged values does every Application Component need?

At minimum: Lifecycle Status, Business Criticality, Health Score (1-5), and Application Owner. For financially governed portfolios, add Annual Run Cost and Contract Expiry. Define them in the MDG profile, and take the values from the systems that own them (ITSM, eGRC, ITFM) rather than typing them in.

How do I build an APM dashboard from Sparx EA data?

Use AI to connect the source systems that hold the portfolio data, let the model relate them to each application, then build the dashboard in Prolaborate or Power BI on the connected data. Filter on Lifecycle Status, Business Criticality, and domain package, and publish to the executive audience.

What’s the difference between an Application Component and an Application Service?

An Application Component is the application itself, the software system as a deployable unit. An Application Service is what it exposes, a specific capability or function available to the business or to other applications. One component typically provides several services.

How do I handle applications serving multiple capabilities?

Model the application as one Application Component and create multiple Association or Serving relationships to the Business Capability elements it supports. The resulting many-to-many map is one of the most valuable APM outputs. It reveals under-supported capabilities and high-impact applications.

How does MDG governance affect dashboard quality?

Directly. The MDG defines the attributes every Application Component carries and the values each may take, so every application is described the same way. The values come from the source systems, so the dashboard is as accurate as they are. If a source system is incomplete, the dashboard shows the gap, and the fix is made in that source. Without agreed definitions, the dashboard isn’t trustworthy as a governance tool.

The path from spreadsheet to live portfolio runs through connecting the systems that already hold the data, and it does not need another dashboard product. We teach your portfolio architects to work this way on your own repository: start at For Architects. Or we build and update the portfolio model for you, connected to your source systems: what we build. Either way the dashboards land in Prolaborate or Power BI: Reporting and Power BI.

Make your portfolio live, not last-month.

Talk to a practitioner about connecting your PPM, ITSM, eGRC and ITFM data to your Sparx EA portfolio, so it stays current without re-keying.

Book a call

Keep reading