The Organised Services Operating Model by Stance is licensed under the Creative Commons Attribution-Noncommercial ShareAlike 4.0 International license, available at:
Any general operating model is exactly that - general.
It shouldn’t be taken as gospel to be implemented verbatim with no regards to the organisation where it is being implemented. Modifications will have to be made for every organisation, in particular with the nomenclature used.
This document should be viewed as describing an ideal - any deviation to it should be accepted as a deviation, but not viewed as an aberration. Compromises are exactly that. What is important is that the nature and consequences of the compromise are understood, accepted, and known when the compromise is made.
In 2011, Marc Andreessen wrote that software was eating the world and in 2020 we find ourselves living in that reality. The delivery of services in all organisations, at all levels of the organisation, almost certainly involves technology. To harness that change, however, requires a changed approach to how we structure our organisations.
The Organised Services Operating Model (OSOM) is a template operating model designed to have the powerful delivery capability and flexibility of technology startups while ensuring the oversight and governance that more traditional operating models provide. It is ideally suited for organisations at any scale that depend on Information Technology for the delivery of their services.
In many organisations the information technology organisation is split into two factions: build, and run. Projects are created to develop new capabilities and hand them to the run part of the organisation for operation. The team that builds the capability is motivated to deliver the new functionality as quickly as possible because their value is measured by their ability to change. The run team, on the other hand, is motivated by stability. Its goal is to ensure that as little changes as possible so that the working environment stays operational and running smoothly. These two parts of the organisation are at odds with each other. Their incentives are misaligned, and bringing them together is an almost impossible challenge.
The alternative to this is to arrange the organisation around services. Small teams that are responsible for both the creation of the service and the operational needs to run the service are far more responsive to the requirement of balancing the need for operational stability against the desire to deliver new capabilities.
While the traditional build/run model appears more efficient when it comes to staffing cost and standardization of how services are managed, it tends to become stagnant over time. Knowledge of how a service actually works tends to leave the organisation as employees who worked on building a service originally either move on to build another service and are therefore unavailable, or leave the organisation entirely.
On the other hand, service-based organisations can become overstaffed, and, if left unchecked, can result in an organisation that is made up of many little empires. In service-based models, staff can become stuck in the silo that they have been hired into, and careful attention needs to be paid to making it possible for employees to move between services as needed, and to use interim staff to supplant FTEs at the appropriate times.
Another problem that organisations face at scale is the tendency to adopt an approach that is singular. For example, lightweight methodologies such as Scrum and Agile vs heavy-weight, high ceremony methods like RUP, PRINCE2, or ITIL. OSOM addresses this by allowing services to operate independently of each other, adopting the methods and processes that best suit each individual service.
The goal of the Organised Services Operating Model is to harness the potential that a service-based organisation enables, to scale it beyond the delivery of a single service, and deliver at pace while retaining the governance and oversight in a build/run enterprise model.
In the Organised Services Operating Model, a Service Manager is responsible for a team of people to deliver a service to customers embodied in the form of a Service Owner, who represents the needs of those customers. The agreement between the Service Owner and the Service Manager is encompassed in a published Service Contract which articulates the relevant details of the service. Service Managers maintain a Wardley Map of their service, that is supplied to the executive and supports them in understanding the landscape of their organisation.
The situational awareness gained from being able to obtain a complete picture of the organisation and its components allows the Executive to offer guidance and oversight to Service Managers in the form of Service Mandates, that help to steer the services strategically.
Beyond issuing mandates, the role of the Executive is to constantly review the market and the organisation to reduce bias and duplication and ensure efficiency and efficacy. When the time comes the output of this research is issued to Service Managers in the form of new Service Mandates.
In organisations that structure themselves around a build/run model many different problems can emerge. One of the more common patterns observed is the inability to introduce new capabilities and services. When the pool of people running the services remains the same, no matter which services they are expected to run it means that the services they are likely to want to run will either be very well known to them or very likely not to fail (i.e. stable and well known). It is unlikely that new services will ever fit into either of those categories. Furthermore, that limited pool of people will, over time, have an increasingly broad, but shallow pool of knowledge. This again will work against any desire to change.
In one organisation Stance worked with, the build teams were project-based and made up entirely of expensive interim staff. While on the surface this sounds like an ideal use of contractors, in practice they had not been able to transition new services to the run organisation, due to the aforementioned issues and the builders were running the services themselves. The high-cost interim build staff had effectively become an even more expensive run team. They’d essentially adopted a service-based model where the builders were responsible for running the new service with no oversight or assurance, while continuing to operate a parallel organisation for existing services.
Another problem with organisations that adopt a build and run model is that the build teams often forget, or at least, de-emphasise operational issues. The ability to run the services that are created is something that is often overlooked by people who are under pressure to deliver change. Having a comprehensive set of operational playbooks that help operational staff address incidents when they occur is obviously important, but of little value to the operational staff members who are woken at 3 am every night to run them.
The origins of OSOM lie in the various elements of Simon Wardley’s work. These include his doctrine and his mapping work.
And while the genesis of OSOM itself lies in the Stance’s experience with that work, the first obvious point at which it was documented occurred in the Ministry of Justice, when one of Stance’s founding partners was asked to examine how to re-organise the digital and technology team to take advantage of the Pioneer, Settler & Town Planner model.
Simon’s work is pivotal to how the OSOM functions, and while the PST model is an excellent way of structuring a highly competent organisation, it is highly challenging to introduce into an organisation that is built around a traditional build/run operating model.
It became obvious that another approach was needed, and the best place to look for that approach was the route taken by the likes of internet-era behemoths Amazon & Netflix. This led to the nascent idea of service contracts and service mandates, as well as a governance function that at the time was called portfolio management.
Since then, the Organised Services Operating Model has evolved as it has been implemented at each new customer, with lessons learned being rolled back into how it works. The model has now evolved to a state that it needs to be extracted from the heads of the various people who use it and properly captured in a document that can evolve as OSOM evolves in practice.
OSOM has a number of benefits, but first and foremost it increases accountability and responsibility. The success or failure of a service manager to deliver upon a service contract exists entirely within their ability to influence and deliver. Similarly, a Service Manager has the opportunity to improve the service as much or as little as they see fit. This allows the trade-off between adding features to a service against improving existing features to be influenced by the service manager in a way that is often not the case in traditional build/run style organisations.
This clear line of responsibility allows for portfolio management and governance to be conducted at a pace that is suitable for the organisation, periodically steering a service to better match the organisational strategy by issuing mandates to that service manager.
By explicitly scoping the role of the service being delivered via the service contract, OSOM limits the ambition of some service managers, who, without limits, might otherwise seek to grow a service beyond its original scope.
OSOM also allows for flexibility in the delivery methodology adopted for any given service. It steps away from the idea that one methodology can suit all projects - and this alone stops organizational upheaval from lurching from lightweight, low-ceremony methodologies to high-touch highly ritualized methodologies like PRINCE2.
This flexibility also helps bridge the often-experienced tribalism between “new and shiny” digital teams, and the more slow-moving, stable corporate technology teams.
OSOM empowers managers to manage how they see fit, and for staff to focus on what truly matters - the delivery of their service.
Service-based organisations can be divided into two, key identifiable parts. The first are the services themselves. Each service has an identified customer or representative known as the Service Owner and a service provider who is the Service Manager.
Service Managers are free to adopt any mechanisms they wish to manage and deliver their service, but what they supply, and how they supply their service is governed by a contract between themselves and the rest of the organisation. Each and every service has a corresponding contract that the service manager is responsible to deliver against.
The second part of the Organised Service Operating Model is the governance organisation - often in a technology organisation, this is the Office of the Chief Information Officer (OCIO) or Office of the Chief Technology Officer (OCTO) but will be referred to in this document as the Executive.
The Executive is responsible for the strategy and governance of the services and performs this latter task by issuing service mandates at regular intervals. A service mandate helps a service manager make better decisions about the service they run, by guiding them in the right direction. For example, a service mandate for a network service might point out that internet-based SaaS packages are being consumed at increasing rates, and the network service should consider that when budgeting; or it might suggest to another service that a different piece of collaboration software should be investigated.
While there is no limit on mandates, they should take care to avoid doing anything that might break the service contract.
Comunities of Practice exist alongside the operating model, as bodies that are freely associated with, to assist people work across the organisation rather than just within a particular service.
Services in OSOM are not the end-to-end silos for a customer journey, or transaction. They are discrete capabilities that can be assembled as components by other, increasingly higher-order capabilities, ultimately to present those customer journeys to users.
Similarly, the word service should not be taken to imply servitude. Just because a customer decides they would like to consume a service, that does not mean that the service will alter itself to gain that customer - quite the opposite. The service presents itself to the world through the guise of the service contract. The customer can agree to that contract and consume the service, or they can decline to agree to it, and not consume it.
Services in OSOM are logical boundaries of operation. They encompass the design, build, deployment and operation of a thing. They need to encapsulate how all those considerations are made in their own context, and they ensure that the consumer is able to consume as advertised. A service should exist wherever there are multiple consumers, and where there would otherwise be duplication of capability in the ecosystem.
Services should be as close as possible to atomically consumable. That is to say, they don’t have a plethora of interfaces by which they can be used. Instead, they have straightforward mechanisms of consumption that can be enumerated with clarity. In a programming sense, this mechanism of consumption would be the API of the service - in OSOM, it doesn’t always have to be, but it often is.
Any change that is made to the service is at the discretion of the manager of that service, and will need to be managed by that individual. That includes ensuring that existing consumers of the service will be able to continue using the service after the change is made - remember, the contract is a two-way street. Just as a consumer cannot demand change, they can also rely on the stability of the contract in the context of the service’s evolution.
In OSOM, Communities of Practice are bodies that are created as needed, associated with freely, and endorsed by the Executive when ready.
In a service-based operating model, sometimes working in a service can leave people feeling disconnected from the type of work they do: designers benefit from the input of other designers, engineers benefit from the input of other engineers.
Service based models also can result in the creation of silos of people who don’t know much about what is going on elsewhere in the organisation. The service any individual works on can become isolated.
Another challenge in a service-based model is that the service manager often will have a background in one discipline, but not in others. They may have a sufficient understanding of design to be able to fairly evaluate designers, but have less of an understanding of engineers.
Communities of Practice are a tool to address these three problems.
Service Contracts are the bedrock of OSOM. They govern the delivery contract between each individual service and the rest of the organisation. Each contract contains the following information:
Who manages the service
The service manager is named up-front in the service contract. It’s really important to identify the person clearly and be sure that they, and everybody else is aware of the person who is accountable and responsible for the service.
Who the service owner is
Who is responsible for the contents of the contract - what the service delivers, and what it is expected to report upon.
What the service does
This sounds obvious but is actually really critical. The service needs to be simple to understand. If the purpose of the service can’t be easily communicated then it probably needs to be rethought.
How to use the service
The service should be easily consumable. If at all possible having read this section of the service contract I shouldn’t have to have any further interaction with anything other than the service itself.
What the expectations of reliability consumers of the service can have, and how they are measured
This is essentially the SLA of the service. The metric that needs to be measured, as well as how and where it is reported.
What to do when those expectations are not met
This is the support structure for the organisation. How do consumers of the service get support for the service? Who do they contact, and what hours do they operate?
The other services that this service relies upon
It is important that dependencies between the services are well known and well-advertised. This is to allow for problem resolution to occur quickly when things go wrong, but also for change management to happen in a decentralised way.
The stage of the technology lifecycle a service is at
Each service has to announce where on the evolutionary axis it sits. This provides hints to the Executive function as to how they should expect to judge the service: is it novel and new? If so it is reasonable that it uses fewer external services. If it is a commodity then it should probably be using formal, waterfall-like methods rather than agile.
How the service will eventually be decommissioned
Services must make it clear how they will be decommissioned. What can consumers expect? Will it be turned off overnight, or will there be a slow wind-down?
Once a service contract has been published, it is rare that they are republished. While some changes will be made - such as who manages the service, or the stage of evolution something is at. It should be very rare that some of the larger sections change at all.
In order to understand the direction of the organisation Service Managers need regular guidance to steer them. A Service Mandate is a tool used by the Executive to steer the direction that services take.
For example, it may be that the company is going to be adopting more internet-based tools, so it is predictable and important that services either optimise their internet consumption, or that the capability of an internet transit service is increased to ensure sufficient bandwidth.
Other than in exceptional circumstances, a Service Mandate should never break the contract of the service it is issued against.
Often organisations want to push governance decisions as much as possible to the executive function of the organisation. Things like architecture, change management, configuration management, etc. In the Organised Service Operating Model, we try to push as many of these responsibilities to the service manager, rather than any controlling brain. In fact, the default answer to any question that starts “Who should….?” will almost certainly be the Service Manager. This default position ensures that the responsibility remains with the Service Manager and that the processes and practices selected will be those best suited to the service, rather than those best suited to people not directly involved in the operation and delivery of a service. This is a good thing!
As the Executive, it is important to consider what good might look like for a particular practice in each phase of evolution. What will work for a novel service is not the same for a service that is a commodity. Rather than operating controlling processes, you instead will make recommendations - sometimes strong recommendations - but recommendations nonetheless.
As a service manager, you’ll have a number of responsibilities that you’ll have to take care of. All of those processes will need some sort of approach that you have adopted in your service. It will be up to you to select what works best for you, and you’ll find that your Executive will want you to defend your selections when the time comes.
That may mean choosing practises that they recommend, or it may mean selecting other approaches to perform whatever task is required. The important thing, however, is that in both cases, you’re responsible for the outcome. If the approach you’ve adopted doesn’t work, it’ll be your responsibility.
As the Executive, it’s important that you review how your service managers are approaching things. It is likely that the reason they are selecting approaches that differ from your recommendations is that their circumstances don’t precisely match those you envisaged.
If you find this is the case in a number of services that sit in the same phase of the evolutionary axis, then it may be time to consider revising the recommendations you make, or at least considering very carefully why the recommendations being made are rejected by the service managers operating at the coal-face.
In OSOM change management is a function of the organisation itself, rather than any one particular group. If a service manager is introducing a change that is going to break their service contract it is incumbent upon them to notify all dependent services and ensure that the change is coordinated with them. Failure to do so is a failure of the service that is changing.
In the case that a dependent service refuses to change, the OCTO governance team will mediate between the service managers. Refusal to change, however, should be viewed as equally problematic as an insistence on change.
Budget management also becomes the responsibility of the service manager. This means devolving budgetary authority, accountability and responsibility to each service. Budgets can be adjusted in the usual OCTO mandate-issuing process, and OCTO can and should be involved in scheduling and planning of business cases that may be required to invest in any particular service. but similarly, it should be possible to allow service managers to re-invest savings made in-year.
As a Service Manager you will be responsible for the delivery of a service contract. The service contract describes what must be delivered, but not how - that is your responsibility. It may be that your service is best engineered by a team of developers that report to you, and designed by a team of designers, or, alternatively, it may be preferable for you to manage the contract between your organisation and a third-party service provider.
Either way, if you in-house or outsource all, or some of your service you remain responsible for ensuring that the service contract is met.
You’ll need to decide how best to arrange for the development and delivery of your service - that includes the best methodology to employ.
As the service manager, you should receive a budget for the delivery of your service. It will be up to you to operate within the constraints of that budget. If you can’t, you’ll need to create a plan and a business case to request greater funding, or perhaps, to petition them to change the level of service in the contract.
Published on [date]; managed by [Service Manager name]; owned by [Service Owner];
[Describe what the service does so that someone can decide whether they wish to use the service or not. Also, include a description of how to use the service]
[Describe what sort of levels of service a consumer of the service can expect, and how to get support if required]
[Enumerate the services that this service requires]
[Is this service novel or new, is it custom-built, is it a product, or is it a commodity?]
[Describe how the service will eventually be decommissioned. This will be different based on where in the lifecycle any given service is]