Architecture Portal

Channel

One service through different routes.

Adrian Sutherland · Version 1.0 · · © 2005–2026

From a message to a call

In the fictional example, a learner opens a cancellation message on a phone, then calls because the available dates are unclear. The person answering should be able to continue the same case. Requiring the learner to restart creates work and can lead to contradictory offers.

The Channel aspect of A Simple Architectural Framework (ASAF) includes technical routes, such as digital services, and business routes, such as intermediaries. It asks how the organisation reaches people, receives their requests and maintains a consistent service as they move between routes.

The channel decision

Concern Question
Need and reach Which interactions and groups does the route serve? What assistance or alternative is needed?
Continuity Can a person resume the same work through another route without losing decisions?
Meaning Do “submitted”, “accepted”, “booked” and “resolved” mean the same thing across routes?
Authority How is identity or representation established for the action being requested?
Failure What happens when a message is delayed, a device is offline or an intermediary is unavailable?
Ownership Who maintains content, scripts, service information and changes across routes?

Different routes can use different presentations while retaining the same meaning for offers, requests and accepted results. An offline action can be saved locally before the service has accepted it. The interface must communicate that distinction and explain how the person will receive confirmation.

Assistance and automation

A conversational service can help explain options or gather a request. Its generated answer still needs to reflect the accepted service facts, and a consequential action needs the appropriate confirmation and authority. Provide a route to a person when the service cannot resolve the need.

Design the mix of channels around the people being served and the available support. Test accessibility and the handover between routes. Include the cost of maintaining scripts, translations, content and staff knowledge when a service changes.

Speed and quality

Observe completion, repeated contact, waiting, corrections and the effort of moving between routes. Compare the same outcome across relevant channels. Architecture review should expose a mismatch in meaning before it becomes extra work for the learner or the service team.

Methodology configuration

Your method may use touchpoints, contact routes, portals or intermediaries. Map their roles and handovers, keeping a technical interface distinct from a complete service channel. Use Methodology configuration to map terms, records and reviews to your own approach.

About this edition

Refreshed for the September 2026 website update. This edition develops the earlier Architecture Portal and ASAF material; the fictional worked example was added in 2026.

Scope, limitations and next checks

Status and accountability

Read this page with its boundaries visible

Status

In development

Last reviewed

Intended users

  • Architects comparing and adapting their existing approach

Non-goals

  • Prescribing a mandatory method or claiming measured benefits

Limitations

  • Guidance illustrated by a fictional example; proposed designs and checks have not been implemented or run.

Next evidence sought

  • Review the guidance and try its records with a practising architect.