content_image/1004542.jpg
The locally installed instances might be there for a specific reason such as to enable coordination of global transactions, or to enable them to function even when they are disconnected from the network. However, in some cases it will simply be for historical reasons. In the past, due to less reliable networking, locally installed IBM MQ was the norm. For early versions of IBM App Connect (up to what was then called IBM Integration Bus v10), a local IBM MQ server was a hard dependency on installation. Interestingly, the administration of these local instances might still be performed by the central IBM MQ administration team, due to the specialized knowledge that is required. 

As networks became trustworthy, more recent applications would be more likely to use a remote queue manager such that it could be administered separately more easily. 

Applications might still have a dedicated instance of IBM MQ per application, such as for Application D. This might be due to the particular requirements that the application team had for isolation, performance, or security for example . See Figure 9-3. 

<img src='content_image/1004542.jpg'>

However, as the number of applications increases, we often see shared queue managers that host queues for multiple applications, to provide a perceived simplification in administration. 

In addition, some or all of these instances might not be included in an IBM MQ cluster. 

However, for simplicity we will leave clustering until later when we discuss availability, scaling, and routing. 

## 9.1.2 Removing local connections 

As noted, the need for local connections (server bindings) has diminished, as the robustness of remote connections has increased dramatically. Removing the need for a local IBM MQ installation has many advantages. It is one less thing for the application team to deal with when configuring their application. Furthermore, they no longer need to concern themselves with how to scale IBM MQ and the application together. See Figure 9-4. 

