Visualizing

Every aspect of the business and IT architecture could be described purely in a textual form; business structure, processes, system integrations, or data structures, they all could be specified using just text, free or structured. But the fact it is possible definitely does not mean it is the way to go. Unfortunately, we see this pattern quite often. Dozens of Word documents describing use cases, processes and architecture, each aspect described on a couple of A4 pages. No wonder all the projects were behind schedule, as finding and reviewing anything in such specification is time-consuming and frustrating.

Although many types of information are better to be described using text (use case scenarios or definitions, for example), there are also certain types which are usually more efficient to be communicated using visual elements. Talking about visualization, the very first thing that probably pops up in most of the analysts’ minds are diagrams. But visualization is not just diagrams.

1. Diagrams

Diagrams are great in cases where the logic behind the described aspect is complex (processes, workflows, algorithms) or when the nature of the aspect is structural (domain model, organizational chart). Despite the obvious benefits, many people still refuse to capture information with diagrams, arguing that the stakeholders do not understand them, and there is no time to teach them the notation. It may be true, but the fact is it is the analyst’s responsibility to evaluate if and which aspects could be expressed with diagrams, depending on the target audience and the particular aspect. Nevertheless, there are only rare cases when stakeholders would resolutely refuse to discuss things described using diagrams. It is mostly the other way around and the models quickly become the main communication medium. Also, the experience has shown that when analysts simplify the notation of the diagrams and use only the basic elements, stakeholders pick it up very quickly. As a result, after a very short training, they have no trouble reading them whatsoever.

2. High-Level Pictures

An essential part of the analysis work is explaining. Analysts repeatedly explain to various parties, for example, the project scope, high-level system architecture, or a business domain overview. Even though the topic could be introduced using a text paragraph or two, it has shown to be convenient to have a high-level introductory schema. A diagram that is easy to understand could be used anytime when it is needed to quickly explain the subject to somebody.

The following schema represents a quick overview of the project scope, showing the affected areas of the Compliance and Monitoring in a bank, including the impacted systems.

3. Demonstrations

The idea of demonstrations is to show stakeholders something real as soon as possible to boost their imagination. The goal is to encourage stakeholders to think about the problem differently and to uncover issues that would have remained hidden otherwise. The particular demonstration technique depends on the subject. It could be simple UI sketches and prototypes, but also live process walk-throughs. But in all cases, once stakeholders are shown something real, even though it is hand-drawn on a paper tissue, they will add new details to it, which is exactly what analysts need!