Understanding Concerns in ArchRepo
What are Concerns?
When building any solution, there are many different perspectives to consider. Think of it like planning a house renovation: the homeowner cares about aesthetics and functionality, the contractor focuses on construction schedules and materials, the electrician thinks about wiring and power, and the plumber concentrates on water systems. Each person has their own “concern” or viewpoint. In solution architecture, concerns work the same way.
They are different lenses through which you can view and organise information about your solution.
Each concern groups together related topics that matter to specific stakeholders or phases of your project.
By organising information this way, ArchRepo makes it easier to find what you need without getting overwhelmed by everything at once.
ArchRepo’s Eight Concerns
ArchRepo divides solution architecture into eight distinct concerns. Here’s what each one covers and why it matters:
🗓️ Project
What it covers: The project management side of your solution—how work gets planned, organised, and tracked.
Why it matters: This concern helps project managers, team leads, and stakeholders stay on top of delivery. It tracks who’s doing the work (delivery teams), when things need to happen (releases and milestones), what could go wrong (risks and issues), and important decisions that guide the project forward.
Key topics include: Delivery teams, releases, milestones, risks, assumptions, issues & blockers, project increments, tasks, design decisions, FAQs, artefacts, diagrams, and glossary terms.
💼 Business
What it covers: The business perspective—what the solution needs to achieve and how it supports business operations.
Why it matters: This concern ensures the solution delivers real business value. It captures what the business wants to achieve (outcomes), how people work (processes and roles), what information they need, and the functional requirements that must be met. It’s essential for business analysts, product owners, and business stakeholders.
Key topics include: Business outcomes, scenarios, requirements, organisational structure, business roles, processes, business information, use cases, references, acceptance criteria, business rules, and feature requests.
💻 Apps & Systems
What it covers: The application and system architecture—what software components make up the solution.
Why it matters: This concern helps developers, architects, and technical leads understand the structure of applications and systems. It defines what applications need to do (non-functional requirements), how users interact with them (UI components, application roles), and how different systems connect (APIs, services, streams).
Key topics include: Non-functional requirements, application roles, systems, applications, UI components, application patterns, reports, APIs, message queues/streams, back-end services, implementation acceptance criteria, and concepts/prototypes.
💾 Data
What it covers: Everything related to data—how it’s structured, stored, moved, and managed.
Why it matters: Data is the lifeblood of modern solutions. This concern helps data architects, database administrators, and developers understand what data exists, where it lives, how it flows between systems, and how it needs to be migrated or tested. Poor data management leads to integration problems and business disruption.
Key topics include: Business information, data flows, data sets, data stores, APIs, streams/message queues, test data, and data migration strategies.
🔧 Technology
What it covers: The technical foundation—what technologies, platforms, and infrastructure support the solution.
Why it matters: This concern helps infrastructure teams, DevOps engineers, and technical architects understand the technology stack. It covers quality characteristics (non-functional requirements), infrastructure environments, specific technologies being used, and how the solution handles observability, availability, scalability, recoverability, and security.
Key topics include: Non-functional requirements, infrastructure environments, technology catalogue, observability, availability, scalability, recoverability, and security mechanisms.
🔨 Build
What it covers: How the solution gets built—development processes, testing, and quality assurance.
Why it matters: This concern supports development teams by organising everything needed to build the solution successfully. It tracks what needs to be done (tasks), what success looks like (acceptance criteria), what test data is needed, and how to measure performance. It bridges the gap between requirements and working software.
Key topics include: Tasks, business acceptance criteria, implementation acceptance criteria, test data, environments (dev, test, staging), and performance metrics.
🚀 Transition
What it covers: The journey from old to new—how you move from the current state to the new solution.
Why it matters: Launching a new solution isn’t just about building it; it’s about successfully transitioning users, data, and operations. This concern helps release managers, change managers, and deployment teams plan and execute smooth transitions. Poor transition planning is a common cause of project failures.
Key topics include: Transition requirements, planned releases, data migration, deployment environments, and deployability mechanisms.
📊 Operations
What it covers: Keeping the solution running—how it’s monitored, maintained, and supported in production.
Why it matters: Solutions need to work reliably long after launch. This concern helps operations teams, site reliability engineers, and support staff understand how to monitor system health, respond to failures, scale under load, and maintain security. It ensures the solution remains stable and performs well in real-world conditions.
Key topics include: Non-functional requirements, production environments, failure mode analysis (FMEA), observability, availability, scalability, recoverability, performance metrics, and security.
Why These Eight Concerns?
ArchRepo organizes information into these eight concerns because:
- Stakeholder Focus: Different people need different information. Project managers need project details; developers need technical details; operations teams need operational details.
- Lifecycle Coverage: Solutions go through distinct phases—planning, designing, building, deploying, and operating. Each concern aligns with different lifecycle phases.
- Reduced Complexity: Instead of one overwhelming mass of information, concerns create manageable chunks that you can explore based on your current needs.
- Flexibility: Topics can appear in multiple concerns when relevant. For example, “Non-Functional Requirements” appears in Apps & Systems, Technology, and Operations because it matters to all three viewpoints.
- Complete Picture: Together, these eight concerns ensure nothing important gets forgotten—from initial business goals through to long-term operational support.
By organising your solution architecture this way, ArchRepo helps everyone find the information they need, when they need it, from the perspective that matters most to them.