IT service build is not a factory

There is a widespread idea in IT that IT is a factory, repeatably turning out code which can be treated as identical products on some kind of optimisable production line. This is only true for parts of our IT world: e.g. standard requests, standard incidents and changes, bug fixes. It's usually not true of building IT services.

What do we mean by factory in this context? We mean that building software can be treated like a production line cranking out standardised components, where we manage work-in-progress (WIP), and we optimise repeated tasks.

IT is not really a factory. I wrote last year about the applicability of factory-floor techniques to IT in general. I want to focus today on service Build in particular. You can't generally treat Build as a factory. Only a sector of the build-centric community think so. The people who run the shop know better; ITSM knows better. IT is more often a bespoke engineering shop, building one-off make-to-order systems, not make-to-stock components as if we were churning out flat-pack bookshelves.

Charles Betz laid this out brilliantly - as ever - in his book Architecture and Patterns for IT Service Management, Resource Planning, and Governance: "IT solution development and service delivery are more variable than stereotypical manufacturing processes". I would like to quote more here but all my reference books are in storage right now, so buy the book and read for yourself.

There are production lines in IT: request fulfilment for example. Even the transactions that flow through our completed services can be thought of as a production line. But service Build is not a factory production line in most contexts.

It's not about how much code you crank out, it's about how much value you deliver to the business. IT value is measured in confidentiality/integrity/availability (CIA) of information as well as the quality of that information. One part of value is the cleverness of the apps that deliver it, but an equal part is the CIA if the information in the resulting system. Then I think a third - and equal - component of value is the service delivered to the customers: how well the information is improved, planned, managed, and supported: both Build and Run contribute to the service.

A great blog post (about something else) by Neil Ernst said

One of the most difficult parts of doing research in Software Engineering is its inherently uncontrollable, one-off nature. Sure, in some cases—like websites for restaurants, for example—we see repeatability. But the most interesting projects, the ones SAFe is applied to, the complex or perhaps complicated ones, there is no repeatability (by definition). This makes it impossible to say with any degree of accuracy what factors are contributing to the success or failure of the project.

And yet our IT sector is beset with mindsets and methodologies that treat IT as a factory: Agile, DevOps, Lean, Six Sigma, TQM, ToC, Kanban, CMMI... The whole premise of the book The Phoenix Project is that we can model IT on a factory and learn from manufacturing theory.

To take one example, the Theory of Constraints (ToC) says "any improvement not made at the constraint is an illusion". I'm probably showing my ignorance of ToC here, but it seems to me that statement is true only if all you care about is to improve throughput of code: that build-centric thinking again. ToC is improving how much you can crank out, not how good the resulting system is. This is of course misleading: quality can be improved at any stage in the process.

So is the factory analogy ever true for Build? Sure, if you are a software product vendor or a development house, and you are able to break code down into small fragments which mostly fall into sets of similar functionality. It's probably applicable if you are an in-house application project using Agile and successfully breaking development down into those tiny fragments. Although I'm not convinced that the fragments are similar enough to apply principles of CMMI or ToC because you don't necessarily have the repeatability and hence predictability to be doing factory production-line optimisation.

It is emphatically not true for most IT organisations - for Real IT - who are reducing their in-house development and sourcing more apps as great big gobs of COTS software or SaaS services. The adoption, configuration and rollout of such a system is a one-off engineering endeavour. We should spend less time looking at factories for guidance and more time looking at civil engineers. Outside of the software development companies, for the rest of us - most of us, the Real IT - we are are not code factories, we are information engineers.