was looking into how to explain a large distributed system with lots of different queues, lots of dependencies, and to get a handle on it in a succinct manner. How do I model persistence of communications, how do you know what is transient, and more importantly how do I do it on a single piece of A4, so that it looks light weight and not burdensome?

Have I just asked for the world on a stick? Sure I could probably model this in UML, but I doubt it would fit on a single sheet of A4, it would not be lightweight, and the slightest change would render the diagram out of date. Furthermore, working in an agile environment, such things are often thought of a heresy. Interestingly, history tends to show that heretics are just those who are pushing the boundaries of our understanding beyond what we are comfortable with. Mordern day oganisations, like the for-said hereitics, tend to close in to quash what they are not comfortable with, so that they do not destabilise their balance of power.

Cranking my mind back through a couple of decades of development, I recalled using a methodology called MASCOT. Now I would not be surprised if you have never heard of it. It was an obscure methodology that was developed by the Ministry of Defence in the 1970’s and actually it was well ahead of its time.

If you think the Americans built the internet as a military communication tool that was a distributed method of communication, with no single point of failure, that enabled the distributed flow of information – the British created a methodology to model it.

Nowadays, the Internet is the life blood of business communication, we connect servers to other servers, we display the output on HTML5 devices or in Apps or plain desktop browsers. We have GPS signals telling us where we are, other devices tagging products using RFID or even paying with NFC, or telematics recording our behaviour. The tools we have to model all this behaviour are overwhelmingly inadequate. There is an innate level of detail, yet we need to see the flow of this data in a simplistic form. Welcome to MASCOT.

Whenever I start anything, I start from Hello World. So let’s do Hello World in MASCOT That’s great, but maybe I want my Hello World program to now be an echo server. I type in a message. transfer it to another computer and display the output.

Ok that’s great, but rather than just sending a message and instantly displaying it, what happens if the display is not online, so the messages need to be persisted?

Ok, well that was easy. But Hello World, or a simple message server, isn’t really complicated, how can this scale? MASCOT has a mechanism to hide complexities in subsystems. All you need to do is manage the connectivity between subsystems. You define what the interfaces are to those subsystems. Then you can implement those subsystems in MASCOT. This gives you an overview of the system as a whole. You can then drill down into the subsystems

What MASCOT does not do is any detailed design of the application. All it does is allow you to design the messaging between processes, but if these processes are small and self contained units, then those units would be suitable for TDD or BDD.