Visio – the Good, the Bad and the Ugly

Oh Visio. Almost any software professional is familiar with the tool. I personally owe my Visio proficiency a major part of my ability to communicate architectural ideas over my 25 years career. From the time it was still a seperate tool and later when acquired by Microsoft and became a part of their Office Pro suite.

With this amount of gratitude, I can say a few words about what Visio is and what it is not.

The Good

Such a vetern software in the market with such a great acceptance has lots of good points. Let me name just few:

  • Easy to start working with.
  • A real productivity booster  with the almost endless number of templates.
  • Extendable with macros and add ons.
  • Tightly integrated with all other Office products.
  • Layering options to make part of the diagram static and another on top of it.

No wonder that it was, and still is, the tool of choice for every software architect and other pros.

The Bad – But Improving

  • Collaboration – Visio started and was designed as a single user single file tool. Up until recently, in order to collaborate on a single diagram you had to email the file, or place it on a shared drive,  to a colleague and get their input. The Microsoft OneDrive as well as other shared drive enable the sharing of files across the internet. But this is not enough for a real-time collaboration, the one provided by Google-Docs and the likes of it. This did not go unnoticed and mutiple companies have developed online tools that enabled real time collaboration for diagraming tools, including Chrome extensions that make it integral into your browser (if you are using Chrome, that is).
  • Data Awareness –  Visio introduced the data linked diagrams. A huge step forward. However it still requires you to have two sources of data – your Visio and your extenral source and to reconcile among them. Try and build an Enterprise archtiecture diagram with all applications and interfaces and connect it to Visio. Still not an easy task, right?

The Bad – Timeliness

This is the one where I did not yet see any solution. I explained the problem in detail in a previous post. Let me quickly recap – diagramming tools gives you a snapshot of a current state.  If you are an IT architect and your software, Database, or enterprise archtiecture is evolving, you need to manually build a set of consecutive diagrams.

UI designers already recognized it and use dedicated tools to build UI interactions and screens. Indigo Studio is my favorite.

If you are building graphics and in the need to add movement, you will proabably go to dedciated tool, or even to the Microsoft own sibling – PowerPoint.

But in case you need to show a diagram with few tens of entities with planned transitions, this is where you may need a dedicated tool. This is exactly why morffy was invented.

The Ugly

This is in the eyes of the beholder. Some like the Microsoft Ribbon and Metro looks. Others, not so much.

Visual transformation – a problem worth solving?

In the beginning there was a project.

Couple of  years ago I was doing a strategic project for a very large Telecom in Europe. They were a mobile comapny who just acquired a wireline company and were dealing with the need to converge their IT systems. Management has set the objectives, and I was there to suggest a road map for the IT integration and the benefits gained at each stage.

As any Communication Service Providers they had a good deal of systems in both companies used for a variety of functions and by various customer segments and geos. The goal was to describe their As-Is architecture of both companies, build a target architecture that will provide the intended benefits and most important prioritize and generate a roadmap to lead from the As-Is to the To-Be architecture.  It was clear that this will take time and effort, but they were also keen about the various outcomes of this initiative.I was reviewing their technological landscape, learning the different systems, their functionality and integration points to start rationalizing it.

I  started by using an Enterprise Architecture tool. The EA tool required a substantial amount of time to implement , but it proved itself quite useful in collecting the data. It was, however, pretty lousy in describing the technical architecture.  The auto generated diagrams, despite their sophisticated alogorithms (and they were sophisticated!) and the multiple variations they provided, could not produce output which even resemble a human created output.

A sample architecture diagram generated by an EA tool. Names were removed.

A sample architecture diagram generated by an EA tool. Names were removed.

I found myself reverting to good old Visio and Powerpoint to describe the transitions in the IT architecture. This meant that I created the As-Is diagram and copied it twice: A phase I that was defined for 12 months later, and a phase II after another 18 months which was also the target architecture. This was a simplification of the reality: major projects were launching every 3 months. But building 10 different architectural diagram would probably be ready in, well, 3o months. So I had to settle for the two milestones. Information about the projects were there, transitions were planned, and I started drawing the changes in the diagram. The initial idea was to track the changes between the phases, but very soon the page became too painstaking. I tried  to use different colors to describe what is added and what is removed at every stage. Two problems raised their ugly head:

  • The paper, or it’s straight forward autoamtion of it, was quite happy with whatever information I placed. I marked a system as becoming obsolete and another one as the new boy on the block, and despite the fact that they were not suppose to work side by side at any point, I could connect an interface between them. Guess what – Visio simply could not care less.
  • The diagram very rapidly became so cluttered with boxes and colors, nobody was be able to make head or tail of it. I simply could not keep it to the level of detail that was needed to make a diligent job.

At this point I retreated to showing three seperate diagrams, each showing the state as is. Three diagrams, and very little to keep track of how you move between one stage to another.

Is that really a problem worth solving? Share if you had a similar experience.