You can run programs on the server computer's CPU. Solutions like Remote Desktop Services (previously called Terminal Services) work that way. The server's CPU, RAM, and disk storage are being used. Each client is, conceptually, an extended keyboard/mouse/monitor attached to the server computer. Don't think of the clients as computers in that scenario, because they're really not acting like computers.
This type of scenario is typically used for very "task-oriented" applications (call center, kiosk, etc) where the client device might be a "thin" client device, or where the client devices are connected via low bandwidth connections. (It's pretty typical to deploy applications that are bandwidth-hungry over low-bandwidth WANs by doing this very thing.)
On the other side of the coin, some programs are installed with the intention of the program's files being stored on a server computer's hard disk drive, but having the program executed on the CPU of computers that are clients of that server. In this case, the server computer can be considered, conceptually, just a hard disk drive that the client is using to recall the program from. The server computer's CPU isn't actually executing the program. It's just shipping the bits of the program across the wire to the client, which is executing the program.
Edit:
There is no "right" or "wrong" way to host applications. It depends on your specific application licensing costs, and your hardware. There's no black-and-white answer.
In a Remote Desktop-type scenario, for example, you will have Microsoft licensing costs that you won't have in a scenario with locally-installed applications (or applications hosted as a file share on a file server computer but executed on client computers). Your application software may have a different license fee structure, as well.
Your server hardware "horsepower" needs will be different with a Remote Desktop scenario versus locally-installed applications.