Designing an effective APM governance model is a cornerstone of any successful APM Implementation and Governance strategy. It requires more than just drawing diagrams or populating elements. The real challenge is defining the operational framework: who owns the data, who is allowed to change it, and how decisions are published to the wider organization.
Sparx Systems Enterprise Architect (EA) provides the structure and rules, while Prolaborate handles stakeholder engagement. However, the governance model provides the logic that keeps roles, application ownership, and update cycles clear.
Discuss your Application Portfolio Management Context, data sources, and governance goals with SSNA’s expert consultants.
Core Governance Teams (Business, Architecture and Operations)
In a practical scenario, APM governance relies on the interaction between three distinct teams. It is essential to be explicit about what each team contributes to the Sparx EA repository.
1. The Business Team
These are your business owners and product managers. They prioritize business value, process criticality, and operational risks. In this model, they generally do not log into the Sparx EA thick client.
Instead, they interact entirely through Prolaborate governance dashboards, reviewing data and confirming business needs without managing technical modeling details.
2. The Architecture Team
This includes enterprise, domain, and solution architects. This group owns the APM metamodel itself like the inventory structure, the scoring criteria, and the rationalization logic.
They work directly inside Sparx EA, maintaining the integrity of the model and designing the specific views that will be exposed to the business.
3. The Operations Team
Your ITSM and infrastructure teams provide data on stability, incident history, and technical debt. While their raw data often lives in a CMDB or ITSM tool, this information is summarized into Sparx EA Tagged Values (see Integrating Sparx EA APM Data with Other Systems) to support decision-making.
Defining Application Ownership: Who Owns the Application Records?
One of the primary challenges in APM design is accountability. If every user can edit the application record, data integrity degrades. A robust strategy involves splitting application ownership across three perspectives:
- The Business Owner (Accountable): Signs off on the application’s function. They confirm if it is still needed, how critical it is, and whether it supports the right business capabilities.
- The Technical Owner (Accountable): Usually a System SME or IT Lead. They are responsible for the stack, hosting details, interfaces, and the technical health score.
- The Architecture Owner (Accountable): Typically the Domain Architect. Their job is to assess strategic fit and propose the specific Rationalization Decisions (Retain, Retire, Rehost, Rebuild, Replace).
How to model this: In Sparx EA, implement this using Tagged Values for specific owner names and Package ownership to segregate domains. This ensures you can easily run reports on who is responsible for each record.
Applying RACI Logic for Application Owners
You do not need to embed a complex RACI matrix inside the repository. The roles assigned in your Tagged Values should map directly to a simple logic:
- Responsible: The Application Owner (often a lead engineer or analyst) who keeps the record up to date.
- Accountable: The Business Owner who signs off on criticality and impact.
- Consulted: The Architects and Security teams who provide strategic and risk context.
- Informed: Finance and Portfolio teams who consume the resulting reports.
Approval and Review Cycles Inside Sparx EA
Governance also requires a defined schedule. You must determine the frequency of reviews for the portfolio.
What to review: Beyond basic descriptions, you must review lifecycle status, health scores, and the Rationalization Roadmap (e.g., verifying if an application is still on track for retirement).
How often:
- Quarterly: A light-touch refresh of scores and lifecycle status.
- Annually: A comprehensive portfolio review to plan major modernization investments.
To support the Sparx EA approval process, use Baselines to capture the state of the portfolio at each major review point. Additionally, use status fields (like GovernanceStatus = Draft, Under Review, Approved) to track where a record sits in the EA review workflow.
Publishing Decisions with Prolaborate Governance
Once valid data exists in EA, it must be accessible to decision-makers. This is where Prolaborate governance features become the primary engagement layer.
Expose APM Decisions
Build dashboards that visualize rationalization outcomes. Stakeholders should be able to view lists such as “Apps marked for retirement” or “Candidates for Cloud Migration” immediately.
Run Decision Reviews
Instead of exchanging spreadsheets, optimize the process by Collaborating on APM through Prolaborate. For example, a Domain Architect can trigger a review for all “Retire” candidates in the Finance domain. Stakeholders comment and approve directly on the live data, streamlining the Sparx EA approval process.
Make Governance Visible
Create executive-level landing pages that highlight decisions pending approval versus those already ratified. This transparency secures buy-in from leadership.
Governance Views for the Business
For business stakeholders, simplicity is the priority. Provide them with:
- A Portfolio View: A specific list of “their” applications showing essentials: Value, Risk, and the plan (Retain/Replace).
- Actionable Dashboards: Learn the basics of Building APM Dashboards in Prolaborate to create views such as “Applications requiring your review” or “Approved modernization candidates.”
Aligning APM with Enterprise Architecture Governance
APM must function as part of the broader Enterprise Architecture. Integration typically occurs in three areas:
1. The Metamodel
The Application Component used for portfolio scoring must be the same object used in Solution Architecture and Strategy models. APM simply adds scoring, cost, and lifecycle attributes to the existing inventory. This allows you to trace a “Retire” decision down to the specific Business Capabilities and Processes that will be impacted.
2. Standards and Target State
APM decisions must link to your reference architecture. If an app is marked for Replatform, that decision should link to the Target Platform or Technology Standard defined by the EA team. This ensures modernization is a managed transition toward your strategic technical direction.
3. Shared Governance Forums
Utilize existing Architecture Review Boards (ARB) or Design Authorities to review APM proposals. When you identify a group of applications to be retired or rebuilt, those Prolaborate views become the input materials for the ARB. This positions the APM governance model as a practical input for existing governance practices, rather than a parallel process.
Deploy a standardized APM framework instantly using our industry-proven metamodels and pre-configured patterns.
By structuring application ownership in EA and exposing decisions through Prolaborate, you transform APM from a static inventory into a strategic tool. Governance ensures clarity. When stakeholders trust the data and understand their role, the portfolio becomes a reliable roadmap for modernization.
