Digital Transformation with Amdahl’s & Gunther’s Law

Reading Time: 3 minutes

Digital transformation is a herculean effort, especially if you would like to transform the entire organization. Each department, each team is a different challenge and must be addressed independently.

Let us dive into how a couple of laws which are mostly used in software are hugely applicable to the modern digital transformation.

Let us first start with the Amdahl’s Law on which Gunther based his law. Amdahl argued that the maximum speed increase for a task would be limited because only a portion of the task could be split up and parallelized. This portion, the “parallel fraction,” might differ from one kind of job to another, but it would always be present. 

Amdahl’s law

What this means is that even though we think that we can digitally transform the entire organization in parallel, we are going to hit departments, teams which can only be worked upon in a sequential way. For example, if we trying to transform finance department then purchasing might have to follow or lead but it might not be able to go in parallel.

Gunther further built on the Amdahl law to suggest that there is an inherent cost of communication as we start working in parallel. According to Gunther when we are working in parallel, there is a peak that we achieve with parallel work. The parallelization however starts giving negative returns when there needs to be increased communication between processes and two processes that need to agree on a state of coherence. This is called the coherence delay.

Effect of coherence delay

Hence, when there are teams/departments which are running in parallel but these teams/departments need to interact with each other and also need to achieve a state of coherence where they need to agree on a state then we have an issue. This issue might slow us down on our journey.

So what do we learn from the two laws when we are looking at digital transformation? The focus areas are the following

  1. Reduce the serial approach – What this means is that instead of going department by department, identify the departments which can be transformed together with a fair amount of isolation.
  2. Reduce the incoherence penalty – If there are departments which need to interact a lot with each other if they are being transformed together in parallel and each need to agree on a state before they can go ahead then it would be better to transform them independently in sequence and not in parallel. This might also apply to the number of departments which can be transformed in parallel. The communication between 2-3 might be ok and not be causing an impedance however, if there are 5+ going on in parallel then the coherence delay might not be worth it and may be negative.


Look for independent departments. Split the transformation with mostly independent teams and departments which can mostly work in isolation

Look out for communication boundaries. If broadcasts work better than 1:1 communication between departments then usually that is a good sign. If it is supposed to be inter department communication to get the transformation done then limit the number of departments being transformed at the same time.

Written by 

Vikas is the CEO and Co-Founder of Knoldus Inc. Knoldus does niche Reactive and Big Data product development on Scala, Spark, and Functional Java. Knoldus has a strong focus on software craftsmanship which ensures high-quality software development. It partners with the best in the industry like Lightbend (Scala Ecosystem), Databricks (Spark Ecosystem), Confluent (Kafka) and Datastax (Cassandra). Vikas has been working in the cutting edge tech industry for 20+ years. He was an ardent fan of Java with multiple high load enterprise systems to boast of till he met Scala. His current passions include utilizing the power of Scala, Akka and Play to make Reactive and Big Data systems for niche startups and enterprises who would like to change the way software is developed. To know more, send a mail to or visit