This is the second part of a series on how to select an architecture drawing tool. If you haven’t read part 1, I suggest that you follow this link and learn about the different types of tools and the features you should have a look at when selecting a tool.

The main purpose of the tool is to support the enterprise architecture/process management capabilities that are desired. One structure of these is shown in the next graphic and a future article will give more details on the EA Capability Model.

 

Enterprise Architecture capabilities supported by architecture drawing tools

 

In this second article we will have a look at more advanced/technical criteria that can make your tool a success, or a “one trick pony” that will end on the shelf soon, because users will see not a positive value compared with the effort that they put into adding content into the repository.

 

Extensibility

When choosing a modeling tool, the expectation is that it supports a wealth of industry‐standards, but also allows users to enhance the capabilities to accommodate, capture, and analyze institution specific information.

These enhancements are enabled by two features:

  1. An extensible and flexible meta model, which allows users to create new model types, object types, and attributes to enable specific use cases.

  2. A scripting/reporting capability to perform analysis, support modeling and administrative tasks, and create interfaces to other tools (covered in the “Interfaces” section below).

A meta model provides the structure governing information connectivity within the tool, and defines the relationships between the models, objects, and attributes that are available.

When considering a tool, consider the ability to enhance the meta model with client/project-specific additions, as well as the ability to adapt/customize the meta model for individual user roles (e.g. business analysts creating process models and org charts, an information architect who has to create logical and physical data models, an application architect managing a system portfolio, etc.). Ideally, the selected tool will provide all of the above functionality.

 

The graphic below shows the comparison between three tools in these two areas as part of a client project:

 

Custom meta model and apis (Architecture drawing tools)

 

As part of a Proof-of-Concept we extended the ARIS meta model to accommodate the client’s business requirements and upstream system specifications, by creating new attributes that allowed a 1:1 mapping of data fields in the interface, while still adhering to a client’s chosen standard notations (e.g. BPMN).

Additionally, ARIS was used as the design tool for the interface development, interface governance processes, application landscapes, logical and physical data model, and security/permission design. Other Process management tools such as Visio or Blueworks could not have provided the above functionality, as they do not allow users to edit and enhance the meta model as ARIS does.

 

Interfaces and Connectivity

In addition to allowing the extension of the meta model, architecture tools should be evaluated on the ability to readily connect to other tools and applications.

Common considerations with respect to connectivity include:

  1. Out‐of‐the box integrations with other tools (such as SAP or Service Now)

  2. Ability to import/export common formats (Microsoft Excel, Adobe PDF, CSV, etc.)

  3. An open Application Programming Interface (API) that can be used to provide information for use in other applications

  4. An extensible meta model (see above)

  5. A scripting engine/development environment that allows to create the necessary scripts

  6. Support of standard programming languages and industry exchange formats to avoid vendor dependency issues and to leverage existing organizational knowledge and skills

 

In the project example above, we compared the out‐of‐the‐box integrations available for a customer – Sparx, Blueworks, and ARIS, and they showed significant differences. Sparx and Blueworks have limited integration ability compared to ARIS. For example, Blueworks can be integrated with other IBM products. ARIS, however, has the following integrations abilities:

  1. Tools developed by Software AG, such as webMethods (a Business Process Management Software), Alfabet (an IT Portfolio tool), or Mashzone (a dashboarding tool).

  2. Enterprise Resource Planning systems, such as SAP and Oracle ERP, or Configuration Management Database Systems (CMDB, such as ServiceNow).

  3. Import and export capabilities from various tools and formats, such as Excel and Visio (mostly used by business users) or *.bpmn, *.dmn, and .xml file formats for exchange with existing IT systems.

ARIS also has an open API that allows the use of mobile devices to be used with ARIS, using standard web technology (HTTP, REST, JSON, etc.). This API is not meant to replace a more traditional, stable integration, but enables working with the process information everywhere based on geo‐information or QR codes. Use cases for this functionality might be the context‐specific display of process descriptions based on a region or product information in a warehouse. These instructions then can also include multimedia items, such as videos or pictures for additional information. The mobile API also includes governance activities, such as reviews and approval workflows being run on a mobile device, or the capturing of a potential risk at the point of execution during audits.

When creating the interfaces, a tool shall bring either its own development environment or integrate seamlessly with standard IDEs (Integrated Development Environments). Ideally the IDE is integrated and no additional software purchase is needed – again, let the vendor do the heavy lifting in supporting the full development process.

 

To integrate or exchange information with other tools, the tools require scripts and reports. In the project example above ARIS showed multiple user interfaces capable of creating these scripts/reports:

  1. A visual query editor that allows users to create queries by simply grouping items together, step‐by‐ step in the graphical user interface: the result can be shared with other users, and creates a spreadsheet model that can be exported into Excel as needed.

  2. A WYSIWYG (What you see is what you get) report editor: While more complex than the query editor above, the WYSIWIG report editor allows advanced business users (“power users”’) to create reports in a visual environment without having to write code. Reports can import/export data, automate tasks within the tool, and can be tailored to update existing content or create new content in the database without human interaction.

  3. For more complex integration and automation scripting needs, an integrated development environment that uses standard programming languages: using an open language (versus a proprietary programming language) increases the likelihood that an organization may have employees with the requisite skill set to work with the tool, reducing the need for extensive retraining and/or vendor dependency.

Queries and reports can be used as data sources for the included dashboarding component and can be refreshed upon access to a dashboard to facilitate real‐time data updates.

 

Deployment Options

Most tools can be deployed in a client data center or in a cloud‐hosted environment.

If cloud hosting is nor desired (for security or other reasons), a common election is for an organization to deploy the tool within its data center, which requires a server and table space, as well as open network ports, so that the clients can communicate with the server. From an ARIS client side, there are two deployment options:

  1. Download clients or locally installed clients

  2. Modeling directly in the browser

Even though option 2 is the desired one due to the benefits of deploying the tool to the users (there is nothing to deploy on the users’ machines), often there is a need for a hybrid approach, which offers both options mentioned above. For example, selected users may use a locally installed client that includes administrative capabilities (user management, database backup, etc.), or advanced functionality (e.g.; simulation), while business users will achieve adequate functionality utilizing a web browser modeling environment.

In addition to this, some tools’ servers can also be installed stand‐alone on a single PC. However, this is not recommended as a deployment option for a multi‐user environment, but rather seen as a temporary solution in case a user has to make changes while traveling without access to a central server.

A cloud‐hosted version of the tool typically offers the same functionality as the on-premise version, and depending on the package chosen, there may be limitations in regards to interfacing with other systems (private cloud vs. public cloud hosting). Accessing the cloud server by a user is identical to an on‐premise installation.

One example is IBM’s Blueworks which is a public cloud‐hosted environment that may have restrictions with respect to interfacing and access as mentioned above.

 

Technical Support

When choosing a vendor you might want to look if they offer support for both deployment options detailed above, have a technical support program, and offer professional services for the company’s products. The technical support is typically included either in an annual maintenance fee for on premise installations, or in the cloud subscription fee.

In addition to this, there should be a very active user community. For example, Software AG’s ariscommunity.com has more than 600,000 members as of 2021. They also host annual user conferences and organize local user group meetings, where users can exchange experiences and remain informed of new features and developments.

In addition to the tool vendor support offerings above other third party companies/tool vendor partners maintain broad expertise and offer services around Enterprise Architecture and Business Process Management end‐to‐end. The size of this ecosystem might influence the selection decision.

 

Analyst Recognition

The market for architecture/process management tools is mature, and covers the process improvement, automation/integration, and analysis use cases. This is recognized by the major analysts (Gartner and Forrester), reflected by consistent ratings of vendors in the “leaders” analysis section.

Until 2013, Gartner had a specific “Business Process Analysis” analysis. Since 2013 the structure of the analysis reports has changed, and the BPA analysis was included in two areas:

  1. Business Process Management Systems, that include not only a modeling and analysis environment, but also the runtime systems

  2. Enterprise Architecture tools, that include IT application portfolio management in addition to modeling capabilities

This new structure does not necessarily match a client’s current evaluation need for a pure process management tool, but some of the “old guard” from pre-2013, such a Software AG’s ARIS or Mega’s HOPEX platform are still around and in active development, and are either integrated or connect to the tools in the leaders area of these new quadrants. One example that stands out here is Mega’s HOPEX which covers both scenarios in one repository, which allows a more model-oriented approach for business users (e.g., process models), while also providing an object-oriented approach for IT users (e.g.; management of individual applications or pieces of technology) in one repository, while other competitors require a synchronization/interface between two tools.

 

Closing Summary

When looking at selecting an architecture/process management tool, it is a good idea not only to look for the functionality needed in the current moment. Looking outside of this and evaluating technical integration capabilities, support offerings -either by the vendor, user groups, or partners- are important criteria as well, since the success of the tool in regards to the acceptance by the users is critical.

Buying a professional architecture tool, because it is “Visio on steroids” is never a good idea, and providing a tool will not guarantee the implementation success … but this is a topic for another article.

 

Bonus: To make things easier for you, I have created a Google spreadsheet that you can use for your tool evaluation efforts. It is read-only, so save a copy of it first.