Skip to Content
MetamodelApplicationsApplication Fields

Application Fields

Within ArchRepo, Applications are defined with a set of fields that describe what the application is, who it is for, and how it is classified within the solution landscape.


1. Description

  • What it’s for: A concise summary of what this application is and what it does.

  • What to include:

    • Describe the application’s primary function and the users it serves.
    • Keep it accessible — this description appears in table views and gives readers a quick orientation.
    • Avoid implementation detail; focus on purpose and scope.
  • Example: "The Customer Self-Service Portal allows registered customers to view their account, submit service requests, and track the status of open cases without contacting the support team."


2. Purpose

  • What it’s for: Classifies the application within the solution landscape, making it easy to filter and organise a large set of applications.
  • Options:
ValueWhen to use
Primary Business Use CaseThe application directly delivers a core business capability to end users
Secondary Business Use CaseThe application supports or enables a primary business capability
System AdministrationThe application is for configuring and managing the system, not using it
Data AdministrationThe application is for managing data — reference data, lookups, bulk operations
External (From another system)An application owned by a third party that the solution interfaces with
  • Guidance: When in doubt, ask: “Is this the thing users do their actual work in?” If yes, it is likely Primary. If it exists mainly to support or feed another application, it is likely Secondary.

3. Business Purpose Description

  • What it’s for: A fuller explanation of why this application exists, written in language that business stakeholders will understand.

  • What to include:

    • Describe the business problem this application solves or the business capability it enables.
    • Avoid technical jargon — write for a business reader who may not know the implementation.
    • This field is separate from Description: Description is brief and factual; Business Purpose is explanatory and contextual.
  • Example: "The portal reduces the volume of inbound calls to the support team by enabling customers to resolve common queries themselves. It supports the business's goal of improving customer satisfaction scores while reducing operational cost."


4. Feature Summary

  • What it’s for: A summary of the main features and capabilities the application provides.

  • What to include:

    • List the key things users can do in the application.
    • Write in terms of user capabilities, not technical components.
    • Useful for scope discussions, onboarding new team members, and stakeholder reviews.
  • Example: "View account details and recent activity. Submit and track service requests. Download invoices and statements. Update contact preferences. View FAQs and self-help articles."


5. Use Cases (relationship)

  • What it’s for: Links the application to the use cases it implements.
  • What to include:
    • Link any use cases from the Use Cases collection that this application is the primary delivery vehicle for.
    • This creates a traceable link from documented user interactions to the application that supports them.

6. Application Patterns (relationship)

  • What it’s for: Links the application to one or more Application Patterns it follows.
  • What to include:
    • Link any patterns from the Application Patterns collection that this application conforms to.
    • Acceptance criteria and implementation acceptance criteria linked to a pattern are automatically displayed on every application that follows it — no need to duplicate them.
    • An application can follow multiple patterns if appropriate.

7. Is this accessible via a web browser?

  • What it’s for: Indicates whether this application is accessed through a web browser.
  • Set to Yes if: The application runs in a browser — whether it is a public-facing website, a web-based admin tool, or a SaaS product accessed via URL.
  • Set to No if: The application is native only and cannot be accessed through a standard browser.

8. Is this a native Mobile application?

  • What it’s for: Indicates whether this application has a native mobile client (iOS or Android).
  • Set to Yes if: The application is distributed as a native app on a mobile platform — App Store, Google Play, or enterprise distribution.
  • Note: An application can be both web-accessible and a native mobile app if both delivery modes exist.

9. Is this a native Desktop application?

  • What it’s for: Indicates whether this application is a native desktop application (Windows, macOS, Linux).
  • Set to Yes if: The application is installed on a user’s machine as a native desktop client.

Other Relationships

RelationshipWhat to link
Supports Business ProcessBusiness processes this application directly supports
Replaces Business ProcessManual or legacy processes this application replaces
Supports Business ScenarioBusiness scenarios in which this application plays a role
Supports Business RequirementBusiness requirements that this application addresses
Supports Business OutcomeBusiness outcomes this application contributes to
Supports Non-Functional RequirementNon-functional requirements (availability, performance, security) that apply to this application
Implements Business RuleBusiness rules this application enforces
Manages Business InformationBusiness information entities this application manages (creates, edits, deletes)
Uses Business InformationBusiness information entities this application reads
Contains UI ComponentUI components that make up this application
Uses APIAPIs this application consumes
Uses ServiceBackend services this application depends on
Uses StreamMessage queues or event streams this application uses
Uses TechnologyTechnologies this application is built with
Has Read Access to Data SetData sets this application reads from
Has Write Access to Data SetData sets this application writes to
Has Acceptance CriteriaBusiness acceptance criteria for this application
Has Implementation Acceptance CriteriaTechnical implementation acceptance criteria
Has Risk / Assumption / IssueRisks, assumptions, and issues associated with this application
Uses Availability / Security / Performance / etc.Non-functional quality mechanisms applied to this application
Implements Business ReferenceReference documents or standards this application aligns with
Has Test DataTest data sets associated with this application
Has TaskTasks in the action tracker associated with this application
Last updated on