The Architecture of Delivery: Constraint, Flow, and the Domain-Aligned Squad

It is submitted that the prevailing orthodoxy of software delivery—characterised by local optimisation, functional silos, and the uncritical adoption of ritualistic frameworks—is fundamentally misaligned with the exigencies of complex systems. This article advances a constructive alternative grounded in the Theory of Constraints, Value Stream Management, and Domain-Driven Design. It argues for the reconstitution of delivery teams as small, domain-aligned feature squads, the reduction of blast radius through vertical decomposition, the empirical determination of internal process according to uncertainty, and the cultivation of T-shaped development. The dissolution of traditional Operations into Development squads is posited as a necessary corollary. The objective is not merely efficiency, but the sustainable production of value.

I. Introduction: The Primacy of Systems Thinking

The pursuit of efficacious software delivery is not, *prima facie*, a matter of mere technical proficiency. It is, *a fortiori*, a question of systems thinking. The failure to appreciate the interdependence of constituent processes—the etiological root of much project failure—ineluctably conduces to suboptimal outcomes. It is incumbent upon leadership to eschew the seductive allure of local optimisation, which, as the Theory of Constraints demonstrates, may exacerbate global inefficiency. The following analysis proceeds from this foundational premise.

II. The Theory of Constraints and Flow/Systems Thinking

The Theory of Constraints, socialised in *The Phoenix Project* by Gene Kim, George Spafford, and Kevin Behr, posits that any system is limited by a finite number of constraints, and that the performance of the whole is determined by the weakest link. Flow/Systems Thinking, derived from this insight, necessitates two cardinal principles: first, the prohibition of passing defective work downstream—that is, the rolling out of code with failed tests—and second, the refusal to optimise a local process at the expense of the global lifecycle. The former is achieved through the adoption of Cycle Time metrics and the systematic drilling into bottleneck areas to remove constraints. The latter requires a holistic appreciation of the value stream, lest the organisation find itself, *mutatis mutandis*, in the position of improving the speed of a stage that is not the constraint, thereby merely accumulating work-in-progress.

III. Value Stream Management

To ameliorate the pipeline from start to finish, it is indispensable to commence with an examination of the whole. Value Stream Management (VSM) entails the mapping of the complete Software Development Lifecycle (SDLC), from task prioritisation to the operation of a feature in production. Upon this cartography, one may calculate metrics such as Cycle Time and drill into areas susceptible to improvement.

The methodological sequence is as follows: first, ascertain the baseline (Cycle Time); second, drill down to identify improvement areas; third, ascertain root cause and propose the fix; fourth, repeat often. This iterative, empirical approach is the *sine qua non* of continuous improvement.

IV. The Case for Small, Domain-Aligned Squads

The CHAOS report, *inter alia*, demonstrates a robust correlation between project size and success. Over a four-year period, the database revealed that whereas 43% of grand projects failed, only 7% of small projects failed. Indeed, small projects are over nine times more likely to be successful—on time, on budget, and on target—than their larger counterparts. A transformation towards Scrum will provide little value, if any, if the persons engaged in building a new feature are not attending the same low-level team Daily Scrum to resolve obstacles to delivery. For productivity to be achieved, teams must be reconstituted as ‘feature squads’ aligned to domains—that is, mini shippable apps or products.

Domain-Driven Design (DDD) is a philosophy born of the need to realign the focus of development teams writing software for complex domains. The whole flow has one Product Owner, leading to quick alignment, a clear product vision focused on the user experience, and alignment to business value (better return on investment) and OKRs. Overall, this constitutes an easier life for the Product Owner. It should be *de rigueur* for the Head of Dev to shuffle which tech team works on which repository. The opportunity exists to achieve an understanding between Product and Dev. Our criteria for distribution activities relating to components must be efficiency, and not how thankless the task may seem.

No more of this ‘throwing it over the fence’ or ‘not my problem’ tennis matches. It is human nature; we can waste time fighting that, or we can work with how people are. A team comprising front-end, back-end, and QA specialists focused on a narrow product slice that impacts just a handful of repositories, is the model.

V. Reducing Blast Radius

"Limit the effects of an outage by using limited blast radius practices" (https://www.ibm.com/garage/method/practices/manage/practice_limited_blast_radius/)

It is prudent to limit the effects of an outage by using limited blast radius practices. Splitting the applications vertically, by delivery stream or domain, with a focus on the customer, achieves this. Each squad owns a section of the UI and a collection of microservices in isolation. This reduces the blast radius of any bug they introduce.

Sir Tim Berners-Lee, inventor of the World Wide Web, explains: “There are lots of reasons for modularity. The basic one is that one module can evolve or be replaced without affecting the others. If the interfaces are clean, and there are no side effects, then a developer can redesign a module without having to deeply understand the neighbouring modules. The flip side is that a cleanly designed module designed as part of one system can be re-used in other systems.” As a result, delivery pipelines have a narrower scope, a smaller blast radius, and less impact from defects. Feature flags become more viable, though nonetheless not for every situation.

One however must be on guard so as not to pursue this concept merely for the purpose of 'riding the bandwagon'. Decoupling, however seductive in the abstract, is not a viable expedient where the entirety of the system subsists upon a single, shared database. Under such conditions, the constituent parts remain inextricably interwoven, and the labour expended would be considerable while the advantage secured would be nugatory. Moreover, such a course would engender gross duplication, entailing the reconstitution of logic already extant within DFX. The authentic problem must be confronted. It is a matter of urgency that DFX be (a) decomposed into microservices—portions of its logic being reconstituted as discrete services—so as (i) to facilitate CI/CD and (ii) to attenuate the blast radius—and (b) rendered wholly amenable to ‘full-stack’ feature teams.

VI. The Determination of Internal Process

The Spotify model champions team autonomy, so that each team (or Squad), not the Product function, selects their framework—be it Scrum, Kanban, Scrumban, or otherwise. “The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.”

The decision as to which framework or approach to use should be driven by the degree of uncertainty. For Scrum to work, the Product function needs to be empirically driven, and provision accurate requirements, mostly keeping to those for a fortnight. It requires strong stakeholder management, with clear prioritisation, a clear Sprint Goal, and embracement of an MVP approach.

However, companies are not necessarily at this stage, and a prescriptive application of whatever one heard at a Scrum training session could do more harm than good. In the Stacey Matrix, where both requirements and the technology feature high degrees of uncertainty, Kanban is appropriate, rather than Scrum. The Scrumban approach is a Kanban-based triage featuring a work-in-progress limit, with the inclusion of some Scrum events to provide feedback loops, e.g., the Daily Scrum.

Feature Squads are cross-functional, self-managing teams (10 or fewer individuals; Brooke’s law) that focus on one feature area. Each Squad has a unique mission that guides the work they do, an Agile coach for support, and a Product Owner for guidance. The technical function determines which agile methodology or framework will be used, according to circumstances. Two obstacles may prevent this approach: domains are not clearly defined; Product Owners do not align to actual domains; and teams are heavily intertwined, i.e., many dependencies between the codebases.

VII. T-Shaped Development

A feature squad has the necessary knowledge and skills to complete an end-to-end customer-centric feature. The squad members are diverse, featuring Product Owners, BAs, front-end developers, back-end developers, QAs, etc. They may have their specialisms and strengths, but come together in the spirit of ‘collective responsibility’ to get an item across the line. The overall objective is not for each person to finish their ticket, but to collaborate as a team, jumping on whatever needs help, whether it is their specialism or not.

VIII. DevOps and the Dissolution of Operations

The designation ‘DevOps’ would appear to be susceptible of a broad construction, to wit, ‘Developer’s Ops Team,’ after the fashion of ‘ProdOps.’ That which currently obtains under the appellation ‘DevOps’ is, in substance, the Platform team, to which the Development squads stand as clients. Where QA responsibilities are devolved upon Development squads, the QA practitioners are, by necessary implication, subsumed within those squads. Therefore, a “DevOps” culture and team structure would entail the dissolution of the Ops team and its scattering across the Dev squads, as was done with QA squads. There is potential to transform ProdOps to SRE.

IX. Conclusion

The architecture of delivery herein proposed is not a panacea, but it is a coherent alternative to the prevailing orthodoxy. It rests upon the recognition that systems must be understood in their entirety; that constraints must be identified and removed; that value streams must be mapped and measured; that teams must be small, domain-aligned, and cross-functional; that blast radius must be reduced through vertical decomposition; that process must be determined empirically according to uncertainty; that development must be T-shaped; and that Operations must be integrated into Development. It is respectfully submitted that this is the positive, evidence-based way forward.

References:

1. Kim, G., Spafford, G., & Behr, K. (2013). *The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win*. IT Revolution Press.

2. Standish Group. (1994). *The CHAOS Report*. Standish Group International.

3. Berners-Lee, T. (1999). *Weaving the Web: The Original Design and Ultimate Destiny of the World Wide Web*. Harper.

4. Stacey, R. D. (1996). *Strategic Management and Organisational Dynamics*. Pitman.

5. Sutherland, J. (2014). *Scrum: The Art of Doing Twice the Work in Half the Time*. Crown Business.

6. Brooks, F. P. (1975). *The Mythical Man-Month*. Addison-Wesley.