Big Iron Software, Part 3

Before we go on, let's qualify what we're discussing a bit further.

In terms of manufacturing company types adopting software, we're discussing successful legacy mobility manufacturing companies that produce cars, trucks, bulldozers, tractors and directional drills upon what most of the world currently relies.

In terms of types of software, we're discussing user-facing software, as well as, control and embedded package types.

The reason for this explicit focus is built upon a single premise: though historically successful in assembly line manufacturing, these legacy companies will not successfully implement a software:hardware integrative process. The reason? Coming off decades of successful hard-line products and assembly line efficiencies known the world around and believing that few things on earth could be as difficult as hard-line assembly, these companies will be inclined to under-value the complexity of software production, delivery and support. Resultantly, software will be over-engineered in terms of features, under-engineered in terms of quality as defined by the software industry, software deliverable costs as a percentage of total production costs will sky-rocket and customer satisfaction for once-heralded products and companies will inevitably decrease. It doesn't have to be that way.

Let's look at the first of six aforementioned steps: Decouple software from hardware.

There are multiples areas where software must be decoupled from hardware:

  • The process and procedure for designing, developing, testing and delivery
  • The process for embedded versus control versus user-facing software
  • The process for Day 02 production support
  • Management
  • Project Management

Design, Develop, Test and Delivery

Typical mechanical design today lives on visual design. CAD, 3D printers and holography as an example. The logic is that a defect in a soft-design is cheaper than a defect in a hard-line prototype. Software agrees with this. A defect found in requirements is cheaper than a defect found in production.

Where design, develop, test and delivery are different is that hard-line production typically is built upon process frameworks known as quality gating systems, based upon Deming's Plan-Do-Check-Act cycle of quality, designed to prohibit product evolution (investment) until it passes at each duly defined checkpoint. Expensive, though it works for hardware. It doesn't work like this for software and in fact is an inhibitor.

In software, waiting until you 'Do' is already too late and expensive to 'Check'. This cycle of quality (Plan-Do-Check-Act) is practised linearly. Software is not linear. In fact, it is concurrent in terms of multiple team members, multiple distributed geographies, multiple code packages and purposes, multiple specifications, integrations, tests and deliveries per hour or less. In software, it is cheaper to mock and stub multiple instances of potential software solutions than it is to build out models in documents and visual design tools talking about working software. Though younger than tool and die hardware assembly behaviors, software engineering has successfully evolved to the point that software is specified, designed, tested, coded, refactored, delivered and generating revenue faster than hardware will make it through prototype, assembly, quality assurance checks and production distribution. The differences are necessary.

Day 01 production delivery. Regardless the cycle-time for software delivery, such solutions are useless without their hardware counterparts. It is true that the software specify, test, code, refactor and delivery loop may be decoupled from the hardware production process giving leadership and teams more freedom to R&D without hardware boundaries. However, production delivery requires pre-production integration and test at the sub-assembly, assembly and system-levels for systems analysis and validation. No argument. Lives of people are often at stake dependent upon end-state system quality. By design, architecture, process and procedure are decoupled from the beginning and later coupled only for Day 01 production release quality control. This means Day 01 deliverables are gated as it is typically practised in legacy hard-line manufacturing systems.

This is where the merging of all deliverable and support behaviors stop in terms of binding them into one deliverable mechanism. Day 01, merge them into a single, iterative release management behaviour. Day 02, decouple. It is at this point in the process that old-thinking will bog down, befuddle or otherwise kill new thinking.

Day 02 production support and delivery. To be delivered to production will require a hardware vehicle. However, were user-facing software systems successfully decoupled from control systems, and control systems decoupled from embedded software systems such as sensors, they need have nothing to do with each other in terms of 'when' delivery to production occurs. Day 01? Sure. Sensor package 1, version 900 is coupled with Control unit 12, version 374 is coupled with end-user software package 13, version 4325. On Day 02? As long as software solutions respect the boundaries and limitations of the physical hardware specifications in production, it doesn't matter. We should be able to update any software package, at anytime, for any reason. However, if we combine them and push them through historical hardware driven quality gates, our operations costs will inevitably increase, customer responsiveness will slowed, and satisfaction? Guess.

In the world of hardware and software integration, the physical boundaries of hardware are the TOC identifiable system constraints. Sure, after a working hardware solution is finally in production, up to 100 units per hour will be manufactured per a static set of specs or static set of fixed-variable specs. Software is not comparable and has even more flexibility than imaginable. And in regards to user-facing software, real-time production change-set responsiveness will be required. Are we really going to send a car or tractor to the garage every time we need to make a software change? Seriously? Software, with a battery of automated tests, inspections and other quality checks based upon evolving specifications, can be coded, tested, validated and delivered in minutes 7x24x365 at far lower COA and COO than anything hardware can currently touch. Not understanding these differences is detrimental to continuing success.

Think about this. Cell phones are activated over the air at the push of a button. Software updates, over the air on-demand or as scheduled. Cars, tractors and the like? Send'em to the shop.

User-facing software changes in near-real-time as defects are discovered, new features are required and as system user requirements demand it. Software system not bearing load? Modify it per collected field data, subsequent analysis then using the spec-test-code-refactor-deliver loop. Get it done in minutes or hours per the same quality standards used for initial production delivery. Cars, tractors and the like? Send-em to the shop or send out thumb-drives. Either guys in the garage are going to need to be senior technical consultants or there will need to be amazingly constructed intermediary software analysis devices or we can eliminate the man-in-the-middle syndrome altogether.

Decouple production delivery and support of software from hardware constraints or be beaten by the teams who figure it out.

Now, let's talk about old project management behaviors and how a manufacturing PM and Manager will not successfully transition to software unless they overhaul their understanding of flow.

1 | 2 | 3 | 4 | 5

No comments:

Post a Comment