> To be fair, the people who use enterprise software typically only understand a single-digit percentage of what the software needs to do, at best. If you asked them to design it, you wouldn't get a better result.
Sure, users don't know what a system needs to do to meet their needs, but if you had modestly competent business analysts work with them to specify the system, you'd have good results.
The role of systems analyst (nowadays confusingly called business analyst) seesm to have largely vanished in the beliefs that either COTS enterprise software would be used as it came, or that users know what they need (as opposed to what they want) and can rationally set priorities and tradeoffs.
Turns out neither of those beliefs was true, and systems analysts are needed. With the passage of time the role has largely been forgotten.
> The role of systems analyst (nowadays confusingly called business analyst)
Classical systems analysts were, as I understand it, usually the more experienced programmers on a project, and had a role that combined the more recent technical architect and business analyst roles, so they aren't interchangeable with BAs, who often are nonprogrammers, and in any case are viewed as less technical than developers.
> seesm to have largely vanished in the beliefs that either COTS enterprise software would be used as it came, or that users know what they need (as opposed to what they want) and can rationally set priorities and tradeoffs.
In theory, the kind of requirement that is the role of a system or business analyst in other development methodologies seems to be largely shoveled into the responsibilities of the omnicompetent development team in Agile methodologies, though some of it also seems to fall into the product owner bucket in methodologies with that role.
I do think that that the requirements elicitation and analysis skills that go with that role have become undervalued because there is an idea that incremental iteration means you never need to look at requirements in a structured way. I don't think this is even approximately correct, but it seems to be the thinking.
That'll get you part way there -- but for a truly enterprise-wide deployment you also need analysts with deep cross-divisional understanding and some degree of cross-divisional political capital.
Often, organizations that try to do this internally have their business analysts inherently shackled to a specific department or division by nature of the org chart. It is the interdepartmental conflicts that are the hardest to mitigate.
This is one of the lesser-spoken reasons that higher-ups call in consultants -- they have a better ability to short-circuit the org chart and haven't been around long enough to piss off that one director, Karen.
Sure, users don't know what a system needs to do to meet their needs, but if you had modestly competent business analysts work with them to specify the system, you'd have good results.