Applications
What Is an Application in ArchRepo?
In ArchRepo, Application does not mean a smartphone app. It is a deliberately broad and generic term for any logical grouping of end-user functionality.
Examples of what an “Application” might represent in your solution:
- A full public-facing website
- A specific section or subdomain of a website (e.g. the customer self-service portal within a larger platform)
- A major feature area within a SaaS product (e.g. the reporting module, the admin console)
- A native mobile application (iOS or Android)
- A native desktop application
- An internal administration tool or back-office portal
- An embedded kiosk or terminal interface
You decide the appropriate level of granularity for your solution. Some teams document their entire web application as a single Application item. Others break it into several items — one per major functional area — when the areas have distinct users, access controls, or delivery timelines.
There is no single correct answer for how coarse or fine-grained your Application items should be. The right level is whichever gives you the most useful picture of who uses what, and what each part of your solution does.
Why Document Applications in an Architecture Repository?
Applications are where business intent meets technical delivery. Documenting them in ArchRepo creates the connective tissue between what the business needs and how it is built:
- Business traceability — link applications to the business processes, requirements, and outcomes they support; demonstrate that every piece of the solution has a clear business justification
- Dependency visibility — see which APIs, services, data sets, and technologies each application depends on
- Access design — link Application Roles to each application to document who can access what, at what level
- Non-functional requirements — associate availability, security, performance, scalability, and other quality mechanisms directly with each application
- Acceptance criteria governance — link business and implementation acceptance criteria to the application, and optionally inherit shared criteria from Application Patterns
- Impact analysis — when a dependency changes, trace which applications are affected
Applications in ArchRepo
In ArchRepo, Applications are model items identified by an auto-generated reference in the format APP-1, APP-2, etc.
Applications support a full set of governance and lifecycle features:
- Status and transition states — track progress from design through to live and decommissioned
- Approval workflow — record formal sign-off before the application goes live
- Action tracker — a kanban-style view of tasks associated with the application
- Estimation — record effort estimates for planning purposes
- Data mapping — map the data the application reads and writes to the data model
The Purpose field classifies each application, making it easy to filter and organise your application landscape:
| Purpose | What it means |
|---|---|
| Primary Business Use Case | The application directly delivers a core business capability to end users |
| Secondary Business Use Case | Supports or enables a primary business capability |
| System Administration | For configuring and managing the system rather than using it |
| Data Administration | For managing data (e.g. reference data, lookups, bulk operations) |
| External | An application owned by a third party that the solution interfaces with |
Collection Views
The Applications collection includes two cross-reference matrix views:
- Business Processes — maps applications to the business processes they support, making it easy to verify that all processes have appropriate application coverage
- Apps v App Roles — maps applications to the Application Roles that have access to them, providing an overview of the access model
Application Patterns
Applications can follow one or more Application Patterns. A pattern defines shared standards — UI components, technologies, business rules, and acceptance criteria — that the application inherits automatically. Acceptance criteria linked to a pattern are displayed on every application that follows it, with no need to duplicate them.
Application Roles
Access to an application is documented by linking Application Roles to it. Each role specifies admin, write, or read access, making the access model explicit and traceable from the architecture documentation.
Fields Reference
See Application Fields for a description of each field and guidance on what to record.