FunkyDexter (1/21/2014)
I think we often forget that businesses don't exist to use our software or follow our procedures. They exist to deliver a product or service to a customer and, in so doing, make money. If our software and processes facilitate that we can expect the business to engage with us. If we obstruct that the business will turn away... and will be right to do so.I think Steve's final sentence was telling. We need to deliver solutions faster than the business unit can develop their own. That might be an all singing all dancing fully integrated system or it might just be sitting down with the user and helping them write the spreadsheet. I absolutely agree that we should put as many development tools as possible in the hands of users and then be there to support them when they need us to.
I absolutely disagree - we don't have a hope in hell of developing faster than users can knock something up in Excel or Access - as long as we're following best practice and designing systems, testing them and reviewing them, practising standard change control practices etc. So it's not a fair comparison.
Obviously, those take up more time than if you don't have to do them, but quite often the quality threshold is much lower for EUC and they release then test and fix things on the fly - often introducing new errors. A professional dev team would never dream of doing that for very good reasons. In almost every field of human endeavour, a quick shabby and substandard version can be done quicker, and the challenge to build a better version doesn't usually have the time constraint that it must be as fast as the lowe quality one.
Putting development tools into the hands of users may seem attractive at first - it gives them results fast and takes the pressure off dev - and for very very constrained tools, that's fine - I remember a time when IT would be responsible for producing presentations and I think Sharepoint is a massive step forward in user empowerment. However, Excel is an extremely powerful tool and is often used as a fundamental step in important business processes, but in common usage doesn't have the checks and balances that you'd hope a formal SDLC process would build in.
The challenge is pointing out to proponents of EUCs what the problems in their approach are, and be flexible enough to know when to leave them alone to do their own thing.
However, like I said before, often the problem is one of short-termism - an end user doesn't give a toss about the big picture or future-proofing, they're under pressure, they're overworked and they're looking at a fix for that problem. However, they're probably ignorant of the risks inherent in their approach. A good company will have policies regarding the use of EUCs and try to limit the amount of it, reduce risk from it and/or ensure that there's an appropriate level of oversight and control of their development.