An operating model describes how IT is set up to do its work: how teams are staffed, how decisions are made, how people collaborate, and which capabilities support delivery. It should follow business goals and technical choices rather than be designed in isolation. section 16.1.2
A useful starting question is whether IT in a particular domain provides business differentiation or primarily serves a utility role. The answer should affect financial, organizational, and technology investment. Greater strategic contribution generally justifies greater investment, but not the same arrangement for every team. section 10.1.1
Tailor the arrangement by asking:
- What team size and mix of skills suit the domain? Where would closer collaboration between domain experts and software engineers, or more discovery work, improve differentiation? section 10.1.1
- Which work deserves priority, and which dependencies slow valuable change enough to warrant removal? section 10.1.1
- Where do architecture, domain modeling, and code health merit sustained investment to support future change? section 10.1.1
From business capabilities to a target arrangement
At IgluCruise.com, leaders mapped business capabilities as unique, supporting, or generic, then examined how technology supported them. Their target architecture distinguished where to build and where to buy. From that architecture, strategic objectives, IT actions, and business context, they designed a target operating model covering team structure, decision rights, ways of working, partners, performance measures, tools, and talent. The test was whether each choice could be traced to business success. section 16.1.2
Treat the result as a revisable set of choices, not a fixed end state. When business or technical context changes, revisit the assumptions behind the strategy and adjust the operating model accordingly. section 16.1.2 section 16.4
