Group Technology For DevOps

One of the often overlooked concepts absorbed by the umbrella term of Lean is Group Technology. The concept originated in Russia, was refined in the UK and then seized upon by North America in the 1960-1980s period, especially when robot cells and flexible manufacturing were the fashion in Manufacturing Systems.

Basically the concep was simple. Old fashioned manufacturing factories used to be laid out in "functional" organisations. So, say, all the Lathes were in one corner, the drilling machines would be in another part of the factory and the milling machines in a different part or even a different building.

A component might require that: 

1. bar metal was cut to size - done by the sawing section;
2. it was turned to shape - done by the lathes section;
3. some holes were drilled - done by the drilling section;
4. a flat surface was milled on one side - done by the milling section;
5. one end was polished extra smoothly - done by the grinding section;
6. before final inspection, packing and shipping.

Each step would be conducted under the aegis of a different foreman. Each foreman had his own priorities and was tasked with running his section efficiently. At each step, the appropriate machine would have to be set up, perhaps with a special jig as well as, with its specific set of cutting tools.

So the process was a long series of queues and delays for set up, with only a small portion of time spent actually cutting metal. Efficiency was assure by having as much work as possible queued at each section, so the machinists never ran out of work.

Process times were long, delivery dates were never guaranteed to meet promised delivery dates, but it appeared efficient, even if  lots of money (working capital) was tied up in work-in-progress inventory. It was great for the foremen, because they were never individually to blame if something was late.

Group technology, was originally focused on reducing setup times. It involved using a classification system to identify parts which were similar to manufacture, e.g. small long thin round round parts or large short squarish parts, and batching them together for manufacture at the same time.

Then the idea of the group technology cell was introduced. All the machine required to make small round parts were organised into one part of the factory, in the normal sequence in which they might be used, creating a flow line. So similar parts were all sent to the same cell and put under the control of a single foreman who was also responsible for delivery performance. This allowed parts to be batched and pipelined along the natural flow line to meet both effectiveness and efficiency needs. It also meant that there was only one queue, the one going into the cell and work in progress could be reduced. Adding TQM techniques into the mix, so that the foreman was responsible for quality as well, turned him into a mini production manager and enabled quality to be improved. Then, where practicable, automation was introduced to raise overall performance further.

So what does this mean to IT operations. Well most organisations have normally organised so that the unix/linux administrators sit in one corner reporting to a senior administrator. The NT administrators sit in another corner with their senior administrator. PC administration sits under desktop support. DBAs sit in their own little getto, with a senior DBA. The network administration people might be in another building. If global outsourcers are involved, then corners become "Competency Centres" often geographically dispersed.

In traditional "on premise" or "in data centre" operations, a large part of the time of administrators is focused on the box shifting aspects of the role with manual administration of builds and maintenance tasks. No one team is responsible for the support of an application. So when things go wrong, different disciplines point the finger at each other, saying "our bit works it must be theirs which has gone wrong". This makes reacting to incidents slow and innefficient, and slows down releases of new features. So what appears efficient is an inhibitor on value by slowing change and reducing uptime..

Modern "Everything as a Service" (XaaS) environments offer new opportunities. The job can be refocussed from box shifting and manual "oiling and adjusting" type tasks to a higher level of "End-to-End" application administration. This requires administrators to be re-organised into either application facing (if it's large like an ERP or core banking system) or business facing (if there are lots of linked smaller applications used by a business area) teams. They can then work with application and business facing development and test teams to meet the continuous delivery needs of modern digital products and applications. Tooling such as Splunk or Oracle's Management as a Service are good at pinpointing root causes of problems, ensuring that the team tracks down causes quickly and focuses on jointly fixing issues. 

That way, accountability lies with the team and incidents can be resolved quickly, whilst new releases are jointly planned to optimise value to the business. This is Group Technology for DevOps.