I have the privilege of knowing some very, but verry smart people that have the experience and the record to show for it. When they design something, they can afford to be a bit loose with their using of formal specification.
Why?
Because usually, when you ask them questions like:
What did you consider for necessary capabilities for geographic data synchronization in this transaction system? they will give you an answer in the lines of: “We accounted for a distributed algorithm with an external-clock synchronization, supporting Suzuki-Kasami for MeX. Same exclusion used homogenously”.
Your goal as an architect that takes decision on implementing distributed solutions for critical systems is to be able to provide this answer. If your name is not, i don’t know, Leslie Lamport, or if you don’t hold an IQ of over 150, you have to be involved in formal specification. “Cloud does not fix stupidity”, is one of the famous quotes in this industry. And when talking about critical systems in cloud, the “stupidity” threshold in terms of IQ is pretty damn high.
What worries me is that I continue to see 99%+ of critical systems being delivered with a design based on the gut feeling of people holding an under-the-threshold-IQ.
And then I get to see them grow and be operated. Holy f**k that’s a mess. Listen, this is normal, it’s not your IQ that I am blaming, is the arrogance. Just find the budget to force yourself to go through the process of doing formal specification. You will be forced to think about the problems that you cannot foresee.
The people that are paying for your design don’t know shit anyway about what is it that you do all day. And you know it. But that’s a whole different discussion.
I know that the time used for formal specification is very valuable, but hey, that’s why your system is critical.
There’s one anonymous quote here that I like: “The money you make being the first one delivering a critical system quickly turn to dust when the critical system fails.” – Chinese Proverb (I kid, of course!)