Skip to main content

Application Portfolio Management

Introduction​

Application Portfolio Management (APM) provides transparency about which applications exist, what they are used for, who owns them, which data they manipulate, and on which technologies they depend.

This pattern describes a pragmatic approach to Application Portfolio Management using ArchiMate, aligned with the ADOIT Lean Profile for Enterprise Architecture.

The focus is on clarity, comparability, and analytical usability rather than exhaustive technical detail.

Design Principle​

Business First, Technology Second​

Applications are defined from a business perspective rather than a technical one.

There is no universally accepted rule for defining what constitutes an application. This pattern recommends defining applications from a business perspective rather than a technical one.

The portfolio focuses on the value an application provides to the business and who is responsible for it, while implementation details are documented separately in the technology architecture.

This separation improves portfolio transparency, avoids unnecessary technical complexity, and better supports application portfolio management and architecture planning.

What Is an Application?​

Before modelling anything in the application portfolio, it must be clear what qualifies as an application.

  • In practice, many components are labelled "application" even though they are:

    • generic platforms,
    • shared technology products,
    • or infrastructure services.

To avoid ambiguity and keep the portfolio lean, the following Application Identification Questionnaire is used.

Application Identification Questionnaire​

The questionnaire helps determine whether a component should be modelled as an Application Component or rather as System Software.

The questions are intentionally business-oriented and independent of implementation details.

  1. Does the component contain business logic?

    • Does it support concrete business functionality?

      If a software component is primarily responsible for hosting or realizing applications, rather than delivering business functionality, it should be modelled as System Software rather than an application.

  2. Can the component be mapped to specific capabilities?

    • Does it clearly realize a defined set of business capabilities?

    • Is its contribution to the business understandable and explainable?

      If the mapping to capabilities is vague or extremely broad, this is a strong indicator that the component is not an application.

  3. Is the component business-specific or general-purpose?

    • Is it tailored to specific business needs?

    • Or does it provide generic functionality across many domains?

      General-purpose components are typically System Software.

  4. Does the component have clear business responsibility?

    • Is there an identifiable Application Owner?

      If a software component is owned and managed entirely by IT and does not provide business functionality directly, it is typically System Software rather than an application and does not belong in the application portfolio.

  5. Can the component be managed independently?

    • Does it have its own roadmap or investment planning?

    • Can it be deployed, updated, replaced, or retired independently of other software?

    • Would its lifecycle differ from that of the surrounding solution?

      If a part of a solution can be managed with its own lifecycle, it is often a good candidate for a separate Application Component. Independent lifecycles are a strong indicator that multiple Application Components should be modelled instead of a single one.

  6. Does the component manipulate business data?

    • Does it create, update, or delete Business Objects?

    • Is it a system of record or system of engagement?

      Components that only transport or technically process data are usually not applications.

  7. Would removing the component remove a business capability?

    A simple but effective control question: If this component were removed, would the organization lose a business capability — or only a technical platform?

    • Loss of a business capability → Application Component
    • Only technical replacement required → System Software
Practical Guidance

The questionnaire is a decision aid, not a rigid checklist.

  • In most cases:

    • If all or most of the questions can be answered with yes, the component should be modelled as an Application Component.
    • If only a few apply, it is typically System Software or another technical element.

This keeps the application portfolio focused on business value.

Modelling Structure​

  • Application Components - Core of the Portfolio

    Each application is modelled as an Application Component.

    • Application Components represent:

      • business responsibility,
      • functional scope,
      • portfolio-relevant planning units.

  • Linking Applications to Capabilities

    To understand why an application exists, it is linked to business capabilities.

    Icon Application Component → Realization → Capability

  • Technology Dependencies via System Software

    Underlying technology products are modelled as System Software.

    Icon System Software → Serving → Application Component

    • This makes visible:

      • technology dependencies,
      • standard platforms,
      • modernization constraints.

  • Information Flows via Application Interfaces

    APIs and interfaces are modelled explicitly using Application Interfaces.

    • Applications compose the interfaces they provide.

      Icon Application Component → Composition → Application Interface

    • Applications are served by the interfaces they consume.

      Icon Application Interface → Serving → Application Component

  • Data Usage via Business Objects

    To understand which data an application manipulates, Business Objects are used.

    Icon Application Component → Access → Business Object

  • Business Responsibility via Business Actors

    Ownership and usage responsibility are explicitly modelled.

    • Application Owner

      Icon Application Component → Responsible → Business Actor (remark: ADOIT-specific relation)

    • User Organization / Customer

      Icon Application Component → Informed → Business Actor (remark: ADOIT-specific relation)

Modelling Pattern​

Architecture Diagram

Do / Don't - Application Portfolio Modelling​

  • Icon Do

    • Model applications as Application Components.
    • Link applications to Capabilities.
    • Separate applications from System Software.
    • Make ownership and usage explicit.
    • Decompose large monoliths where useful.

  • Icon Don't

    • Don't model generic platforms as applications.
    • Don't model applications without clear ownership.
    • Don't connect applications directly without interfaces.
    • Don't treat monoliths as indivisible units.

Scope and Intent​

  • This pattern supports:

    • application inventory and transparency,
    • portfolio analysis and rationalization,
    • modernization and replacement planning,
    • alignment between business, application, and technology views.

  • It is not intended to:

    • replace technical system documentation,
    • model deployment or runtime architecture,
    • describe application internals.