A day in the life of a service architect

Ever wondered what a typical day looks like for someone juggling the hats of a service architect?  It’s a dynamic blend of strategy, collaboration, and relentless attention to detail, says Rachael Elliot.

This ‘day in the life’ provides a representative snapshot of the activities carried out by a service architect, particularly where outputs from the Service Acceptance Criteria (SAC) are captured and fed directly into the Service Design Pack (SDP).  The SDP, in turn, defines the assurance levels necessary to support a successful Early Life Support (ELS) phase and ongoing live service operations.

While this account captures a typical day, it is important to recognise that the role is dynamic, and its scope can vary significantly across different industries, organisations and programme landscapes.

Here’s a behind-the-scenes glimpse into a day in the life of this multi-faceted role.

Morning kickoff: the daily check-in

Every day begins with two key check-ins:

• Service design practice check-in. This is the daily sync with peers to discuss the day’s priorities and surface blockers, and tap into collective intelligence for guidance.

• Project check-in. Here, the focus shifts to providing progress updates on service design and transition activities to project managers and escalating any project-specific issues.

This dual-check-in structure ensures alignment both within the service design practice and with broader project teams.

Stakeholder engagement: the engine behind service design

A big part of the role involves identifying and working closely with the right stakeholders.  From collaborating on service acceptance criteria to capturing and refining inputs into service design packs, communication is constant and critical.  Key steps include:

• Identifying and agreeing service requirements.
• Reviewing the SAC checklist to track progress and priorities.
• Organising meetings to define expectations and outstanding deliverables.
• Updating SAC statuses using RAG indicators.
• Iteratively building and refining the SDP through stakeholder input.

Building the SDP: deep, not long

The SDP is the cornerstone and living artefact – it must be comprehensive yet concise, a single point of reference for IT operations once the service goes live.  Activities feeding into this include:

• Documenting end-to-end service responsibilities across multiple service providers.
• Engaging service owners for commercial and contractual details.
• Drafting the service model to connect all service components seamlessly.
• Collating testing and validation inputs, ensuring everything has been thoroughly vetted.

The goal? A robust, end-to-end view of how the service is designed, costed, governed, and supported.

Bridging technical and service worlds

Regular attendance at technical design meetings ensures the service perspective is represented throughout the solution lifecycle. Likewise, participation in testing readiness reviews and test collaboration is crucial to guarantee service completeness.

Governance and approval: getting to go-live

Progressing a service to live status involves navigating the governance maze:

• Writing and presenting ORR (Operational Readiness Review) and FOR (Final Operational Readiness) packs at a Service Transition Board (STB).
• Confirming that all transition review meetings are completed, and the SDP reflects the accepted service state.
• Gaining formal approval through a STB, while capturing and resolving any caveats or observations.

Continuous improvement and knowledge sharing

Beyond delivery, there’s a strong focus on evolving the Service Design and Transition (SDT) function:

• Sharing lessons learned and process improvements.
• Participating in the monthly or quarterly SDT CSI (Continual Service Improvement) review meetings.
• Logging enhancements in a CSI register for future iterations.

Monthly 1:1s and looking ahead

Finally, monthly 1:1s with the service design practice manager offer a moment of reflection; discussing progress, receiving guidance, and preparing for the next wave of service engagements.

Final thoughts

Whether championing new services, aligning stakeholders, or ensuring seamless go-lives, the work of a service architect is both challenging and immensely rewarding.  It’s not just about ticking boxes, it’s about building services that are resilient, operationally sound, and truly fit for purpose; having a foot in all IT and business camps.

If you’re considering stepping into this role or already navigating it, remember: your SDP is your story, your stakeholders are your collaborators, and your service is your legacy.