Answer
Administrators typically need deep performance visibility, index and SQL plan analysis, and the ability to see exactly what is running against the system at a given moment. Developers need comfortable SQL tooling and enough schema visibility to build and debug without waiting on someone else to pull data for them. Analysts and business users need something very different: governed, simplified access to the numbers that matter to them, without needing to understand file relationships, journaling, or the underlying RPG programs that originally wrote the data.
Buyers should map out these audiences before comparing products, since a tool built primarily for DBAs will frustrate a finance analyst, and a tool built for simple reporting will frustrate a developer trying to tune a slow query. Security boundaries deserve explicit attention here: object-level and column-level authorities, along with any exit point controls already in place, should carry through to whatever new access layer gets introduced, not get quietly bypassed because the new tool connects with a service account that has broader rights than any individual user should have. Ask vendors directly how their product respects existing QSECURITY-level authorities rather than assuming it does.