01 The Unknown, 03 An Abstract System

Abstractly Complex: Verticals

Reading Time: 4 minutes

One of the hardest things I had to do as Silo’s CTO was to explain how complicated this project was. The project required a resilient system to meet customer’s experience and an elastic one  to meet the company’s unknown goals. As I was the “software guy”, for the rest of the management team the project was “no more than a few lines of code” by someone who had one course in programming 15 years ago. Or someone else’s rule of thumb was “a full HD video takes one DVD of 4.7GB so our database size will never be more than 1GB”. My favorite ones were “a friend of mine said it should take 3 months” or “but Google did it”. 

It drove me insane. It was a major part of why I needed a mentor [see Not Company Values]. Don’t get me wrong, each one was a genius on his own, but only in his own respected field. They knew nothing about software, only that it should be pretty. At least we agreed on that. I did however manage to partially convey the complexity of the system, while keeping it abstract as I had no idea what’s it’s going to do, using Verticals.

A Vertical has at least one new Project in another new Discipline with an entire new Product Lifecycle.

Experience and Knowledge with one Vertical means almost nothing at another Vertical, but it helps.

To management, I’ve presented what a single Vertical is composed of. I thought about starting with how a Web Application Vertical very loosely look like.

But for Silo’s management, a better more simplified example would be of Silo’s Device, the only thing they know of and can relate to. Know your audience, I guess.

The how is what the software team will be mostly working on in the beginning, on setting up and coding whatever is needed to make the what work. The what is what the product will be mostly working on, with considerations to the how. If the how can’t make it, it doesn’t matter what what is.

They also noticed the frequency of change to consider [see Impermanent Continuous Chaos].

  • Deployment is mostly a one time thing to set up, with odds of it changing should be very low (no reason to change a solid working update, in risk of bricking it).
  • Infrastructure, where the application would run, that is the device’s Linux OS. It is supposed to be a one time setup, but the odds of it changing are a little higher as the Application Engine may be somewhat dependent on it (a package would be required).
  • The Application Engine is setting up a new application project from scratch and implementing frameworks, specifically a state machine. If chosen and done correctly, a framework should not change that easily, but it may be needed to facilitate new Business Logic needs (upgrade a major version).
  • Business Logic is what the device would actually do which would also operate the interface, coded using/on top of the Application Engine. It will change with customer expectations.
  • User Facing UI/UX is far more than just an interface, as it is not only technical in nature, but very much product oriented. It will change with customer expectations.

You’d notice that what triggers a change in “the how” would most likely be of a technical nature and what would change “the what” would most likely be of a product nature. That is a very important distinction, as these natures affect the frequency of change and the system’s resilience to them [see Impermanent Continuous Chaos]. These layers and the increase in change of frequency are mostly the same in all Verticals (with different odds).

After going layer after layer with the management, emphasizing how each layer is unique, sensitive and requires a different kind of skill set, only then I dropped the real bomb – we’ve got five(!) of those (and two halves)

One of the halves is a yet unknown TBD Web Application that no one ever spoke of, but I already know that there would eventually be one. The other one is due to us using React Native, which greatly simplifies development for both Android and iOS, but requires some technical adjustment from one OS to another as well as somewhat of a different UI/UX.

To make things even worse, these verticals need to communicate with each other. We don’t know how yet.

I remember that everyone who’s seen this, his eyes popped out. Mission accomplished. In hindsight, although we managed to avoid starting some verticals from scratch, it was in fact that complicated as I presented a year and a half ago.

Leave a Reply