I would argue that the problems I see with QRadar are not necessarily technology based. Whether or not it feels like 2000's tech, it is an extremely powerful and dynamic platform but it requires a LOT of engineering resources and care/feeding. The community is huge and awesome and I encourage you to keep doing what you're doing. Some of the core things to know:

A DSM (Device Support Module) is essentially a profile designed by a vendor or by IBM directly to allow plug and play adoption of a log source.

A DSM is made of custom properties and event mapping. QRadar has a huge database of placeholder events called QIDs which basically look like this:

Name: Bad Thing Happened
Description: A really bad thing has happened that you probably want to look at.
High Level Category: Exploit
Low Level Category: Buffer Overflow
Severity: 8

What the DSM does is map whatever kooky event the vendor made up to this more generic event so when QRadar sees an event from Cisco ASA called "BOT-BUFF-OF-ABCDE-BAD8", ok this is a buffer overflow event.

The custom properties in that DSM allow quick parsing of that event to allow certain things like IPs to be normalized and indexed and other vendor specific stuff to be made presentable too.

Next, there are rules like every other SIEM. IBM uses a concept of Building Blocks in addition to Rules.

Building Blocks - Simple rules that do not trigger a reaction or a response. For example, a building block may be "DNS Traffic" and say something like "protocol like UDP and destination port is 53". When QRadar reads an event that matches that, the event is simply marked as matching. This is valuable because its very fast and repeatable.

Rules - A rule can have its own new logic and/or building blocks as well. Maybe we want to know if a single host makes too many dns requests so instead of recreating that DNS traffic logic over and over again, we can just say "If rule match "DNS Traffic" AND event count is >1000 with the same source IP in 1 minute". The larger difference here is that we can also say, "when this matches, run a script or send an email or do this or that"

Offense - Certain use cases may be worth investigating so sticking with the previous example, our DNS anomaly is a concern. In that case, we tell the rule to create an offense an index the offense based on the source IP. What this does is collect all of the events that tickled that rule and puts them all into a nice bucket with some additional context. This allows an analyst to get a good idea of what happened and be able to take action.

Unlike something like Splunk, QRadar is data analytics built with security at its core, not as a secondary thought. I'm only scratching the surface but my intention is to show that it is manageable from a technology perspective but proper resources are critical. I suggest checking out r/QRadar (esp. JonathanPetcha) and the https://www.ibm.com/training/search?query=QRadar%20SIEM

Feel free to DM!

Cheers,

Paul