IT professionals use many types of tools and the advantages and disadvantages between them are not always clear. Diagramming, modeling, and visualization tools all have their strengths and we recommend using the best tool for the job - often in combination, where that makes sense.
Diagramming tools like Lucidchart and Visio are extremely easy to get started with to quickly sketch a design to understand your own thoughts or to share with others. Modeling tools like Archi, Sparx Enterprise Architect, etc have a higher barrier to entry but that extra effort pays off when you are creating multiple, linked views or when you need to infer information across many linked components. Finally, visualization tools excel in generating insights across multiple datasets.
The following box summarizes the key points with each type of tool. Then this article explores modeling v. diagramming in more detail with some examples.
Drawing tools
Examples of drawing (or diagramming) tools: Lucidchart, Miro, Visio
What you can do: You quickly create diagrams from widgets and use a custom layout.
What you can’t do: The widgets on a screen don’t have any identity. If you want the same “box+name” component in multiple diagrams then you need to draw it again. However, just because two boxes have the same name does not mean they represent the same thing. Consequently, changing one in one diagram will not be reflected anywhere that has the same component or line |
Data visualization tools
Examples of data analytics visualization tools: Qlik, PowerBI, Tableau
What you can do: Query data sets, run analytic processing, and generate useful visualizations for insight.
What you can’t do: Represent and reason about IT components and their relationships. |
Modeling tools
Examples of EA modeling tools: Sparx EA, Archi
What you can do: They let you create components and relationships that have an identity so that the same “box+name” can be represented in multiple diagrams. Changing that component in one place will be reflected everywhere that it is referenced. The components can also have fields/attributes which let them encapsulate more information. Diagrams can be created in these tools by arranging widgets and links from a palette with a custom layout.
What you can’t do: Quickly sketch ideas without considering the consequence if those components and relationships are also represented in other views |
Ardoq compared to all of these tools
Ardoq has elements of both modeling tools and data visualization tools. Its components are similar to that of a modeling tool - they have an identity and encapsulate data.
Because the underlying model is a graph, we also get some of the benefits of a data visualization tool through automated layouts, data queries and processing, and data visualization. Using data visualization techniques on the data provided by traditional modeling tools is one of the advantages of new-gen EA tools. |
Modeling vs Diagramming
Questions about the difference between modeling and diagramming have been part of software and enterprise architecture dating back over 30 years to the first CaSE tools.
The widgets that you represent graphically with modeling tools - often boxes and lines - have an identity beyond that one diagram or view. If that same component is represented in a different diagram or view, then both those boxes represent the same thing.
For example, the two diagrams below represent two different views that include the same component - the “Customer Payment Portal”.
The first represents a system integration view and shows how the Customer Payment Portal is integrated with other systems.
The second represents an organization view and shows how the same Customer Payment Portal application is related to expert users, business departments, and ongoing development projects.
These two views could be created in either a modeling tool like Ardoq or a diagramming tool. There are several advantages to using a modeling tool.
If you change a component in one view, it will be updated in another view. E.g., let’s assume the “Customer Payment Portal” application is a self-developed system and the business decides to replace it with an external payments provider. Then updating the model will result in all views that contain that component being updated. That is, updating the model view for application integration will also result in the view that represents how the organization and application interrelate to also be updated.
This may seem like a small benefit. As you build a model of your organization, there will be many 10’s or 100’s of views, dashboards, queries, and integrations that are all based on your underlying data. You need to create a comprehensive model of your organization to help you understand your business and how it changes. You don’t want to maintain all possible views of that data manually when it is continuously evolving. At this level of scale and complexity, you need to automate as much of the documentation process as possible so that your limited number of IT people can focus on design and decision-making rather than documentation and “knowledge archeology”.
Components are objects with an identity and can encapsulate additional data in attributes or fields. E.g., the “Customer Payment Portal” component can include attributes such as licensing information or operational expenditure. Your enterprise architecture model is more than just static documentation. It is a representation of your organization that combines the structural elements of your business and IT landscape together with live operational data that, together, allow you to make informed decisions about change.
Components, links, and their encapsulated data can be analyzed to create insight. For example, a combination of the integration and organizational views can be analyzed to plan for a significant change project. You can quickly find the answer when your CIO asks, “How many integrations does the Customer Payment Portal system have and which teams will be impacted by that replacement project?”. Similarly, data connected with a component - such as the operational expenditure attribute mentioned previously - can be aggregated to answer “how much OPEX do we spend on customer payment-related systems?”.
Components and links that have an identity can be connected to those same components outside the modeling tool. For example, the “Customer Payment Portal” component in Ardoq could be linked to the same system that is represented in a company’s CMDB, ERP, or continuous build pipeline system. As information about machine hosting changes in the CI/CD pipeline, it can then be automatically reflected in your EA model.
Modeling vs Diagramming tradeoffs
These benefits of modeling tools come at a cost - they require more rigor and discipline from the people using them. That is, they have a higher initial cost that will be paid back over time as you deal with complex environments that are in constant change. Alternatively, diagramming tools are extremely useful for quickly sketching out ideas. They have a much lower initial cost to use but will be more expensive to maintain as the size and complexity grows over time. We’ve seen many organizations successfully document some architecture decisions as sketches - for example using Gliffy in Confluence. The ease of use of diagramming tools must be traded off with the other benefits you get from modeling tools.
It's also possible to use both. We often use diagramming tools ourselves to quickly sketch ideas and then, if we want the benefits of modeling and visualization, we import them into Ardoq for subsequent analysis.
Here’s an example where we used Miro for some distributed event storming and then used Miro’s REST API to automatically extract the results and import the cards into Ardoq through its REST API. Other diagramming tools, such as Lucidchart, also have an API where you could do something similar.
The choice between modeling and diagramming is often a tradeoff between the speed and simplicity of diagramming tools and the additional capabilities provided by modeling tools. However, those additional capabilities require more rigor to create the model and then discipline to extract the potential benefits.
Let us know how you’re combining Ardoq with diagramming tools.