Currently I am working for a large international organization. This organization has many roles according to the IT book in place: business architects, enterprise architects, solution architects, product owners, solution designers, UI/UX experts and infra architects and I probably haven’t mentioned other important roles.
A lot of those architects use various tools to create beautiful diagrams. Mostly in the colours yellow, blue and green. Yes it’s an Archimate shop. Since a lot of system development is also done in-house UML is to be found in the “lower regions”. Money does not seem to be an issue here so the Atlassian toolsuite is running in full galore extended with various document “management” systems like Sharepoint.
Many architects are doing there utmost to create diagrams to explain how difficult it really is. To achieve this various tools are being used. The application landscape is large and pretty old. Hence a migration to more up-to-date systems and top-notch technology is in the making. Each specialist is allowed to create diagrams with his/her own tool of choice. Especially tools that run in the cloud and deliver point solutions are in demand. I did not know that so many tools existed out there. My toolset is limited to Sparx and Dragon1 which with I can manage 98% of my modelling needs.
Since coupling and traceability between all these diagrams is pretty difficult (let’s say impossible) everything needs to come together in a Wiki page. Decoupled diagrams also have the need to re-enter basic design elements like roles, application, business processes and such.
In the project there is the same problem. Enterprise Architects provide large ArchiMate diagrams, data modelist provide class diagrams and those diagrams are reworked on by solutions architects and provide input for solution designers. However all diagrams have the same problem. Yes I see a box, yes it has sort-of-a-name, yes the colour and type is correct, but what does it mean. Implicit design decisions are given with names like Something Manager, Something Provider etc. And thus along the line information is added but does not have the same quality or impact as it had when the initial diagram was created. Just because it is an empty box.
One of the main reasons, I think, is that all tool users of more sophisticated (or at least more applicable) tools that store design elements in repositories are still thinking of the tool as were it Visio. When I showed a user last week that “hey if you enter descriptions here” and use the same element in a different diagram he was amazed and exclaimed “hey this is not Visio”. When I presented him a generated Word document containing a diagram with elements that do contain descriptions he was amazed. Alas he is not alone and unknowing about this.
I think tool vendors should present there tools as collaboration tools that can produce useful pixel perfect reviewable documents with pretty adjustable formatting and filtering features. Reading your models in text form helps you better understand and structure your model, but more importantly you will find that your models tend to become better in a faster. Because if your document is unreadable the origin of this is your diagrams. Pixel perfectness helps in the joy of opening a document by others. Although crappy looking documents might contain very useful information after reading it, your first feeling is just “ahhh, crappy”. We are all humans and have a first impression before we know.
Helpful documents start with filled boxes.