The system I'm dealing with is one that adds functionality to a legacy system that's actually a bandaid to an old system below that. The turtles go all the way down. The architecture also means the flowchart for how a transaction generates a receipt is wide and deep. We IT folks know all the nooks and crannies for the transaction-receipt workflow but why would a user care? Should they care? It really only comes into play when they don't get the expected results from their transactions. That's an exception case, right?
Well, it is except when it isn't.
I tweeted this earlier and I firmly believe it: Too many enterprise systems require users to know something about how the system works. Non-IT people don't want to be bothered by those details.
Having said that, I'll make the argument that they SHOULDN'T be bothered with those details.
It's not about simplicity or elegance (though many IT types do). This is all about accomplishing the primary objective of the system: Get the work done.
If your system requires run-of-the-mill users to understand the inner workings of your enterprise system in order to successfully use the system there is an inherent fail. The thing that makes it feel like a betrayal is that the failure hits IT hard. Not only will you get the same questions over and over, there's not a whole lot to be done to mitigate the problem. Sure, you can educate users, post documentation, make videos, etc. The problem will always be the same. Users that want to get work done are frequently put in situations that require them to either be indoctrinated into the secret system society or spend time to search through documentation to find the solution. And neither of these 2 things are likely to happen.
This means calls to IT. The same calls to IT. Over and over.
As you design systems for your enterprise if you do not address the issue of complexity you are setting your project up for failure in the long-run. Any software solution that users to understand the complexity to operate is full of failure.