The following is a reprint of an article that first appeared in IDG’s TECH(Talk) online community forum.

Chapter 2

I don’t know if I want to do this. Seems like a lot of work. Will it be worth it? How much effort? Will the risk be worth the reward? Can’t we just stick with what we’ve been doing and hope for the best?

These are all valid questions – except for the last one! Clearly, if we are going to get a handle on the cybersecurity threats we face, we have to do something different and sticking with what we’ve got is not going to cut it.

But, lets be honest here. This is a big ask. We’re asking an entire industry full of bright, talented people to stop and ask themselves, “Is what we’re doing the right approach to begin with?”

In Chapter 1, I presented the overarching theme that a Modern Mainframe Architecture could be the answer to our problems. In essence, a Modern Mainframe Architecture turns the middle-tier into an elastic security isolation layer with no resources; only responsible for the transformation between the client and the data layers.

So, if that’s the fundamental concept, moving resources out of the middle-tier, how do we get there? Will it be worthwhile? How much effort will be required? How hard will it be to drag all of our apparatus to a new architecture? Because, the fundamental fact of human nature is that we resist change unless the effort is manageable with tangible and immediate benefits.

Some of these questions will be answered in this chapter while others will develop in future installments. To begin with we need to tackle the big elephant in the room – the legacy file system.

The File System – Our First Mission Critical Application

The file system. It is and remains the first mission critical, killer application. After all, if your files are not there, you are not doing any work! Furthermore, 50+ years later, we’ve constructed a huge amount of apparatus around the file system. It really is central to how we do things with a computer. If you’ve ever built up a computer for yourself and installed an operating system, you know that the first thing that happens is that a file system is burned onto the hard drive. It really does sit at the bottom of our technology stack.

Others have recognized the need to pivot away from the file system and attempts have been made. What happened of those efforts? Was anything realized? The answer is, yes others have tried and everything has come up short. Scanning the internet we find several discussions and even recent articles that talk about the need to embrace a new paradigm. As mentioned in an article that appeared in The Verge¹ magazine recently, the younger generation that grew up with Google doesn’t even know how to use a file system. They just pile all of their files (objects) on the desktop and use an integrated search feature to find what they want. They call it the laundry basket approach. Kids!!!

So, if others have tried and people know that we need something new, what’s holding things up? With all of the talent and venture capital available you’d think somebody would have given it another shot. Truth is, as others have found out, it’s pretty hard to come up with a replacement for the file system. We really don’t stop to think of all the things we rely upon the file system for. Obviously it holds our data but there’s more:

• The file system is where the majority of our programs live
• It is a fabric to share information
• It provides a workflow staging area
• It provides an organizational model for our assets
• It provides security (cough)
• It is the scaffolding that many operating systems rely upon

We can now see that moving files into a database is just the first step. We also need all of the other features that we rely upon the file system for.

Migrate Your Files? There’s No Turning Back….

I think we have come to a conclusion – transition away from the file system. We are going to turn our back on the file system – we can not go back. We have to figure out:

• How to migrate the data
• How to find the data
• How to access the data
• How to use our existing programs
• How to backup and restore our data

What are we going to use at the data-layer then? What kind of database? NoSQL can manage unstructured data as JSON documents. Is that sufficient? You’d think by now they would have come upon some great discovery if that was the proper platform.

What about the old guard, SQL? Is that more appropriate? Well, they tried SQL before and that didn’t pan out. But, a lot of time has transpired since that effort. Have any improvements been made to SQL databases that would facilitate this transition?

The Big Benefit

More questions. You can see this is opening a can of worms! So, lets start with our requirements. Our most important requirement is a means of finding the data. After all, if we are going to move the assets to a database there is no longer a need to keep a static filename anymore nor do we need subdirectories and so forth.

Hey, wait a minute! That might just be something real significant. If we don’t have static filenames anymore, how will ransomware, viruses and hackers infect your files? We are proposing no user files in the file system. What are the hackers going to do? They rely upon the file system just as much as we do!

I think we’ve found our first big payoff. Stopping ransomware, viruses and hackers. Actually, that’s huge. It’ll make this all worthwhile, if we can pull it off.

No Filesystem? How Will I Find My Files?

OK…getting back to our requirements. Before we can find our data we need a way of describing it. A dynamic keyword and tagging mechanism that allows us to mimic many aspects of the hierarchical file system, but without the inherent limitations that imposes, may be ideal. We could have:

• Keywords
• Groups of keywords
• Group keywords by object type
• Keyword tags tied to a specific value type (e.g. character, date, integer)
• Suggested tag values
• Objects with multiple keywords and tags

This gives us the descriptive qualities of the file system and more but without the constraints. Think of it this way: If you have a document that pertains to two different employees, you’d have a difficult time expressing that association in the file system. Yes, you could use symbolic links but that starts to get messy real fast. For a keyword tagging mechanism, we can have a keyword for employee names. It’s then a simple process to associate two keywords and tags with the document – one for each employee name.

With our method in place to describe the data, it should be a relatively straightforward process to write a UI that prompts a user for the desired keywords and tags. The UI could also allow for selection by object type and filtering by other metadata (e.g. last access date) that would be associated with the object.

Another Big Benefit – Operational Costs

Another benefit may becoming clear to you. If we have all of our structured and unstructured data in the same database that could really simplify things like backup, restore, replication and redundancy. Another benefit that we should all appreciate is the elimination of policies, technologies and components that are no longer needed – namely everything involved around managing files in shared directories at the enterprise level. That could represent a lot of savings through indirect means such as space, hardware, power consumption, cooling requirements etc.

This is starting to sound good. But, what’s next? Does it get any better? What else is there to discover? One thing that may come to mind is: if we have all of our data in one place, it sure seems like it would be good if we could get all of our business logic in that same place too. Then, we really can pull all of the resources out of the middle-tier.

Migrating business logic out of the middle-tier will be the topic of discussion in our next installment. Until, then, please post your comments and views in the discussion section that follows.

1https://www.theverge.com/22684730/students-file-folder-directory-structure-education-gen-z