The Big Picture

Chances are that at some point in your life as an architect you have come across UML. Maybe even had the dubious pleasure of working with a humongous all-problems-solved tool like Rational Rose. In which case you probably have suffered a life-long allergy towards all things UML and are now doing all of your designs with pen and paper.

Anyway, at some point I stumbled across Enterprise Architect, a neat UML tool with fairly low pretensions and was instantly hooked. It looked fairly neat and allowed you to throw together nice UML-compliant diagrams and even share them with your team without locking you into some sort of bizarre development process. Surely, it has major usability niggles, is unstable at times, its reporting module is a joke (why on earth can't you just provide proper schemas for your models so people can draw their own reports?), it runs awfully slow on remote databases and is Windows-only. However, it was wieldy enough to provide for years of good service.

Now and then, people would come to me to start an argument over UML-based design and how it can lead to endless tinkering with details that would be best solved by actually writing some code. And how useless a model is if it's not derived from the code and that code generation just does not work. I used to counter them with the statement that I was just drawing pictures and EA was providing me a consistent and hopefully universally comprehensible way to do so.
Until recently.

When I first started at Skype I took upon myself to put down everything I learn about its systems. And, being a devoted EA user, it was clear what would be the tool to do so. At the beginning it was pretty cool: the boxes started to pile up, dependencies appeared and the picture was there. However, as the time passed (a month or so) I would work less and less with that diagram. It seemed that nobody seemed to have enough detail on the connections and even worth, the details seemed to change daily. Also, the amount of components and their connections grew to a point that the whole thing resembled a modern art piece rather than a clear map of "what we have".

So I gave up. Afterwards, when somebody (usually a neophyte) approached me and asked for "the Big Picture", I would sometimes make another stab at it but would soon give up. So there it lay, dormant and outdated.

Until one of our team leads approached me with a very clear request. He had an off-site coming and needed presentation material for new members of his team. This time I decided to take a different route. I took Omni Graffle (an excellent Mac diagram tool recommended by Dan) and just drew away. A round-edged and shadowed box here, another there. Some arrows, coloring and there it was. Sure, it did not have all the details as you would need to be able to still grasp it, so I had to leave some out (Still ended up with a densely populated A2 sheet). Sure, it was not UML because sometimes an arrow was a SOAP call, sometimes meant that a module was linked in and sometimes just meant a database usage. And most of our database or queuing infrastructure was not pictured at all as it is in constant change and our DBAs generate their own diagrams from its configuration. After some minor correction (had forgotten some components) the picture was ready, did its first outing on that off-site and serves its purpose nicely.

So how come I was not able to do something in two years using a professional-grade UML tool but could cook up a useful diagram within hours using a dead-simple diagram drawer? The answer is simple: there's a tool for every purpose and UML is just not good for maintaining a high-level view. It's just too detailed. It's not very good for maintaining nitty-gritty details either as developers usually know much better how long and of what type a particular field should be, but that's another story.

The lesson learned from all this is to use the right tool for the task and if you have a really good and handy hammer, most things start to look like nails.