A small investment firm can depend on a surprisingly large technology estate. Identity, email, documents, relationship data, research tools, and external providers all support the same working day. I want to be able to explain how those pieces fit together, who is responsible for them, and what happens when one fails. That is the starting point for an operating model the firm can actually use.
Source
The operating model now has another kind of actor
NIST’s August 2026 identity discussion examines agents acting through user accounts and the challenge of governing delegated authority. That raises a question for the service map: where does responsibility sit when software begins doing work previously assigned to a person?
I would extend the same ownership model to automated actors. Record their purpose, permitted actions, information access, and shutdown owner. The test is whether an unfamiliar operator can explain both the human service owner and the automation acting within the service.
Start with the working day
The service map should begin with things people recognize: preparing for a meeting, finding a document, reviewing an opportunity, sharing information with an adviser, and getting a new colleague ready to work. Each workflow connects technology to a consequence. That makes it easier to decide what deserves attention.
Consider a hypothetical meeting-preparation workflow. The relationship system contains the history, the document platform contains the materials, and identity controls access to both. A provider might support the applications while someone inside the firm owns the quality of the information. Listing the applications alone would miss that division of responsibility.
Describe this figure
A hypothetical meeting-preparation workflow sits on top of the services it needs. Beneath it, the relationship system contains the history and the document platform contains the materials; identity, below both, controls access to both; and a provider, at the base, might support the applications. Beside the services, four roles apply to each one: the business owner decides whether the service meets the business need, the technical owner maintains its configuration and access, support and escalation responds when someone needs help, and the recovery owner coordinates recovery when ordinary support is insufficient. Every role is left unnamed, as an empty ring, because the piece does not assign them: one person may fill several roles, and a provider may perform much of the work, but delegation still leaves an identifiable decision owner inside the firm.
For each important workflow, record the services it needs, the information it uses, and the people who depend on it. Include external dependencies such as support providers and account recovery contacts. Keep the map short enough that someone will update it when the arrangement changes.
Proposal
Give every responsibility somewhere to land
I find four questions useful:
- Who decides whether the service meets the business need?
- Who maintains its configuration and access?
- Who responds when someone needs help?
- Who can coordinate recovery when ordinary support is insufficient?
One person may fill several roles. A provider may perform much of the work. The important point is that delegation leaves an identifiable decision owner inside the firm. “The vendor handles that” still needs an explanation of what the vendor handles, how performance is checked, and who resolves a gap.
Make the support boundary concrete. If a CRM export fails, does the service provider investigate the application, the integration, or both? Who determines whether the export contains the right information? Resolving that distinction during planning is much easier than discovering it during an urgent request.
NIST’s small-business guide provides a useful foundation for defining responsibilities around technology risk. The service map here is my proposed way to bring that governance into everyday operations.
Review decisions and evidence together
A monthly review can be compact. Start with service interruptions and material changes. Check unresolved access or recovery issues. Look ahead to renewals, migrations, and projects that will introduce new responsibilities. End with the decisions leadership needs to make.
The evidence should suit the service. A recovery exercise tells us something different from an availability report. A clean support queue says little about whether permissions remain appropriate. Record what each check establishes and what remains uncertain.
Google’s SRE foundations connect service objectives, monitoring, and operational simplicity. A small firm can use those principles at its own scale: a handful of meaningful checks, clear escalation, and a record of improvements.
Make the model survive a handover
Ask someone unfamiliar with a service to use the map. Can they find its owner, reach support, locate the runbook, and explain how to escalate? Any missing answer is useful feedback.
The operating model earns its place when it makes ordinary work easier and unusual events less confusing. Start with a few critical workflows. Give each a clear owner and a support path. Expand the map as the firm’s needs justify it.
Proposal
What I would test next
I would pilot the map on three critical workflows and one automated task. Ask a second person to route a failure without help from the original owner. If the map adds paperwork without improving that handoff, simplify its fields before expanding it.