I think separation of development and operations is essential. Operations need software that works. That's the task of the development team, to construct the software and to test it, debug it. That can not be done by operations.
I've worked in an investment bank, which in theory had clear boundaries between development and operations but I found myself doing both. When dealing with large sums of money, operations comes first and always did, consequently, application development was stifled.
Fortunately, the development projects I was engaged in were quite small and no great dependency on them, deadlines for them weren't business critical, if I was a bit late, then so be it, there wasn't much training to be given so no real hardship.
Now, there needs to be close communication between operations and development, right up at the start of the project definition, requirements analysis phase.
Operations will be using the system so they should be involved in establishing the requirements, and they should be involved during development, particularly so in factory acceptance testing of the system.
Yes, there needs to be a line of demarquation between the two, but the development should not continue without the input and the involvement of the operations.
For one very large military project I worked on, when the decision was made to involve operations staff from the client in the development team's testing, this made a huge difference to the success of the system. Requirements problems, software bugs were caught much earlier on in the life cycle by the operations staff, it also acted as a form of training for them because they were able to get some hands-on on the system before it was thrown over the fence to them and expected to use it operationally.
Having operations involved in that way, helps win them over to using a new system and does help improve morale.