The company I work for builds solutions - these are the items we take to market. Solutions consist of programs (1-to-many) - these are repeatable projects, or 'recipes' that we piece together to make a solution. Programs consist of multiple components. Components can (and typically do) apply to more than one program (many-to-many). What we end up with is a fairly complicated set of network dependencies - e.g.:

enter image description here

Explaining the network of solutions and components to internal teams is difficult so we build Solutions Maps to show how things interrelate. The purpose of the Solutions Map is to visually describe to our internal teams, how our world fits together. It is designed to be printed out in large format and posted on the walls of our offices. Some typical usage scenarios:

  • it helps people learn how our world wires together - new employees / tech teams can see how components are re-used between solutions
  • it explains to what segments our software provides value - sales can understand what components are applicable to which channels
  • it illustrates how we do business - anyone can see how we take our software to market

Solutions Maps are not too far removed from the diagram above and use connectors to represent relationships. The issue is that this visualization itself is now too complex, and will only get more complex as our portfolio size increases.

What are some other ways we can visually represent the relationships between these objects such that a single static image can contain the entire graph?

UPDATE: updated the audience and purpose as a result of @adrianh answer below.

UPDATE: as per @vitaly's comment below, there are 5 solutions, each with 4-6 programs, and 30 or so components that each belong to between 2 and 10 solutions.

  • 1
    Skip the middle level in the visualization and de-duplicate the components in the solution... (Customers and non-techies need not be bothered with the way you have "optimized" your solution building from components.) – Marjan Venema Dec 6 '12 at 7:21
  • I think that is a good suggestion - could you put it in an answer below? – Jon White Dec 6 '12 at 16:14
  • Since you added a bounty I'm assuming that none of the answers provided thus far would meet your need--is there some feedback you can provide about how/why the solutions below don't make the cut? – Charles Wesley Dec 7 '12 at 23:34
  • I understand that you are specifically looking to capture all this knowledge in a single static image, but I question if that is the best way to capture this ever increasing amount of data wihtout having to outright omit data. It may have made sense before the portfolio grew to this size, but it seems the data may no longer be adequately captured in a single static image. Interactivity, such as the data layering offered in Google Maps could be useful, and building blocks such as steve's answer might be more helpful. I recognize this is not an answer; food for thought. – Shash Dec 8 '12 at 0:01
  • 1
    Great question. It would help a lot if you provided an order of magnitude for each of the elements and for their relationships. Meaning how many components are there (dozens? thousands?), how many programs and solutions - and also how many elements of each type are usually contained in a single element of a higher order. – Vitaly Mijiritsky Dec 8 '12 at 6:59

Creating a feature comparison chart similar to what you see for tiered hosting plans or software packages are great for this:


download bmml source – Wireframes created with Balsamiq Mockups

The advantage is you can let your eye move across the X and Y axis fairly quickly and it seems simple even though the relationships are fairly complex.

  • Mind explaining the difference to my earlier answer? – kontur Dec 10 '12 at 8:42
  • 3
    Both of our answers are coming at the problem from the same angle. I thought your answer was a good one, which is why I gave it an up vote last week. When I first read the OPs question, a feature matrix/chart was what I thought would work well. The difference in our answers is in the illustration of a possible implementation of the general concept. However, I thought a table with repeating cells or columns similar to a spread sheet (your implementation) would not be as usable as what I outlined above. I posted my own take on the matrix approach using a specific example. – Charles Wesley Dec 10 '12 at 16:22

We had a very complex system we were building with similar objects as you've defined. We ended up grouping the components into families or modules. This allowed at a glance to see an overview but the flexibility to retain complex information for devs.

enter image description here

Notice a few things:

  • Modules are repeated in the top section. This is to simplify connections.
  • Modules can have the same components as other modules.
  • Modules can contain other modules.

For our company, we these modules are really our features. If Program 1 needs some image resizing component tied with device detection and Program 2 wants image resizing tied with device detection, then we're really reusing an Image Resizing / Device Detection Component.

Hope that makes sense.

  • 1
    An idea of splitting complex objects into a smaller and simpler parts is sometimes called a decomposition. – alexeypegov Dec 9 '12 at 19:21

While it's not always appropriate and it requires a bit more work than a (simple) dependency diagram, a dependency matrix is the tool developed for this job (presenting graphically the dependencies in a complex system). Here's an example of a relatively simple dependency matrix beside the equivalent graph:

Dependency matrix for a relatively simple graph

This technique scales much better than graphs, too:

Dependency matrix compared to very complex dependency graph


I'd be asking myself whether a single diagram showing all the dependencies is the best way of explaining the structure.

I'd be wondering if the customers actually care about how their solutions are structured?

What are you trying to communicate and why and to whom?

For example:

  • Do customers care about components? Can you just explain stuff at the program or solution level?
  • Do all customers care about all solutions? Maybe you need different diagrams for different customer segments?
  • Do customers need to understand how the structure works - but not the detail of individual mappings. Then maybe having a couple of examples rather than trying to show everything at once would work better?

Without understanding a bit more about the purpose of the diagram it's hard to figure out a concrete recommendation.

  • Fair comments - I think it is more important as a reference for internal teams / sales than it is for customers. I will update the question to reflect this. – Jon White Dec 6 '12 at 16:06

As per request my comment as an answer:


The fact that you need a complex network of programs and modules to build up your solutions is completely uninteresting to your customers and non-techies. So hide the complexity for them. Give them a list of the components available in a solution. And give them a simple way to compare two or three solutions to know what they would be getting in addition (or missing out on). You can take your inspiration from feature matrices and or product comparison sites for this.


Instead of trying to draw a too complex relationship map, you could condense the information to a list. One program per row, with its associated solution, and with modules as columns that are checked or unchecked.


download bmml source – Wireframes created with Balsamiq Mockups

This way it is easier to scan a particular component and see in which rows it is checked. You can also flip the axis' of the table and list the components as rows and check or uncheck which programs and solutions they belong to.


While your set of solutions is limited to two this could work (I could envision 4 or 6 working too, you'd just need to open up the space).

enter image description here

Key ingredients: Color coding, logical groupings (for the solutions), and enough white space to keep your connections readable. Where possible, I think it helps to use abbreviations to tame down the visual noise. Where there are discrete, descriptive names they should be included.

In your case, I think it's really valuable to have it all in one chart. You'll make the depth of the relationships so much more evident, even for people who think they know the system.

Your Answer

