When something doesn't work, the first thing to do is localize the problem. The top diagram on the right shows how things were before ASCOM. The "device" includes both the actual device as well as special "native" adapter code inside the app. As a user how do you know who's responsible? It could be the app developer (their special native adapter code), or the USB connection, or the device itself (including its firmware)? Often this leads to "finger pointing" and frustration.
Have a look at the diagram below. By separating the device specific "native" logic from the app, ASCOM makes it much easier to isolate the problem. The app has no "native" special logic in it. Since the app uses identical calls for all devices, you can tell the app to use the ASCOM Simulator for the device instead of your real device. The app doesn't see any difference. Now try to reproduce your problem. Is it gone? If so, then you know the problem is in the device adapter/driver, the USB, or the physical device. The problem is not with the app (*). This is a game changer. No more finger pointing.
Congratulations, now you should have a working understanding of ASCOM and how it implements the fundamental principles of modern systems architectures. If you have additional questions, concerns, or comments, feel free to post to the ASCOM Talk Help forum. Thanks for letting us help you understand.
(*) ASCOM greatly reduces the chances of apps having device interfacing problems because the app developer uses only one universal interface, the ASCOM standard. By testing with the ASCOM simulator, the app can be assured of "supporting" any ASCOM compliant device. After all, if the app has a problem speaking ASCOM, it's going to have problems with any device, and the app developer would have a mob with pitchforks and torches at their gates.