I used to be an Engineer. Yes, really. A proper one. I used to design physical things rather than what I do now – specify how ones and zeroes should be arranged. I used to help design equipment for aeroplanes. In fact, it was automating repetitive calculations through scripting and via programming languages that eventually made me decide that the software was more fun. But that’s another story.
I still learned a lot from my time as an Engineer, and a real formative experience was one where I was seconded onto a manufacturing project. Concurrent Engineering was really taking off in aerospace at the time and the company I worked for was trying to get on board. They were also getting on board with Lean Manufacturing – yet another story I’ll be picking up soon.
Concurrent Engineering refers to the development of manufacturing systems in parallel with the development of a product. Whether this is an aircraft, an automobile or an iPhone the idea is still the same: you need to pay attention to the manufacturing process right from the start if your product is going to be (a) manufactured cheaply enough and (b) manufactured to the correct level of quality. You also need to develop your supply chain at the same time, and you need to develop it in such a way that your manufacturing volumes can flex with demand.
To me, the relationship between DevOps and Software Engineering has significant parallels to the relationship between Concurrent Engineering and Product Engineering.
A product is no use of you can’t deliver it when needed, or it has such poor quality that it’s unusable.
DevOps is like building the shop floor in your factory. Code is the raw material that makes its way through Goods In. Compiling, unit testing, deploying, load testing, functional testing – these are all the stages of the manufacturing process. In software the stages of the process are heavily biased towards QA, as the “build” tends to be rather straightforward, but the principle still stands.
How efficient and automated do you want your manufacturing process to be? In some ways that depends on how many times product will roll along the production line. Back in our naïve days, we used to think that software rolled off the production line once per release. This made software development something of a cottage industry. You had as much automation as old ladies knitting Aran sweaters.
Now we are striving for Continuous Delivery (CD) we think of software going through the factory on every commit. On a sizeable development team this can easily be tens of times per day if not more. And we’re talking about a complex product that needs hundreds or thousands of quality checks before it’s completed. If you were building a hundred cars a day you would have a production line that dictated your process, ensuring that only quality cars were made. With DevOps we are in the same place: each commit results in high quality shippable product.
If you look at it like this, it doesn’t matter whether you’re shipping packaged software or installed software that your users consume as a service. That’s just the detail of what “rolling off the assembly line” actually means. The difference between publishing an installable update or deploying an update when prior to this you have performed all the relevant deployment and testing cycles to get to the point you know you can ship.
When’s the right time to start designing the shop floor for your factory? You start at the same moment you start designing the software. How else will you deliver product if you have no production line?
For the rapid delivery of quality product you need a production line. DevOps is about building that production line. Dev leading is running the production line. Architecting is designing the product with manufacture in mind. Get these in harmony and you’ll achieve amazing results.
[yikes-mailchimp form=”1″]
