You're right, every organization attacks that differently. The best documentation I've seen for laying out roles & responsibilities is an older book called "Database Administration" by Craig Mullins. It's still very applicable to more modern methods.

In general, I'd suggest you get two roles filled. First, and most important, that of the DBA. This is the person who you'll task with responsibility for your production data. He'll act as gatekeeper & guard on the production systems. That means backups & integrity checks, but also security, disaster recovery, high availability, etc. If he does the job right, he's going to keep your developers out of production (which inevitably leads to fights) and he's going to control and direct reporting & other ad hoc access to secondary systems (either purpose built reporting systems, or QA/test environments).

I'd suggest getting a second role for database design & development. This person will know how databases work internally. He'll be able to write or tune T-SQL queries, design well structured databases and create deployment processes.

I outline a lot of the work involved in database development in my chapters of the book SQL Server Team-based Development[/url]. The e-book is a free download.