Great question, thanks! I think there are several issues wrapped up in this - let me take them one by one:
1. Should application development and application support be together?

There’s always an “it depends” aspect to this, and no organization model is perfect for all time. In fact, it has been said that every organization design contains the seeds of its own destruction, which is why we tend to see the cycles of centralize-decentralize. With those caveats, when development is constantly interrupted by support needs, productivity and quality suffer, so there is an argument to keep them separate. Having said that, cycling people between development and support groups (i.e., developers take a turn supporting what they’ve developed) is a good practice.

2. Should either application development or application support be located in the business rather than in an IT organization? There are arguments for locating support in the business, though this is not the most common practice. Having said that, we have to be careful in defining what is meant by, and what is the scope of support. I think of support as being strictly about helping users to use a system effectively, and dealing with bugs and fixes. Anything beyond that is development. This is an important distinction as “support” has a way of becoming a back door into development - a quick way to get stuff done without going through the disciplines common to a development organization. This is a slippery slope and usually ends up in “tears before bedtime” as my wife likes to say.

The other issue is tiers of support - Tier 1 typically means basic handholding, Tier 2 means some level of real problem solving and analysis, and Tier 3 means deep problem solving. It makes a lot of sense to put Tier 1 in the business - if possible, even turn it into a self-service model. Tier 2 is typically in IT but separate from development, and Tier 3 is often in development.

I think there are rarely good reasons to put development in the business, except for high maturity organizaitons, or if the development needs of a given business unit are TRULY unique (i.e., not just becasue the business likes to think they are different!)

Having said all of that, if you really are lower maturity, I’d be inclined to centralize as much as possible under IT so as to deploy good practices, common methods and disciplines, and look to migrate those things that can be migrated later on, once those disciplines have been internalized.