{"id":65,"date":"2022-05-20T10:20:00","date_gmt":"2022-05-20T10:20:00","guid":{"rendered":"https:\/\/baecke.io\/?p=65"},"modified":"2022-05-20T10:20:00","modified_gmt":"2022-05-20T10:20:00","slug":"cloud-operating-model-series-4-provider-consumer","status":"publish","type":"post","link":"https:\/\/baecke.io\/?p=65","title":{"rendered":"Cloud Operating Model Series (4\/6): Provider vs Consumer, the Service Model Shift That Changes How IT Operates"},"content":{"rendered":"<p>The move to a cloud operating model asks IT to do something genuinely uncomfortable: to stop thinking of itself as the owner of infrastructure and start thinking of itself as the provider of a service.<\/p>\n<p>That sounds like a change of vocabulary and is actually a change of identity. An owner of infrastructure controls a resource and grants access to it, which casts IT as a gatekeeper. A provider of services offers capabilities to customers and is judged by how well those customers are served, which casts IT as an enabler. The whole Cloud Operating Model turns on this shift, and the friction most enterprises feel in adopting it comes from making the change in name without making it in mindset, leaving IT calling itself a service provider while still behaving like a gatekeeper.<\/p>\n<h2>The Consumer-Provider Dynamic<\/h2>\n<p>At the heart of the model is a relationship between IT as provider and the rest of the organisation as consumer, and the two come at it with different priorities. The consumer wants speed, self-service, and the freedom to get on with their work. The provider wants control, consistency, and assurance that the rules are followed. Neither set of priorities is wrong, and the friction between them is not a problem to be eliminated but a tension to be managed by design.<\/p>\n<p>The misalignment that creates the worst friction is when the provider optimises entirely for its own priorities and treats the consumer&#8217;s needs as someone else&#8217;s concern. That is the gatekeeper failure mode: IT builds for control and experiences the consumer&#8217;s demand for speed as a threat to be resisted. The service-provider mindset inverts this. It starts from the consumer&#8217;s needs and builds control into a service designed to meet them, so that speed and governance arrive together rather than fighting.<\/p>\n<h2>Why One Size Fits None<\/h2>\n<p>The mistake that defeats most service-design efforts is building a single service for a single imagined consumer, when IT actually serves several very different ones. A one-size-fits-all service fits none of them well, because the people consuming IT&#8217;s services have genuinely different needs, and a service tuned to the average serves everyone equally poorly.<\/p>\n<p>This is why the model is persona-based. Enterprise IT has to design for distinct personas, each with its own priorities. Developers want fast, frictionless self-service and get blocked by anything that makes them wait. Platform engineers want robust, composable building blocks they can assemble. Business unit leaders want outcomes and cost transparency, not technical detail. Security and compliance teams want assurance, auditability, and control. A service that treats these four as one constituency will frustrate all of them, because what delights a developer is not what reassures a compliance officer, and forcing both through the same undifferentiated service satisfies neither.<\/p>\n<h2>Designing the Service for Each Persona<\/h2>\n<p>Persona-based service design means building the service catalogue, the self-service experience, and the governance model to serve each persona on its own terms while keeping the whole coherent. The developer gets genuine self-service, fast and frictionless, within guardrails they rarely have to think about. The platform engineer gets composable primitives and the freedom to build. The business leader gets a view of outcomes and costs in business language. The security team gets the policy enforcement and auditability that lets them assure the whole without inspecting every part.<\/p>\n<p>The art is doing this without fragmenting into a different system for everyone. The personas are served by different views and different entry points into a common, consistently governed platform, not by separate platforms that reintroduce the silos the operating model exists to remove. One platform, several front doors, each designed for who walks through it. That is what makes the service model work in practice, and it is the part that turns the abstract provider-consumer shift into something an organisation can actually operate.<\/p>\n<h2>Design for Who You Actually Serve<\/h2>\n<p>The provider-consumer shift is the identity change at the centre of the cloud operating model, and it succeeds or fails on whether IT genuinely adopts the service-provider mindset or merely the title. Adopting it for real means designing services around the distinct personas IT serves, the developer, the platform engineer, the business leader, the security team, each on their own terms and through a common, well-governed platform. Build one undifferentiated service and you will serve no one well, while wondering why adoption is poor and shadow IT persistent. Design for who you actually serve, and IT stops being the gatekeeper everyone routes around and becomes the provider everyone chooses to use.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>A cloud operating model asks IT to shift from owner of infrastructure to provider of services, and from gatekeeper to enabler. Making that work means designing services around the distinct personas IT actually serves.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-65","post","type-post","status-publish","format-standard","hentry","category-operating-models"],"_links":{"self":[{"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts\/65","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=65"}],"version-history":[{"count":0,"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts\/65\/revisions"}],"wp:attachment":[{"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=65"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=65"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=65"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}