Hmm. According to BOL, if OVER used with a SUM, then an order by clause is required...
As others already said, BOL is wrong.
OVER() with normal aggregate functions (like SUM) works in two possible ways:
1. Without ORDER BY - either with PARTITION BY, or just as OVER (). In this case, the PARTITION BY defines groups (no PARTITION BY means that the entire result set is considered a single group), and the aggregate is applied to all rows in the group.
2. With ORDER BY. In this case, a ROWS or RANGE specification should also be added, allthough the system does supply a default for the latter. With ORDER BY, the results are still grouped based on the PARTITION BY clause, but the ORDER BY + ROWS or RANGE specification limits the function of the aggregate to a subset of the group. This is very useful for, for instance, running totals.
When using ORDER BY, please do not rely on the default ROWS or RANGE specification. The default may appear to give you running totals, but it uses RANGE instead of ROWS; depending on whether the ORDER BY specification has duplicates or not, this either means that you sometimes get unexpected results, or it means that though you get the same results, you are thrashing performance.