The signals of a broken IT operating model are familiar to anyone who has worked in or with a large enterprise technology function in the past five years. Projects that take months to approve and months to staff before a line of code is written. Platform choices that reflect the preferences of a central architecture team rather than the operational requirements of the product teams that will use them. Security reviews that happen at the end of the delivery cycle because the security process was not designed to operate at delivery pace. Cloud costs that grow faster than the business value they generate because the accountability for spending sits with a team that does not see the business outcome it is enabling.<\/p>\n
These are not individual dysfunction indicators. They are symptoms of an operating model whose structural characteristics produce these outcomes consistently, regardless of the quality or effort of the people operating within it. The model is the problem.<\/p>\n
The governance structures in most legacy IT operating models were designed to manage the risk of large, expensive, slow technology programmes. Project governance, change advisory boards, architecture review processes, and investment approval frameworks all reflect a risk management approach calibrated to a technology environment where changes were infrequent, expensive to reverse, and executed by large teams over long timescales. In a cloud-native, continuous delivery environment, these risk management structures add cost and latency without providing the risk reduction they were designed for.<\/p>\n
The funding models are equally misaligned. Annual budget cycles that allocate technology funding as departmental overhead do not support the investment patterns that cloud-native product development requires: continuous investment in small increments against a business outcome, rather than large upfront commitments to project deliverables. The mismatch between the funding model and the delivery model creates the projects-within-products confusion that slows enterprise technology delivery and distorts the accountability for technology investment.<\/p>\n
The IT operating model redesign that resolves these structural failures is not a single change. It is a set of interlocking changes that together produce a different system behaviour. Implementing any one of them without the others produces partial improvement and new friction.<\/p>\n
Governance redesign moves from project governance to product governance. Products are ongoing capabilities with continuous investment, measured by business outcome rather than project completion. The governance model for products is different from the governance model for projects: investment decisions are made based on product performance against business outcome metrics, not on project scope and schedule adherence. The change advisory board that reviews every change is replaced by continuous deployment with automated compliance validation, with human review reserved for the changes where the risk profile genuinely warrants it.<\/p>\n
Funding model redesign moves from annual budget allocation to continuous value-based investment. This is the change that most organisations describe as desirable and few achieve, because it requires coordination between the technology function, finance, and the product and business owners who together determine investment priorities. The practical implementation typically begins with pilot product teams that operate on a value-based funding model within the existing budget structure, demonstrating the model before the broader organisation changes.<\/p>\n
Delivery model redesign moves from project-based delivery to product team delivery. The stable, cross-functional product team that owns a business capability end-to-end, including its technology components, is the delivery unit that cloud-native product development requires. The project that assembles a team for a defined scope and then dissolves it at completion is the delivery unit of the previous model. The transition from one to the other is an organisational change that affects career structures, reporting lines, skills development, and management model.<\/p>\n
There are specific governance failures in the legacy IT operating model that have to be addressed explicitly, because they will reassert themselves if the redesign leaves them structurally intact.<\/p>\n
The architecture bottleneck is the first. Central architecture teams that must review and approve every significant technology decision create a bottleneck that guarantees delivery delays and discourages the kind of iterative experimentation that modern product development requires. The redesign replaces central architecture approval with architecture governance: principles and guardrails that product teams operate within, supplemented by central expertise that teams can access when they need it rather than by central control that they must navigate to proceed.<\/p>\n
The security gate is the second. Security review processes that insert between delivery and deployment are governance structures designed for a delivery pace at which they could operate. At continuous delivery pace, they are blocking rather than governing. The redesign moves security from a deployment gate to an integrated practice: security requirements in the product backlog, automated security validation in the pipeline, and security expertise embedded in or available to product teams rather than operating as a central checkpoint.<\/p>\n
The change management bureaucracy is the third. Change approval processes that require multi-week lead times and cross-functional committee sign-off for routine changes are legacy risk management designed for a risk profile that cloud-native delivery does not have. The redesign implements automated deployment verification, comprehensive observability, and fast rollback capability that provide better risk management than pre-deployment committees, at the speed that continuous delivery requires.<\/p>\n
The IT operating model redesign described above requires changes that will create short-term disruption and resistance. The governance structures being redesigned are owned by people whose roles and authority are defined by them. The funding model being changed is controlled by finance processes that have been stable for years. The delivery model being shifted is the established pattern for most of the technology organisation.<\/p>\n
None of these changes happen without executive leadership that is prepared to endorse the disruption, protect the redesign from the resistance that will arise when established interests are threatened, and maintain the commitment through the twelve to eighteen months before the new operating model is generating the outcomes that validate it.<\/p>\n
Organisations that attempt operating model redesign without this executive commitment produce a set of pilot teams operating in a new model surrounded by an organisation still operating in the old one. The pilots succeed. The model does not propagate. The organisation concludes that the new approach works for some teams and not for others, and uses that conclusion to avoid the broader change.<\/p>\n
The operating model change that actually works requires the executive sponsor who refuses to accept that conclusion.<\/p>\n","protected":false},"excerpt":{"rendered":"
Most enterprise IT operating models were designed for a world of stable infrastructure, waterfall delivery, and centralised technology ownership. That world no longer exists, and the operating models designed for it are actively obstructing the organisations that still use them.<\/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-114","post","type-post","status-publish","format-standard","hentry","category-operating-models"],"_links":{"self":[{"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts\/114","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=114"}],"version-history":[{"count":0,"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts\/114\/revisions"}],"wp:attachment":[{"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=114"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=114"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=114"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}