Introducing a change
Consider the later software option in the fictional cancellation example. The case-service software might be running while the support team still lacks access and staff are using an old call script. A partner arrangement, if introduced, would also need agreed responsibilities. These gaps would prevent the service from being ready for use.
The Operating process area of A Simple Architectural Framework (ASAF) concerns running the organisation. Deployment and service transition connect the work of Transforming to that continuing operation. Governing supplies acceptance and control decisions throughout. This view connects the aspects through those process areas.
Readiness across the service
| Concern | Information needed for acceptance |
|---|---|
| Business architecture and Process | In-scope cases, agreements, unresolved work, expected demand and permitted fallback. |
| Structure | Named owners, cover, training, access, support contacts and escalation. |
| Information | Migration checks, authoritative records, retention and reconciliation of open transactions. |
| Systems | Compatible contracts, tested changes, version identity and pending actions. |
| Technology | Environments, capacity, monitoring, restoration and recovery after a failed release. |
| Security | Effective access controls, remaining risks, detection and response arrangements. |
| Finance and Supplier | Funded operating effort, accepted responsibilities and support commitments. |
The technology section develops the technical deployment detail. Here, the service owner brings together the results needed to accept the whole change into use.
Continuing operation
Retain the current service arrangement, known errors, operating procedures, dependencies and improvement decisions. Distinguish a service request from an incident that disrupts expected operation. Investigate recurring causes as problems, while restoring service when an incident occurs.
A supplier outage, exhausted model quota or unstaffed queue can all interrupt the same service. Establish who coordinates the response, who can act and who communicates with affected people. A working component is useful only when the necessary work can proceed.
Change and retirement
Plan the move to the new service around unfinished work and versions that may run alongside each other. Reverting software does not undo a booking, disclosure or accepted handover. Recovery may need business reconciliation as well as restoration of data or configuration.
Retirement needs an owner for remaining records, obligations and unfinished cases. Remove obsolete access and dependencies when their work is complete, and retain what is needed to understand the service’s history.
Speed and quality
Observe time to usable service, failed handovers, support effort, disruption and the time needed to resume work from a reconciled position. Measure deployment frequency separately from successful service introduction. Later operating experience should inform the design and the method used to produce it.
Data governance connects daily corrections, quality issues, access reviews and disposal to agreed authority and procedures.
Methodology configuration
Map this view to your release, service acceptance, support and improvement practices. Several responsibilities can share one process, with their owners kept clear. Use Methodology configuration to map terms, records and reviews to your own approach.