Software Industrialization

Industrialize software and service delivery for speed and responsiveness.  Industrialize so that developers can devote their energy to creating customer valua and discovering new opportunities and needs – all at a fast pace.  Adoption of modern application delivery practices, continuous integration and delivery, and DevOps – depends on this industrialization.

Forrester: Reforming AD&D Organizations for Customer Obsession: The Three Models, December 23, 2016.

I’ve got days, perhaps weeks worth of material just on this one bullet point from Forrester.  Let’s talk about “industrialization” and see where that takes us.  Wikipedia says:

Industrialisation or industrialization is the period of social and economic change that transforms a human group from an agrarian society into an industrial one, involving the extensive re-organisation of an economy for the purpose of manufacturing.

It’s not a bad definition, but it doesn’t work for me in context with the rest of the Forrester quote.

Let’s try Investopedia:

Industrialization is the process by which an economy is transformed from primarily agricultural to one based on the manufacturing of goods. Individual manual labor is often replaced by mechanized mass production, and craftsmen are replaced by assembly lines. Characteristics of industrialization include economic growth, more efficient division of labor, and the use of technological innovation to solve problems as opposed to dependency on conditions outside human control.

OK, this fits in much better.  So, Forrester says that we need to “industrialize” software and service delivery and that this is the intent of Agile, CI/CD and DevOps.  Industrialize.  So we need to “mechanize” or “automate” as much as possible.  Instead of craftsmen, we need assembly lines and we will use technology to solve the problems.

One of the biggest things that DevOps tries to do (in conjunction with Agile and CI/CD) is to reduce the amount of time needed for identifying the need for a change and when that change is in production.  And while this can be done in a number of different ways, the DevOps way would be to automate the process of deploying the application.  The more automation the better off we are.

But if we have to create a custom deployment workflow for every application unless we are doing a lot of deployments, the cost/benefit is a little hard to buy.  So, let’s turn this into an assembly line like Investopedia said.  In an assembly line, things are not customized, they are standardized.  Everything uses the same nuts and bolts, the same screws, the same individual components.  So in the DevOps world, we automate through standardization.  You want to automate your deployment then your deployment will follow these steps and this pattern.

Do you want to deviate?  No.  (OK, “no” turns into “please justify the reason why your application is different from everyone else’s application” and if you can’t justify it in 20 words or less then the odds are that it’s not a good reason.  And then this gets escalated to your boss and my boss and they have a chat and then it comes down to “the only reason you’re different is that you didn’t follow standards, so follow the standards”.  Wow, I can justify almost anything in my own mind.)

So, in order to automate, in order to industrialize the development of software and services we need to standardize on stuff.  A lot of stuff.  Probably more things than we realize right now but the entire process is an evolution so the list of standards will need to evolve as well.

Now, how about continuous integration and continuous delivery?

(Originally published January 4, 2017)