So, I just finished Steve Bell's excellent Lean Enterprise Systems... a book that has already contributed to one insight, that of the CMDB as a Bill of Materials or Resources.
Another well written section was that covering the continuum of manufacturing models. While this breakdown is industry standard (appearing also in Vollman's Manufacturing Planning & Control Systems for Supply Chain Management, the official APICS text), Bell's discussion is concise and effective, and got me thinking more about how to apply the concepts to transactional IT considered as the "shop floor."
The major continuum is:
- Make to Stock
- Assemble to Order
- Make to Order
- Engineer to Order
in order proceeding from higher volume, more standardized products, to lower volume and one of a kind products.
However, I think that there is a missing one: Make as Service. (I know, how dare I propose an extension to APICS standard terms!)
If we accept that part of the basic definition of service is that it is simultaneous, we have a class of activity where the product is assembled in real time based on customer pull. If the product is information, we have an IT service, providing transactional information in real time.This allows us to see transactional IT systems as part of the same continuum.
The two ends of the spectrum then become:
- Engineer to Order
- Make as Service
Here is an interesting conjecture: any high volume, deterministic Make to Stock or Make as Service processes are themselves the product of one or more Engineer to Order (ETO) processes. In fact, is not product development in general a form of an Engineer to Order process? Think not about producing the product, but rather producing its assembly line.
Certainly, as I look at Bell's characterization of ETO:
"Complex presales design and engineering... unique design may require a large and complex multilevel BOM using many unique and often custom-built parts that have never before been purchased or manufactured. In many ETO environments, a permanent finished part record is not created... rather, a job or a project record is created... often scheduled as a multiphase project rather than a single process flow..."
I am struck by its similarity to large IT projects. Hence the fundamental point of this post:
The large scale enterprise IT organization is fundamentally an Engineer to Order concern.
What is interesting is looking at the practices of industrial ETO shops in general (the non-IT kind, like engineering firms). Per Bell, there is a degree of rigor and consistency not typically found in the large IT organization, where development practices may vary wildly from group to group and even the most basic forms of record keeping non-existent. The question:
are there unappreciated ETO practices that might benefit the large IT organization?
Bell is not unaware of this analogy, as towards the end of his book he characterizes Agile as a form of Assemble to Order. But in the case of any novel IT system, there is always an engineering aspect: what programming language shall we use? what design patterns? what middleware? what OS? what hardware? These decisions set boundary conditions and cannot easily be altered, unlike agile increments of functionality.They require careful analysis and may consume considerable time and effort to solidify.
There is another form of Assemble to Order, however. The boundary between applications and hosting groups (what I have termed the Hosting Zone of Contention) perhaps delineates an ETO/ATO boundary. Software development is less deterministic than assembling a hosting environment, especially if one is using predefined patterns of infrastructure. In fact, the trend towards standard infrastructure patterns (up to and including cloud platforms) combined with the use of software design patterns can be seen in general as an attempt to move system development from ETO towards ATO, reducing complexity, cycle time, and other kinds of waste.
However, we must never forget that we are dealing with general purpose computing machines here (in the Turing, not the Dell sense). From a computer science perspective, ETO processes involving computation will resist full migration to more rapid, deterministic ATO processes due to the inherent uncertainty of computational results pre-computation for any systems involving more than three states. (See Halting Problem.) That is to say, in the general case, we cannot automatically engineer any non-trivial information system and know that it will run correctly, before we have actually tested it over a variety of inputs.
Hence, we will never see systems engineering itself translated into a simple MTO or ATO model. This may be possible in specific cases, but in the general case, it will always present ETO problems, implying the requisite skills, and harboring the essential complexity of software engineering, as imperishably stated by Brooks in "No Silver Bullet."
