Selecting an Enterprise Architecture tool (part 1)

Setting up an architecture/process management capability is a large endeavor, and the choice of the enterprise architecture tool (or the refusal/delay of a tool selection) can determine the overall success of the program. If the tool does not provide the necessary functionality, the value can be diminished or not realized, and additional purchases might be necessary to compensate. This brings the overall cost over the cost of a more complete – but more expensive in the beginning – alternative. Or the tool chosen is just for one user group (the nerdy analysts and architects) and the implementation fails because the tool is not accepted by the rest of the organization.

The criteria for selecting the right enterprise architecture tool is pretty long, and therefore this article is split into two parts. Part two will also include a worksheet that you can use for your own tool evaluation.

 

Categories of Enterprise Architecture Tools

Architecture tools that provide varying functionalities and capabilities, and you can buy more modeling-oriented tools, or more database-type tools where information is captured on forms and not in diagrams. Modeling tools are more flexible than DB-driven tools if they fall in the later category shown below:

 

 

 

1. “Drawing Tools” – Allow users to “draw” a diagram, but typically create standalone artifacts that are not connected, and therefore do not allow model analysis or the creation of a model structure that adheres to a framework such as The Open Group’s Architecture Framework (TOGAF). Further, these tools do not provide the functionality for users to develop a process model hierarchy that allows users to drill‐down into lower layers of a model or connect models for essential navigation.
   

   In general, drawing tools do not provide support of semantics that help a user to model in accordance with a specification (such as BPMN 2.0), and do not provide automated semantic checks to highlight non‐adherence to desired modeling specifications.

   Example: Microsoft Visio
   
   

2. Implementation Front Ends – Allow the visual modeling of processes, while requiring the configuration of an underlying execution engine. As such, not all artifacts that are typically needed for a complete process design are available (see the “Elements of a process” graphic below).

   These tools typically do not support the creation of model structures/hierarchies or the connection of models because the executable processes that they help configure are self‐contained with well‐ defined start and end events. In other words, the models “pile up” on each other and are managed as individual, isolated models.

   Process analysis in these tools is typically restricted to single processes that are currently executed (performed in a production environment), using the runtime data available from the production environment. However, more advanced analysis methods, such as 6 Sigma, are typically not supported by this class of tools.

   Example: IBM Blueworks
   
   

3. Database‐Driven Enterprise Architecture Tools – These tools are built for the specific use case of designing and analyzing any desired type of process and architecture views. As such, these tools possess the capability of managing a large number of models in a multi‐user environment. These tools often maintain tens of thousands of models in a database with numerous users accessing the database simultaneously, which allows them to scale well throughout an organization.

From a functional perspective these tools support standard industry frameworks and notations out‐of‐the‐box, which enables efficient implementation while also providing the modeling consistency of a standard. This is supported by automated semantic checks, and other automation possibilities (e.g., establishing governance procedures with automated approvals processes).

For large, complex organizations interested in establishing a BPM/EA capability, this class of tool provides significant advantages above others.

Example: Software AG ARIS; Mega HOPEX

 

 

General Enterprise Architecture Tool Capabilities

When evaluating a process/architecture tool the following criteria, separated into the four categories of user focus, functional requirements, methodology, and technology should be considered:

 

User focus

The enterprise architecture tool should be able to support various end user types/personas, and provide the information for them in the right format, so that not every user needs to be a “full modeler” to use it. This means that, for example, management stakeholders will interact with dashboards and tabular views, while analysts mostly will create and modify diagrams. Regular end users might be only interested in narratives and step-by-step instructions that support the work at hand and will be displayed on kiosks or tablets.

• User Interface: Modeling requirements, such as visual representations of large models or web‐based publishing (portals) and modeling and the ability to adapt to an institution’s desired “look‐and‐feel” or corporate identity standards, including WYSIWYG report creation and modeling support.
  
  
• Dashboards and workflows: One critical success factor will be the ability to communicate complex content to a non-architect stakeholders. These users do not need to (and do not want to) learn the details of a modeling tool, and the structure that is set up to manage the content. They want to have the findings and KPIs being presented directly in easy to understand dashboards, or be guided by screens as part of a (governance) workflow.
  
  
• Reporting: Provide robust reporting and dashboarding capabilities, allowing the analysis of the BPM/architecture content in real‐time or on demand. This capability is especially necessary for non‐ technical business users who require readily accessible overviews of results without interacting with the underlying database.

 

Functionality

A good tool should support the full lifecycle of the content (see the “Process Lifecycle” graphic below), and either provide the necessary functionality directly in the tool stack, or have pre-built interfaces to specialty tools that provide the desired functionality.

 

The artifacts of the specialty tools should be integrated seamlessly in the architecture tool.

 

Methodology

As shown above, the preferred type of tool – a database-driven tool- should have a methodology/meta model being built in. A meta model determines the available model types, the object types within the available models, and attribute types and connection types.

 

Technical requirements

The selected tool will be more accepted as a System of Record if it can be integrated into an existing IT landscape and is managed like a “real IT system” (vs. a drawing tool). This will also bring the architecture/process management team to the table, and position them as a main player in the organization.

The next graphic shows artifacts from different architectural views in one diagram. A good tool allows to manage these in different views (and grant permissions for the responsible user groups), while also allowing to bring in artifacts that are read-only and managed by others.

Only some of the database-driven tools bring these key capabilities, and some of them have included third-party SW in their core product, or created interfaces to the market-leading niche players in an area. For obvious reasons an inclusion is the preferred way to go, because the tool vendor already has done the heavy lifting for their customers.

 

In part 2 of this series, we will have a look at other criteria, such as extensibility, integration with other tools and support offerings.