Category: IT System Design 101

Posted on

IT System Design 101: Subsystems are NOT just dumb pipes

One design pattern in non-trivial IT systems is as follows. There exists a central authority of data and business logic with subsystems interfacing it. This, contemporarily somewhat obvious model, is called the Hexagonal Architecture and was first formalized in writing by Alistair Cockburn in 2005 (see https://en.wikipedia.org/wiki/Hexagonal_architecture_(software) ).

What is a subsystem in our context then? It is a system managing a domain (“a collection of things”), communicating to the central authority with a well-defined API. As with everything else, subsystems can be defined and implemented in different ways. One bad way to implement subsystem is to treat it as just a dumb pipe just passing data around. I will explain my rationale.

Continue reading “IT System Design 101: Subsystems are NOT just dumb pipes”

Posted on

IT System Design 101: Nothing is as prevalent as temporary mock or debug program

I believe the following happens to every seasoned software engineer during some part of their career. You have been tasked to create a new program. Or you just start to create it yourself to assist you in some time-consuming mundane tasks. You pay no attention to code quality. It is enough that it just works. So, you cut some corners. Maybe there is a new library you are trying. You fiddle around with the parameters, stick in 1, 0, NULL in some obscure order until it works. You leave in the code a lot of magics (pure numbers and symbols which do not tell WHY they have been defined as such). Because, you know, it is just a temporary debug program.

What happens in reality, at an alarming rate, is that these programs, meant strictly temporary, become actually quite permanent. In many cases they end up outliving the contract periods of the engineer originally writing them.

Continue reading “IT System Design 101: Nothing is as prevalent as temporary mock or debug program”

Posted on

IT System Design 101: Introduction

During the past few decades, I have been involved in multiple embedded IT systems in distinct roles. I have been developing, maintaining, and designing. I have worked with individual subcomponents and with complete systems. I have seen ready-made stuff, implemented some myself and see others create new in parallel.

Many times, the result has been somewhat working. Many times, however, sub-optimality has been involved in some way. Part of the blame falls on me and part on other people. I am in no position to hold anyone else responsible for the problematic stuff than myself. And to be honest it has been many times a great learning experience to work out all the kinks out there and challenge previous thinking about the state of things.

IT System Design 101 will be a series of articles I will be writing about how to design an IT system. Emphasis will be on systems with embedded actors. There is no guarantee that the design patterns I’m going to lay down will result in a perfect system. I am quite sure though that the result will not be the worst possible.

Below will be an updating table of contents about already written and upcoming articles.

IT System Design 101: Nothing is as prevalent as temporary mock or debug program

IT System Design 101: Subsystems are NOT just dumb pipes

IT System Design 101: Design for Deltas