Product Architecture Canvas (PAC)

Who is it for?

• Founder: Struggling to describe your product idea in a way a tech team can scope and estimate?
• Shared Vision: Missing a shared picture of the product, but a product backlog full of user stories?
• Team Friction: Wasting time due to different understanding of terminology, requirements, or complexity?
• Onboarding: Struggling to give new joiners a simple overview of how all fits together?

The Product Architecture Canvas (PAC) is a living one-page summary of your digital product to help everyone understand WHAT their product needs to do for WHOM and HOW it delivers these value propositions. It aligns the teams delivering a product's desirability, feasibility, and viability through a shared language.

From startup to large corporate teams, it allows business owners, designers, developers, testers, business analysts, DevOps, marketing, or customer support teams to have a shared understanding of their digital product.

What is it?

Six blocks that cover conceptually who interacts with your product (Users and External Systems), what they do (Actions) and what they need to see (Reports), what data your product represents and manages (Business Objects) and what Non-Functional Requirements need to be considered:

1. Actors: User Roles and External Systems: Describes the Actors as User Roles (and their agents) and External Systems that interact with your product by triggering Actions, reading or supplying data. Group these by organisation, connect their Value Propositions, revenue- or cost-models, and access rights.
2. Business Objects: Describes the key Business Objects needed to represent the domain and their relationships through a Domain Model. Break these down into detailed data schema (e.g. Entity-Relationship Models or Property Graphs) and Data Architecture Diagrams to define data lifecycle, data access, and data persistence in more detail.
3. Interactions: Actions and Reports: Describes the key Actions taken and Reports consumed by the various Actors.
   Actions are the interactive ways Actors engage with the system as part of the service journeys and grouped into Use Cases and Capabilities to be delivered by functional Modules. Actions can be defined through Business Process Maps or similar sequence and orchestration diagrams defining process and screen flows, API architectures and access controls.
   Reports are read-only views on system activities taken and drive the instrumentation and logging to deliver Audit Reports, Usage Reports, and Status Reports used to inform or notify Actors so they can take follow-up actions as they deem fit.
4. Non-Functional Requirements: Describes the key non-functional requirements for security, compliance, performance, scale, infrastructure, etc. in terms of orders of magnitude to keep in mind when designing the system. Using the ISO/IEC 25010 standard is a good start, specifically focussing on Performance Efficiency, Compatibility, Interaction Capability, Reliability, Security and any other requirements.

Where does it fit?

The Product Architecture Canvas (PAC) pairs well with the Business Model Canvas (BMC) or Lean Canvas, to scope the product and align your Product Triangle of Desirability, Feasibility and Viability. It works together with Wardley Maps to recognise which functionality and modules to buy and not to build. It provides agile teams with a skeleton and scope for the work, which is sequenced and shaped via Product Backlog and User Story Maps, or Shape Up.

Technical teams can use tools like C4, DDD, arc42, TOGAF and ArchiMate to flesh out work into detail. And product teams can use Event Storming sessions to create, and the canvas to capture and maintain the team's alignment on product.

Who made it?

The Product Architecture Canvas (PAC) is free and the result of more than a decade of work analysing, scoping, solutioning and designing digital products, platforms, and systems: For business owners with a conceptual idea needing to be developed (0→1), organisations needing processes digitised and reimagined, or large corporate teams maintaining and developing established complex systems:

• Digital products like a meeting room booking system, wealth management portal, etc.
• Digital platforms like a digital patient record and care orchestration, KYC portals, digital banking and payroll solution, etc.
• Digital systems like medical device licensing system, production performance monitoring and collaboration system, etc.

The canvas was developed by Wolfgang MAEHR.

Special thanks to Mark GLIKSON, Marcos PINEDO, Maish NICHANI, Vasu KOLLA, Cherie LECK and Vignesh MANU for their contributions, discussions and feedback to this work.