Having got the boxes and wires sorted out, it's now time to look at the distribution of software components across those boxes. There will usually be some restrictions or recommendations from the vendors, but there will still be a lot of flexibility, and the designer must juggle the CPU, RAM, and bandwidth requirements to spread the load most effectively. One typical solution might be as shown in Figure 2.
Call Center Component Diagram
Notice that I've used the interface "lollipop" notation to show the interconnection of APIs. Where a component doesn't have real COM or object-style interfaces, I tend to treat the component as a big singleton object with the functions of the API being its methods. (An alternative technique is to model the API as static or class methods, and to represent it as a class utility. I prefer the singleton approach because it allows for the flexibility to add another identical package into the system with minimal changes.) The CTI T-Server and the ACD are examples in the diagram. Normally, I would use stereotypes to indicate whether the components were DLLs or processes, but space prevents me from doing so here. Note that the CRM database has two interfaces, ODBC used by the CRM server and JDBC used by the dialer.