Enable changes or enforce design

We have this dilemma. Customers who see our siCluster systems often like everything they see, but want “minor” changes. And we evaluate the changes they want for impact, describe it, and suggest a go/no-go based upon many aspects. Including supportability, stability, etc. We like providing this flexibility. Which gives rise to the dilemma. For us to provide supportable systems that work in a predictable manner, we have to cordon off changes. Provide a list of subsystems people can change, and provide a list of subsystems they cannot change. Because if we let them change what they should not change, then breakage … bad … bad … breakage … always occurs. And when I say always, I mean 100% of the time. When you let people mess with a complex interdependent design without appropriate engineering support, stuff breaks. And not in a predictable manner. Which gives rise to a number of support calls I’ve fielded over the last 2 weeks. Specific things at a number of sites were broken in very specific manners. Similar manners as it turns out, though the systems are owned by other folks, and are a quarter turn of the planet away from each other. In both cases, our design was either altered at purchase time (with a specific promise of the removed functionality being correctly supplied by local gear), or it was altered post installation. There is nothing quite like walking through a process to perform a function, that you’ve done hundreds of times, only to discover that some change performed without your input, somewhere in the system, has rendered it unsupportable. Its even more intriguing when customers don’t grasp that their money saving or management decisions have such a profound impact upon supportability. I am starting to question whether or not we will allow changes in these things anymore. We can’t have 1000 different versions of our siCluster and siCloud bits out there. We really need a baseline non-changeable subset to go in if we are to have any hope of supporting this. Call it functionality as a service. Without all the functionality, service would be unreliable at best, and non-functional at worst. Its time to make this call. So it is made.