My grandfather's axe

It's an ontological paradox: this is my grandfather's axe. My father replaced the haft, and I put a new head on it. It's my grandfather's axe. It's supposed to make you think about what the essential quality of an object is. Designing a new business system for a company about three years ago made me think of it.

Because that's what the information and processes of a business - or an individual come to that - should be like. Technology changes, but the nature of a company's business need not. So their software and information should move smoothly through these changes so that, after a sufficient period of time, while they think their business system is the same as it ever was, bar certain improvements and adaptations, in fact none of the components are those they began with.

It's not like that in real life, though. This particular business is probably the world brand leader in an area of add-on components for cars, ranging from motorsports through to exploration. They're an engineering company. They started out in the days of drawing boards, then bought one of the early CAD systems. Drawings were scanned so they were accessible on the network, along with the CAD files. Then they bought into AutoCAD, then more recently SolidWorks. They used a Novell server, then moved to NT4, then Linux, then FreeBSD; WordPerfect gave way to Microsoft Office.

This gave them four file formats for CAD drawings and two for documents. But Word can read WordPerfect files, and some file conversion moved their CAD drawings into AutoCAD at least, which SolidWorks can read. Not too bad so far.

The fly in the ointment was the accountancy software, because it contained the bills of material - more than 15,000 products with over 75,000 components. And there they got stuck, with a legacy DOS system that was deeply unsatisfactory, but achieved lock-in just because of the amount of disruption any move to a new system would entail. Eventually, though, they had to move.

With niche applications like CAD or media editing and playback, proprietary file formats are unavoidable. But they are now very avoidable for documentation, thanks to XML. XML is a way of describing the relationships between pieces of information (books in a library or the elements of a letter) that is agnostic about how these are presented to the user. So you can state that a certain block of text is the address a letter should go to, and leave it up to some other application, which can change, to decide what font should be used, and what position on a page. I'm using a trivial example, but it's a non-trivial technology, and there are other approaches to this that work equally well. So there's really no excuse for locking documentation into closed file formats any more.

But what about a company's core processes, which necessarily include the financial accountancy system but in the case of this particular business also included their crown jewels - the bills of material: what their products are made of, and how the bits go together?

I wanted something like my grandfather's axe, so I started with a simple abstraction of the system into components: data and how it is stored, the business logic of the system (what it actually does), and the interface by means of which users interact with it. Three layers.

Data storage consists of at least one file system and at least one database. It doesn't matter what the file system is, so long as it stores and retrieves files. Similarly, it doesn't matter what the database is so long as it works. That means either or both can be changed as technology changes without there being any impact on the overall system.

I wanted a user interface that was platform agnostic - that didn't care what sort of computer it was running on. There's only really one obvious candidate for this: a web browser. Web browsers can do sophisticated things nowadays (play with Google Apps or Maps). There'd be a certain amount of code specific to web browsers to enhance the user experience (auto-completion, AJAX stuff) but none of it would be actual business logic. That way, the specific browser can change, or even be replaced by some sort of application I can't foresee, and the only work needed would be on the enhancements to the user experience.

That leaves the business logic. If we're using a web browser, we're using a web server. There are lots of environments in which to develop we server software, ASP, .NET, PHP, perl, even C. I chose PHP because it's also platform agnostic (runs on pretty much any web server on pretty much any kind of operating system) and it's where the action is right now. Changing the logic of the system, even doen to the language it's written in, might be a biggish job (though decent object orientated design minimises this) but has no effect on either of the other two layers.

This way, any element of the system can be changed without much effect on the other components. And we have my grandfather's axe. We also have the LAMP/WAMP stack - the basis of all web applications offered today.

So, why am I blathering on about this? In his most recent column John Dvorak warns against the use of web applications, based on a recent outage at Microsoft:

Microsoft's Windows Genuine Advantage plan became a genuine disadvantage two weekends ago when the server that verified users went down and began to disable operating systems around the world.

At least, it disabled the operating systems of computers that checked into the home base to affirm their legitimacy.
[...]
The bigger issue here, though, is the genuine threat to "software as a service" and the entire online model for applications.

This is because network outages can make it impossible to connect to your application server. That's true, but so long as the inability to connect doesn't actually disable your computer that needn't be an issue. In the case mentioned above, manufacturing was outsourced to central Europe, and the manufacturers needed access to the system. They were supplied with a satellite server that used database replication and periodic file system synchronisation to stay up to date. Radio links were installed onsite to connect buildings. It all worked fine, even over dial up connections.

The point I think Dvorak missed is that the internet is a network of networks. No business could operate today without an internal network on each of its sites. The internet connects these together. If your work is mission critical, you can build in redundancy to compensate for occasional internet problems, though these are very rare.

The computer is the network, as Sun used to say. They were right. Once you embrace this idea fully, the machine you're sitting in front of is just a window into the network. If it fails, change seat and carry on working.

And once you really embrace this idea, the application you're working on ceases to be a binary installed on your stand alone computer and becomes a cloud, composed of myriad components, with redundancy and resilience, and capable of evolution.