Recently a Systems Engineer from an Interactive Intelligence partner contacted me for help in creating a diagram for a complicated architecture.  This architecture was what we systems engineers would call “A Big Kahuna.” His was an architecture that consisted of multiple data centers, several remote sites, work from home agents, several resiliency requirements, and integrations to multiple point solutions that the customer employed.  It can get confusing trying to create a diagram that would incorporate all the above requirements.

 See, there is something about engineering diagrams.  They can range from extremely simple to quite complicated and everything in between.  Take a look at the following examples which are on opposite sides of the spectrum:

   


In my opinion, the goal of a diagram is to have an effect on its target audience, which for me is usually the contact center managers and supervisors.  A good engineering diagram is a visual representation of a customer’s contact center.  It allows them to visualize their call-flows using the solution that is provided.  In other words, it is simple.  The following are some guidelines I use when creating architecture diagrams:

1)  Keep it simple, Oh! Did I already mention that?

2)  I like to use Microsoft Visio. Just like MS PowerPoint is the de-facto presentation software, I feel MS Visio is widely used for creating engineering diagrams.  Using standardized icons and/or pictures in the diagram allows for easy audience digestibility and understanding of the solution.

3)  Clearly label architecture components, especially those icons which may not be understood by just looking at them.  Having said that, avoid stating the obvious.  I have seen many competing solutions where the picture of a telephone has been labeled “telephone.”  I am sure our customers have already watched Sesame Street or been Hooked on Phonics.

4)  State only specific assumptions made while creating the solution so that the customer understands the requirements.  No need to state the obvious.  “Appropriate Power requirements for Servers” would be an obvious assumption unless there is an extra ordinary power requirement for the server, and if state that.

5)  Avoid Clutter.  Remember the diagram is not an inventory sheet used to indicate the number of components in a solution.  For example, if the actual implementation uses four gateways, you can still use one gateway in the diagram to explain the solution.  This keeps the diagram simple, and the customer focused on the solution rather than being distracted by counting components.

 I know I have created a successful diagram when my customers do not schedule a follow-up call with me for diagram interpretation.  What tricks do you use to create successful diagrams?  Paging all Systems Engineers.

Abi Chandra