Architecture Portal

Customer

The people and organisations being served.

Adrian Sutherland · Version 1.0 · · © 2005–2026

Whose outcome matters?

In the fictional training-provider example, a learner attends a course, an employer pays for it and an intermediary arranges the booking. After a cancellation, they may need different information and have different authority. Treating them as one “customer” can obscure who chooses an alternative and who agrees a payment change.

The Customer aspect of A Simple Architectural Framework (ASAF) looks outwards from the organisation. It asks who is served, what they need, how the relationship works and how change affects them. In a public service, the relevant terms may be citizen, service user, beneficiary or partner. Distinguish roles by their needs and responsibilities.

A useful customer view

View Questions to retain
Groups and roles Which needs differ enough to change the service? Who uses, pays, benefits or acts for someone else?
Outcomes What result matters to each party, and what constitutes agreement or completion?
Relationship What commitments exist, how are expectations communicated and how can problems be raised?
Experience Where do people wait, repeat information, abandon work or need assistance?
Change Who must be informed, supported or moved to a different arrangement? What happens to open cases?

Use interviews, observations, complaints and service records to test the view. Label assumptions and gaps. Grouping people by a relevant need can help design a service; a convenient category should not substitute for checking that need.

Connections

The channel view determines how people interact, while organisation and process assigns the work needed to meet the commitment. Information defines what must be known. Security governs access and disclosure. A payer’s commercial relationship does not automatically grant access to every detail about the person using the service.

A conversational interface may help explain an option. The architecture still needs a way to verify the user’s request, confirm any consequential choice and reach someone who can resolve an exception.

Speed and quality

Observe how much effort the customer makes, how long they wait and whether they reach an agreed resolution. Count repeated contacts and completed cases. Review outcomes for groups with different needs. Judge the architecture method separately by how quickly it exposes those differences and supports a useful decision.

Methodology configuration

Map Customer to the people and organisations your method describes. Actors can include systems, so check the meaning rather than treating the words as interchangeable. 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.