You can find parallelism everywhere. Some examples:
- If you have a user interface which is not responsive, then this might be due to a long running task. A nice way to handle such a thing is to keep that long running task out of the main user interface thread and run it in the background. Then you may be able to only block a small part of the user interface while that task is running. This "pattern" is used a lot in the Eclipse
IDE user interface for example.
- If you want to speed up a long running server task, then often such a task can be broken up in some parallel tasks. In such a case I draw the server process in a diagram (e.g. UML activity diagram). If you do not think parallel, then often you draw a sequential diagram, but often a lot of these sequential steps are unrelated to each other and may be performed in parallel. For example:
Sequential:
Start -> Validate order -> Persist order -> Update customer -> Inform logistics -> Send customer e-mail -> End
Parallel (the update customer, inform logistics and send customer e-mail can be executed in parallel):
Start -> Validate order -> Persist order -> (Update customer | Inform logistics | Send customer e-mail) -> End
- The example which has been already mentioned, a system (e.g. web application) with multiple input channels (e.g. user sessions) which may not interfere.
Finally don't over-parallelize, as Sergey indicated, there is no need to complicate things if there is nothing to gain. On the other hand I advise you to experiment with it, because a lot of things look complicated when you have never done them before. And as you get more and more experienced with the subject and your tool set grows, you will be able to handle more difficult problems with more ease.