When building a system for a prison you need to consider a few more levels of high availably than usual. In particular, you might need to operate while there are riots in progress, which may be prison wide, in a single block or section or in general while in a partial failure mode. Regardless of what is going on, you want maximum survivability for the system. If there is a riot in the next block, I still want to be able to do a proper count of the inmates in this block, for example. So each block must be able to operate independently from the others.  For that matter, the command & control center must always be operational and so does the medical ward, the registration (who is in the prison right now is something that is important to know especially when there are issues.

All of this means that we can’t rely on any centralized architecture and that we want maximum separation between the different pieces. The reason this post is titled physical architecture is just that, we are talking about physical machines that reside some distance from one another. Now, granted, prisons are, by their very nature, limited in size, so we don’t have to worry too much about the latency of calls. However, we are worried about other aspects. We have to assume low to no maintenance and the chance of riots / floods and possible locusts.

The best case scenario for us is that each server will be installed on its own block, with a UPS  if we are lucky. The whole thing residing in a locked cupboard in the block’s sergeant's office. Given typical conditions, the cupboard is also were the teapot and coffeemaker will reside, and we’ll have to worry about our server going doing because someone spilled a whole pot of tea on the machine.  But I’ll leave completely fictional heart attack inducing events to another day and focus on the software architecture.

We need to be able to operate each block independently of other blocks and from the central prison administration. That means that we will use an architecture that assumes that we are an island. All the applications that are used will only talk to a local database, and cannot assume any other connectivity being available.

Instead, we’ll build explicit data flow channels between the different parts of the system and handle that part explicitly.

It is important to note that this type of architecture also has another major benefit, it cushions certain type of errors. If an inmate managed to trip on a wire and cut the network cable leading to the block, we want to still be able to operate normally for all / most usual things. This means that we can summon the network guy to come and fix things in the morning, rather than have them come up now. That is the kind of architectural results that you like if you are one of the guys who might be called in such a case.

The block server will hold:

• The inmates that are in the block and well as their record in the block (disciplinary actions, privileges withheld / given, notes, etc).
• Records of counting of inmates.
• Log of actions happening in the block (Sargent's diary).
• Tasks and operations required (sending inmates to court, scheduled work parties, cell searches, etc)

That kind of data is essential for the routine operation of the block and should always be available.

At the prison’s level, you have all kind of departments and the kind of data they need to keep:

• Medical – medical history and other medical stuff. This is a separate system, because there is nothing unique in a prison medical ward that require anything special other than the bars on the windows and better locks on the drug cabinets.
• Registration – all the inmates in the prison as well as all their holding documents. These are the documents and authorization to withhold someone’s freedom, and it is stored and managed by this department. This is also the department that can generate work orders (send this inmate to this court) for the rest of the prison and is the primary outside contact.
• Command & control center – has a view of everything and is in charge of tracking operations, but the only action it takes is to pass that information onward.

I’ll speak more about each of these departments at length in the future, but for now I want to focus on something that is very interesting. None of these departments actually need to talk to anyone else to do most of its job.

The C&C center needs to get reports from the blocks about counts, that inmates were sent to court, that the inmates that were supposed to be freed were actually freed, etc. But none of that has to happen through regular channels. In fact, in many cases, they’re multiple channels that are used on an ongoing basis.

In addition to having the block’s server notify the C&C systems that the counts were completed, the sergeant will also notify C&C directly via a phone call about the count and how many inmates are currently in residence in the block.

The prison software needs to record all of that. In fact, even though it looks like it is doing the same work twice, we need it to happen, for the same reason we have double entry book keeping. It helps catch issues and omissions.

So that leads to another architectural tenant for the system. Not only are the system made of physically separated components, but we are also considering each portion of the system as a consistency boundary.

I hesitated here with regards to the naming. I almost went with a security boundary, but that isn’t quite right. It isn’t that the other side is not trusted in the classic sense. They are trusted, but they aren’t verified. We’ll need to double check all such data as it goes into the system. But that leads to the next big challenge, how are we going to handle the flow of data and verification of the data across the system as a whole.

I think this post is long enough as it is, so I’ll keep that for the next one.