If you are using SSAS in MOLAP storage mode, then you have to process the cube to refresh reports that use the cube as a data source. Whether you use your "live" database or a "non-live" version generated via ETL processes, you must process the cube to bring the cube up to date. If you are using SSAS for the advantages of high performance aggregations, then you will have to accept some degree of data latency.
On the other end of storage modes for SSAS is ROLAP. ROLAP does not require processing a cube since it doesn't actually generate a cube data store. Instead, all it does is spawn SQL queries against the source system database anytime you run a MDX query. This means that it is going directly against your underlying database. So if you have a "live" database, you can get current data from it without processing a cube if your storage mode is ROLAP. My own presonal experience is the underlying queries are generally horrific. For instance, if I wanted to query a fact and a few attributes of a dimension, the MDX would spawn a SELECT DISTINCT * FROM Dimimension.Table JOIN Fact.Table ON Key.Column = Key2.Column2. This basically made ROLAP useless for me since it performed worse than any alternatives.
In the middle you have HOLAP storage mode. This is basically MOLAP for some dimensions and facts tables and ROLAP for others. So you have to process part of your cube and the other part is live data from the database. To me, this was not a viable solution since it still suffered the same performance issues as ROLAP and added some latency like MOLAP.
If you really want to query your live data without forcing users to learn SQL, you could create a report data model in BIDS, deploy it to your Reporting Services server, and then use it as a data source. The data model is a metadata later that is almost identical to the model in SSAS -- it just doesn't allow you to generate a precached cube from it. This could be a reasonable alternative to SSAS. However, report data models only work with SSAS -- they do not work with Excel. If your users want a high-speed data source for Excel that does not require writing SQL, then your only viable solution is MOLAP SSAS. If your users want "live" data and don't need Excel as a starting point, then go with SSRS and a report data model.
If you are using Cognos, Business Objects, Microstrategy, or some other BI solution, then please note they all have data model metadata layers similar to the report data model and they can also query the "live" source systems with generated SQL statements.
A word of advice: don't program a reporting solution against a production database unless you are building the reports into the underlying production application's interface. Even then, you probably still want to offload report queries to some replicated data source instead of the production OLTP system. You don't want someone's query about past sales to block an actual new sale. If you are building a reporting system for internal users only, then take the time to load the data into another server either via replication, log shipping, mirroring, backup/restore, etc., and then load the data into a data warehouse via SSIS or some other ETL solution. You really don't want a report to be the reason for a production system outage or latency issue.