In an ideal world, Assuan would not be necessary. Assuan's primary use is to allow a client to interact with a non-persistent server. Using Assuan, this is accomplished by forking a subprocess and communicating with it via, for example, a pipe or Unix domain socket. This method is neither elegant nor efficient, especially when there is a lot of data spread across several transactions: not only is there a penalty for an increased number of context switches, but also a significant amount of data is memcpyed from the client to a file descriptor and from the file descriptor to the server. Despite these and other disadvantages, this type of client/server communication can be useful: the client is completely separate from the server; they are in different address spaces. This is especially important in situations where the server must have a known degree of reliability and data must be protected: as the Assuan protocol is well defined and clients cannot corrupt the servers' address space, auditing becomes much easier.
Assuan was developed for use by the GNU Privacy Guard, GnuPG, to prevent potentially buggy clients from unwittingly corrupting sensitive transactions or compromising data such as a secret key. Assuan permits the servers, which do the actual work, e.g. encryption and decryption of data using a secret key, to be developed independently of the user interfaces, e.g. mail clients and other encryption front ends. Like a shared library, the interface is well defined and any number of front ends can use it; however, unlike a shared library, the client cannot see or touch the server's data. As with any modular system, Assuan helps keep the components small, understandable and less error prone.
Assuan is not, however, limited to use with GnuPG servers and clients: it was designed to be flexible enough to meet the demands of many transaction based environments with non-persistent servers.