All of these things should be documented in detail, although when the operation is standard for the operating system, application server, web server etc you may be able to assume the IT operations people know how to do that.
Installation: document everything about how it is installed and configured, including how to tell if it is operating correctly.
Tell us about the architecture, especially about the communication between various solution components (e.g. range of ports - RPC mechanisns often use a range of ports - we need to know what the range is and when the application might run out of ports).
Patching: document anything specific to the application - what needs to be shut down before patching, and any follow up actions after patching (caches, indexes, proxies that may need to be cleared or rebuilt).
Maintainance: document what normal and abnormal operation looks like - what queues and other things should be monitored and what the normal range of these is.
Tell us how to manage the data - especially tables and files that grow without limit (e.g. log files and transaction histories). How should these be purged and what's the impact of removing old entries? (on reporting etc).
Tell us how to carry out standard "business as usual"/in-life management actions - this might be adding or modifying user accounts, for example.
Tell us about any other regular management actions that might be required (e.g. which certificates are used and what to do when they expire).
For all changes tell us how to roll them back (not all changes are successful). And tell us that you've tested the rollback plans!
Diagnosis: Document log file formats and locations and EVERY application error message that might turn up, saying what the error message means has gone wrong and what might need to be changed to fix it. Never use the same error message for two different events.
Shot down and start up: How, what order, any special procedures (e.g. letting servers drain connections before shutting them down).
I strongly disagree that the best way of doing this is to throw the application over the fence and let the IT people work out what is needed. The operational documentation (and in general, the manageability features of the application) need to be thought about up front.