Skip to main content

Not Robots, software

This is a non-technical blog post I felt like writing. Main focus will be the change being driven by the tremendous technological advances the last 5-10 years. The inspiration of this writing is mostly derived from a talk by Technical Fellow Jeffery Snower called “Software development in an age of social responsibility” (it is available on youtube) and my ever curious mind.


Executive summary

If you think the technological changes are moving fast, you are in for a surprise. It will accelerate exponentially as the 4th industrial revolution gains momentum. How will you adapt to the change and what are the things you should think about to avoid extinction for your business? Software is eating businesses and the world and if you think that software does not apply to your organization, you might want to rethink your approach.

Recent history

In 2011 a paper came out in the Wall Street Journal called “Why Software Is Eating The World”. The paper was written by Marc Andreessen. As the title suggests, the paper predicts that going forward, software will have a huge impact and disrupt all industries and consequently all business one way or the other. In 2011 none of the biggest companies in the world was “software driven”. In the 2017 version of the list, about 50% of the largest businesses in the world is software companies and the prediction of Mr. Andreessen has been proven correct. In my opinion we are at the very beginning of a revolution driven by software. Some industries have a head start and have been transforming during this time frame. Other industries are about to be affected by this or is already starting to be disturbed. Software is challenging industries and traditional business models and value chains both vertically and horizontally.


The fourth what?

Throughout the history, we have had 3 industrial revolutions where the last one was driven by the micro processor and transistors. Planetary scale services, cloud solutions, devices (mobile and IoT) and network bandwidth are the main ingredients in the 4th industrial revolution, however they are all powered by software one way or the other. We have all experienced the revolution in some way or the other and I suspect that you have not really thought about it that way. Software has been feeding on traditional businesses already. Huge successful businesses like Amazon, Google and PayPal have already dissolved, concurred and disrupted the global markets. Traditional value chains in the car industry and the retail business have had their chain messed up by software.


Robots

It is hard to miss the media attention “Robots” are receiving. There is always an article in a paper or online where they claim that robots are overtaking jobs. While it is true, there is another side to the story. Someone has to make the robots do the things. That will create new jobs, however that is not my point at all. I very much dislike the use of the term “Robot” in the current landscape of software. First it is more like an automated process that is made specifically to understand a single context/thing and do it fast and with a high degree of success (same result each time). Secondly true robots in the winder term should be able to understand any context and adapt to the surroundings it is introduced to. That is not the case for “Robots” available to businesses today. You know there is a World Championship in “Robot” football (soccer to my American friends). Watch the finals in 2018 and tell me we have true robots. They don’t even play as good at 2-3-year-old kids. And you know, that is the way it should be given that we are in the very beginning of the revolution.


The future

I understand why people and CEOs are excited by “Robots”. They are a masterpiece compared to human resources that need parental leave, sick leave and holidays. We even need lunch breaks as well. It is my impression that executives are making business decisions based upon the fact that they need “Robots” to succeed. They fail to recognize that we have just scratched the surface of the software revolution and that everything will be quite different in a very, very short time. As Bill Gates so elegantly put it; “We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten. Don't let yourself be lulled into inaction”. By accepting the current state of inaction, you have in essence made an active decision to permit it to continue.

In my part of the world, many businesses have started or is about to start on the journey of transforming their businesses and becoming digitalized organizations. That process is very often disruptive and painful, however I suspect that many executives thinks that a successful transformation automatically will make their company compatible with the revolution. They fail to recognize that they will be hit head on by the software revolution while they are in the most challenging transformation ever encountered. Digitalization of the business is the foundation needed to be able to build and adapt your new value chain to be able to conquer the revolution. Some businesses may be able to this as a two-step rocket where they can successfully transform their model and build a new foundation and then focus on adapting the value chain. Others might not be that lucky and will have to do both at the same time.


Things to ponder about

As we have previously experienced, a revolution will have winners and losers. Business and industry opportunities will arise and as a specie we will face challenges like we did previously when our society was disrupted by a shift in technology. The issue now is not defined by something that can blow up (steam train boiler for instance), however software can still cause very serious damage since it is connected and controls rather nasty things. Automated things like AI and machine learning probably need a new dimension where you start to ask ethical questions and align it accordingly. Smarter people than me have already talk about this for a while and I suspect that there will be more to come here sooner rather than later. To quote Brad Smith; “We’ll need to be thoughtful about how we address the societal issues that [technology advances from Artificial Intelligence will] bring about”.


Embrace change – adapt or meet Darwin

To move faster and be able to adapt, you need to change quickly. Huge complicated changes that are costly and time consuming is extremely hard and prone to failure. Learn from process engineering 101 and rather do things as follows:


  1. Define repeatable steps and measure them including the outcome
  2. Make the steps smaller and increase speed. Measure them
  3. Automate the steps and measure them
  4. Align the steps to optimize outcome


While optimizing the steps, continuously evaluate security, accessibility and privacy. Review social justice and ethical issues with the steps. Develop/build the things that differentiate you and buy everything else you need to sustain your uniqueness and value add.


Embrace failure – fail and learn or meet Darwin

Moving fast and pushing the envelope, breaks things. That is a huge challenge for large changes, less so for smaller steps. Fail fast, learn from your mistakes and apply your new earned knowledge to prevent new failures. Spending 6 months to automate a collection of steps and fail is disastrous, and you will probably want to have a serious conversation with the person responsible for that decision. Spending 4 hours on a step and fail, is something to be proud of. I am convinced the latter person(s) learned something useful. You probably want to talk to that person or group next and learn what they experienced.


Embrace DevOps – Implement and adopt or meet Darwin

If you have never heard about DevOps, you are probably living in a cabin without internet connectivity. There are many definitions of the term, however Wikipedia defines it as; “The goal of DevOps is to shorten the systems development life cycle while also delivering features, fixes, and updates frequently in close alignment with business objectives. The DevOps approach is to include automation and event monitoring at all steps of the software build”.

DevOps is not something you can “buy”. To me and many others, it is a philosophy and a way of life that enables an organization to collectively reach a common goal or a collection of common goals. To benefit from it, you need to implement it in your organization at every level. Your cooperate culture need to reek of DevOps, there is no DevOps light that is easy and painless.
Puppet has a nice whitepaper describing the five stages of DevOps describing the journey of DevOps. Let me summarize those for you quickly:


Stage 0: Build the foundation

Implement technology for collaboration and sharing of ideas, metrics, knowledge, processes and technologies. This is a continuous task throughout your journey towards DevOps.


Stage 1: Normalize the technology stack

You need to go agile in your teams and eliminate redundant system. If you have not already adopted versioning control (GitHub, Bitbucket, Azure DevOps etc) you probably should do it to be able to evolve to a CI/CD/CM (Continuous Integration, Continuous Delivery and Continuous Monitoring) pipeline.


Stage 2: Standardize

The goal is to reduce the overall complexity to enable teams to scale their experience and applying consistent management and deployment patterns. This will increase the deployment speed and reduce errors caused by complexity.


Stage 3: Expand DevOps practices

At this stage you should experience a return on your investment. The agile method has probably put some strain on some stages in your pipeline. These need to be identified and resolved. DevOps should help you into reusing patterns from other teams and apply them where it hurts the most. At this stage you probably will be doing infrastructure testing after change to validate the implementation. Testing provide predictability and reliability that create trust in methods and practices.


Stage 4: Automate infrastructure delivery

Automation of system configuration and provisioning is key. It enables your organization to deliver identical environments for the different stages in the pipeline. Enabling self-service of the infrastructure throughout the stages of the pipeline, will make you more efficient and your developers even happier.


Stage 5: Provide self-service capabilities

At this stage you have very high levels of automation and trust in the organization. You automate to be efficient and achieve high levels of precision, thus the organization is benefiting from DevOps. Success awaits you on the horizon if you continue to evolve and adapt to the revolution.

Even if DevOps looks like a framework you can apply to an organization, it is not. You can probably not find to organizations that have implemented it identically in the whole world. Nevertheless, they have used and utilized many of the same tools to achieve the DevOps way. That is both the curse and the blessing of DevOps.


Summary

My point is this; Software will disrupt everything. I do not care if your business is to sell awesome paperclips, distribute legacy software or work as a consultant. Your business will be affected by this even if your main product is not software based. Your place and ability to operate in your value chain is influenced by the revolution and thus your business model is challenged. Automation, AI and machine learning is a huge step for mankind, however a very small step in the current revolution. Software has arrived, will you change and adapt accordingly?

Comments

Popular posts from this blog

Developing PowerShell modules for REST APIs – Part1

Over the years I have developed different PowerShell modules for different web APIs. I thought it would be a good idea to write a 2 series post about how you could go about to do this. This will be a 2 part blog series where we will run through the entire process of building a module for a REST API. I will try my best to keep this as simple as possible and leave more advanced stuff for a follow up post if the interest is there.What you needDepending on your experience with source control and PowerShell in general, you might want to use GIT or some other software repro for the code. In addition we are going to create a test REST API using the splendid UniversalDashboard PowerShell module created by Adam Driscoll. It is available on the PowershellGallery. Other prerequisites are built-in to Powershell. I will assume that you will be following along using at least PowerShell version 5 or greater.
What is HTTP metods for REST API.The primary or most common HTTP verbs used are POST, GET, PU…

Serialize data with PowerShell

Currently I am working on a big new module. In this module, I need to persist data to disk and reprocess them at some point even if the module/PowerShell session was closed. I needed to serialize objects and save them to disk. It needed to be very efficient to be able to support a high volume of objects. Hence I decided to turn this serializer into a module called HashData.



Other Serializing methods

In PowerShell we have several possibilities to serialize objects. There are two cmdlets you can use which are built in:
Export-CliXmlConvertTo-JSON
Both are excellent options if you do not care about the size of the file. In my case I needed something lean and mean in terms of the size on disk for the serialized object. Lets do some tests to compare the different types:


(Hashdata.Object.ps1)

You might be curious why I do not use the Export-CliXML cmdlet and just use the [System.Management.Automation.PSSerializer]::Serialize static method. The static method will generate the same xml, however we …

Developing PowerShell modules for REST APIs – Part2

This is part 2 of the REST API blogpost. In part1 we successfully setup two REST API endpoints using the UniversalDashboard PowerShell module. In this part we are going to create a simple module that support some CRUD operation against our API. As we are trying to keep things as simple as possible, we will not use any fancy framework (like Plaster) to build our module. We are also going to skip a very important step you should familiarize yourself with, Pester tests. Lets get to it.


The moduleWe will build a module called FilesAPI. The module folder will look like this:



In the functions folder I have already added the 2 helper functions from part 1, Get-AuthorizationHeader and ConvertTo-Base64. The other folders are just placeholders for important stuff like classes, private functions that you do not want to make available for the module consumer and tests for Pester tests. For such a small module that we are going to create, one could argue that it is much easier to just add the functi…