Last time I developed the Strategy Pattern "Provide-from-Stock" for you.  This month I will wrap up this series with the "Assemble-to-Order" Pattern. 

Clearly, you have to change the strategy … to an Assemble-to-Order strategy … Mass-Customization, "custom products, mass-produced in quantities of one for immediate delivery."  But this then is a completely different kind of business.  You have to have PARTS in inventory … NOT finished goods … and those parts have to be engineered such that they can be assembled into more than one product. 

How do you engineer parts that can be assembled into more than one thing?  You have to know the total set of things you have to assemble at any given point in time.  You do the engineering Enterprise-wide. 

After you engineer the parts to assemble the Enterprise set of products, you can pre-fabricate the parts and have them in inventory before you get the order.  Then when you get the order, the only time it takes to produce the custom product is the time it takes to map the specifications of the product in the order to the inventory of parts, pick the parts, and assemble the custom product to order.

So, the pattern is...

"Make-to-Order" ---> "Provide-from Stock" ---> "Assemble-to-Order"

Having engineered parts that can be assembled into the Enterprise set of products at any given point in time provides substantial flexibility to support changes in the Enterprise Product set.  However, when products are demanded that are beyond the capability supported by the current inventory of parts, it is a matter of a "delta" to parts … not a major overhaul of the manufacturing process and the product line.

I am sure you have already figured out the Enterprise Engineering and Manufacturing equivalent for the assemble-to-order strategy.  If you engineer the Enterprise, Enterprise-wide, creating the set of Primitive models as specified in the Zachman Framework and you populate a database (Repository) with the inventory of Primitive Components, you could map the characteristics of the new Enterprise to the Primitive Components, pick the Primitive Components, and assemble them (bind them at execute time) into a Composite implementation, dynamically, custom to the specification of the new Enterprise as required.  "Custom Enterprises, mass-produced in quantities of one for immediate delivery."

This is a little over-simplification, but I think you get the idea.  You don't have to populate all of the Cells of the Framework — Enterprise-wide, integrated horizontally and vertically at excruciating level of detail — before you produce any implementations.  That is a common MIS-conception!  You can populate the Framework primitives iteratively and incrementally, implementation by implementation, using the governance system to maintain the continuity and integration over time.  You do have to have a Repository metamodel that maintains a separation of the independent variables and allows you to dynamically bind Primitive Components into Composite implementations. I have written another book on Models and Metamodels that elaborates this issue.

This column can also be viewed on John's blog — presented here, with permission.

# # #