published on

Programming for Recruiters - On Software Architecture

I have quite a few friends and acquaintances who are working in recruiting or areas where they require some knowledge around software engineering but not too much. I’ve decided to start a series where we are going to explore some basic programming concepts targeting you, recruiters and sourcers, so you don’t get super confused when you are talking to your respective engineering manager when they start talking about monads and other insane crap.

In this edition, we are going to aim for understanding what software architectures are in general. This will be particularly interesting for those of you who are working with web developers. Let’s start by learning what the word architecture means when we are talking about software.

Note before we get started: the definitions I am going to list here are by no means scientific, don’t cover the entire topic and are somewhat opinionated towards my understanding to the topic. I will be linking articles to as many places as I can to make sure that I am not talking complete mumbo-jumbo.

Software architectures from a bird’s-eye view

So the first question that we might be asking ourselves is what this entire architecture bogus is all about.

According to Wikipedia, software development and (building) architecture has been compared as early as the 1960, however, the term software architecture has only been around for about 25 years, since the early-mid 1990s. Those were the times when the usage of the internet started spreading rapidly and the software that was to be delivered became more and more complex. Earlier, people we able to use algorithms and data structures to manage complexity, however, these did not describe precisely how an entire system and it’s sub-parts were operating together. The earliest significant appearance could be associated with a legendary computer scientist Edsger Dijkstra.

So basically, the word “architecture” would indicate a high-level overview of software and systems. But what systems am I actually talking about here? Software has multiple layers where we can talk about systems. Here are some that might be important for you, with a short tl;dr if you didn’t have time to read the rest of the article.

  1. Machine-level architecture - The architecture of the machine that the software is executed on. This is probably the system layer that stands closest to electrical engineers and real architects, since we are mostly talking about physical things here, such as wires, transistors, gates (not Bill) and chips. Typically when you are talking to a software engineer, you will not be addressing these items, unless you are hiring for hardware developers or IoT.
  2. Code-level architecture - The way of organizing code in the way that it’s (presumed to be) the least confusing. This is the part where most software engineers land when they talk about architecture, since this is literally about the code itself. Architecture on this level mostly talks about design patterns (if the word architecture was not confusing enough, I’d gonna throw in design here as well) that are used to give form and structure to massive amounts of code. Design patterns are taught at schools and are sometimes required to know from apprentice to master level engineers. Most likely everyone you are recruiting should be vaguely familiar with the idea of code-level architecture.
  3. Network-level architecture - The way of describing how software systems that live in different places talk to each other. Software does not necessarily live in one place. It’s possible that a piece of code that is running in Ireland in an Amazon data center needs access to data from the machine of a 15 year old kid from their mother’s basement in Illinois. In this case the software needs to have access to the other piece of software which is usually done over the internet or some sort of network.

Now that we have a list of interesting architectures to talk about, it’s time to get serious. Let’s take a look at them one-by-one, starting with the iron.

Conclusions

This article is way too long. I hope that you, the reader, now has a better understanding about the different type of architectures in software development.