A course is cancelled. The learner needs an alternative they accept and a clear answer about who will arrange it. This blueprint brings the architecture of that service into one connected set of views.
The worked example follows the decisions and their consequences. Here the views show the resulting arrangements, their shared rules and the decisions still needed. The service is fictional; its trial and software implementation have not been carried out.
Design states
| State | Arrangement | Scope |
|---|---|---|
| PROC-01 (Process-only proposal) | Shared register, named case owner and explicit acceptance of handovers | Proposed trial for provider-run courses |
| SOFT-01 (Later software option) | A case service with staff access, booking integration and recoverable transfers | Possible later software support |
| PART-01 (Partner extension) | An agreed partner service with its own booking and confirmation responsibilities | Later extension; responsibility and terms remain open |
These states describe different arrangements. Conceptual, Logical and Physical describe how much detail a view supplies. Visioning, Transforming, Operating and Governing describe the architectural work around them.
The views
| View | Question |
|---|---|
| Service overview | Who keeps the learner’s case moving? |
| Work and responsibility | How is agreement reached, ownership transferred and an exception handled? |
| Information | What does the case mean, and which states and relationships are valid? |
| Systems and rules | Which components own decisions, records and exchanges? |
| Accepted handover | What happens when a transfer succeeds but its reply is lost? |
| Security | Where are identity, permission and information use checked? |
| Technology and operation | What must survive release, restart and restoration? |
| Direction and measures | Who decides, what would it cost and how would results be judged? |
| Change and review | How do the process areas revisit the design? |
The object reference defines identifiers, roles, information and components used across the views. The records and downloads provide the completed blueprint and an outline to adapt.
ASAF coverage
A Simple Architectural Framework (ASAF) supplies the aspects below. One view may address several aspects, and an open choice can be a useful part of the architecture.
| Aspect | Treatment in this blueprint |
|---|---|
| Customer | Learner choice, payer and representative authority |
| Supplier | Partner confirmation, failure and exit |
| Channel | Messages, assisted contact and offline proposals |
| Process | Work, acceptance and escalation |
| Structure | Role responsibilities and delegated decisions |
| Information | Definitions, relationships, state and history |
| Security | Access, risks, controls and incident response |
| Metrics | Service results, method effort and recovery quality |
| Systems | Applications, integration, software and business rules |
| Technology | Runtime, release, persistence and recovery |
| Management | Authority, dependencies and exceptions |
| Finance | Comparable option costs and commitments |
| Purpose | Accepted resolution, learner agreement and continuous ownership |
Detail and open choices
The views provide Conceptual and Logical architecture. The implementation choices record what a Physical description would need: named people, products, environments, configuration and operating procedures. Those choices remain open in this fictional service.
Methodology configuration
Use the views that answer your team’s questions and combine them with your existing records. Retain the meaning, authority and source references when renaming an object or moving it into another diagram. The configuration guidance explains this mapping.
The Systems reference components offer a wider catalogue of responsibilities. They can inform a design without becoming mandatory components of this service.