{ "source": { "repository": "https://github.com/APIOpsCycles/apiops-cycles-method-data", "commit": "ff0c7bd82485e4aa0d04d36ad23bfd7144bc2a41" }, "locales": [ "en", "fi", "fr", "de", "pt" ], "defaultLocale": "en", "translations": { "en": [ { "id": "capability-productization-cycle:question-template-markdown", "cycleId": "capability-productization-cycle", "kind": "questions", "format": "markdown", "title": "Capability Productization Cycle question template Markdown", "body": "# Capability Productization Cycle question template\n\nA cycle for defining and productizing reusable digital capabilities without assuming the implementation style in advance.\n\nUse this template to gather answers and evidence station by station. Canvas section prompts are listed first, followed by other related resources.\n\n## 1. Capability Strategy\n\nStart from customer journey, capability value, and viability evidence, then validate whether the proposed reusable digital capability should proceed.\n\n### Canvas questions\n#### Customer Journey Canvas\nWhat journey does the most external meaningful customer experience, and what should improve?\n- **Persona**: Who is the typical customer experiencing this journey?\n- **Customer Discovers Need**: How does the customer recognize their need or problem?\n- **Customer Need Is Resolved**: How is the customer's need ultimately resolved?\n- **Journey Steps**: What are the steps the customer takes in their journey?\n- **Pains**: What are the customer's pain points or challenges?\n- **Gains**: What are the customer's gains or benefits?\n- **Inputs & Outputs**: What are the inputs and outputs at each step?\n- **Interaction & Processing Rules**: What are the interaction and processing rules at each step?\n- **Improvement opportunities**: Which journey steps indicate that an underlying capability or process should be created, improved, automated, or removed?\n\n#### Capability Value Proposition Canvas\nWhich reusable capability would create value for consumers without deciding yet whether it should be delivered as an API, event, file, stream, data product, or another implementation style?\n- **Consumer tasks and outcomes**: What are consumers, partners, users, systems, or teams trying to achieve?\n- **Gain-enabling capability features**: What capability features would help consumers achieve better outcomes, speed, automation, insight, reach, or compliance?\n- **Pain-relieving capability features**: What capability features would remove friction, manual work, errors, delays, risk, or uncertainty for consumers?\n- **Reusable capabilities**: What reusable business or data capabilities could serve these tasks, gains, and pains across more than one consumer or use case?\n\n#### Capability Business Model Canvas\nHow viable, reusable, funded, owned, supported, and discoverable should this capability be?\n- **Capability value proposition**: What value does this reusable capability provide to consumers and to the organization or ecosystem?\n- **Capability consumer segments**: Who are the current and potential consumers of the capability, including teams, partners, systems, products, or data users?\n- **Consumer engagement**: How will consumers discover, evaluate, request, onboard, get support for, and provide feedback on the capability?\n- **Channels**: Through which catalogs, portals, marketplaces, documentation sites, support paths, or governance processes will consumers interact with the capability?\n- **Key resources**: Which systems, data assets, platforms, people, standards, funding, and operational capabilities are required?\n- **Key activities**: What must the capability owner and producers do to design, deliver, govern, support, and improve the capability?\n- **Key partners**: Which business, technology, data, security, legal, platform, or external partners are needed to make the capability work?\n- **Benefits**: What business, operational, ecosystem, reuse, compliance, or cost benefits justify the capability?\n- **Costs**: What are the significant costs of building, operating, governing, supporting, and evolving the capability?\n\n#### Capability Validation Canvas\nValidate whether a proposed reusable digital capability should proceed.\n- **Capability to validate**: Which proposed capability and reusable scope are being tested?\n- **Reused evidence**: Which earlier canvas outputs support the proposal?\n- **Critical assumptions**: What could invalidate value, reuse, ownership, sustainability, or adoption?\n- **Minimum validation**: What is the smallest useful validation and success threshold?\n- **Decision**: Proceed, narrow, revise and retest, or stop?\n\n### Before this station\n- [ ] Business goals are defined.\n- [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.\n\n### Ready to leave when\n- [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.\n- [ ] Business goals are defined.\n- [ ] Market research identifies capability opportunities.\n- [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.\n\n## 2. Consumer & Producer Commitments\n\nAgree mutual owner, producer, and consumer commitments for access, service, support, change, and lifecycle.\n\n### Canvas questions\n#### Capability Consumer & Producer Commitments Canvas\nAgree mutual commitments for providing and consuming a reusable capability.\n- **Selected consumers and use cases**: Which consumers and usage contexts are covered?\n- **Owner and producer commitments**: What will owners and producers provide, maintain, monitor, and support?\n- **Consumer responsibilities**: What must consumers do for appropriate use, access, testing, and feedback?\n- **Access and onboarding**: What discovery, approval, testing, and onboarding path is agreed?\n- **Service and lifecycle**: What service, change, deprecation, and retirement commitments are agreed?\n- **Open commitments**: What remains unresolved before architecture or delivery?\n\n### Before this station\n- [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.\n- [ ] Business goals are defined.\n- [ ] Market research identifies capability opportunities.\n- [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.\n\n### Ready to leave when\n- [ ] Capability opportunity is identified and documented.\n- [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The capability value proposition has been validated with business and consumer stakeholders.\n- [ ] Consumer segments are identified.\n- [ ] A high-level implementation roadmap is defined.\n\n### Other related resources\n- **Capability Consumer Onboarding Guide**: Guidance for helping consumers discover, evaluate, request access to, test, onboard, and begin using a reusable capability.\n- **Reusable Capability Service Expectations Guide**: Guidance for defining service quality, availability, timeliness, support, change, lifecycle, and consumer commitments.\n- **Capability Ownership and Producer Responsibilities Guide**: Guidance for defining business, capability, producer, operational, platform, and support ownership and commitments.\n\n## 3. Capability Architecture & Platform Decisions\n\nSelect the capability implementation style, architecture pattern, enabling platform, and governance model from evidence.\n\n### Canvas questions\n#### Business Impact Canvas\nWhat value, risk, operational, financial, customer, employee, compliance, and strategic impact is expected or at stake?\n- **Expected benefits**: What business, customer, employee, quality, speed, risk, compliance, or strategic benefits are expected?\n- **Operational efficiency impact**: How could work effort, waiting time, rework, throughput, reliability, support load, or operational cost change?\n- **Customer and employee impact**: How will customers, employees, partners, operators, or support teams experience the change?\n- **Financial impact**: What revenue, cost, investment, savings, loss avoidance, or funding impact is expected?\n- **Compliance and strategic impact**: What regulatory, contractual, policy, reputation, market, ecosystem, or strategic consequences matter?\n- **Impact of not proceeding**: What happens if the capability, automation, integration, or service is not improved or delivered?\n- **Risks and criticality**: What availability, security, data, safety, process, adoption, or business continuity risks could affect the outcome?\n- **Mitigations and decision impact**: Which mitigations, constraints, trade-offs, or residual risks should influence prioritization, architecture, rollout, or readiness decisions?\n\n#### Location Canvas\nWhat geopolitical, regulatory, network, and trust boundaries affect this capability or integration?\n- **Location / Trust Groups**: What are the relevant geopolitical, regulatory, network, or trust groups?\n- **Group Characteristics**: What are the characteristics of those groups, such as residency, trust level, or network exposure?\n- **Relevant Locations / Zones**: What are the relevant locations, zones, or environments within each group?\n- **Location / Zone Characteristics**: What are the characteristics of those locations or zones, such as ownership, region, or exposure?\n- **Network / Regulatory Distances**: What latency, trust, regulatory, or connectivity distances exist between the locations?\n- **Distance Characteristics**: What are the characteristics of those distances, such as latency sensitivity, residency constraints, or trust boundaries?\n- **Connectivity Endpoints**: What connectivity endpoints or interfaces are associated with the locations?\n- **Endpoint Access Characteristics**: What are the characteristics of those endpoints, such as exposure, protocol, security, or access restrictions?\n\n#### Capacity Canvas\nHow much demand, load, timing, and scaling capacity must be understood for the capability, automation, integration, or service?\n- **Current Business Volumes**: What are the current business volumes and transaction rates?\n- **Future Consumption Trends**: What are the anticipated future consumption trends?\n- **Peak Load and Availability Requirements**: What are the peak load and availability requirements?\n- **Caching Strategies**: What caching strategies can be used to optimize performance?\n- **Rate Limiting Strategies**: What rate limiting strategies can be used to manage consumption?\n- **Scaling Strategies**: What scaling strategies can be used to accommodate growth?\n\n#### Capability Architecture Decision Canvas\nChoose how the capability will be delivered using evidence already gathered.\n- **Reused inputs**: Which earlier decisions and constraints shape the implementation choice?\n- **Viable options**: Which API, event, workflow, application, data product, shared service, human service, or hybrid options remain viable?\n- **Selected approach**: Which implementation style and enabling platform are selected?\n- **Decision rationale**: Why does the selected approach fit best?\n- **Rejected alternatives**: Which serious alternatives were rejected, and why?\n- **Open risks**: What still needs validation before delivery or release?\n\n### Before this station\n- [ ] Capability opportunity is identified and documented.\n- [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The capability value proposition has been validated with business and consumer stakeholders.\n- [ ] Consumer segments are identified.\n- [ ] A high-level implementation roadmap is defined.\n\n### Ready to leave when\n- [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The capability value proposition has been validated with business and consumer stakeholders.\n- [ ] Consumer segments are identified.\n- [ ] A high-level implementation roadmap is defined.\n\n## 4. Capability Solution & Interaction Design\n\nDesign how consumers access, interact with, receive, or use the capability through the selected implementation style.\n\n### Canvas questions\n#### Domain Canvas\nWhat are the core entities and business rules related to this capability or domain?\n- **Selected Customer Journey Steps**: Which customer journey steps are relevant to this domain?\n- **Core Entities & Business Meaning**: What are the core entities and their business meaning?\n- **Attributes & Business Importance**: What are the key attributes of each entity and their business importance?\n- **Relationships Between Entities**: What are the relationships between the entities?\n- **Business, Compliance & Integrity Rules**: What are the business, compliance, and integrity rules related to the entities?\n- **Security & Privacy Considerations**: What are the security and privacy considerations related to the entities?\n\n#### Capability Solution Design Canvas\nRefine the selected implementation style into a clear consumer-facing capability design.\n- **Selected inputs**: Which earlier journey, value, domain, commitment, and architecture decisions are reused?\n- **Boundary and interaction**: What belongs inside the capability, and how do consumers use it?\n- **Contract, rules, and outcomes**: What behavior, responsibilities, inputs, outputs, and outcomes are promised?\n- **Errors and security**: How are exceptions, access, privacy, and trust handled?\n- **Lifecycle and support**: How will change, versioning, support, deprecation, and retirement work?\n- **Observability**: What health, usage, quality, value, and consumer signals must be visible?\n\n#### Interaction Canvas\nWhat kinds of interactions should this capability support before choosing a protocol-specific design?\n- **CRUD Interactions**: Are CRUD (Create, Read, Update, Delete) interactions needed here?\n- **CRUD Input & Output Models**: What are the input and output models for the CRUD interactions, if this style is needed?\n- **CRUD Processing & Validation**: What are the processing and validation rules for the CRUD interactions, if this style is needed?\n- **Query-Driven Interactions**: What read or query interactions are needed to answer consumer questions?\n- **Query-Driven Input & Output Models**: What are the input and output models for the query-driven interactions?\n- **Query-Driven Processing & Validation**: What are the processing and validation rules for the query-driven interactions?\n- **Command-Driven Interactions**: What state-changing commands are needed, if any?\n- **Command-Driven Input & Output Models**: What are the input and output models for the command-driven interactions, if this style is needed?\n- **Command-Driven Processing & Validation**: What are the processing and validation rules for the command-driven interactions, if this style is needed?\n- **Event-Driven Interactions**: What events need to be published or consumed, if any?\n- **Event-Driven Input & Output Models**: What are the input and output models for the event-driven interactions, if this style is needed?\n- **Event-Driven Processing & Validation**: What are the processing and validation rules for the event-driven interactions, if this style is needed?\n\n### Before this station\n- [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The capability value proposition has been validated with business and consumer stakeholders.\n- [ ] Consumer segments are identified.\n- [ ] A high-level implementation roadmap is defined.\n\n### Ready to leave when\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface design follows agreed design standards and conventions.\n\n### Other related resources\n- **Contract-First Capability Design**: Guidance for validating capability contracts before delivery, including API contracts, event schemas, file schemas, data contracts, service agreements, workflow inputs and outputs, and user-facing service promises.\n\n## 5. Capability Delivery & Operations\n\nDeliver and operate the reusable capability using implementation-style-appropriate engineering, testing, security, release, support, and operational ownership practices.\n\n### Canvas questions\n#### Capability Readiness & Operations Canvas\nPrepare the minimum operating evidence needed before capability readiness review.\n- **Ownership**: Who owns value, the capability lifecycle, production, operations, support, and changes?\n- **Environments and access**: Are required environments, access, permissions, and credentials ready?\n- **Test evidence**: What proves outcomes, quality, security, compatibility, resilience, and consumer usability?\n- **Monitoring and support**: How will health, usage, value, incidents, consumers, and operators be supported?\n- **Continuity and recovery**: How will service continue, degrade safely, recover, or fall back?\n- **Readiness status**: Are service definitions, runbooks, risks, conditions, and blocking gaps clear?\n\n### Before this station\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface design follows agreed design standards and conventions.\n\n### Ready to leave when\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface design follows agreed design standards and conventions.\n\n### Other related resources\n- **Capability Delivery Guide**: Guidance for selecting implementation-style-appropriate engineering, configuration, validation, release, and operational practices.\n- **Capability Testing and Validation Guide**: Guidance for validating expected outcomes, contracts or service definitions, quality, security, compatibility, resilience, and consumer usability.\n- **Capability CI/CD and Release Guide**: Guidance for release automation when the selected implementation style includes deployable software, configuration, contracts, or infrastructure.\n- **Capability Operational Ownership Guide**: Guidance for assigning runtime health, incident, support, recovery, change, and lifecycle ownership for a reusable capability.\n- **Capability Security and Access Guide**: Guidance for defining identity, access, confidentiality, privacy, consent, retention, audit, and trust controls for a reusable capability.\n- **Capability Support and Lifecycle Guide**: Guidance for support paths, change communication, service status, lifecycle expectations, deprecation, retirement, and improvement handling.\n\n## 6. Capability Readiness Assurance\n\nReview capability readiness using evidence from solution design, contract or service definition, testing, operations, permissions, monitoring, support, fallback, lifecycle, risk, and ownership before release.\n\n### Station questions\n- Review the completed design, test evidence, operating model, permissions, credentials, monitoring, support, fallback, and rollback arrangements.\n- Verify that known risks, exceptions, unsafe actions, human oversight, compliance requirements, and unresolved assumptions have been addressed or explicitly accepted.\n- Record blocking findings, accepted residual risks, release conditions, and required remediation actions.\n- Decide whether the release is ready, ready with conditions, requires remediation, or is not approved.\n- Record the decision owner, decision date, and evidence used.\n- Confirm that nothing proceeds to release without clear business and operational ownership.\n- Use readiness evidence to make an explicit go, conditional-go, or no-go decision before production use.\n- A formal readiness decision prevents automation solutions from being released without clear evidence, accepted risks, remediation actions, and business and operational ownership.\n\n### Before this station\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface design follows agreed design standards and conventions.\n\n### Ready to leave when\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.\n- [ ] The interface design follows agreed design standards and conventions.\n- [ ] The interface contract has been validated and tested against functional and non-functional requirements.\n\n### Other related resources\n- **Capability Readiness Checklist**: A checklist for reviewing evidence, risks, ownership, service commitments, support, continuity, lifecycle arrangements, and release readiness.\n- **Capability Compliance and Governance Guide**: Guidance for compliance, policy, funding, ownership, data governance, auditability, and lifecycle governance of reusable capabilities.\n- **Capability Service Quality Checklist**: A checklist for assessing availability, quality, timeliness, support, continuity, consumer impact, and service expectations before release.\n\n## 7. Capability Publishing & Enablement\n\nPublish the reusable capability so intended consumers can discover it, understand its purpose and service expectations, request access, onboard, use it, and get support.\n\n### Station questions\n- Affected people and changed work: Who will use, operate, support, approve, consume, or be affected by the release, and what responsibilities, decisions, handoffs, or working practices will change?\n- Activation and rollout approach: How will access, permissions, pilot use, phased rollout, restricted groups, parallel operation, and rollout expansion be managed?\n- Enablement and support: What communication, training, operating instructions, and support paths are required?\n- Feedback and control: How will adoption, trust, actual use, issues, and unexpected behavior be monitored, and what conditions trigger pause, rollback, or return to manual operation?\n- Plan rollout, enablement, support, feedback, and rollback so released solutions can be adopted safely.\n- Automation solutions only create value after rollout when affected people and consuming systems understand what changes, how access and operation work, where to get support, and when rollout should pause, expand, or roll back.\n\n### Before this station\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.\n- [ ] The interface design follows agreed design standards and conventions.\n- [ ] The interface contract has been validated and tested against functional and non-functional requirements.\n\n### Ready to leave when\n- [ ] The solution passes quality, security, compliance, and readiness checks.\n- [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.\n- [ ] The capability is ready to be published or released through the selected delivery mechanism.\n- [ ] Consumer-facing documentation and onboarding materials are ready.\n\n### Other related resources\n- **Capability Publishing and Discovery Guide**: Guidance for publishing capability purpose, value, ownership, lifecycle status, usage conditions, examples, limitations, dependencies, access, and support.\n- **Capability Consumer Onboarding Guide**: Guidance for helping consumers discover, evaluate, request access to, test, onboard, and begin using a reusable capability.\n- **Capability Service Agreement Template**: A template for documenting reusable capability service expectations, responsibilities, support model, quality commitments, lifecycle rules, and consumer obligations.\n- **Capability Versioning and Lifecycle Guide**: Guidance for capability change, compatibility, migration, versioning, deprecation, retirement, and consumer communication.\n\n## 8. Capability Monitoring & Improvement\n\nMonitor capability value, outcomes, adoption, reuse, service health, consumer experience, cost, sustainability, and lifecycle improvement needs.\n\n### Station questions\n- Outcomes and value: Are the expected process, user, and business outcomes being achieved?\n- Operational performance: What do successful runs, failures, partial completions, exceptions, retries, timeouts, interventions, processing time, waiting time, and cost show?\n- User, risk, and recovery signals: What errors, corrections, unsafe actions, bypassing, mistrust, support needs, fallback events, or recovery failures are occurring?\n- Learning and lifecycle decision: Which hypothesis assumptions were supported or rejected, and should the solution be improved, expanded, restricted, redesigned, paused, or retired?\n- Use operational, user, risk, and value evidence to decide what to improve, expand, restrict, pause, or retire.\n- Released solutions need evidence to show whether expected outcomes are being achieved, where manual intervention or recovery is still needed, and what lifecycle decision should be made next.\n\n### Before this station\n- [ ] The solution passes quality, security, compliance, and readiness checks.\n- [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.\n- [ ] The capability is ready to be published or released through the selected delivery mechanism.\n- [ ] Consumer-facing documentation and onboarding materials are ready.\n\n### Ready to leave when\n- [ ] Consumer-facing documentation and onboarding materials are ready.\n- [ ] Consumer onboarding, support, and communication processes are ready.\n- [ ] Legal, privacy, and compliance requirements for publishing or release are defined and understood.\n\n### Other related resources\n- **Capability Monitoring and Value Metrics**: Guidance for measuring value, outcomes, adoption, reuse, service health, consumer experience, cost, sustainability, and lifecycle fitness.\n- **Capability Adoption and Reuse Guide**: Guidance for tracking consumer adoption, reuse growth, duplicate capability creation, onboarding friction, and reuse barriers.\n- **Capability Consumer Feedback Guide**: Guidance for collecting consumer feedback, support needs, improvement requests, abandonment signals, and evidence of consumer success.\n- **Capability Lifecycle Management Guide**: Guidance for deciding whether to improve, expand, consolidate, standardize, replace, deprecate, or retire a reusable capability." }, { "id": "capability-productization-cycle:question-template-confluence-wiki", "cycleId": "capability-productization-cycle", "kind": "questions", "format": "confluence-wiki", "title": "Capability Productization Cycle question template Confluence wiki", "body": "h1. Capability Productization Cycle question template\n\nA cycle for defining and productizing reusable digital capabilities without assuming the implementation style in advance.\n\nUse this template to gather answers and evidence station by station. Canvas section prompts are listed first, followed by other related resources.\n\nh2. 1. Capability Strategy\n\nStart from customer journey, capability value, and viability evidence, then validate whether the proposed reusable digital capability should proceed.\n\nh3. Canvas questions\nh4. Customer Journey Canvas\nWhat journey does the most external meaningful customer experience, and what should improve?\n* *Persona*: Who is the typical customer experiencing this journey?\n* *Customer Discovers Need*: How does the customer recognize their need or problem?\n* *Customer Need Is Resolved*: How is the customer's need ultimately resolved?\n* *Journey Steps*: What are the steps the customer takes in their journey?\n* *Pains*: What are the customer's pain points or challenges?\n* *Gains*: What are the customer's gains or benefits?\n* *Inputs & Outputs*: What are the inputs and outputs at each step?\n* *Interaction & Processing Rules*: What are the interaction and processing rules at each step?\n* *Improvement opportunities*: Which journey steps indicate that an underlying capability or process should be created, improved, automated, or removed?\n\nh4. Capability Value Proposition Canvas\nWhich reusable capability would create value for consumers without deciding yet whether it should be delivered as an API, event, file, stream, data product, or another implementation style?\n* *Consumer tasks and outcomes*: What are consumers, partners, users, systems, or teams trying to achieve?\n* *Gain-enabling capability features*: What capability features would help consumers achieve better outcomes, speed, automation, insight, reach, or compliance?\n* *Pain-relieving capability features*: What capability features would remove friction, manual work, errors, delays, risk, or uncertainty for consumers?\n* *Reusable capabilities*: What reusable business or data capabilities could serve these tasks, gains, and pains across more than one consumer or use case?\n\nh4. Capability Business Model Canvas\nHow viable, reusable, funded, owned, supported, and discoverable should this capability be?\n* *Capability value proposition*: What value does this reusable capability provide to consumers and to the organization or ecosystem?\n* *Capability consumer segments*: Who are the current and potential consumers of the capability, including teams, partners, systems, products, or data users?\n* *Consumer engagement*: How will consumers discover, evaluate, request, onboard, get support for, and provide feedback on the capability?\n* *Channels*: Through which catalogs, portals, marketplaces, documentation sites, support paths, or governance processes will consumers interact with the capability?\n* *Key resources*: Which systems, data assets, platforms, people, standards, funding, and operational capabilities are required?\n* *Key activities*: What must the capability owner and producers do to design, deliver, govern, support, and improve the capability?\n* *Key partners*: Which business, technology, data, security, legal, platform, or external partners are needed to make the capability work?\n* *Benefits*: What business, operational, ecosystem, reuse, compliance, or cost benefits justify the capability?\n* *Costs*: What are the significant costs of building, operating, governing, supporting, and evolving the capability?\n\nh4. Capability Validation Canvas\nValidate whether a proposed reusable digital capability should proceed.\n* *Capability to validate*: Which proposed capability and reusable scope are being tested?\n* *Reused evidence*: Which earlier canvas outputs support the proposal?\n* *Critical assumptions*: What could invalidate value, reuse, ownership, sustainability, or adoption?\n* *Minimum validation*: What is the smallest useful validation and success threshold?\n* *Decision*: Proceed, narrow, revise and retest, or stop?\n\nh3. Before this station\n* [ ] Business goals are defined.\n* [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.\n\nh3. Ready to leave when\n* [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.\n* [ ] Business goals are defined.\n* [ ] Market research identifies capability opportunities.\n* [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.\n\nh2. 2. Consumer & Producer Commitments\n\nAgree mutual owner, producer, and consumer commitments for access, service, support, change, and lifecycle.\n\nh3. Canvas questions\nh4. Capability Consumer & Producer Commitments Canvas\nAgree mutual commitments for providing and consuming a reusable capability.\n* *Selected consumers and use cases*: Which consumers and usage contexts are covered?\n* *Owner and producer commitments*: What will owners and producers provide, maintain, monitor, and support?\n* *Consumer responsibilities*: What must consumers do for appropriate use, access, testing, and feedback?\n* *Access and onboarding*: What discovery, approval, testing, and onboarding path is agreed?\n* *Service and lifecycle*: What service, change, deprecation, and retirement commitments are agreed?\n* *Open commitments*: What remains unresolved before architecture or delivery?\n\nh3. Before this station\n* [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.\n* [ ] Business goals are defined.\n* [ ] Market research identifies capability opportunities.\n* [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.\n\nh3. Ready to leave when\n* [ ] Capability opportunity is identified and documented.\n* [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The capability value proposition has been validated with business and consumer stakeholders.\n* [ ] Consumer segments are identified.\n* [ ] A high-level implementation roadmap is defined.\n\nh3. Other related resources\n* *Capability Consumer Onboarding Guide*: Guidance for helping consumers discover, evaluate, request access to, test, onboard, and begin using a reusable capability.\n* *Reusable Capability Service Expectations Guide*: Guidance for defining service quality, availability, timeliness, support, change, lifecycle, and consumer commitments.\n* *Capability Ownership and Producer Responsibilities Guide*: Guidance for defining business, capability, producer, operational, platform, and support ownership and commitments.\n\nh2. 3. Capability Architecture & Platform Decisions\n\nSelect the capability implementation style, architecture pattern, enabling platform, and governance model from evidence.\n\nh3. Canvas questions\nh4. Business Impact Canvas\nWhat value, risk, operational, financial, customer, employee, compliance, and strategic impact is expected or at stake?\n* *Expected benefits*: What business, customer, employee, quality, speed, risk, compliance, or strategic benefits are expected?\n* *Operational efficiency impact*: How could work effort, waiting time, rework, throughput, reliability, support load, or operational cost change?\n* *Customer and employee impact*: How will customers, employees, partners, operators, or support teams experience the change?\n* *Financial impact*: What revenue, cost, investment, savings, loss avoidance, or funding impact is expected?\n* *Compliance and strategic impact*: What regulatory, contractual, policy, reputation, market, ecosystem, or strategic consequences matter?\n* *Impact of not proceeding*: What happens if the capability, automation, integration, or service is not improved or delivered?\n* *Risks and criticality*: What availability, security, data, safety, process, adoption, or business continuity risks could affect the outcome?\n* *Mitigations and decision impact*: Which mitigations, constraints, trade-offs, or residual risks should influence prioritization, architecture, rollout, or readiness decisions?\n\nh4. Location Canvas\nWhat geopolitical, regulatory, network, and trust boundaries affect this capability or integration?\n* *Location / Trust Groups*: What are the relevant geopolitical, regulatory, network, or trust groups?\n* *Group Characteristics*: What are the characteristics of those groups, such as residency, trust level, or network exposure?\n* *Relevant Locations / Zones*: What are the relevant locations, zones, or environments within each group?\n* *Location / Zone Characteristics*: What are the characteristics of those locations or zones, such as ownership, region, or exposure?\n* *Network / Regulatory Distances*: What latency, trust, regulatory, or connectivity distances exist between the locations?\n* *Distance Characteristics*: What are the characteristics of those distances, such as latency sensitivity, residency constraints, or trust boundaries?\n* *Connectivity Endpoints*: What connectivity endpoints or interfaces are associated with the locations?\n* *Endpoint Access Characteristics*: What are the characteristics of those endpoints, such as exposure, protocol, security, or access restrictions?\n\nh4. Capacity Canvas\nHow much demand, load, timing, and scaling capacity must be understood for the capability, automation, integration, or service?\n* *Current Business Volumes*: What are the current business volumes and transaction rates?\n* *Future Consumption Trends*: What are the anticipated future consumption trends?\n* *Peak Load and Availability Requirements*: What are the peak load and availability requirements?\n* *Caching Strategies*: What caching strategies can be used to optimize performance?\n* *Rate Limiting Strategies*: What rate limiting strategies can be used to manage consumption?\n* *Scaling Strategies*: What scaling strategies can be used to accommodate growth?\n\nh4. Capability Architecture Decision Canvas\nChoose how the capability will be delivered using evidence already gathered.\n* *Reused inputs*: Which earlier decisions and constraints shape the implementation choice?\n* *Viable options*: Which API, event, workflow, application, data product, shared service, human service, or hybrid options remain viable?\n* *Selected approach*: Which implementation style and enabling platform are selected?\n* *Decision rationale*: Why does the selected approach fit best?\n* *Rejected alternatives*: Which serious alternatives were rejected, and why?\n* *Open risks*: What still needs validation before delivery or release?\n\nh3. Before this station\n* [ ] Capability opportunity is identified and documented.\n* [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The capability value proposition has been validated with business and consumer stakeholders.\n* [ ] Consumer segments are identified.\n* [ ] A high-level implementation roadmap is defined.\n\nh3. Ready to leave when\n* [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The capability value proposition has been validated with business and consumer stakeholders.\n* [ ] Consumer segments are identified.\n* [ ] A high-level implementation roadmap is defined.\n\nh2. 4. Capability Solution & Interaction Design\n\nDesign how consumers access, interact with, receive, or use the capability through the selected implementation style.\n\nh3. Canvas questions\nh4. Domain Canvas\nWhat are the core entities and business rules related to this capability or domain?\n* *Selected Customer Journey Steps*: Which customer journey steps are relevant to this domain?\n* *Core Entities & Business Meaning*: What are the core entities and their business meaning?\n* *Attributes & Business Importance*: What are the key attributes of each entity and their business importance?\n* *Relationships Between Entities*: What are the relationships between the entities?\n* *Business, Compliance & Integrity Rules*: What are the business, compliance, and integrity rules related to the entities?\n* *Security & Privacy Considerations*: What are the security and privacy considerations related to the entities?\n\nh4. Capability Solution Design Canvas\nRefine the selected implementation style into a clear consumer-facing capability design.\n* *Selected inputs*: Which earlier journey, value, domain, commitment, and architecture decisions are reused?\n* *Boundary and interaction*: What belongs inside the capability, and how do consumers use it?\n* *Contract, rules, and outcomes*: What behavior, responsibilities, inputs, outputs, and outcomes are promised?\n* *Errors and security*: How are exceptions, access, privacy, and trust handled?\n* *Lifecycle and support*: How will change, versioning, support, deprecation, and retirement work?\n* *Observability*: What health, usage, quality, value, and consumer signals must be visible?\n\nh4. Interaction Canvas\nWhat kinds of interactions should this capability support before choosing a protocol-specific design?\n* *CRUD Interactions*: Are CRUD (Create, Read, Update, Delete) interactions needed here?\n* *CRUD Input & Output Models*: What are the input and output models for the CRUD interactions, if this style is needed?\n* *CRUD Processing & Validation*: What are the processing and validation rules for the CRUD interactions, if this style is needed?\n* *Query-Driven Interactions*: What read or query interactions are needed to answer consumer questions?\n* *Query-Driven Input & Output Models*: What are the input and output models for the query-driven interactions?\n* *Query-Driven Processing & Validation*: What are the processing and validation rules for the query-driven interactions?\n* *Command-Driven Interactions*: What state-changing commands are needed, if any?\n* *Command-Driven Input & Output Models*: What are the input and output models for the command-driven interactions, if this style is needed?\n* *Command-Driven Processing & Validation*: What are the processing and validation rules for the command-driven interactions, if this style is needed?\n* *Event-Driven Interactions*: What events need to be published or consumed, if any?\n* *Event-Driven Input & Output Models*: What are the input and output models for the event-driven interactions, if this style is needed?\n* *Event-Driven Processing & Validation*: What are the processing and validation rules for the event-driven interactions, if this style is needed?\n\nh3. Before this station\n* [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The capability value proposition has been validated with business and consumer stakeholders.\n* [ ] Consumer segments are identified.\n* [ ] A high-level implementation roadmap is defined.\n\nh3. Ready to leave when\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface design follows agreed design standards and conventions.\n\nh3. Other related resources\n* *Contract-First Capability Design*: Guidance for validating capability contracts before delivery, including API contracts, event schemas, file schemas, data contracts, service agreements, workflow inputs and outputs, and user-facing service promises.\n\nh2. 5. Capability Delivery & Operations\n\nDeliver and operate the reusable capability using implementation-style-appropriate engineering, testing, security, release, support, and operational ownership practices.\n\nh3. Canvas questions\nh4. Capability Readiness & Operations Canvas\nPrepare the minimum operating evidence needed before capability readiness review.\n* *Ownership*: Who owns value, the capability lifecycle, production, operations, support, and changes?\n* *Environments and access*: Are required environments, access, permissions, and credentials ready?\n* *Test evidence*: What proves outcomes, quality, security, compatibility, resilience, and consumer usability?\n* *Monitoring and support*: How will health, usage, value, incidents, consumers, and operators be supported?\n* *Continuity and recovery*: How will service continue, degrade safely, recover, or fall back?\n* *Readiness status*: Are service definitions, runbooks, risks, conditions, and blocking gaps clear?\n\nh3. Before this station\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface design follows agreed design standards and conventions.\n\nh3. Ready to leave when\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface design follows agreed design standards and conventions.\n\nh3. Other related resources\n* *Capability Delivery Guide*: Guidance for selecting implementation-style-appropriate engineering, configuration, validation, release, and operational practices.\n* *Capability Testing and Validation Guide*: Guidance for validating expected outcomes, contracts or service definitions, quality, security, compatibility, resilience, and consumer usability.\n* *Capability CI/CD and Release Guide*: Guidance for release automation when the selected implementation style includes deployable software, configuration, contracts, or infrastructure.\n* *Capability Operational Ownership Guide*: Guidance for assigning runtime health, incident, support, recovery, change, and lifecycle ownership for a reusable capability.\n* *Capability Security and Access Guide*: Guidance for defining identity, access, confidentiality, privacy, consent, retention, audit, and trust controls for a reusable capability.\n* *Capability Support and Lifecycle Guide*: Guidance for support paths, change communication, service status, lifecycle expectations, deprecation, retirement, and improvement handling.\n\nh2. 6. Capability Readiness Assurance\n\nReview capability readiness using evidence from solution design, contract or service definition, testing, operations, permissions, monitoring, support, fallback, lifecycle, risk, and ownership before release.\n\nh3. Station questions\n* Review the completed design, test evidence, operating model, permissions, credentials, monitoring, support, fallback, and rollback arrangements.\n* Verify that known risks, exceptions, unsafe actions, human oversight, compliance requirements, and unresolved assumptions have been addressed or explicitly accepted.\n* Record blocking findings, accepted residual risks, release conditions, and required remediation actions.\n* Decide whether the release is ready, ready with conditions, requires remediation, or is not approved.\n* Record the decision owner, decision date, and evidence used.\n* Confirm that nothing proceeds to release without clear business and operational ownership.\n* Use readiness evidence to make an explicit go, conditional-go, or no-go decision before production use.\n* A formal readiness decision prevents automation solutions from being released without clear evidence, accepted risks, remediation actions, and business and operational ownership.\n\nh3. Before this station\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface design follows agreed design standards and conventions.\n\nh3. Ready to leave when\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.\n* [ ] The interface design follows agreed design standards and conventions.\n* [ ] The interface contract has been validated and tested against functional and non-functional requirements.\n\nh3. Other related resources\n* *Capability Readiness Checklist*: A checklist for reviewing evidence, risks, ownership, service commitments, support, continuity, lifecycle arrangements, and release readiness.\n* *Capability Compliance and Governance Guide*: Guidance for compliance, policy, funding, ownership, data governance, auditability, and lifecycle governance of reusable capabilities.\n* *Capability Service Quality Checklist*: A checklist for assessing availability, quality, timeliness, support, continuity, consumer impact, and service expectations before release.\n\nh2. 7. Capability Publishing & Enablement\n\nPublish the reusable capability so intended consumers can discover it, understand its purpose and service expectations, request access, onboard, use it, and get support.\n\nh3. Station questions\n* Affected people and changed work: Who will use, operate, support, approve, consume, or be affected by the release, and what responsibilities, decisions, handoffs, or working practices will change?\n* Activation and rollout approach: How will access, permissions, pilot use, phased rollout, restricted groups, parallel operation, and rollout expansion be managed?\n* Enablement and support: What communication, training, operating instructions, and support paths are required?\n* Feedback and control: How will adoption, trust, actual use, issues, and unexpected behavior be monitored, and what conditions trigger pause, rollback, or return to manual operation?\n* Plan rollout, enablement, support, feedback, and rollback so released solutions can be adopted safely.\n* Automation solutions only create value after rollout when affected people and consuming systems understand what changes, how access and operation work, where to get support, and when rollout should pause, expand, or roll back.\n\nh3. Before this station\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.\n* [ ] The interface design follows agreed design standards and conventions.\n* [ ] The interface contract has been validated and tested against functional and non-functional requirements.\n\nh3. Ready to leave when\n* [ ] The solution passes quality, security, compliance, and readiness checks.\n* [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.\n* [ ] The capability is ready to be published or released through the selected delivery mechanism.\n* [ ] Consumer-facing documentation and onboarding materials are ready.\n\nh3. Other related resources\n* *Capability Publishing and Discovery Guide*: Guidance for publishing capability purpose, value, ownership, lifecycle status, usage conditions, examples, limitations, dependencies, access, and support.\n* *Capability Consumer Onboarding Guide*: Guidance for helping consumers discover, evaluate, request access to, test, onboard, and begin using a reusable capability.\n* *Capability Service Agreement Template*: A template for documenting reusable capability service expectations, responsibilities, support model, quality commitments, lifecycle rules, and consumer obligations.\n* *Capability Versioning and Lifecycle Guide*: Guidance for capability change, compatibility, migration, versioning, deprecation, retirement, and consumer communication.\n\nh2. 8. Capability Monitoring & Improvement\n\nMonitor capability value, outcomes, adoption, reuse, service health, consumer experience, cost, sustainability, and lifecycle improvement needs.\n\nh3. Station questions\n* Outcomes and value: Are the expected process, user, and business outcomes being achieved?\n* Operational performance: What do successful runs, failures, partial completions, exceptions, retries, timeouts, interventions, processing time, waiting time, and cost show?\n* User, risk, and recovery signals: What errors, corrections, unsafe actions, bypassing, mistrust, support needs, fallback events, or recovery failures are occurring?\n* Learning and lifecycle decision: Which hypothesis assumptions were supported or rejected, and should the solution be improved, expanded, restricted, redesigned, paused, or retired?\n* Use operational, user, risk, and value evidence to decide what to improve, expand, restrict, pause, or retire.\n* Released solutions need evidence to show whether expected outcomes are being achieved, where manual intervention or recovery is still needed, and what lifecycle decision should be made next.\n\nh3. Before this station\n* [ ] The solution passes quality, security, compliance, and readiness checks.\n* [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.\n* [ ] The capability is ready to be published or released through the selected delivery mechanism.\n* [ ] Consumer-facing documentation and onboarding materials are ready.\n\nh3. Ready to leave when\n* [ ] Consumer-facing documentation and onboarding materials are ready.\n* [ ] Consumer onboarding, support, and communication processes are ready.\n* [ ] Legal, privacy, and compliance requirements for publishing or release are defined and understood.\n\nh3. Other related resources\n* *Capability Monitoring and Value Metrics*: Guidance for measuring value, outcomes, adoption, reuse, service health, consumer experience, cost, sustainability, and lifecycle fitness.\n* *Capability Adoption and Reuse Guide*: Guidance for tracking consumer adoption, reuse growth, duplicate capability creation, onboarding friction, and reuse barriers.\n* *Capability Consumer Feedback Guide*: Guidance for collecting consumer feedback, support needs, improvement requests, abandonment signals, and evidence of consumer success.\n* *Capability Lifecycle Management Guide*: Guidance for deciding whether to improve, expand, consolidate, standardize, replace, deprecate, or retire a reusable capability." }, { "id": "api-productization-cycle:question-template-markdown", "cycleId": "api-productization-cycle", "kind": "questions", "format": "markdown", "title": "API Productization Cycle question template Markdown", "body": "# API Productization Cycle question template\n\nThe API-focused APIOps Cycles journey for productizing, designing, delivering, publishing, and improving APIs.\n\nUse this template to gather answers and evidence station by station. Canvas section prompts are listed first, followed by other related resources.\n\n## 1. API Product Strategy\n\nBefore building anything, define your API's value, users, and business goals from day one.\n\n### Canvas questions\n#### Customer Journey Canvas\nWhat journey does the most external meaningful customer experience, and what should improve?\n- **Persona**: Who is the typical customer experiencing this journey?\n- **Customer Discovers Need**: How does the customer recognize their need or problem?\n- **Customer Need Is Resolved**: How is the customer's need ultimately resolved?\n- **Journey Steps**: What are the steps the customer takes in their journey?\n- **Pains**: What are the customer's pain points or challenges?\n- **Gains**: What are the customer's gains or benefits?\n- **Inputs & Outputs**: What are the inputs and outputs at each step?\n- **Interaction & Processing Rules**: What are the interaction and processing rules at each step?\n- **Improvement opportunities**: Which journey steps indicate that an underlying capability or process should be created, improved, automated, or removed?\n\n#### Domain Canvas\nWhat are the core entities and business rules related to this capability or domain?\n- **Selected Customer Journey Steps**: Which customer journey steps are relevant to this domain?\n- **Core Entities & Business Meaning**: What are the core entities and their business meaning?\n- **Attributes & Business Importance**: What are the key attributes of each entity and their business importance?\n- **Relationships Between Entities**: What are the relationships between the entities?\n- **Business, Compliance & Integrity Rules**: What are the business, compliance, and integrity rules related to the entities?\n- **Security & Privacy Considerations**: What are the security and privacy considerations related to the entities?\n\n#### API Value Proposition Canvas\nHow does the customer journey map to APIs? What end-user and API consumer pains, and gains need to be addressed?\n- **Tasks**: What are the customers (end-users) trying to achieve?\n- **Gain Enabling Features**: What features enable end-users and API consumers to achieve gains?\n- **Pain Relieving Features**: What features help end-users and API consumers overcome pains?\n- **API Products**: What API products and features address the tasks, pains, and gains?\n\n#### API Business Model Canvas\nHow feasible and reusable will this API be? Do we have a business case from a cost - benefit point of view?\n- **API Value Proposition**: Start with one sticky note naming the API or API family, then capture what value the API offers to API consumers.\n- **API Consumer Segments**: Who are the target audiences for the API?\n- **Developer Relations**: How does the API provider reach and support API consumers?\n- **Channels**: Through which mechanisms do API consumers interact with the API?\n- **Key Resources**: What unique strategic assets must the API provider acquire or build?\n- **Key Activities**: What are the most important actions the API provider must take to operate successfully?\n- **Key Partners**: Who are the key stakeholders involved?\n- **Benefits**: What are the significant benefits or revenue streams generated by the API?\n- **Costs**: What are the significant costs involved in building, deploying, and operating the API?\n\n### Before this station\n- [ ] Capability opportunity is identified and documented.\n- [ ] Consumer segments are identified.\n\n### Ready to leave when\n- [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.\n- [ ] Business goals are defined.\n- [ ] Market research identifies capability opportunities.\n- [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.\n\n## 2. API Consumer Experience\n\nEnsure your API is discoverable, understandable, and usable — before and after launch.\n\n### Canvas questions\n#### API Value Proposition Canvas\nHow does the customer journey map to APIs? What end-user and API consumer pains, and gains need to be addressed?\n- **Tasks**: What are the customers (end-users) trying to achieve?\n- **Gain Enabling Features**: What features enable end-users and API consumers to achieve gains?\n- **Pain Relieving Features**: What features help end-users and API consumers overcome pains?\n- **API Products**: What API products and features address the tasks, pains, and gains?\n\n#### Customer Journey Canvas\nWhat journey does the most external meaningful customer experience, and what should improve?\n- **Persona**: Who is the typical customer experiencing this journey?\n- **Customer Discovers Need**: How does the customer recognize their need or problem?\n- **Customer Need Is Resolved**: How is the customer's need ultimately resolved?\n- **Journey Steps**: What are the steps the customer takes in their journey?\n- **Pains**: What are the customer's pain points or challenges?\n- **Gains**: What are the customer's gains or benefits?\n- **Inputs & Outputs**: What are the inputs and outputs at each step?\n- **Interaction & Processing Rules**: What are the interaction and processing rules at each step?\n- **Improvement opportunities**: Which journey steps indicate that an underlying capability or process should be created, improved, automated, or removed?\n\n### Before this station\n- [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.\n- [ ] Business goals are defined.\n- [ ] Market research identifies capability opportunities.\n- [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.\n\n### Ready to leave when\n- [ ] Capability opportunity is identified and documented.\n- [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The capability value proposition has been validated with business and consumer stakeholders.\n- [ ] Consumer segments are identified.\n- [ ] A high-level implementation roadmap is defined.\n\n### Other related resources\n- **API Onboarding Best Practices**: Best practices to streamline API consumer onboarding journeys with step-by-step registration, discovery, and first-call guidance.\n\n## 3. API Platform Architecture\n\nEnsure scalability, reuse, and governance across your API and platform components.\n\n### Canvas questions\n#### Business Impact Canvas\nWhat value, risk, operational, financial, customer, employee, compliance, and strategic impact is expected or at stake?\n- **Expected benefits**: What business, customer, employee, quality, speed, risk, compliance, or strategic benefits are expected?\n- **Operational efficiency impact**: How could work effort, waiting time, rework, throughput, reliability, support load, or operational cost change?\n- **Customer and employee impact**: How will customers, employees, partners, operators, or support teams experience the change?\n- **Financial impact**: What revenue, cost, investment, savings, loss avoidance, or funding impact is expected?\n- **Compliance and strategic impact**: What regulatory, contractual, policy, reputation, market, ecosystem, or strategic consequences matter?\n- **Impact of not proceeding**: What happens if the capability, automation, integration, or service is not improved or delivered?\n- **Risks and criticality**: What availability, security, data, safety, process, adoption, or business continuity risks could affect the outcome?\n- **Mitigations and decision impact**: Which mitigations, constraints, trade-offs, or residual risks should influence prioritization, architecture, rollout, or readiness decisions?\n\n#### Location Canvas\nWhat geopolitical, regulatory, network, and trust boundaries affect this capability or integration?\n- **Location / Trust Groups**: What are the relevant geopolitical, regulatory, network, or trust groups?\n- **Group Characteristics**: What are the characteristics of those groups, such as residency, trust level, or network exposure?\n- **Relevant Locations / Zones**: What are the relevant locations, zones, or environments within each group?\n- **Location / Zone Characteristics**: What are the characteristics of those locations or zones, such as ownership, region, or exposure?\n- **Network / Regulatory Distances**: What latency, trust, regulatory, or connectivity distances exist between the locations?\n- **Distance Characteristics**: What are the characteristics of those distances, such as latency sensitivity, residency constraints, or trust boundaries?\n- **Connectivity Endpoints**: What connectivity endpoints or interfaces are associated with the locations?\n- **Endpoint Access Characteristics**: What are the characteristics of those endpoints, such as exposure, protocol, security, or access restrictions?\n\n#### Capacity Canvas\nHow much demand, load, timing, and scaling capacity must be understood for the capability, automation, integration, or service?\n- **Current Business Volumes**: What are the current business volumes and transaction rates?\n- **Future Consumption Trends**: What are the anticipated future consumption trends?\n- **Peak Load and Availability Requirements**: What are the peak load and availability requirements?\n- **Caching Strategies**: What caching strategies can be used to optimize performance?\n- **Rate Limiting Strategies**: What rate limiting strategies can be used to manage consumption?\n- **Scaling Strategies**: What scaling strategies can be used to accommodate growth?\n\n### Before this station\n- [ ] Capability opportunity is identified and documented.\n- [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The capability value proposition has been validated with business and consumer stakeholders.\n- [ ] Consumer segments are identified.\n- [ ] A high-level implementation roadmap is defined.\n\n### Ready to leave when\n- [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The capability value proposition has been validated with business and consumer stakeholders.\n- [ ] Consumer segments are identified.\n- [ ] A high-level implementation roadmap is defined.\n\n### Other related resources\n- **API Metrics And Analytics**: A resource for defining, collecting, and analyzing API performance and usage data to align technical KPIs with business outcomes.\n\n## 4. API Design\n\nCreate API designs that are consistent, reusable, and grounded in business intent and shared standards.\n\n### Canvas questions\n#### Domain Canvas\nWhat are the core entities and business rules related to this capability or domain?\n- **Selected Customer Journey Steps**: Which customer journey steps are relevant to this domain?\n- **Core Entities & Business Meaning**: What are the core entities and their business meaning?\n- **Attributes & Business Importance**: What are the key attributes of each entity and their business importance?\n- **Relationships Between Entities**: What are the relationships between the entities?\n- **Business, Compliance & Integrity Rules**: What are the business, compliance, and integrity rules related to the entities?\n- **Security & Privacy Considerations**: What are the security and privacy considerations related to the entities?\n\n#### Interaction Canvas\nWhat kinds of interactions should this capability support before choosing a protocol-specific design?\n- **CRUD Interactions**: Are CRUD (Create, Read, Update, Delete) interactions needed here?\n- **CRUD Input & Output Models**: What are the input and output models for the CRUD interactions, if this style is needed?\n- **CRUD Processing & Validation**: What are the processing and validation rules for the CRUD interactions, if this style is needed?\n- **Query-Driven Interactions**: What read or query interactions are needed to answer consumer questions?\n- **Query-Driven Input & Output Models**: What are the input and output models for the query-driven interactions?\n- **Query-Driven Processing & Validation**: What are the processing and validation rules for the query-driven interactions?\n- **Command-Driven Interactions**: What state-changing commands are needed, if any?\n- **Command-Driven Input & Output Models**: What are the input and output models for the command-driven interactions, if this style is needed?\n- **Command-Driven Processing & Validation**: What are the processing and validation rules for the command-driven interactions, if this style is needed?\n- **Event-Driven Interactions**: What events need to be published or consumed, if any?\n- **Event-Driven Input & Output Models**: What are the input and output models for the event-driven interactions, if this style is needed?\n- **Event-Driven Processing & Validation**: What are the processing and validation rules for the event-driven interactions, if this style is needed?\n\n#### REST Canvas\nHow can the API be designed using RESTful principles?\n- **API Resources**: What are the key resources exposed by the API?\n- **API Resource Model**: What is the structure of the API resource model?\n- **API Verbs**: What HTTP verbs are used to interact with the API resources?\n- **API Verb Example**: Provide an example of an API request and response for each verb.\n\n#### Event Canvas\nWhat events are relevant to the integration capability, and how are they produced, consumed, processed, and governed?\n- **User Task / Trigger**: What user action or system event triggers this event operation?\n- **Input / Event Payload**: What data is included in the incoming event payload? Specify key attributes.\n- **Processing / Logic**: Describe the backend processing logic, including validations, transformations, or routing decisions.\n- **Output / Event Result**: What resulting event or acknowledgment is produced? Include attributes of the output payload.\n\n#### GraphQL Canvas\nHow can the API be designed using GraphQL principles?\n- **API Name**: What is the name of the GraphQL API or endpoint?\n- **Consumer Goals**: What problems are API consumers trying to solve? What data do they need?\n- **Key Types**: What are the core types exposed (e.g., User, Order, Product)?\n- **Relationships**: How do types relate to each other in nested queries?\n- **Queries**: What common queries should be supported?\n- **Mutations**: What operations will modify data (e.g., create, update, delete)?\n- **Subscriptions**: Are there any real-time updates or events consumers can subscribe to?\n- **Authorization Rules**: Who can access which fields or types?\n- **Consumer Constraints**: Are there pagination, filtering, or rate-limiting constraints?\n- **Notes / Open Questions**: Any pending decisions or integration considerations?\n\n### Before this station\n- [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The capability value proposition has been validated with business and consumer stakeholders.\n- [ ] Consumer segments are identified.\n- [ ] A high-level implementation roadmap is defined.\n\n### Ready to leave when\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface design follows agreed design standards and conventions.\n\n### Other related resources\n- **API Design Principles**: A concise guide to API usability, discoverability, and consistency grounded in shared design rules and real consumer needs.\n- **Contract-First Capability Design**: Guidance for validating capability contracts before delivery, including API contracts, event schemas, file schemas, data contracts, service agreements, workflow inputs and outputs, and user-facing service promises.\n\n## 5. API Delivery\n\nBuild, test, and release APIs using modern delivery pipelines and engineering best practices.\n\n### Station questions\n- Use API Development Best Practices as guidance for implementing the validated contract with established frameworks and libraries, ensuring the result is reusable and maintainable.\n- Build the API implementation from the validated contract using established frameworks, libraries, and team standards.\n- Test APIs for functionality, security, and performance using automated testing tools.\n- Use CI/CD pipelines to automate build, test, and deployment processes, ensuring consistent quality and traceability.\n- Ensure APIs meet security and compliance requirements through automated checks and audits.\n- Use the API Audit Checklist to ensure the API meets functional and non-functional requirements, including security, performance, and compliance.\n- Deliver coding frameworks, libraries, and standards for API implementation. Implement CI/CD pipelines, quality assurance frameworks, and deployment automation tools.\n- Even the best API designs fail if delivery is inconsistent. This station ensures your APIs are built with quality, tested thoroughly, and deployed reliably — enabling faster iterations and greater confidence.\n\n### Before this station\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface design follows agreed design standards and conventions.\n\n### Ready to leave when\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface design follows agreed design standards and conventions.\n\n### Other related resources\n- **API Development Best Practices**: Implementation guidance for turning a validated API interface contract into a consistent, maintainable API codebase using standard libraries, reusable patterns, and aligned development workflows.\n- **API Testing Best Practices**: Guidelines for implementing automated functional, performance, and security testing throughout the API lifecycle.\n- **APIOps CI/CD For APIs**: Deployment guidance that integrates API lifecycle tasks—design, testing, governance—into continuous integration and delivery pipelines.\n- **API Security Best Practices**: A set of actionable controls for securing APIs, including authentication, authorization, encryption, rate-limiting, and pipeline-level compliance checks.\n\n## 6. API Audit\n\nValidate that APIs meet business, design, and operational standards before release.\n\n### Station questions\n- Conduct audits to ensure APIs meet organizational, technical, and legal standards before release.\n- Use checklists, linters, and testing tools to verify consistency and conformance with standards.\n- Collaborate with governance teams and domain experts to ensure APIs are ready for production.\n- Establish a consistent audit process that evaluates API readiness across lifecycle stages using defined criteria, evidence, and standards. Ensure gaps are identified early and resolved before release.\n- APIs are long-lived products and must meet expectations for quality, consistency, and compliance. The audit connects design decisions, implementation, and operational readiness to defined standards, reducing risk before exposure.\n\n### Before this station\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface design follows agreed design standards and conventions.\n\n### Ready to leave when\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.\n- [ ] The interface design follows agreed design standards and conventions.\n- [ ] The interface contract has been validated and tested against functional and non-functional requirements.\n\n### Other related resources\n- **API Audit Checklist**: A lifecycle-based checklist to verify API readiness across design, delivery, publishing, and compliance using defined audit criteria and evidence.\n- **API Compliance Best Practices**: Ensure APIs meet legal, regulatory, and internal compliance through documentation, controls, and automated validations.\n\n## 7. API Publishing\n\nExpose APIs securely and clearly to the right audience with the right documentation and processes.\n\n### Station questions\n- Publish APIs to the appropriate gateways and environments to support reusability for multiple API consumers.\n- Document how consumers find and use the API, including onboarding processes and registration.\n- Ensure security models, gateway configuration, and legal terms are clear and accessible to consumers.\n- Enable APIs to be published to the relevant environment and have clear registration and access mechanisms (e.g., API keys, OAuth, subscription plans) depending on the API consumer segments and security and compliance requirements.\n- Publishing is more than deploying — it’s about discoverability, access, and support. If APIs aren't published correctly, they won’t be used, reused, or secured effectively.\n\n### Before this station\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.\n- [ ] The interface design follows agreed design standards and conventions.\n- [ ] The interface contract has been validated and tested against functional and non-functional requirements.\n\n### Ready to leave when\n- [ ] The solution passes quality, security, compliance, and readiness checks.\n- [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.\n- [ ] The capability is ready to be published or released through the selected delivery mechanism.\n- [ ] Consumer-facing documentation and onboarding materials are ready.\n\n### Other related resources\n- **APIOps CI/CD For APIs**: Deployment guidance that integrates API lifecycle tasks—design, testing, governance—into continuous integration and delivery pipelines.\n- **API Onboarding Best Practices**: Best practices to streamline API consumer onboarding journeys with step-by-step registration, discovery, and first-call guidance.\n- **API Audit Checklist**: A lifecycle-based checklist to verify API readiness across design, delivery, publishing, and compliance using defined audit criteria and evidence.\n\n## 8. API Monitoring & Improvement\n\nUse metrics and feedback to track API performance and drive continuous improvement.\n\n### Station questions\n- Monitor performance metrics (e.g., API calls, latency, error rates) and adoption metrics (e.g., NPS).\n- Analyze API usage metrics and incorporate user feedback into API iterations.\n- Establish a habit of reviewing metrics and planning continuous improvement activities.\n- Set up analytics frameworks to track performance and engagement. Develop feedback loops, analytics tools, and engagement strategies for APIs.\n- API delivery doesn’t stop at launch. Without monitoring, teams can’t improve adoption, performance, or ROI. This station ensures APIs remain useful, secure, and evolving with business needs.\n\n### Before this station\n- [ ] The solution passes quality, security, compliance, and readiness checks.\n- [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.\n- [ ] The capability is ready to be published or released through the selected delivery mechanism.\n- [ ] Consumer-facing documentation and onboarding materials are ready.\n\n### Ready to leave when\n- [ ] Consumer-facing documentation and onboarding materials are ready.\n- [ ] Consumer onboarding, support, and communication processes are ready.\n- [ ] Legal, privacy, and compliance requirements for publishing or release are defined and understood.\n\n### Other related resources\n- **API Metrics And Analytics**: A resource for defining, collecting, and analyzing API performance and usage data to align technical KPIs with business outcomes.\n- **API Community Engagement Strategies**: A playbook for fostering API adoption by cultivating communities through content, support channels, feedback loops, and social engagement strategies." }, { "id": "api-productization-cycle:question-template-confluence-wiki", "cycleId": "api-productization-cycle", "kind": "questions", "format": "confluence-wiki", "title": "API Productization Cycle question template Confluence wiki", "body": "h1. API Productization Cycle question template\n\nThe API-focused APIOps Cycles journey for productizing, designing, delivering, publishing, and improving APIs.\n\nUse this template to gather answers and evidence station by station. Canvas section prompts are listed first, followed by other related resources.\n\nh2. 1. API Product Strategy\n\nBefore building anything, define your API's value, users, and business goals from day one.\n\nh3. Canvas questions\nh4. Customer Journey Canvas\nWhat journey does the most external meaningful customer experience, and what should improve?\n* *Persona*: Who is the typical customer experiencing this journey?\n* *Customer Discovers Need*: How does the customer recognize their need or problem?\n* *Customer Need Is Resolved*: How is the customer's need ultimately resolved?\n* *Journey Steps*: What are the steps the customer takes in their journey?\n* *Pains*: What are the customer's pain points or challenges?\n* *Gains*: What are the customer's gains or benefits?\n* *Inputs & Outputs*: What are the inputs and outputs at each step?\n* *Interaction & Processing Rules*: What are the interaction and processing rules at each step?\n* *Improvement opportunities*: Which journey steps indicate that an underlying capability or process should be created, improved, automated, or removed?\n\nh4. Domain Canvas\nWhat are the core entities and business rules related to this capability or domain?\n* *Selected Customer Journey Steps*: Which customer journey steps are relevant to this domain?\n* *Core Entities & Business Meaning*: What are the core entities and their business meaning?\n* *Attributes & Business Importance*: What are the key attributes of each entity and their business importance?\n* *Relationships Between Entities*: What are the relationships between the entities?\n* *Business, Compliance & Integrity Rules*: What are the business, compliance, and integrity rules related to the entities?\n* *Security & Privacy Considerations*: What are the security and privacy considerations related to the entities?\n\nh4. API Value Proposition Canvas\nHow does the customer journey map to APIs? What end-user and API consumer pains, and gains need to be addressed?\n* *Tasks*: What are the customers (end-users) trying to achieve?\n* *Gain Enabling Features*: What features enable end-users and API consumers to achieve gains?\n* *Pain Relieving Features*: What features help end-users and API consumers overcome pains?\n* *API Products*: What API products and features address the tasks, pains, and gains?\n\nh4. API Business Model Canvas\nHow feasible and reusable will this API be? Do we have a business case from a cost - benefit point of view?\n* *API Value Proposition*: Start with one sticky note naming the API or API family, then capture what value the API offers to API consumers.\n* *API Consumer Segments*: Who are the target audiences for the API?\n* *Developer Relations*: How does the API provider reach and support API consumers?\n* *Channels*: Through which mechanisms do API consumers interact with the API?\n* *Key Resources*: What unique strategic assets must the API provider acquire or build?\n* *Key Activities*: What are the most important actions the API provider must take to operate successfully?\n* *Key Partners*: Who are the key stakeholders involved?\n* *Benefits*: What are the significant benefits or revenue streams generated by the API?\n* *Costs*: What are the significant costs involved in building, deploying, and operating the API?\n\nh3. Before this station\n* [ ] Capability opportunity is identified and documented.\n* [ ] Consumer segments are identified.\n\nh3. Ready to leave when\n* [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.\n* [ ] Business goals are defined.\n* [ ] Market research identifies capability opportunities.\n* [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.\n\nh2. 2. API Consumer Experience\n\nEnsure your API is discoverable, understandable, and usable — before and after launch.\n\nh3. Canvas questions\nh4. API Value Proposition Canvas\nHow does the customer journey map to APIs? What end-user and API consumer pains, and gains need to be addressed?\n* *Tasks*: What are the customers (end-users) trying to achieve?\n* *Gain Enabling Features*: What features enable end-users and API consumers to achieve gains?\n* *Pain Relieving Features*: What features help end-users and API consumers overcome pains?\n* *API Products*: What API products and features address the tasks, pains, and gains?\n\nh4. Customer Journey Canvas\nWhat journey does the most external meaningful customer experience, and what should improve?\n* *Persona*: Who is the typical customer experiencing this journey?\n* *Customer Discovers Need*: How does the customer recognize their need or problem?\n* *Customer Need Is Resolved*: How is the customer's need ultimately resolved?\n* *Journey Steps*: What are the steps the customer takes in their journey?\n* *Pains*: What are the customer's pain points or challenges?\n* *Gains*: What are the customer's gains or benefits?\n* *Inputs & Outputs*: What are the inputs and outputs at each step?\n* *Interaction & Processing Rules*: What are the interaction and processing rules at each step?\n* *Improvement opportunities*: Which journey steps indicate that an underlying capability or process should be created, improved, automated, or removed?\n\nh3. Before this station\n* [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.\n* [ ] Business goals are defined.\n* [ ] Market research identifies capability opportunities.\n* [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.\n\nh3. Ready to leave when\n* [ ] Capability opportunity is identified and documented.\n* [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The capability value proposition has been validated with business and consumer stakeholders.\n* [ ] Consumer segments are identified.\n* [ ] A high-level implementation roadmap is defined.\n\nh3. Other related resources\n* *API Onboarding Best Practices*: Best practices to streamline API consumer onboarding journeys with step-by-step registration, discovery, and first-call guidance.\n\nh2. 3. API Platform Architecture\n\nEnsure scalability, reuse, and governance across your API and platform components.\n\nh3. Canvas questions\nh4. Business Impact Canvas\nWhat value, risk, operational, financial, customer, employee, compliance, and strategic impact is expected or at stake?\n* *Expected benefits*: What business, customer, employee, quality, speed, risk, compliance, or strategic benefits are expected?\n* *Operational efficiency impact*: How could work effort, waiting time, rework, throughput, reliability, support load, or operational cost change?\n* *Customer and employee impact*: How will customers, employees, partners, operators, or support teams experience the change?\n* *Financial impact*: What revenue, cost, investment, savings, loss avoidance, or funding impact is expected?\n* *Compliance and strategic impact*: What regulatory, contractual, policy, reputation, market, ecosystem, or strategic consequences matter?\n* *Impact of not proceeding*: What happens if the capability, automation, integration, or service is not improved or delivered?\n* *Risks and criticality*: What availability, security, data, safety, process, adoption, or business continuity risks could affect the outcome?\n* *Mitigations and decision impact*: Which mitigations, constraints, trade-offs, or residual risks should influence prioritization, architecture, rollout, or readiness decisions?\n\nh4. Location Canvas\nWhat geopolitical, regulatory, network, and trust boundaries affect this capability or integration?\n* *Location / Trust Groups*: What are the relevant geopolitical, regulatory, network, or trust groups?\n* *Group Characteristics*: What are the characteristics of those groups, such as residency, trust level, or network exposure?\n* *Relevant Locations / Zones*: What are the relevant locations, zones, or environments within each group?\n* *Location / Zone Characteristics*: What are the characteristics of those locations or zones, such as ownership, region, or exposure?\n* *Network / Regulatory Distances*: What latency, trust, regulatory, or connectivity distances exist between the locations?\n* *Distance Characteristics*: What are the characteristics of those distances, such as latency sensitivity, residency constraints, or trust boundaries?\n* *Connectivity Endpoints*: What connectivity endpoints or interfaces are associated with the locations?\n* *Endpoint Access Characteristics*: What are the characteristics of those endpoints, such as exposure, protocol, security, or access restrictions?\n\nh4. Capacity Canvas\nHow much demand, load, timing, and scaling capacity must be understood for the capability, automation, integration, or service?\n* *Current Business Volumes*: What are the current business volumes and transaction rates?\n* *Future Consumption Trends*: What are the anticipated future consumption trends?\n* *Peak Load and Availability Requirements*: What are the peak load and availability requirements?\n* *Caching Strategies*: What caching strategies can be used to optimize performance?\n* *Rate Limiting Strategies*: What rate limiting strategies can be used to manage consumption?\n* *Scaling Strategies*: What scaling strategies can be used to accommodate growth?\n\nh3. Before this station\n* [ ] Capability opportunity is identified and documented.\n* [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The capability value proposition has been validated with business and consumer stakeholders.\n* [ ] Consumer segments are identified.\n* [ ] A high-level implementation roadmap is defined.\n\nh3. Ready to leave when\n* [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The capability value proposition has been validated with business and consumer stakeholders.\n* [ ] Consumer segments are identified.\n* [ ] A high-level implementation roadmap is defined.\n\nh3. Other related resources\n* *API Metrics And Analytics*: A resource for defining, collecting, and analyzing API performance and usage data to align technical KPIs with business outcomes.\n\nh2. 4. API Design\n\nCreate API designs that are consistent, reusable, and grounded in business intent and shared standards.\n\nh3. Canvas questions\nh4. Domain Canvas\nWhat are the core entities and business rules related to this capability or domain?\n* *Selected Customer Journey Steps*: Which customer journey steps are relevant to this domain?\n* *Core Entities & Business Meaning*: What are the core entities and their business meaning?\n* *Attributes & Business Importance*: What are the key attributes of each entity and their business importance?\n* *Relationships Between Entities*: What are the relationships between the entities?\n* *Business, Compliance & Integrity Rules*: What are the business, compliance, and integrity rules related to the entities?\n* *Security & Privacy Considerations*: What are the security and privacy considerations related to the entities?\n\nh4. Interaction Canvas\nWhat kinds of interactions should this capability support before choosing a protocol-specific design?\n* *CRUD Interactions*: Are CRUD (Create, Read, Update, Delete) interactions needed here?\n* *CRUD Input & Output Models*: What are the input and output models for the CRUD interactions, if this style is needed?\n* *CRUD Processing & Validation*: What are the processing and validation rules for the CRUD interactions, if this style is needed?\n* *Query-Driven Interactions*: What read or query interactions are needed to answer consumer questions?\n* *Query-Driven Input & Output Models*: What are the input and output models for the query-driven interactions?\n* *Query-Driven Processing & Validation*: What are the processing and validation rules for the query-driven interactions?\n* *Command-Driven Interactions*: What state-changing commands are needed, if any?\n* *Command-Driven Input & Output Models*: What are the input and output models for the command-driven interactions, if this style is needed?\n* *Command-Driven Processing & Validation*: What are the processing and validation rules for the command-driven interactions, if this style is needed?\n* *Event-Driven Interactions*: What events need to be published or consumed, if any?\n* *Event-Driven Input & Output Models*: What are the input and output models for the event-driven interactions, if this style is needed?\n* *Event-Driven Processing & Validation*: What are the processing and validation rules for the event-driven interactions, if this style is needed?\n\nh4. REST Canvas\nHow can the API be designed using RESTful principles?\n* *API Resources*: What are the key resources exposed by the API?\n* *API Resource Model*: What is the structure of the API resource model?\n* *API Verbs*: What HTTP verbs are used to interact with the API resources?\n* *API Verb Example*: Provide an example of an API request and response for each verb.\n\nh4. Event Canvas\nWhat events are relevant to the integration capability, and how are they produced, consumed, processed, and governed?\n* *User Task / Trigger*: What user action or system event triggers this event operation?\n* *Input / Event Payload*: What data is included in the incoming event payload? Specify key attributes.\n* *Processing / Logic*: Describe the backend processing logic, including validations, transformations, or routing decisions.\n* *Output / Event Result*: What resulting event or acknowledgment is produced? Include attributes of the output payload.\n\nh4. GraphQL Canvas\nHow can the API be designed using GraphQL principles?\n* *API Name*: What is the name of the GraphQL API or endpoint?\n* *Consumer Goals*: What problems are API consumers trying to solve? What data do they need?\n* *Key Types*: What are the core types exposed (e.g., User, Order, Product)?\n* *Relationships*: How do types relate to each other in nested queries?\n* *Queries*: What common queries should be supported?\n* *Mutations*: What operations will modify data (e.g., create, update, delete)?\n* *Subscriptions*: Are there any real-time updates or events consumers can subscribe to?\n* *Authorization Rules*: Who can access which fields or types?\n* *Consumer Constraints*: Are there pagination, filtering, or rate-limiting constraints?\n* *Notes / Open Questions*: Any pending decisions or integration considerations?\n\nh3. Before this station\n* [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The capability value proposition has been validated with business and consumer stakeholders.\n* [ ] Consumer segments are identified.\n* [ ] A high-level implementation roadmap is defined.\n\nh3. Ready to leave when\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface design follows agreed design standards and conventions.\n\nh3. Other related resources\n* *API Design Principles*: A concise guide to API usability, discoverability, and consistency grounded in shared design rules and real consumer needs.\n* *Contract-First Capability Design*: Guidance for validating capability contracts before delivery, including API contracts, event schemas, file schemas, data contracts, service agreements, workflow inputs and outputs, and user-facing service promises.\n\nh2. 5. API Delivery\n\nBuild, test, and release APIs using modern delivery pipelines and engineering best practices.\n\nh3. Station questions\n* Use API Development Best Practices as guidance for implementing the validated contract with established frameworks and libraries, ensuring the result is reusable and maintainable.\n* Build the API implementation from the validated contract using established frameworks, libraries, and team standards.\n* Test APIs for functionality, security, and performance using automated testing tools.\n* Use CI/CD pipelines to automate build, test, and deployment processes, ensuring consistent quality and traceability.\n* Ensure APIs meet security and compliance requirements through automated checks and audits.\n* Use the API Audit Checklist to ensure the API meets functional and non-functional requirements, including security, performance, and compliance.\n* Deliver coding frameworks, libraries, and standards for API implementation. Implement CI/CD pipelines, quality assurance frameworks, and deployment automation tools.\n* Even the best API designs fail if delivery is inconsistent. This station ensures your APIs are built with quality, tested thoroughly, and deployed reliably — enabling faster iterations and greater confidence.\n\nh3. Before this station\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface design follows agreed design standards and conventions.\n\nh3. Ready to leave when\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface design follows agreed design standards and conventions.\n\nh3. Other related resources\n* *API Development Best Practices*: Implementation guidance for turning a validated API interface contract into a consistent, maintainable API codebase using standard libraries, reusable patterns, and aligned development workflows.\n* *API Testing Best Practices*: Guidelines for implementing automated functional, performance, and security testing throughout the API lifecycle.\n* *APIOps CI/CD For APIs*: Deployment guidance that integrates API lifecycle tasks—design, testing, governance—into continuous integration and delivery pipelines.\n* *API Security Best Practices*: A set of actionable controls for securing APIs, including authentication, authorization, encryption, rate-limiting, and pipeline-level compliance checks.\n\nh2. 6. API Audit\n\nValidate that APIs meet business, design, and operational standards before release.\n\nh3. Station questions\n* Conduct audits to ensure APIs meet organizational, technical, and legal standards before release.\n* Use checklists, linters, and testing tools to verify consistency and conformance with standards.\n* Collaborate with governance teams and domain experts to ensure APIs are ready for production.\n* Establish a consistent audit process that evaluates API readiness across lifecycle stages using defined criteria, evidence, and standards. Ensure gaps are identified early and resolved before release.\n* APIs are long-lived products and must meet expectations for quality, consistency, and compliance. The audit connects design decisions, implementation, and operational readiness to defined standards, reducing risk before exposure.\n\nh3. Before this station\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface design follows agreed design standards and conventions.\n\nh3. Ready to leave when\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.\n* [ ] The interface design follows agreed design standards and conventions.\n* [ ] The interface contract has been validated and tested against functional and non-functional requirements.\n\nh3. Other related resources\n* *API Audit Checklist*: A lifecycle-based checklist to verify API readiness across design, delivery, publishing, and compliance using defined audit criteria and evidence.\n* *API Compliance Best Practices*: Ensure APIs meet legal, regulatory, and internal compliance through documentation, controls, and automated validations.\n\nh2. 7. API Publishing\n\nExpose APIs securely and clearly to the right audience with the right documentation and processes.\n\nh3. Station questions\n* Publish APIs to the appropriate gateways and environments to support reusability for multiple API consumers.\n* Document how consumers find and use the API, including onboarding processes and registration.\n* Ensure security models, gateway configuration, and legal terms are clear and accessible to consumers.\n* Enable APIs to be published to the relevant environment and have clear registration and access mechanisms (e.g., API keys, OAuth, subscription plans) depending on the API consumer segments and security and compliance requirements.\n* Publishing is more than deploying — it’s about discoverability, access, and support. If APIs aren't published correctly, they won’t be used, reused, or secured effectively.\n\nh3. Before this station\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.\n* [ ] The interface design follows agreed design standards and conventions.\n* [ ] The interface contract has been validated and tested against functional and non-functional requirements.\n\nh3. Ready to leave when\n* [ ] The solution passes quality, security, compliance, and readiness checks.\n* [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.\n* [ ] The capability is ready to be published or released through the selected delivery mechanism.\n* [ ] Consumer-facing documentation and onboarding materials are ready.\n\nh3. Other related resources\n* *APIOps CI/CD For APIs*: Deployment guidance that integrates API lifecycle tasks—design, testing, governance—into continuous integration and delivery pipelines.\n* *API Onboarding Best Practices*: Best practices to streamline API consumer onboarding journeys with step-by-step registration, discovery, and first-call guidance.\n* *API Audit Checklist*: A lifecycle-based checklist to verify API readiness across design, delivery, publishing, and compliance using defined audit criteria and evidence.\n\nh2. 8. API Monitoring & Improvement\n\nUse metrics and feedback to track API performance and drive continuous improvement.\n\nh3. Station questions\n* Monitor performance metrics (e.g., API calls, latency, error rates) and adoption metrics (e.g., NPS).\n* Analyze API usage metrics and incorporate user feedback into API iterations.\n* Establish a habit of reviewing metrics and planning continuous improvement activities.\n* Set up analytics frameworks to track performance and engagement. Develop feedback loops, analytics tools, and engagement strategies for APIs.\n* API delivery doesn’t stop at launch. Without monitoring, teams can’t improve adoption, performance, or ROI. This station ensures APIs remain useful, secure, and evolving with business needs.\n\nh3. Before this station\n* [ ] The solution passes quality, security, compliance, and readiness checks.\n* [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.\n* [ ] The capability is ready to be published or released through the selected delivery mechanism.\n* [ ] Consumer-facing documentation and onboarding materials are ready.\n\nh3. Ready to leave when\n* [ ] Consumer-facing documentation and onboarding materials are ready.\n* [ ] Consumer onboarding, support, and communication processes are ready.\n* [ ] Legal, privacy, and compliance requirements for publishing or release are defined and understood.\n\nh3. Other related resources\n* *API Metrics And Analytics*: A resource for defining, collecting, and analyzing API performance and usage data to align technical KPIs with business outcomes.\n* *API Community Engagement Strategies*: A playbook for fostering API adoption by cultivating communities through content, support channels, feedback loops, and social engagement strategies." }, { "id": "integration-productization-cycle:question-template-markdown", "cycleId": "integration-productization-cycle", "kind": "questions", "format": "markdown", "title": "Integration Productization Cycle question template Markdown", "body": "# Integration Productization Cycle question template\n\nA cycle for defining and productizing reusable integration capabilities without assuming the implementation style in advance.\n\nUse this template to gather answers and evidence station by station. Canvas section prompts are listed first, followed by other related resources.\n\n## 1. Integration Capability Strategy\n\nStart from customer journey, capability value, and viability evidence, then validate whether the proposed reusable integration capability should proceed.\n\n### Canvas questions\n#### Customer Journey Canvas\nWhat journey does the most external meaningful customer experience, and what should improve?\n- **Persona**: Who is the typical customer experiencing this journey?\n- **Customer Discovers Need**: How does the customer recognize their need or problem?\n- **Customer Need Is Resolved**: How is the customer's need ultimately resolved?\n- **Journey Steps**: What are the steps the customer takes in their journey?\n- **Pains**: What are the customer's pain points or challenges?\n- **Gains**: What are the customer's gains or benefits?\n- **Inputs & Outputs**: What are the inputs and outputs at each step?\n- **Interaction & Processing Rules**: What are the interaction and processing rules at each step?\n- **Improvement opportunities**: Which journey steps indicate that an underlying capability or process should be created, improved, automated, or removed?\n\n#### Capability Value Proposition Canvas\nWhich reusable capability would create value for consumers without deciding yet whether it should be delivered as an API, event, file, stream, data product, or another implementation style?\n- **Consumer tasks and outcomes**: What are consumers, partners, users, systems, or teams trying to achieve?\n- **Gain-enabling capability features**: What capability features would help consumers achieve better outcomes, speed, automation, insight, reach, or compliance?\n- **Pain-relieving capability features**: What capability features would remove friction, manual work, errors, delays, risk, or uncertainty for consumers?\n- **Reusable capabilities**: What reusable business or data capabilities could serve these tasks, gains, and pains across more than one consumer or use case?\n\n#### Capability Business Model Canvas\nHow viable, reusable, funded, owned, supported, and discoverable should this capability be?\n- **Capability value proposition**: What value does this reusable capability provide to consumers and to the organization or ecosystem?\n- **Capability consumer segments**: Who are the current and potential consumers of the capability, including teams, partners, systems, products, or data users?\n- **Consumer engagement**: How will consumers discover, evaluate, request, onboard, get support for, and provide feedback on the capability?\n- **Channels**: Through which catalogs, portals, marketplaces, documentation sites, support paths, or governance processes will consumers interact with the capability?\n- **Key resources**: Which systems, data assets, platforms, people, standards, funding, and operational capabilities are required?\n- **Key activities**: What must the capability owner and producers do to design, deliver, govern, support, and improve the capability?\n- **Key partners**: Which business, technology, data, security, legal, platform, or external partners are needed to make the capability work?\n- **Benefits**: What business, operational, ecosystem, reuse, compliance, or cost benefits justify the capability?\n- **Costs**: What are the significant costs of building, operating, governing, supporting, and evolving the capability?\n\n#### Integration Capability Validation Canvas\nValidate whether a proposed reusable integration capability should proceed.\n- **Capability to validate**: Which proposed integration capability and reuse scope are being tested?\n- **Reused evidence**: Which earlier canvas outputs support the proposal?\n- **Critical assumptions**: What could invalidate value, reuse, ownership, feasibility, or adoption?\n- **Validation step**: What is the smallest useful validation and success threshold?\n- **Decision**: Proceed, narrow, revise and retest, or stop?\n\n### Before this station\n- [ ] Business goals are defined.\n- [ ] Capability opportunity is identified and documented.\n\n### Ready to leave when\n- [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.\n- [ ] Business goals are defined.\n- [ ] Market research identifies capability opportunities.\n- [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.\n\n## 2. Integration Consumer & Provider Commitments\n\nAgree provider and consumer commitments for access, validation, service, failure handling, recovery, compatibility, and lifecycle.\n\n### Canvas questions\n#### Integration Consumer & Provider Commitments Canvas\nAgree the responsibilities needed to use and provide a reusable integration capability.\n- **Selected parties and use cases**: Which producers, providers, consumers, and use cases are covered?\n- **Provider commitments**: What will providers deliver, maintain, monitor, and support?\n- **Consumer commitments**: What must consumers test, protect, operate, and communicate?\n- **Access and validation**: How will access, environments, credentials, and conformance be handled?\n- **Failure and recovery**: Who handles failures, replay, duplicates, reconciliation, and recovery?\n- **Change and lifecycle**: How will compatibility, migration, notice, deprecation, and retirement work?\n\n### Before this station\n- [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.\n- [ ] Business goals are defined.\n- [ ] Market research identifies capability opportunities.\n- [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.\n\n### Ready to leave when\n- [ ] Capability opportunity is identified and documented.\n- [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The capability value proposition has been validated with business and consumer stakeholders.\n- [ ] Consumer segments are identified.\n- [ ] A high-level implementation roadmap is defined.\n\n### Other related resources\n- **Integration Consumer Onboarding Guide**: Guidance for helping consumer teams discover, request access to, test, validate, and start using an integration capability.\n- **Integration Access and Environment Checklist**: A checklist for access requests, identities, credentials, certificates, sandbox, test, staging, production, partner, and recovery environments.\n\n## 3. Integration Architecture & Platform Decisions\n\nSelect the integration architecture, implementation style, and platform capabilities, taking account of constraints and the governance model.\n\n### Canvas questions\n#### Business Impact Canvas\nWhat value, risk, operational, financial, customer, employee, compliance, and strategic impact is expected or at stake?\n- **Expected benefits**: What business, customer, employee, quality, speed, risk, compliance, or strategic benefits are expected?\n- **Operational efficiency impact**: How could work effort, waiting time, rework, throughput, reliability, support load, or operational cost change?\n- **Customer and employee impact**: How will customers, employees, partners, operators, or support teams experience the change?\n- **Financial impact**: What revenue, cost, investment, savings, loss avoidance, or funding impact is expected?\n- **Compliance and strategic impact**: What regulatory, contractual, policy, reputation, market, ecosystem, or strategic consequences matter?\n- **Impact of not proceeding**: What happens if the capability, automation, integration, or service is not improved or delivered?\n- **Risks and criticality**: What availability, security, data, safety, process, adoption, or business continuity risks could affect the outcome?\n- **Mitigations and decision impact**: Which mitigations, constraints, trade-offs, or residual risks should influence prioritization, architecture, rollout, or readiness decisions?\n\n#### Location Canvas\nWhat geopolitical, regulatory, network, and trust boundaries affect this capability or integration?\n- **Location / Trust Groups**: What are the relevant geopolitical, regulatory, network, or trust groups?\n- **Group Characteristics**: What are the characteristics of those groups, such as residency, trust level, or network exposure?\n- **Relevant Locations / Zones**: What are the relevant locations, zones, or environments within each group?\n- **Location / Zone Characteristics**: What are the characteristics of those locations or zones, such as ownership, region, or exposure?\n- **Network / Regulatory Distances**: What latency, trust, regulatory, or connectivity distances exist between the locations?\n- **Distance Characteristics**: What are the characteristics of those distances, such as latency sensitivity, residency constraints, or trust boundaries?\n- **Connectivity Endpoints**: What connectivity endpoints or interfaces are associated with the locations?\n- **Endpoint Access Characteristics**: What are the characteristics of those endpoints, such as exposure, protocol, security, or access restrictions?\n\n#### Capacity Canvas\nHow much demand, load, timing, and scaling capacity must be understood for the capability, automation, integration, or service?\n- **Current Business Volumes**: What are the current business volumes and transaction rates?\n- **Future Consumption Trends**: What are the anticipated future consumption trends?\n- **Peak Load and Availability Requirements**: What are the peak load and availability requirements?\n- **Caching Strategies**: What caching strategies can be used to optimize performance?\n- **Rate Limiting Strategies**: What rate limiting strategies can be used to manage consumption?\n- **Scaling Strategies**: What scaling strategies can be used to accommodate growth?\n\n#### Integration Architecture Decision Canvas\nChoose the integration style and platform using evidence already gathered.\n- **Reused inputs**: Which commitments, capacity, location, impact, and domain decisions constrain the choice?\n- **Viable options**: Which API, event, messaging, file, stream, data, connector, platform, or custom options remain viable?\n- **Selected approach**: Which integration style, platform, or hybrid is selected?\n- **Decision rationale**: Why does the selected approach fit best?\n- **Rejected alternatives**: Which serious alternatives were rejected, and why?\n- **Open risks**: What still needs validation before delivery or release?\n\n### Before this station\n- [ ] Capability opportunity is identified and documented.\n- [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The capability value proposition has been validated with business and consumer stakeholders.\n- [ ] Consumer segments are identified.\n- [ ] A high-level implementation roadmap is defined.\n\n### Ready to leave when\n- [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The capability value proposition has been validated with business and consumer stakeholders.\n- [ ] Consumer segments are identified.\n- [ ] A high-level implementation roadmap is defined.\n\n## 4. Integration Solution Design\n\nDesign the integration solution, contracts, schemas, data structures, mappings, and interaction or delivery patterns for the selected style.\n\n### Canvas questions\n#### Domain Canvas\nWhat are the core entities and business rules related to this capability or domain?\n- **Selected Customer Journey Steps**: Which customer journey steps are relevant to this domain?\n- **Core Entities & Business Meaning**: What are the core entities and their business meaning?\n- **Attributes & Business Importance**: What are the key attributes of each entity and their business importance?\n- **Relationships Between Entities**: What are the relationships between the entities?\n- **Business, Compliance & Integrity Rules**: What are the business, compliance, and integrity rules related to the entities?\n- **Security & Privacy Considerations**: What are the security and privacy considerations related to the entities?\n\n#### Integration Solution Design Canvas\nRefine the selected architecture into an implementable integration design.\n- **Selected inputs**: Which architecture, domain, interaction, and commitment decisions are reused?\n- **Contract and model**: What contract, schema, data model, and version define the integration?\n- **Mapping and delivery**: What transformations, delivery pattern, and metadata are required?\n- **Errors and recovery**: How are failures, retries, replay, duplicates, and reconciliation handled?\n- **Security and trust**: What identity, access, privacy, and trust controls apply?\n- **Observability and evolution**: How will the integration be monitored, changed, migrated, and deprecated?\n\n#### Interaction Canvas\nWhat kinds of interactions should this capability support before choosing a protocol-specific design?\n- **CRUD Interactions**: Are CRUD (Create, Read, Update, Delete) interactions needed here?\n- **CRUD Input & Output Models**: What are the input and output models for the CRUD interactions, if this style is needed?\n- **CRUD Processing & Validation**: What are the processing and validation rules for the CRUD interactions, if this style is needed?\n- **Query-Driven Interactions**: What read or query interactions are needed to answer consumer questions?\n- **Query-Driven Input & Output Models**: What are the input and output models for the query-driven interactions?\n- **Query-Driven Processing & Validation**: What are the processing and validation rules for the query-driven interactions?\n- **Command-Driven Interactions**: What state-changing commands are needed, if any?\n- **Command-Driven Input & Output Models**: What are the input and output models for the command-driven interactions, if this style is needed?\n- **Command-Driven Processing & Validation**: What are the processing and validation rules for the command-driven interactions, if this style is needed?\n- **Event-Driven Interactions**: What events need to be published or consumed, if any?\n- **Event-Driven Input & Output Models**: What are the input and output models for the event-driven interactions, if this style is needed?\n- **Event-Driven Processing & Validation**: What are the processing and validation rules for the event-driven interactions, if this style is needed?\n\n### Before this station\n- [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The capability value proposition has been validated with business and consumer stakeholders.\n- [ ] Consumer segments are identified.\n- [ ] A high-level implementation roadmap is defined.\n\n### Ready to leave when\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface design follows agreed design standards and conventions.\n\n### Other related resources\n- **Contract-First Capability Design**: Guidance for validating capability contracts before delivery, including API contracts, event schemas, file schemas, data contracts, service agreements, workflow inputs and outputs, and user-facing service promises.\n- **Integration Style-Specific Design Guide**: Guidance for selecting design resources after the architecture decision, including REST, GraphQL, events, messaging, files, streams, data products, direct integration, connectors, and hybrids.\n\n## 5. Integration Delivery & Operations\n\nBuild, test, deploy, and operate the integration capability using its selected implementation style and validated contract.\n\n### Canvas questions\n#### Integration Readiness & Operations Canvas\nPrepare the minimum operating evidence needed before integration readiness review.\n- **Ownership**: Who owns business, integration, producer, consumer, platform, and incident responsibilities?\n- **Environments and access**: Are environments, credentials, connectivity, permissions, and sequencing ready?\n- **Test evidence**: What proves contract, mapping, compatibility, quality, resilience, and recovery?\n- **Monitoring and support**: How will producers, consumers, platforms, incidents, and service questions be supported?\n- **Failure and recovery**: How will retry, replay, duplicates, reconciliation, fallback, and compensation work?\n- **Readiness status**: Are contracts, runbooks, dependencies, risks, conditions, and blocking gaps clear?\n\n### Before this station\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface design follows agreed design standards and conventions.\n\n### Ready to leave when\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface design follows agreed design standards and conventions.\n\n### Other related resources\n- **Integration Development Best Practices**: Implementation guidance for building integration capabilities from validated contracts using maintainable code, configuration, connectors, mappings, and platform patterns.\n- **Integration Testing Guide**: Guidance for testing integration contracts, schemas, mappings, compatibility, data quality, security, performance, resilience, replay, reconciliation, and recovery.\n- **Integration CI/CD and Deployment Guide**: Guidance for automating build, validation, deployment, configuration, migration, release, rollback, and traceability for integration capabilities.\n- **Integration Security Guide**: Guidance for protecting integration identities, credentials, data, trust boundaries, access, privacy, auditability, and platform controls.\n- **Integration Recovery and Reconciliation Guide**: Guidance for retry, replay, duplicate handling, ordering, dead-lettering, restartability, reconciliation, fallback, compensation, and rollback.\n\n## 6. Integration Readiness Assurance\n\nAssure integration readiness, governance, quality, security, compliance, and operational evidence before release.\n\n### Station questions\n- Review the completed design, test evidence, operating model, permissions, credentials, monitoring, support, fallback, and rollback arrangements.\n- Verify that known risks, exceptions, unsafe actions, human oversight, compliance requirements, and unresolved assumptions have been addressed or explicitly accepted.\n- Record blocking findings, accepted residual risks, release conditions, and required remediation actions.\n- Decide whether the release is ready, ready with conditions, requires remediation, or is not approved.\n- Record the decision owner, decision date, and evidence used.\n- Confirm that nothing proceeds to release without clear business and operational ownership.\n- Use readiness evidence to make an explicit go, conditional-go, or no-go decision before production use.\n- A formal readiness decision prevents automation solutions from being released without clear evidence, accepted risks, remediation actions, and business and operational ownership.\n\n### Before this station\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface design follows agreed design standards and conventions.\n\n### Ready to leave when\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.\n- [ ] The interface design follows agreed design standards and conventions.\n- [ ] The interface contract has been validated and tested against functional and non-functional requirements.\n\n### Other related resources\n- **Integration Readiness Checklist**: A checklist for release readiness across contracts, schemas, mappings, test evidence, environments, permissions, credentials, monitoring, support, replay, reconciliation, fallback, recovery, risks, and ownership.\n- **Integration Compliance and Data Governance Guide**: Guidance for privacy, retention, residency, consent, lineage, ownership, data contracts, auditability, regulatory obligations, and policy controls in integrations.\n\n## 7. Integration Publishing & Enablement\n\nPublish the integration capability so teams can discover it, evaluate it, request access, complete onboarding, reuse it, and get support.\n\n### Station questions\n- Affected people and changed work: Who will use, operate, support, approve, consume, or be affected by the release, and what responsibilities, decisions, handoffs, or working practices will change?\n- Activation and rollout approach: How will access, permissions, pilot use, phased rollout, restricted groups, parallel operation, and rollout expansion be managed?\n- Enablement and support: What communication, training, operating instructions, and support paths are required?\n- Feedback and control: How will adoption, trust, actual use, issues, and unexpected behavior be monitored, and what conditions trigger pause, rollback, or return to manual operation?\n- Plan rollout, enablement, support, feedback, and rollback so released solutions can be adopted safely.\n- Automation solutions only create value after rollout when affected people and consuming systems understand what changes, how access and operation work, where to get support, and when rollout should pause, expand, or roll back.\n\n### Before this station\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.\n- [ ] The interface design follows agreed design standards and conventions.\n- [ ] The interface contract has been validated and tested against functional and non-functional requirements.\n\n### Ready to leave when\n- [ ] The solution passes quality, security, compliance, and readiness checks.\n- [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.\n- [ ] The capability is ready to be published or released through the selected delivery mechanism.\n- [ ] Consumer-facing documentation and onboarding materials are ready.\n\n### Other related resources\n- **Integration Publishing and Discovery Guide**: Guidance for publishing integration purpose, ownership, lifecycle status, contracts, schemas, service expectations, dependencies, examples, limitations, access paths, and support information.\n- **Integration Consumer Onboarding Guide**: Guidance for helping consumer teams discover, request access to, test, validate, and start using an integration capability.\n- **Integration Service Agreement Template**: A template for documenting service expectations, ownership, support, incident communication, availability, latency, throughput, data quality, change, and recovery commitments.\n- **Integration Versioning and Deprecation Guide**: Guidance for compatibility, versioning, migration, deprecation, retirement, change notice, consumer impact, and lifecycle communication.\n\n## 8. Integration Monitoring & Improvement\n\nMonitor integration reliability, reuse, incidents, performance, consumer outcomes, and improvement needs.\n\n### Station questions\n- Outcomes and value: Are the expected process, user, and business outcomes being achieved?\n- Operational performance: What do successful runs, failures, partial completions, exceptions, retries, timeouts, interventions, processing time, waiting time, and cost show?\n- User, risk, and recovery signals: What errors, corrections, unsafe actions, bypassing, mistrust, support needs, fallback events, or recovery failures are occurring?\n- Learning and lifecycle decision: Which hypothesis assumptions were supported or rejected, and should the solution be improved, expanded, restricted, redesigned, paused, or retired?\n- Use operational, user, risk, and value evidence to decide what to improve, expand, restrict, pause, or retire.\n- Released solutions need evidence to show whether expected outcomes are being achieved, where manual intervention or recovery is still needed, and what lifecycle decision should be made next.\n\n### Before this station\n- [ ] The solution passes quality, security, compliance, and readiness checks.\n- [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.\n- [ ] The capability is ready to be published or released through the selected delivery mechanism.\n- [ ] Consumer-facing documentation and onboarding materials are ready.\n\n### Ready to leave when\n- [ ] Consumer-facing documentation and onboarding materials are ready.\n- [ ] Consumer onboarding, support, and communication processes are ready.\n- [ ] Legal, privacy, and compliance requirements for publishing or release are defined and understood.\n\n### Other related resources\n- **Integration Monitoring and Value Metrics**: Guidance for monitoring reliability, performance, capacity, data quality, consumer experience, reuse, cost, operability, value, learning, and lifecycle decisions.\n- **Integration Consumer Feedback and Adoption Guide**: Guidance for collecting consumer feedback, onboarding friction, support needs, adoption evidence, reuse patterns, and improvement requests.\n- **Integration Reliability and Data Quality Metrics**: Guidance for measuring availability, success rate, failure rate, retries, dead-lettering, replay, duplication, ordering, latency, throughput, queue depth, stream lag, batch duration, file delivery, schema violations, mapping errors, missing data, and reconciliation differences.\n- **Integration Lifecycle Management Guide**: Guidance for lifecycle decisions such as improve, scale, standardize, consolidate, version, deprecate, replace, retire, or split an integration capability." }, { "id": "integration-productization-cycle:question-template-confluence-wiki", "cycleId": "integration-productization-cycle", "kind": "questions", "format": "confluence-wiki", "title": "Integration Productization Cycle question template Confluence wiki", "body": "h1. Integration Productization Cycle question template\n\nA cycle for defining and productizing reusable integration capabilities without assuming the implementation style in advance.\n\nUse this template to gather answers and evidence station by station. Canvas section prompts are listed first, followed by other related resources.\n\nh2. 1. Integration Capability Strategy\n\nStart from customer journey, capability value, and viability evidence, then validate whether the proposed reusable integration capability should proceed.\n\nh3. Canvas questions\nh4. Customer Journey Canvas\nWhat journey does the most external meaningful customer experience, and what should improve?\n* *Persona*: Who is the typical customer experiencing this journey?\n* *Customer Discovers Need*: How does the customer recognize their need or problem?\n* *Customer Need Is Resolved*: How is the customer's need ultimately resolved?\n* *Journey Steps*: What are the steps the customer takes in their journey?\n* *Pains*: What are the customer's pain points or challenges?\n* *Gains*: What are the customer's gains or benefits?\n* *Inputs & Outputs*: What are the inputs and outputs at each step?\n* *Interaction & Processing Rules*: What are the interaction and processing rules at each step?\n* *Improvement opportunities*: Which journey steps indicate that an underlying capability or process should be created, improved, automated, or removed?\n\nh4. Capability Value Proposition Canvas\nWhich reusable capability would create value for consumers without deciding yet whether it should be delivered as an API, event, file, stream, data product, or another implementation style?\n* *Consumer tasks and outcomes*: What are consumers, partners, users, systems, or teams trying to achieve?\n* *Gain-enabling capability features*: What capability features would help consumers achieve better outcomes, speed, automation, insight, reach, or compliance?\n* *Pain-relieving capability features*: What capability features would remove friction, manual work, errors, delays, risk, or uncertainty for consumers?\n* *Reusable capabilities*: What reusable business or data capabilities could serve these tasks, gains, and pains across more than one consumer or use case?\n\nh4. Capability Business Model Canvas\nHow viable, reusable, funded, owned, supported, and discoverable should this capability be?\n* *Capability value proposition*: What value does this reusable capability provide to consumers and to the organization or ecosystem?\n* *Capability consumer segments*: Who are the current and potential consumers of the capability, including teams, partners, systems, products, or data users?\n* *Consumer engagement*: How will consumers discover, evaluate, request, onboard, get support for, and provide feedback on the capability?\n* *Channels*: Through which catalogs, portals, marketplaces, documentation sites, support paths, or governance processes will consumers interact with the capability?\n* *Key resources*: Which systems, data assets, platforms, people, standards, funding, and operational capabilities are required?\n* *Key activities*: What must the capability owner and producers do to design, deliver, govern, support, and improve the capability?\n* *Key partners*: Which business, technology, data, security, legal, platform, or external partners are needed to make the capability work?\n* *Benefits*: What business, operational, ecosystem, reuse, compliance, or cost benefits justify the capability?\n* *Costs*: What are the significant costs of building, operating, governing, supporting, and evolving the capability?\n\nh4. Integration Capability Validation Canvas\nValidate whether a proposed reusable integration capability should proceed.\n* *Capability to validate*: Which proposed integration capability and reuse scope are being tested?\n* *Reused evidence*: Which earlier canvas outputs support the proposal?\n* *Critical assumptions*: What could invalidate value, reuse, ownership, feasibility, or adoption?\n* *Validation step*: What is the smallest useful validation and success threshold?\n* *Decision*: Proceed, narrow, revise and retest, or stop?\n\nh3. Before this station\n* [ ] Business goals are defined.\n* [ ] Capability opportunity is identified and documented.\n\nh3. Ready to leave when\n* [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.\n* [ ] Business goals are defined.\n* [ ] Market research identifies capability opportunities.\n* [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.\n\nh2. 2. Integration Consumer & Provider Commitments\n\nAgree provider and consumer commitments for access, validation, service, failure handling, recovery, compatibility, and lifecycle.\n\nh3. Canvas questions\nh4. Integration Consumer & Provider Commitments Canvas\nAgree the responsibilities needed to use and provide a reusable integration capability.\n* *Selected parties and use cases*: Which producers, providers, consumers, and use cases are covered?\n* *Provider commitments*: What will providers deliver, maintain, monitor, and support?\n* *Consumer commitments*: What must consumers test, protect, operate, and communicate?\n* *Access and validation*: How will access, environments, credentials, and conformance be handled?\n* *Failure and recovery*: Who handles failures, replay, duplicates, reconciliation, and recovery?\n* *Change and lifecycle*: How will compatibility, migration, notice, deprecation, and retirement work?\n\nh3. Before this station\n* [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.\n* [ ] Business goals are defined.\n* [ ] Market research identifies capability opportunities.\n* [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.\n\nh3. Ready to leave when\n* [ ] Capability opportunity is identified and documented.\n* [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The capability value proposition has been validated with business and consumer stakeholders.\n* [ ] Consumer segments are identified.\n* [ ] A high-level implementation roadmap is defined.\n\nh3. Other related resources\n* *Integration Consumer Onboarding Guide*: Guidance for helping consumer teams discover, request access to, test, validate, and start using an integration capability.\n* *Integration Access and Environment Checklist*: A checklist for access requests, identities, credentials, certificates, sandbox, test, staging, production, partner, and recovery environments.\n\nh2. 3. Integration Architecture & Platform Decisions\n\nSelect the integration architecture, implementation style, and platform capabilities, taking account of constraints and the governance model.\n\nh3. Canvas questions\nh4. Business Impact Canvas\nWhat value, risk, operational, financial, customer, employee, compliance, and strategic impact is expected or at stake?\n* *Expected benefits*: What business, customer, employee, quality, speed, risk, compliance, or strategic benefits are expected?\n* *Operational efficiency impact*: How could work effort, waiting time, rework, throughput, reliability, support load, or operational cost change?\n* *Customer and employee impact*: How will customers, employees, partners, operators, or support teams experience the change?\n* *Financial impact*: What revenue, cost, investment, savings, loss avoidance, or funding impact is expected?\n* *Compliance and strategic impact*: What regulatory, contractual, policy, reputation, market, ecosystem, or strategic consequences matter?\n* *Impact of not proceeding*: What happens if the capability, automation, integration, or service is not improved or delivered?\n* *Risks and criticality*: What availability, security, data, safety, process, adoption, or business continuity risks could affect the outcome?\n* *Mitigations and decision impact*: Which mitigations, constraints, trade-offs, or residual risks should influence prioritization, architecture, rollout, or readiness decisions?\n\nh4. Location Canvas\nWhat geopolitical, regulatory, network, and trust boundaries affect this capability or integration?\n* *Location / Trust Groups*: What are the relevant geopolitical, regulatory, network, or trust groups?\n* *Group Characteristics*: What are the characteristics of those groups, such as residency, trust level, or network exposure?\n* *Relevant Locations / Zones*: What are the relevant locations, zones, or environments within each group?\n* *Location / Zone Characteristics*: What are the characteristics of those locations or zones, such as ownership, region, or exposure?\n* *Network / Regulatory Distances*: What latency, trust, regulatory, or connectivity distances exist between the locations?\n* *Distance Characteristics*: What are the characteristics of those distances, such as latency sensitivity, residency constraints, or trust boundaries?\n* *Connectivity Endpoints*: What connectivity endpoints or interfaces are associated with the locations?\n* *Endpoint Access Characteristics*: What are the characteristics of those endpoints, such as exposure, protocol, security, or access restrictions?\n\nh4. Capacity Canvas\nHow much demand, load, timing, and scaling capacity must be understood for the capability, automation, integration, or service?\n* *Current Business Volumes*: What are the current business volumes and transaction rates?\n* *Future Consumption Trends*: What are the anticipated future consumption trends?\n* *Peak Load and Availability Requirements*: What are the peak load and availability requirements?\n* *Caching Strategies*: What caching strategies can be used to optimize performance?\n* *Rate Limiting Strategies*: What rate limiting strategies can be used to manage consumption?\n* *Scaling Strategies*: What scaling strategies can be used to accommodate growth?\n\nh4. Integration Architecture Decision Canvas\nChoose the integration style and platform using evidence already gathered.\n* *Reused inputs*: Which commitments, capacity, location, impact, and domain decisions constrain the choice?\n* *Viable options*: Which API, event, messaging, file, stream, data, connector, platform, or custom options remain viable?\n* *Selected approach*: Which integration style, platform, or hybrid is selected?\n* *Decision rationale*: Why does the selected approach fit best?\n* *Rejected alternatives*: Which serious alternatives were rejected, and why?\n* *Open risks*: What still needs validation before delivery or release?\n\nh3. Before this station\n* [ ] Capability opportunity is identified and documented.\n* [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The capability value proposition has been validated with business and consumer stakeholders.\n* [ ] Consumer segments are identified.\n* [ ] A high-level implementation roadmap is defined.\n\nh3. Ready to leave when\n* [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The capability value proposition has been validated with business and consumer stakeholders.\n* [ ] Consumer segments are identified.\n* [ ] A high-level implementation roadmap is defined.\n\nh2. 4. Integration Solution Design\n\nDesign the integration solution, contracts, schemas, data structures, mappings, and interaction or delivery patterns for the selected style.\n\nh3. Canvas questions\nh4. Domain Canvas\nWhat are the core entities and business rules related to this capability or domain?\n* *Selected Customer Journey Steps*: Which customer journey steps are relevant to this domain?\n* *Core Entities & Business Meaning*: What are the core entities and their business meaning?\n* *Attributes & Business Importance*: What are the key attributes of each entity and their business importance?\n* *Relationships Between Entities*: What are the relationships between the entities?\n* *Business, Compliance & Integrity Rules*: What are the business, compliance, and integrity rules related to the entities?\n* *Security & Privacy Considerations*: What are the security and privacy considerations related to the entities?\n\nh4. Integration Solution Design Canvas\nRefine the selected architecture into an implementable integration design.\n* *Selected inputs*: Which architecture, domain, interaction, and commitment decisions are reused?\n* *Contract and model*: What contract, schema, data model, and version define the integration?\n* *Mapping and delivery*: What transformations, delivery pattern, and metadata are required?\n* *Errors and recovery*: How are failures, retries, replay, duplicates, and reconciliation handled?\n* *Security and trust*: What identity, access, privacy, and trust controls apply?\n* *Observability and evolution*: How will the integration be monitored, changed, migrated, and deprecated?\n\nh4. Interaction Canvas\nWhat kinds of interactions should this capability support before choosing a protocol-specific design?\n* *CRUD Interactions*: Are CRUD (Create, Read, Update, Delete) interactions needed here?\n* *CRUD Input & Output Models*: What are the input and output models for the CRUD interactions, if this style is needed?\n* *CRUD Processing & Validation*: What are the processing and validation rules for the CRUD interactions, if this style is needed?\n* *Query-Driven Interactions*: What read or query interactions are needed to answer consumer questions?\n* *Query-Driven Input & Output Models*: What are the input and output models for the query-driven interactions?\n* *Query-Driven Processing & Validation*: What are the processing and validation rules for the query-driven interactions?\n* *Command-Driven Interactions*: What state-changing commands are needed, if any?\n* *Command-Driven Input & Output Models*: What are the input and output models for the command-driven interactions, if this style is needed?\n* *Command-Driven Processing & Validation*: What are the processing and validation rules for the command-driven interactions, if this style is needed?\n* *Event-Driven Interactions*: What events need to be published or consumed, if any?\n* *Event-Driven Input & Output Models*: What are the input and output models for the event-driven interactions, if this style is needed?\n* *Event-Driven Processing & Validation*: What are the processing and validation rules for the event-driven interactions, if this style is needed?\n\nh3. Before this station\n* [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The capability value proposition has been validated with business and consumer stakeholders.\n* [ ] Consumer segments are identified.\n* [ ] A high-level implementation roadmap is defined.\n\nh3. Ready to leave when\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface design follows agreed design standards and conventions.\n\nh3. Other related resources\n* *Contract-First Capability Design*: Guidance for validating capability contracts before delivery, including API contracts, event schemas, file schemas, data contracts, service agreements, workflow inputs and outputs, and user-facing service promises.\n* *Integration Style-Specific Design Guide*: Guidance for selecting design resources after the architecture decision, including REST, GraphQL, events, messaging, files, streams, data products, direct integration, connectors, and hybrids.\n\nh2. 5. Integration Delivery & Operations\n\nBuild, test, deploy, and operate the integration capability using its selected implementation style and validated contract.\n\nh3. Canvas questions\nh4. Integration Readiness & Operations Canvas\nPrepare the minimum operating evidence needed before integration readiness review.\n* *Ownership*: Who owns business, integration, producer, consumer, platform, and incident responsibilities?\n* *Environments and access*: Are environments, credentials, connectivity, permissions, and sequencing ready?\n* *Test evidence*: What proves contract, mapping, compatibility, quality, resilience, and recovery?\n* *Monitoring and support*: How will producers, consumers, platforms, incidents, and service questions be supported?\n* *Failure and recovery*: How will retry, replay, duplicates, reconciliation, fallback, and compensation work?\n* *Readiness status*: Are contracts, runbooks, dependencies, risks, conditions, and blocking gaps clear?\n\nh3. Before this station\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface design follows agreed design standards and conventions.\n\nh3. Ready to leave when\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface design follows agreed design standards and conventions.\n\nh3. Other related resources\n* *Integration Development Best Practices*: Implementation guidance for building integration capabilities from validated contracts using maintainable code, configuration, connectors, mappings, and platform patterns.\n* *Integration Testing Guide*: Guidance for testing integration contracts, schemas, mappings, compatibility, data quality, security, performance, resilience, replay, reconciliation, and recovery.\n* *Integration CI/CD and Deployment Guide*: Guidance for automating build, validation, deployment, configuration, migration, release, rollback, and traceability for integration capabilities.\n* *Integration Security Guide*: Guidance for protecting integration identities, credentials, data, trust boundaries, access, privacy, auditability, and platform controls.\n* *Integration Recovery and Reconciliation Guide*: Guidance for retry, replay, duplicate handling, ordering, dead-lettering, restartability, reconciliation, fallback, compensation, and rollback.\n\nh2. 6. Integration Readiness Assurance\n\nAssure integration readiness, governance, quality, security, compliance, and operational evidence before release.\n\nh3. Station questions\n* Review the completed design, test evidence, operating model, permissions, credentials, monitoring, support, fallback, and rollback arrangements.\n* Verify that known risks, exceptions, unsafe actions, human oversight, compliance requirements, and unresolved assumptions have been addressed or explicitly accepted.\n* Record blocking findings, accepted residual risks, release conditions, and required remediation actions.\n* Decide whether the release is ready, ready with conditions, requires remediation, or is not approved.\n* Record the decision owner, decision date, and evidence used.\n* Confirm that nothing proceeds to release without clear business and operational ownership.\n* Use readiness evidence to make an explicit go, conditional-go, or no-go decision before production use.\n* A formal readiness decision prevents automation solutions from being released without clear evidence, accepted risks, remediation actions, and business and operational ownership.\n\nh3. Before this station\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface design follows agreed design standards and conventions.\n\nh3. Ready to leave when\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.\n* [ ] The interface design follows agreed design standards and conventions.\n* [ ] The interface contract has been validated and tested against functional and non-functional requirements.\n\nh3. Other related resources\n* *Integration Readiness Checklist*: A checklist for release readiness across contracts, schemas, mappings, test evidence, environments, permissions, credentials, monitoring, support, replay, reconciliation, fallback, recovery, risks, and ownership.\n* *Integration Compliance and Data Governance Guide*: Guidance for privacy, retention, residency, consent, lineage, ownership, data contracts, auditability, regulatory obligations, and policy controls in integrations.\n\nh2. 7. Integration Publishing & Enablement\n\nPublish the integration capability so teams can discover it, evaluate it, request access, complete onboarding, reuse it, and get support.\n\nh3. Station questions\n* Affected people and changed work: Who will use, operate, support, approve, consume, or be affected by the release, and what responsibilities, decisions, handoffs, or working practices will change?\n* Activation and rollout approach: How will access, permissions, pilot use, phased rollout, restricted groups, parallel operation, and rollout expansion be managed?\n* Enablement and support: What communication, training, operating instructions, and support paths are required?\n* Feedback and control: How will adoption, trust, actual use, issues, and unexpected behavior be monitored, and what conditions trigger pause, rollback, or return to manual operation?\n* Plan rollout, enablement, support, feedback, and rollback so released solutions can be adopted safely.\n* Automation solutions only create value after rollout when affected people and consuming systems understand what changes, how access and operation work, where to get support, and when rollout should pause, expand, or roll back.\n\nh3. Before this station\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.\n* [ ] The interface design follows agreed design standards and conventions.\n* [ ] The interface contract has been validated and tested against functional and non-functional requirements.\n\nh3. Ready to leave when\n* [ ] The solution passes quality, security, compliance, and readiness checks.\n* [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.\n* [ ] The capability is ready to be published or released through the selected delivery mechanism.\n* [ ] Consumer-facing documentation and onboarding materials are ready.\n\nh3. Other related resources\n* *Integration Publishing and Discovery Guide*: Guidance for publishing integration purpose, ownership, lifecycle status, contracts, schemas, service expectations, dependencies, examples, limitations, access paths, and support information.\n* *Integration Consumer Onboarding Guide*: Guidance for helping consumer teams discover, request access to, test, validate, and start using an integration capability.\n* *Integration Service Agreement Template*: A template for documenting service expectations, ownership, support, incident communication, availability, latency, throughput, data quality, change, and recovery commitments.\n* *Integration Versioning and Deprecation Guide*: Guidance for compatibility, versioning, migration, deprecation, retirement, change notice, consumer impact, and lifecycle communication.\n\nh2. 8. Integration Monitoring & Improvement\n\nMonitor integration reliability, reuse, incidents, performance, consumer outcomes, and improvement needs.\n\nh3. Station questions\n* Outcomes and value: Are the expected process, user, and business outcomes being achieved?\n* Operational performance: What do successful runs, failures, partial completions, exceptions, retries, timeouts, interventions, processing time, waiting time, and cost show?\n* User, risk, and recovery signals: What errors, corrections, unsafe actions, bypassing, mistrust, support needs, fallback events, or recovery failures are occurring?\n* Learning and lifecycle decision: Which hypothesis assumptions were supported or rejected, and should the solution be improved, expanded, restricted, redesigned, paused, or retired?\n* Use operational, user, risk, and value evidence to decide what to improve, expand, restrict, pause, or retire.\n* Released solutions need evidence to show whether expected outcomes are being achieved, where manual intervention or recovery is still needed, and what lifecycle decision should be made next.\n\nh3. Before this station\n* [ ] The solution passes quality, security, compliance, and readiness checks.\n* [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.\n* [ ] The capability is ready to be published or released through the selected delivery mechanism.\n* [ ] Consumer-facing documentation and onboarding materials are ready.\n\nh3. Ready to leave when\n* [ ] Consumer-facing documentation and onboarding materials are ready.\n* [ ] Consumer onboarding, support, and communication processes are ready.\n* [ ] Legal, privacy, and compliance requirements for publishing or release are defined and understood.\n\nh3. Other related resources\n* *Integration Monitoring and Value Metrics*: Guidance for monitoring reliability, performance, capacity, data quality, consumer experience, reuse, cost, operability, value, learning, and lifecycle decisions.\n* *Integration Consumer Feedback and Adoption Guide*: Guidance for collecting consumer feedback, onboarding friction, support needs, adoption evidence, reuse patterns, and improvement requests.\n* *Integration Reliability and Data Quality Metrics*: Guidance for measuring availability, success rate, failure rate, retries, dead-lettering, replay, duplication, ordering, latency, throughput, queue depth, stream lag, batch duration, file delivery, schema violations, mapping errors, missing data, and reconciliation differences.\n* *Integration Lifecycle Management Guide*: Guidance for lifecycle decisions such as improve, scale, standardize, consolidate, version, deprecate, replace, retire, or split an integration capability." }, { "id": "automation-cycle:question-template-markdown", "cycleId": "automation-cycle", "kind": "questions", "format": "markdown", "title": "Automation Cycle question template Markdown", "body": "# Automation Cycle question template\n\nA cycle for selecting, designing, delivering, enabling, and improving automation solutions across people, rules, workflows, agents, integrations, UI automation, and operations.\n\nUse this template to gather answers and evidence station by station. Canvas section prompts are listed first, followed by other related resources.\n\n## 1. Automation Opportunity Strategy\n\nStart from the most external meaningful customer. Reuse journey and capability-value evidence to validate whether an automation hypothesis should proceed.\n\n### Canvas questions\n#### Customer Journey Canvas\nWhat journey does the most external meaningful customer experience, and what should improve?\n- **Persona**: Who is the typical customer experiencing this journey?\n- **Customer Discovers Need**: How does the customer recognize their need or problem?\n- **Customer Need Is Resolved**: How is the customer's need ultimately resolved?\n- **Journey Steps**: What are the steps the customer takes in their journey?\n- **Pains**: What are the customer's pain points or challenges?\n- **Gains**: What are the customer's gains or benefits?\n- **Inputs & Outputs**: What are the inputs and outputs at each step?\n- **Interaction & Processing Rules**: What are the interaction and processing rules at each step?\n- **Improvement opportunities**: Which journey steps indicate that an underlying capability or process should be created, improved, automated, or removed?\n\n#### Capability Value Proposition Canvas\nWhich reusable capability would create value for consumers without deciding yet whether it should be delivered as an API, event, file, stream, data product, or another implementation style?\n- **Consumer tasks and outcomes**: What are consumers, partners, users, systems, or teams trying to achieve?\n- **Gain-enabling capability features**: What capability features would help consumers achieve better outcomes, speed, automation, insight, reach, or compliance?\n- **Pain-relieving capability features**: What capability features would remove friction, manual work, errors, delays, risk, or uncertainty for consumers?\n- **Reusable capabilities**: What reusable business or data capabilities could serve these tasks, gains, and pains across more than one consumer or use case?\n\n#### Automation Hypothesis & Validation Canvas\nTurn existing journey, value, impact, domain, and capacity evidence into a testable automation decision.\n- **Automation hypothesis**: What work do we believe should be automated, and what outcome should it achieve?\n- **Reused evidence**: Which earlier canvas outputs support the hypothesis?\n- **Critical assumptions**: What could make the hypothesis wrong, unsafe, or unworkable?\n- **Validation experiment**: What is the smallest useful test, evidence threshold, and stop condition?\n- **Decision**: Proceed, revise, redesign the process, or stop?\n\n### Before this station\n- [ ] The automation hypothesis has enough referenced evidence about expected outcome, scope, initial implementation assumptions, critical risks, validation experiment, thresholds, and decision to determine whether it should proceed.\n- [ ] Ownership is clear for the automation opportunity, process decisions, PoC validation, risks, and lifecycle outcomes.\n\n### Ready to leave when\n- [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.\n- [ ] Business goals are defined.\n- [ ] Market research identifies capability opportunities.\n- [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.\n\n## 2. Process & Experience Requirements\n\nClarify the process, experience, domain, service, and non-functional requirements that the later workflow and architecture must satisfy.\n\n### Canvas questions\n#### Consumer Experience Requirements Canvas\nWhat experience, operational, and non-functional requirements must the solution satisfy for users, operators, consumers, approvers, and support teams?\n- **User, operator, or consumer goals**: What business, workflow, decision, automation, support, or data usage goals must be supported?\n- **Availability and timeliness needs**: When must the solution be available, how fresh must information be, and what response, delivery, or completion windows matter to users and operators?\n- **Volume and performance expectations**: What user, case, transaction, record, event, file, batch, or work-item volumes must be understood before capacity planning?\n- **Data quality and consistency needs**: What accuracy, completeness, consistency, ordering, deduplication, reconciliation, or validation expectations do users, operators, or consuming systems have?\n- **Security, privacy, and compliance constraints**: What identity, authorization, confidentiality, residency, consent, retention, audit, or regulatory constraints must the solution satisfy?\n- **Activation and access**: How do users, operators, or consuming teams gain access, initiate or participate in the solution, and receive the required permissions and guidance?\n- **Change and versioning expectations**: How much change tolerance exists, and what notice, compatibility, migration, training, or versioning expectations apply?\n- **Observability and support needs**: What monitoring, status, traceability, quality visibility, support, ownership, and incident communication do users and operators need?\n- **Recovery and continuity needs**: What replay, retry, reconciliation, backup, fallback, continuity, or manual recovery expectations must be supported?\n- **Constraints for later design**: Which requirements must later architecture, workflow, capacity, integration, or implementation decisions satisfy?\n\n#### Domain Canvas\nWhat are the core entities and business rules related to this capability or domain?\n- **Selected Customer Journey Steps**: Which customer journey steps are relevant to this domain?\n- **Core Entities & Business Meaning**: What are the core entities and their business meaning?\n- **Attributes & Business Importance**: What are the key attributes of each entity and their business importance?\n- **Relationships Between Entities**: What are the relationships between the entities?\n- **Business, Compliance & Integrity Rules**: What are the business, compliance, and integrity rules related to the entities?\n- **Security & Privacy Considerations**: What are the security and privacy considerations related to the entities?\n\n### Before this station\n- [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.\n- [ ] Business goals are defined.\n- [ ] Market research identifies capability opportunities.\n- [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.\n\n### Ready to leave when\n- [ ] Capability opportunity is identified and documented.\n- [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The capability value proposition has been validated with business and consumer stakeholders.\n- [ ] Consumer segments are identified.\n- [ ] A high-level implementation roadmap is defined.\n\n## 3. Automation Architecture & Platform Decision\n\nUse impact, location, capacity, and earlier requirements to choose the automation implementation approach and record the rationale and remaining risks.\n\n### Canvas questions\n#### Business Impact Canvas\nWhat value, risk, operational, financial, customer, employee, compliance, and strategic impact is expected or at stake?\n- **Expected benefits**: What business, customer, employee, quality, speed, risk, compliance, or strategic benefits are expected?\n- **Operational efficiency impact**: How could work effort, waiting time, rework, throughput, reliability, support load, or operational cost change?\n- **Customer and employee impact**: How will customers, employees, partners, operators, or support teams experience the change?\n- **Financial impact**: What revenue, cost, investment, savings, loss avoidance, or funding impact is expected?\n- **Compliance and strategic impact**: What regulatory, contractual, policy, reputation, market, ecosystem, or strategic consequences matter?\n- **Impact of not proceeding**: What happens if the capability, automation, integration, or service is not improved or delivered?\n- **Risks and criticality**: What availability, security, data, safety, process, adoption, or business continuity risks could affect the outcome?\n- **Mitigations and decision impact**: Which mitigations, constraints, trade-offs, or residual risks should influence prioritization, architecture, rollout, or readiness decisions?\n\n#### Location Canvas\nWhat geopolitical, regulatory, network, and trust boundaries affect this capability or integration?\n- **Location / Trust Groups**: What are the relevant geopolitical, regulatory, network, or trust groups?\n- **Group Characteristics**: What are the characteristics of those groups, such as residency, trust level, or network exposure?\n- **Relevant Locations / Zones**: What are the relevant locations, zones, or environments within each group?\n- **Location / Zone Characteristics**: What are the characteristics of those locations or zones, such as ownership, region, or exposure?\n- **Network / Regulatory Distances**: What latency, trust, regulatory, or connectivity distances exist between the locations?\n- **Distance Characteristics**: What are the characteristics of those distances, such as latency sensitivity, residency constraints, or trust boundaries?\n- **Connectivity Endpoints**: What connectivity endpoints or interfaces are associated with the locations?\n- **Endpoint Access Characteristics**: What are the characteristics of those endpoints, such as exposure, protocol, security, or access restrictions?\n\n#### Capacity Canvas\nHow much demand, load, timing, and scaling capacity must be understood for the capability, automation, integration, or service?\n- **Current Business Volumes**: What are the current business volumes and transaction rates?\n- **Future Consumption Trends**: What are the anticipated future consumption trends?\n- **Peak Load and Availability Requirements**: What are the peak load and availability requirements?\n- **Caching Strategies**: What caching strategies can be used to optimize performance?\n- **Rate Limiting Strategies**: What rate limiting strategies can be used to manage consumption?\n- **Scaling Strategies**: What scaling strategies can be used to accommodate growth?\n\n#### Automation Architecture Decision Canvas\nChoose the implementation approach using evidence already gathered.\n- **Reused inputs**: Which requirements, capacity, location, impact, and responsibility decisions constrain the choice?\n- **Viable options**: Which human, workflow, rule, agent, API, connector, custom, or UI automation options remain viable?\n- **Selected approach**: Which implementation style or hybrid is selected?\n- **Decision rationale**: Why does the selected approach fit best?\n- **Rejected alternatives**: Which serious alternatives were rejected, and why?\n- **Open risks**: What still needs validation before delivery or release?\n\n### Before this station\n- [ ] Capability opportunity is identified and documented.\n- [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The capability value proposition has been validated with business and consumer stakeholders.\n- [ ] Consumer segments are identified.\n- [ ] A high-level implementation roadmap is defined.\n\n### Ready to leave when\n- [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The capability value proposition has been validated with business and consumer stakeholders.\n- [ ] Consumer segments are identified.\n- [ ] A high-level implementation roadmap is defined.\n\n## 4. Automation Workflow Design\n\nDesign the internal workflow needed to deliver the selected customer and capability outcomes, including work allocation, controls, exceptions, recovery, evidence, and monitoring.\n\n### Canvas questions\n#### Automation Workflow Canvas\nDesign the internal workflow needed to deliver the selected customer and capability outcomes.\n- **Selected customer and capability outcomes**: Which agreed customer outcomes and capability results must this workflow deliver?\n- **Internal workflow steps**: What internal work must happen to produce those outcomes?\n- **Work allocation and human control**: What remains human, what is automated, and where are oversight or escalation required?\n- **Inputs, outputs, and interactions**: What information, systems, and handoffs are needed?\n- **Decisions, exceptions, and recovery**: What changes the flow, what can fail, and how is work recovered?\n- **Evidence and monitoring**: What proves correct operation and shows whether the intended outcome was achieved?\n\n### Before this station\n- [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The capability value proposition has been validated with business and consumer stakeholders.\n- [ ] Consumer segments are identified.\n- [ ] A high-level implementation roadmap is defined.\n\n### Ready to leave when\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface design follows agreed design standards and conventions.\n\n## 5. Automation Delivery & Operations\n\nBuild, configure, test, version, deploy, and prepare the operating model for the selected automation path, including ownership, environments, runbooks, monitoring, fallback, rollback, support, and known risks.\n\n### Canvas questions\n#### Automation Readiness & Operations Canvas\nPrepare the minimum operating evidence needed before readiness review.\n- **Ownership**: Who owns business outcomes, operations, support, and changes?\n- **Environments and access**: Are environments, permissions, credentials, and identities ready?\n- **Test evidence**: What proves correct, safe, and reliable behavior?\n- **Monitoring and support**: How will health, incidents, users, and operators be supported?\n- **Failure and recovery**: How will exceptions, fallback, rollback, and manual recovery work?\n- **Readiness status**: Are documentation, risks, conditions, and blocking gaps clear?\n\n### Before this station\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface design follows agreed design standards and conventions.\n\n### Ready to leave when\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface design follows agreed design standards and conventions.\n\n## 6. Automation Readiness Review\n\nUse a readiness checklist to review evidence and record the release decision: ready, ready with conditions, remediation required, or not approved.\n\n### Station questions\n- Review the completed design, test evidence, operating model, permissions, credentials, monitoring, support, fallback, and rollback arrangements.\n- Verify that known risks, exceptions, unsafe actions, human oversight, compliance requirements, and unresolved assumptions have been addressed or explicitly accepted.\n- Record blocking findings, accepted residual risks, release conditions, and required remediation actions.\n- Decide whether the release is ready, ready with conditions, requires remediation, or is not approved.\n- Record the decision owner, decision date, and evidence used.\n- Confirm that nothing proceeds to release without clear business and operational ownership.\n- Use readiness evidence to make an explicit go, conditional-go, or no-go decision before production use.\n- A formal readiness decision prevents automation solutions from being released without clear evidence, accepted risks, remediation actions, and business and operational ownership.\n\n### Before this station\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The selected interface provides an appropriate abstraction for consumers.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface design follows agreed design standards and conventions.\n\n### Ready to leave when\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.\n- [ ] The interface design follows agreed design standards and conventions.\n- [ ] The interface contract has been validated and tested against functional and non-functional requirements.\n\n### Other related resources\n- **Automation Readiness Checklist**: A checklist for reviewing automation evidence, blocking findings, accepted residual risks, release conditions, remediation actions, decision owner, decision date, and release readiness.\n\n## 7. Automation Rollout & Enablement\n\nActivate and roll out the automation safely with communications, training, operating instructions, support paths, adoption monitoring, feedback channels, phased rollout, pause, and rollback conditions.\n\n### Station questions\n- Affected people and changed work: Who will use, operate, support, approve, consume, or be affected by the release, and what responsibilities, decisions, handoffs, or working practices will change?\n- Activation and rollout approach: How will access, permissions, pilot use, phased rollout, restricted groups, parallel operation, and rollout expansion be managed?\n- Enablement and support: What communication, training, operating instructions, and support paths are required?\n- Feedback and control: How will adoption, trust, actual use, issues, and unexpected behavior be monitored, and what conditions trigger pause, rollback, or return to manual operation?\n- Plan rollout, enablement, support, feedback, and rollback so released solutions can be adopted safely.\n- Automation solutions only create value after rollout when affected people and consuming systems understand what changes, how access and operation work, where to get support, and when rollout should pause, expand, or roll back.\n\n### Before this station\n- [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n- [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n- [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.\n- [ ] The interface design follows agreed design standards and conventions.\n- [ ] The interface contract has been validated and tested against functional and non-functional requirements.\n\n### Ready to leave when\n- [ ] The solution passes quality, security, compliance, and readiness checks.\n- [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.\n- [ ] The capability is ready to be published or released through the selected delivery mechanism.\n- [ ] Consumer-facing documentation and onboarding materials are ready.\n\n### Other related resources\n- **Automation Rollout And Enablement Guide**: Guidance for activating and rolling out automations with changed-work analysis, rollout approach, enablement, support, feedback, adoption monitoring, and control conditions.\n\n## 8. Automation Monitoring & Improvement\n\nMonitor actual automation outcomes, run success and failure, exceptions, retries, interventions, cycle time, waiting time, cost, errors, unsafe actions, adoption, trust, realized benefit, and which hypothesis assumptions were supported or rejected.\n\n### Station questions\n- Outcomes and value: Are the expected process, user, and business outcomes being achieved?\n- Operational performance: What do successful runs, failures, partial completions, exceptions, retries, timeouts, interventions, processing time, waiting time, and cost show?\n- User, risk, and recovery signals: What errors, corrections, unsafe actions, bypassing, mistrust, support needs, fallback events, or recovery failures are occurring?\n- Learning and lifecycle decision: Which hypothesis assumptions were supported or rejected, and should the solution be improved, expanded, restricted, redesigned, paused, or retired?\n- Use operational, user, risk, and value evidence to decide what to improve, expand, restrict, pause, or retire.\n- Released solutions need evidence to show whether expected outcomes are being achieved, where manual intervention or recovery is still needed, and what lifecycle decision should be made next.\n\n### Before this station\n- [ ] The solution passes quality, security, compliance, and readiness checks.\n- [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.\n- [ ] The capability is ready to be published or released through the selected delivery mechanism.\n- [ ] Consumer-facing documentation and onboarding materials are ready.\n\n### Ready to leave when\n- [ ] Consumer-facing documentation and onboarding materials are ready.\n- [ ] Consumer onboarding, support, and communication processes are ready.\n- [ ] Legal, privacy, and compliance requirements for publishing or release are defined and understood.\n\n### Other related resources\n- **Automation Monitoring and Value Metrics**: Guidance for measuring outcomes, operational performance, user behavior, risk, recovery, realized value, hypothesis learning, and lifecycle decisions after rollout." }, { "id": "automation-cycle:question-template-confluence-wiki", "cycleId": "automation-cycle", "kind": "questions", "format": "confluence-wiki", "title": "Automation Cycle question template Confluence wiki", "body": "h1. Automation Cycle question template\n\nA cycle for selecting, designing, delivering, enabling, and improving automation solutions across people, rules, workflows, agents, integrations, UI automation, and operations.\n\nUse this template to gather answers and evidence station by station. Canvas section prompts are listed first, followed by other related resources.\n\nh2. 1. Automation Opportunity Strategy\n\nStart from the most external meaningful customer. Reuse journey and capability-value evidence to validate whether an automation hypothesis should proceed.\n\nh3. Canvas questions\nh4. Customer Journey Canvas\nWhat journey does the most external meaningful customer experience, and what should improve?\n* *Persona*: Who is the typical customer experiencing this journey?\n* *Customer Discovers Need*: How does the customer recognize their need or problem?\n* *Customer Need Is Resolved*: How is the customer's need ultimately resolved?\n* *Journey Steps*: What are the steps the customer takes in their journey?\n* *Pains*: What are the customer's pain points or challenges?\n* *Gains*: What are the customer's gains or benefits?\n* *Inputs & Outputs*: What are the inputs and outputs at each step?\n* *Interaction & Processing Rules*: What are the interaction and processing rules at each step?\n* *Improvement opportunities*: Which journey steps indicate that an underlying capability or process should be created, improved, automated, or removed?\n\nh4. Capability Value Proposition Canvas\nWhich reusable capability would create value for consumers without deciding yet whether it should be delivered as an API, event, file, stream, data product, or another implementation style?\n* *Consumer tasks and outcomes*: What are consumers, partners, users, systems, or teams trying to achieve?\n* *Gain-enabling capability features*: What capability features would help consumers achieve better outcomes, speed, automation, insight, reach, or compliance?\n* *Pain-relieving capability features*: What capability features would remove friction, manual work, errors, delays, risk, or uncertainty for consumers?\n* *Reusable capabilities*: What reusable business or data capabilities could serve these tasks, gains, and pains across more than one consumer or use case?\n\nh4. Automation Hypothesis & Validation Canvas\nTurn existing journey, value, impact, domain, and capacity evidence into a testable automation decision.\n* *Automation hypothesis*: What work do we believe should be automated, and what outcome should it achieve?\n* *Reused evidence*: Which earlier canvas outputs support the hypothesis?\n* *Critical assumptions*: What could make the hypothesis wrong, unsafe, or unworkable?\n* *Validation experiment*: What is the smallest useful test, evidence threshold, and stop condition?\n* *Decision*: Proceed, revise, redesign the process, or stop?\n\nh3. Before this station\n* [ ] The automation hypothesis has enough referenced evidence about expected outcome, scope, initial implementation assumptions, critical risks, validation experiment, thresholds, and decision to determine whether it should proceed.\n* [ ] Ownership is clear for the automation opportunity, process decisions, PoC validation, risks, and lifecycle outcomes.\n\nh3. Ready to leave when\n* [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.\n* [ ] Business goals are defined.\n* [ ] Market research identifies capability opportunities.\n* [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.\n\nh2. 2. Process & Experience Requirements\n\nClarify the process, experience, domain, service, and non-functional requirements that the later workflow and architecture must satisfy.\n\nh3. Canvas questions\nh4. Consumer Experience Requirements Canvas\nWhat experience, operational, and non-functional requirements must the solution satisfy for users, operators, consumers, approvers, and support teams?\n* *User, operator, or consumer goals*: What business, workflow, decision, automation, support, or data usage goals must be supported?\n* *Availability and timeliness needs*: When must the solution be available, how fresh must information be, and what response, delivery, or completion windows matter to users and operators?\n* *Volume and performance expectations*: What user, case, transaction, record, event, file, batch, or work-item volumes must be understood before capacity planning?\n* *Data quality and consistency needs*: What accuracy, completeness, consistency, ordering, deduplication, reconciliation, or validation expectations do users, operators, or consuming systems have?\n* *Security, privacy, and compliance constraints*: What identity, authorization, confidentiality, residency, consent, retention, audit, or regulatory constraints must the solution satisfy?\n* *Activation and access*: How do users, operators, or consuming teams gain access, initiate or participate in the solution, and receive the required permissions and guidance?\n* *Change and versioning expectations*: How much change tolerance exists, and what notice, compatibility, migration, training, or versioning expectations apply?\n* *Observability and support needs*: What monitoring, status, traceability, quality visibility, support, ownership, and incident communication do users and operators need?\n* *Recovery and continuity needs*: What replay, retry, reconciliation, backup, fallback, continuity, or manual recovery expectations must be supported?\n* *Constraints for later design*: Which requirements must later architecture, workflow, capacity, integration, or implementation decisions satisfy?\n\nh4. Domain Canvas\nWhat are the core entities and business rules related to this capability or domain?\n* *Selected Customer Journey Steps*: Which customer journey steps are relevant to this domain?\n* *Core Entities & Business Meaning*: What are the core entities and their business meaning?\n* *Attributes & Business Importance*: What are the key attributes of each entity and their business importance?\n* *Relationships Between Entities*: What are the relationships between the entities?\n* *Business, Compliance & Integrity Rules*: What are the business, compliance, and integrity rules related to the entities?\n* *Security & Privacy Considerations*: What are the security and privacy considerations related to the entities?\n\nh3. Before this station\n* [ ] Relevant market signals, feedback, or operational insights are available to guide this capability opportunity.\n* [ ] Business goals are defined.\n* [ ] Market research identifies capability opportunities.\n* [ ] Relevant stakeholders agree this capability opportunity is worth exploring and prioritizing.\n\nh3. Ready to leave when\n* [ ] Capability opportunity is identified and documented.\n* [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The capability value proposition has been validated with business and consumer stakeholders.\n* [ ] Consumer segments are identified.\n* [ ] A high-level implementation roadmap is defined.\n\nh2. 3. Automation Architecture & Platform Decision\n\nUse impact, location, capacity, and earlier requirements to choose the automation implementation approach and record the rationale and remaining risks.\n\nh3. Canvas questions\nh4. Business Impact Canvas\nWhat value, risk, operational, financial, customer, employee, compliance, and strategic impact is expected or at stake?\n* *Expected benefits*: What business, customer, employee, quality, speed, risk, compliance, or strategic benefits are expected?\n* *Operational efficiency impact*: How could work effort, waiting time, rework, throughput, reliability, support load, or operational cost change?\n* *Customer and employee impact*: How will customers, employees, partners, operators, or support teams experience the change?\n* *Financial impact*: What revenue, cost, investment, savings, loss avoidance, or funding impact is expected?\n* *Compliance and strategic impact*: What regulatory, contractual, policy, reputation, market, ecosystem, or strategic consequences matter?\n* *Impact of not proceeding*: What happens if the capability, automation, integration, or service is not improved or delivered?\n* *Risks and criticality*: What availability, security, data, safety, process, adoption, or business continuity risks could affect the outcome?\n* *Mitigations and decision impact*: Which mitigations, constraints, trade-offs, or residual risks should influence prioritization, architecture, rollout, or readiness decisions?\n\nh4. Location Canvas\nWhat geopolitical, regulatory, network, and trust boundaries affect this capability or integration?\n* *Location / Trust Groups*: What are the relevant geopolitical, regulatory, network, or trust groups?\n* *Group Characteristics*: What are the characteristics of those groups, such as residency, trust level, or network exposure?\n* *Relevant Locations / Zones*: What are the relevant locations, zones, or environments within each group?\n* *Location / Zone Characteristics*: What are the characteristics of those locations or zones, such as ownership, region, or exposure?\n* *Network / Regulatory Distances*: What latency, trust, regulatory, or connectivity distances exist between the locations?\n* *Distance Characteristics*: What are the characteristics of those distances, such as latency sensitivity, residency constraints, or trust boundaries?\n* *Connectivity Endpoints*: What connectivity endpoints or interfaces are associated with the locations?\n* *Endpoint Access Characteristics*: What are the characteristics of those endpoints, such as exposure, protocol, security, or access restrictions?\n\nh4. Capacity Canvas\nHow much demand, load, timing, and scaling capacity must be understood for the capability, automation, integration, or service?\n* *Current Business Volumes*: What are the current business volumes and transaction rates?\n* *Future Consumption Trends*: What are the anticipated future consumption trends?\n* *Peak Load and Availability Requirements*: What are the peak load and availability requirements?\n* *Caching Strategies*: What caching strategies can be used to optimize performance?\n* *Rate Limiting Strategies*: What rate limiting strategies can be used to manage consumption?\n* *Scaling Strategies*: What scaling strategies can be used to accommodate growth?\n\nh4. Automation Architecture Decision Canvas\nChoose the implementation approach using evidence already gathered.\n* *Reused inputs*: Which requirements, capacity, location, impact, and responsibility decisions constrain the choice?\n* *Viable options*: Which human, workflow, rule, agent, API, connector, custom, or UI automation options remain viable?\n* *Selected approach*: Which implementation style or hybrid is selected?\n* *Decision rationale*: Why does the selected approach fit best?\n* *Rejected alternatives*: Which serious alternatives were rejected, and why?\n* *Open risks*: What still needs validation before delivery or release?\n\nh3. Before this station\n* [ ] Capability opportunity is identified and documented.\n* [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The capability value proposition has been validated with business and consumer stakeholders.\n* [ ] Consumer segments are identified.\n* [ ] A high-level implementation roadmap is defined.\n\nh3. Ready to leave when\n* [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The capability value proposition has been validated with business and consumer stakeholders.\n* [ ] Consumer segments are identified.\n* [ ] A high-level implementation roadmap is defined.\n\nh2. 4. Automation Workflow Design\n\nDesign the internal workflow needed to deliver the selected customer and capability outcomes, including work allocation, controls, exceptions, recovery, evidence, and monitoring.\n\nh3. Canvas questions\nh4. Automation Workflow Canvas\nDesign the internal workflow needed to deliver the selected customer and capability outcomes.\n* *Selected customer and capability outcomes*: Which agreed customer outcomes and capability results must this workflow deliver?\n* *Internal workflow steps*: What internal work must happen to produce those outcomes?\n* *Work allocation and human control*: What remains human, what is automated, and where are oversight or escalation required?\n* *Inputs, outputs, and interactions*: What information, systems, and handoffs are needed?\n* *Decisions, exceptions, and recovery*: What changes the flow, what can fail, and how is work recovered?\n* *Evidence and monitoring*: What proves correct operation and shows whether the intended outcome was achieved?\n\nh3. Before this station\n* [ ] The capability addresses a clear business need and is reusable by its intended consumers.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The capability value proposition has been validated with business and consumer stakeholders.\n* [ ] Consumer segments are identified.\n* [ ] A high-level implementation roadmap is defined.\n\nh3. Ready to leave when\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface design follows agreed design standards and conventions.\n\nh2. 5. Automation Delivery & Operations\n\nBuild, configure, test, version, deploy, and prepare the operating model for the selected automation path, including ownership, environments, runbooks, monitoring, fallback, rollback, support, and known risks.\n\nh3. Canvas questions\nh4. Automation Readiness & Operations Canvas\nPrepare the minimum operating evidence needed before readiness review.\n* *Ownership*: Who owns business outcomes, operations, support, and changes?\n* *Environments and access*: Are environments, permissions, credentials, and identities ready?\n* *Test evidence*: What proves correct, safe, and reliable behavior?\n* *Monitoring and support*: How will health, incidents, users, and operators be supported?\n* *Failure and recovery*: How will exceptions, fallback, rollback, and manual recovery work?\n* *Readiness status*: Are documentation, risks, conditions, and blocking gaps clear?\n\nh3. Before this station\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface design follows agreed design standards and conventions.\n\nh3. Ready to leave when\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface design follows agreed design standards and conventions.\n\nh2. 6. Automation Readiness Review\n\nUse a readiness checklist to review evidence and record the release decision: ready, ready with conditions, remediation required, or not approved.\n\nh3. Station questions\n* Review the completed design, test evidence, operating model, permissions, credentials, monitoring, support, fallback, and rollback arrangements.\n* Verify that known risks, exceptions, unsafe actions, human oversight, compliance requirements, and unresolved assumptions have been addressed or explicitly accepted.\n* Record blocking findings, accepted residual risks, release conditions, and required remediation actions.\n* Decide whether the release is ready, ready with conditions, requires remediation, or is not approved.\n* Record the decision owner, decision date, and evidence used.\n* Confirm that nothing proceeds to release without clear business and operational ownership.\n* Use readiness evidence to make an explicit go, conditional-go, or no-go decision before production use.\n* A formal readiness decision prevents automation solutions from being released without clear evidence, accepted risks, remediation actions, and business and operational ownership.\n\nh3. Before this station\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The selected interface provides an appropriate abstraction for consumers.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface design follows agreed design standards and conventions.\n\nh3. Ready to leave when\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.\n* [ ] The interface design follows agreed design standards and conventions.\n* [ ] The interface contract has been validated and tested against functional and non-functional requirements.\n\nh3. Other related resources\n* *Automation Readiness Checklist*: A checklist for reviewing automation evidence, blocking findings, accepted residual risks, release conditions, remediation actions, decision owner, decision date, and release readiness.\n\nh2. 7. Automation Rollout & Enablement\n\nActivate and roll out the automation safely with communications, training, operating instructions, support paths, adoption monitoring, feedback channels, phased rollout, pause, and rollback conditions.\n\nh3. Station questions\n* Affected people and changed work: Who will use, operate, support, approve, consume, or be affected by the release, and what responsibilities, decisions, handoffs, or working practices will change?\n* Activation and rollout approach: How will access, permissions, pilot use, phased rollout, restricted groups, parallel operation, and rollout expansion be managed?\n* Enablement and support: What communication, training, operating instructions, and support paths are required?\n* Feedback and control: How will adoption, trust, actual use, issues, and unexpected behavior be monitored, and what conditions trigger pause, rollback, or return to manual operation?\n* Plan rollout, enablement, support, feedback, and rollback so released solutions can be adopted safely.\n* Automation solutions only create value after rollout when affected people and consuming systems understand what changes, how access and operation work, where to get support, and when rollout should pause, expand, or roll back.\n\nh3. Before this station\n* [ ] The chosen architecture, platform, and implementation style have been validated with the relevant architecture, security, and platform stakeholders.\n* [ ] The interface design and exposed capabilities trace back to business value and consumer needs.\n* [ ] The interface and its capabilities are documented clearly enough for review, audit, and onboarding.\n* [ ] The interface design follows agreed design standards and conventions.\n* [ ] The interface contract has been validated and tested against functional and non-functional requirements.\n\nh3. Ready to leave when\n* [ ] The solution passes quality, security, compliance, and readiness checks.\n* [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.\n* [ ] The capability is ready to be published or released through the selected delivery mechanism.\n* [ ] Consumer-facing documentation and onboarding materials are ready.\n\nh3. Other related resources\n* *Automation Rollout And Enablement Guide*: Guidance for activating and rolling out automations with changed-work analysis, rollout approach, enablement, support, feedback, adoption monitoring, and control conditions.\n\nh2. 8. Automation Monitoring & Improvement\n\nMonitor actual automation outcomes, run success and failure, exceptions, retries, interventions, cycle time, waiting time, cost, errors, unsafe actions, adoption, trust, realized benefit, and which hypothesis assumptions were supported or rejected.\n\nh3. Station questions\n* Outcomes and value: Are the expected process, user, and business outcomes being achieved?\n* Operational performance: What do successful runs, failures, partial completions, exceptions, retries, timeouts, interventions, processing time, waiting time, and cost show?\n* User, risk, and recovery signals: What errors, corrections, unsafe actions, bypassing, mistrust, support needs, fallback events, or recovery failures are occurring?\n* Learning and lifecycle decision: Which hypothesis assumptions were supported or rejected, and should the solution be improved, expanded, restricted, redesigned, paused, or retired?\n* Use operational, user, risk, and value evidence to decide what to improve, expand, restrict, pause, or retire.\n* Released solutions need evidence to show whether expected outcomes are being achieved, where manual intervention or recovery is still needed, and what lifecycle decision should be made next.\n\nh3. Before this station\n* [ ] The solution passes quality, security, compliance, and readiness checks.\n* [ ] Audit findings and remediation decisions are shared with the relevant stakeholders.\n* [ ] The capability is ready to be published or released through the selected delivery mechanism.\n* [ ] Consumer-facing documentation and onboarding materials are ready.\n\nh3. Ready to leave when\n* [ ] Consumer-facing documentation and onboarding materials are ready.\n* [ ] Consumer onboarding, support, and communication processes are ready.\n* [ ] Legal, privacy, and compliance requirements for publishing or release are defined and understood.\n\nh3. Other related resources\n* *Automation Monitoring and Value Metrics*: Guidance for measuring outcomes, operational performance, user behavior, risk, recovery, realized value, hypothesis learning, and lifecycle decisions after rollout." } ] } }