Contents

The Tortoise and not the Hare - Part 1

Contents

/images/posts/2009/11/production-line-300x195.jpg

The production line is one of the marvels of the industrial era. I’ve always been fascinated with production lines in factories and how a product, like a car, gets constructed from individual components and grows until finally it rolls off the production line as a finished product. In the last few years I’ve been thinking more and more about production lines and how they overlap with IT Operations. So do they have anything in common? Can you draw parallels between building a car and running an IT operation? Damn right you can!

Production lines construct assets from components and then sells these assets. IT shops also construct assets, in the form of software, infrastructure and services. These assets are also constructed from components to make a functioning whole and are then sold to customers. The perfect example is hosting infrastructure. A host is constructed from hardware (CPU, storage, networking), software (operating system, applications) and configuration data and then delivered to a customer for use (or “sale”). I’m going to look at the core principles of production lines, specifically some of the methodologies around their management, and see if they offer value in running IT organisations and operations. I’m also going to demonstrate some work flow and how to use some tools (like Puppet and others) to model these principles in your own IT shop.

The production line relies heavily on process and continuous flow to function efficiently. The asset moves through the line having actions performed on it or components added to it. The objective is an uninterrupted flow from beginning to end with enough of the right components, processes and people being introduced at the right time. Getting this production life cycle right isn’t easy. As a result, the study and practise of production line management has become a science.

One of the most famous methodologies is the Toyota Production System or TPS. If you work anywhere where process is important - and that’s pretty much every manufacturing organisation and almost every large corporate (including banks, insurance companies, transport, logistics and a flurry of others) - then you’ll probably have heard of TPS and one of its integral components, Kanban. The TPS is a lean/Just In Time (JIT) production practice model. Lean practises are ones where the focus is on the activities that deliver customer value. Resources that are expended on other activities are always suspect and targets for elimination. JIT attempts to improve ROI (“Return on Investment”) by streamlining production process, managing demand and hence reducing the amount of inventory (“parts”) carried so that only the parts needed are stored and then for the shortest possible time before being consumed for production.

So where does Kanban fit in? Kanban is a demand management and signalling system that uses physical signs to act as triggers between processes. I’ve stolen a very simple kanban example from Wikipedia:

“A simple example of the kanban system implementation might be a “three-bin system” for the supplied parts (where there is no in-house manufacturing) – one bin on the factory floor (demand point), one bin in the factory store and one bin at the suppliers’ store. The bins usually have a removable card that contains the product details and other relevant information – the kanban card. When the bin on the factory floor becomes empty, i.e, there is demand for parts, the empty bin and kanban cards are returned to the factory store. The factory store then replaces the bin on the factory floor with a full bin, which also contains a kanban card. The factory store then contacts the supplier’s store and returns the now empty bin with its kanban card. The supplier’s inbound product bin with its kanban card is then delivered into the factory store completing the final step to the system. Thus the process will never run out of product and could be described as a loop, providing the exact amount required, with only one spare so there will never be an issue of over- supply. This ‘spare’ bin allows for the uncertainty in supply, use and transport that are inherent in the system.”

Simple huh? You can also readily scale this example by adding multiple bins (which each have their own kanban card). This allows tights controls on stock management (and hence costs!).

So can we apply these concepts to IT infrastructure? Hang onto your hats because in Part II of this series of posts I’m going to do exactly that.