Six Degrees of Application Architecture

DZone 's Guide to

Six Degrees of Application Architecture

A Zone Leader evaluates findings the Six Degrees revealed by Netflix, pondering if such a situation exists in Application Architecture.

· Agile Zone ·
Free Resource

Image title

How many degrees of Kevin Bacon is this?

I have kept this article idea on my backlog for several months now. In fact, the article was inspired after reading a Forbes post by Dana Feldman in February of 2019. The article was titled "According To Netflix, We All Have 6 Shows In Common" and it refers to an analysis completed by Netflix demonstrating the Six Degrees of Kevin Bacon at play.

You may also like: Software Architecture: The 5 Patterns You Need to Know

For those who are not aware, the Six Degrees of Kevin Bacon is defined on Wikipedia as follows:

Six Degrees of Kevin Bacon or "Bacon's Law" is a parlour game based on the "six degrees of separation" concept, which posits that any two people on Earth are six or fewer acquaintance links apart. Movie buffs challenge each other to find the shortest path between an arbitrary actor and prolific actor Kevin Bacon. It rests on the assumption that anyone involved in the Hollywood film industry can be linked through their film roles to Bacon within six steps. 

Feldman's article provided this very interesting statistic:

Netflix studied its 139 million paid memberships in over 190 countries and the research shows the Six Shows Statistic: The average number of shows shared between two randomly paired Netflix active accounts is 6.2. Both accounts had to have watched at least one episode of the show in common or 70% of the film in common in the past year. — Dana Feldman

This made me wonder if a "Six Degrees of Application Architecture" concept exists.

Common Concepts With Application Architecture

At the core, I feel like information technology (IT) professionals reside in a role that builds upon repetitive tasks.  Some common examples:

  • Production Support teams find and resolve issues within an application, then work towards deploying them.

  • Product Owners spend time working with their customers to discover and annotate new features and functionality.

  • Feature Teams work through the process of introducing new functionality into a given application.

With application architecture, there is often a high-level approach or cycle that flows through the process of design and early development/prototyping. As time passes, we get better by leveraging frameworks and patterns that help reduce boilerplate or duplicate efforts in the design process.

Think about it, since ORM frameworks have been introduced, few are spending time writing code that provides what Hibernate (as an example) provides. Even improvements to languages like Java cut down on the repetitive code which used to be required to process a list of objects.

These advancements allow us to focus on meeting the business needs of the customer. For the application architect, the approach does not vary all that much from one need to the next:

  • Gain an understanding of the problem being solved.

  • Perform a discovery session to understand any standards or requirements that are in place.

  • Determine the best technologies, frameworks and utilities to meet the needs at hand.

  • Map out the design and begin to prototype a solution.

While the details of the application architecture will vary from one solution to the next, these core aspects tend to remain the same. This is a large reason why corporations can leverage business partners to provide assistance in this area.

In the Java world, I feel like the "Six Degrees" would involve items like:

  • Spring.

  • Hibernate.

  • RESTful APIs.

On the client-side, those "Six Degrees" might involve:

  • JavaScript/TypeScript.

  • ReactJS/Angular/AngularJS.

  • jQuery.

  • Node.js.

Considering Existing Applications

With such much in common with what we do, there is the aspect of "existing applications" (or legacy applications) that we should consider — but often leave off the radar.

What I mean is that most organizations have a service catalog full of existing applications in use. These applications were new and maybe even exciting at some point — introducing new functionality to the business groups accessing the services. As new applications emerge, we tend to forget about these applications — despite the value that they continue to provide.

So when a new application is architected, the question should be asked if the existing catalog of applications can benefit from the features being introduced.

Consider a service that provides a customer list. The new Customer Service API might end up being:

a) More robust

b) Better from a performance perspective

c) More accurate

d) All of the above

It is rare for work to be put into place to update those existing applications to take advantage of the new service. Even if the existing applications are not RESTful based, adding the functionality to make a call over HTTP is typically not that involved — especially if the value gained by the legacy application is significant.

Most of the time the reason I encounter for such tasks not getting completed is tied to budgeting costs for the updates, validation/testing, and deployment. In my experience I feel like an allocation of time for technical debt is something all teams should embrace — recognizing the fact that technical debt might span outside the realm of the current application of focus.

The 80/20 Rule (Outside the Six Degrees)

With the Netflix results pointed out by Feldman, the focus is on what one Netflix watcher has in common with some other random Netflix watcher. But what about the 80/20 rule (or the Pareto principle) that we often embrace during application architecture?

In computer science, the Pareto principle can be applied to optimization efforts. For example, Microsoft noted that by fixing the top 20% of the most-reported bugs, 80% of the related errors and crashes in a given system would be eliminated. Lowell Arthur expressed that

"20 percent of the code has 80 percent of the errors. Find them, fix them!"

It was also discovered that in general the 80% of a certain piece of software can be written in 20% of the total allocated time. Conversely, the hardest 20% of the code takes 80% of the time.

To me, twenty percent of the application, which takes a significant amount of time, the items that typically differentiate applications. Otherwise, they would be in the eighty percentile that take the least amount of time to develop.

Applying this to the Netflix metaphor, this would be similar to conversing with a Netflix user about the movie "Luka Chuppi" — which according to OnNetflix.ca was the least popular movie in July 2019.


As I noted, Dana Feldman's article was from February of this year. Having a toddler in the house, our time available to watch television (or non-toddler programming) is quite limited.

Here is an interesting break-down of some of the Netflix programs mentioned in Feldman's article:

  • Bird Box (we watched it).

  • Stranger Things (we watched some of the first seasons).

  • Tidying Up With Marie Kondo (we watched a few episodes).

The crazy thing is, Nicole and I do not actually have a Netflix account. Rather we use the account of our (now) college student, Sydney.

There is certainly some merit to the Six Degrees — because I feel like we are more alike than different in so many aspects of our lives. Thus, this ideal is further justified when seeking entertainment options, but even more so when accomplishing our day-to-day responsibilities.

Have a really great day!

Further Reading

The Drive to Modern Application Architectures

Quick Introduction to Software Architecture

agile, agile adoption, architecture & design, netflix, spring

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}