In my last post I explored notions of system architecture. Other than helping a new generation of software architects, a consumer of technology should legitimately ask:
What's in it for me?
There are a lot of consequences.
The one I want to focus on is this notion of proven. Vendors like to say lots of things about what is and is not proven, but if you believe what I said earlier, then here's what you need to know.
1. Buy a proven architecture.
Buying a proven architecture is not just a risk averse decision, it's a sane and technologically sound decision. Of course if a new architecture brings tremendous benefits, waiting to adopt the architecture until it is proven has other risks so there is a tradeoff.
2. Proven does not mean orthodox
What's important to note is that proven is more important than orthodox.Some vendors like to pooh-pooh their competition because the alternative architecture does not match their notions of orthodoxy.
Vendors who make appeals to orthodoxy are assuming that there exists one true of way of doing things. Or even better yet, are assuming customers are unwilling to accept the notion that there are multiple ways of solving the same problem.
3. Discount the "I am not insane, the world is insane" attack on proof.
There is a temptation among engineering companies to appeal to a customers engineering bias to pick something because the architecture is superior. Or even better to discount proof or evidence in favor of Fear, Uncertainty and Doubt about the architecture.
The reality is that every architecture of any robust reliable system represents the collected wisdom of many customer deployments.
Because if the software actually reflects how the world really works, then claiming the software doesn't work is like the man who says: I am not insane, the world is insane.
Comments