New Feature: Bulk Component Editing

Bulk editing is something that many customers have asked us for, and today we’re happy to deliver. Bulk editing is available now in the product, so try it out and let us know what you think!

Selecting multiple components

In the navigator, hold down Cmd (Mac) or Ctrl (PC) to select multiple components.

Note that simply clicking a component to focus on it does not include it in the selection, you’ll need to Cmd/Ctrl click that component as well.


Drag components to reorder or change hierarchy

You can drag selected components into new positions in their current level, or move them to a different hierarchy level (where you can move them of course depends on the hierarchy rules of your model). This example uses a flexible model, so the components can be placed at any hierarchy level:


Bulk edit component properties

By right clicking on the selected components, you can edit the properties and fields that exist in all of the component types. Whatever change you make in this dialog will be applied to all selected components.


Bulk tag components

Using Tagscape view, you can drag multiple components from the navigator to a tag to apply it to them.


Webhooks & Conditional Component Formatting - Our Holiday Gifts to You

Happy Holidays! We agonized over what to get for you (you’re tough to shop for, you know), but in the end, we decided a handmade present would show you how much we care. Let’s unwrap.

Webhooks (beta)

We’ve implemented a beta version of webhooks, and it’s currently open to testers – just submit your email below to request access.

We’ve always offered a REST API to give you direct access to your data, but webhooks introduces a new capability that lets you subscribe to and act on changes that happen in Ardoq.

Webhooks can be used to build sophisticated integrations with Ardoq, and makes integration that needs to synchronize state or react to changes in Ardoq a lot easier to write. We’re excited to see what creative uses our users come up with using them.

To sign up for beta access, please submit the email address associated with your Ardoq account:

Conditional Component Formatting (released)

Conditional component formatting is an extension of the filtering functionality of Ardoq. But instead of showing or hiding components, with conditional formatting the matching components are set to the color you choose.

Set component color based on component properties.

This is nice for creating heatmaps – you can set color gradients for things that are critical, expensive, risky, etc. Like webhooks, we have some use cases in mind for this feature, but are very excited to see what our users use it for.

Components that don’t match any conditional formatting show up as gray.

This feature is live in production and ready for you to play with.

That’s a Wrap ( Bad joke eel )

Let us know how you like your presents – hopefully they make you feel like this:

Cheers to a new year,
Team Ardoq

Reducing Risk by Relinquishing Control

Our thoughts on required fields

I wanted to take the time to write a quick summary on a topic that is brought up in nearly every meeting we have with potential customers, especially from the management and enterprise architecture teams:

“Do you support required fields?”


“Can I define what types of integrations are allowed?”

Short answer: No.

But the reasons behind this answer make for a much more interesting blog topic. Our lack of support for especially required fields is one of design, not poor product development.

A feature, not a bug.

Our experience with documentation and traditional enterprise architecture tools has left a bad taste in our mouth, hence why we started Ardoq. One of the most irritating things was the tool’s ability to encourage you to NOT document. For example, we have had situations in our professional career where we found a new system formally missing from the EA repository. Being responsible employees, we thought to update the lacking repository, but then hit a wall with a notification: You can not commit this change without filling in the mandatory fields…

Often these fields are not readily available, things like cost, responsible maintainer, etc. If we knew all these details, it’s likely that we would already have the system in our repository.

The point is, if you require too much of people, they are more likely to just not update or document. By allowing people to quickly input information, even if it’s incomplete, you can identify more “known unknowns” – that is, you will know what documentation is missing. This is still a potential risk, but much less of a risk than not knowing if the system, change, integration, etc., even exists.

The same can be said for rules on dependencies (relationship, integrations, etc.). Yes, ideally you would like your enterprise architect’s design guidelines to be followed, but not allowing people to document the reality can be dangerous.

We have actually seen this when we compared the as-is model found in the customer’s traditional EA tool with the data dumped into Ardoq (the reality). The EA team was quickly made aware of multiple integrations that were dangerous not only to their architecture design (point-to-point), but to legal compliance in handling sensitive data (not over HTTPS).

But then how can we manage the potential chaos?

This is a very valid concern.

Traditionally, reports have provided a sense of safety and control – but all too often it is a false sense. We’ve seen too many cases where architects depend on static reports with outdated information – making decisions based on that information can have costly results.

We understand that Ardoq can fall short in feature comparisons when it comes to reporting, since we don’t offer out-of-the-box reports…yet. We’re a startup with limited resources, and we have prioritized gathering data and automatically visualizing it over vanity reports.

We believe that Ardoq enables processes that result in accurate, up-to-date and quality data. With that data as the foundation of your architecture documentation, you can derive much more valuable insights from live representations of that data than report functionality based on outdated, fragmented and incomplete documentation.

Our vision is to continue to build on our powerful data model to create better reporting and analysis. We also hope to include functionality that will allow you to define suggested rules, and instead of enforcing them strictly, would inform managers as to the health of their documentation and highlight deviatioons from their design. This would enable quick and dirty documentation but still allow for the necessary QA process.

Looking forward

Our first round of enabling Elasticsearch (due to be delivered within 2016) in our search and filtering functionality will provide the basis for more powerful queries and analysis. We are also working with partners and customers to build custom plugins in-app to support gap analysis and conditional highlighting. These developments will be the first steps towards dashboards and reports based on the reality of your documentation, not your best guess.

We just recently improved our filtering capabilities to allow for filtering by “empty” fields. This will give managers the ability to filter workspaces to get a short list of the components or references which are missing field values that should be documented. And since we have full history and an overview of the creator and last to modify, you will know who to contact to get the missing info updated.

At the end of the day, Ardoq is a tool. Nothing is a substitute for good processes and a culture which prioritizes quality documentation. We hope to provide you with the tools and functionality you need to maintain speed and control in your development.

6 Best Practice Tips for New Ardoq Users

Starting to use a new tool can be daunting – learning how it works and incorporating it into existing processes and toolsets take time. To help new Ardoq users spend their time wisely, we’ve written a list of things to think about before you dive in, along with product usage best practices that help you get the most out of Ardoq.


User Creations: Python API Client & Sunburst Visualization

Two of our users have recently completed projects that extend the functionality of Ardoq. We wanted to highlight their efforts and show off the results: a Python client for the Ardoq API, and a new Sunburst visualization.


Releasing a new version of Ardoq


Today, we are releasing a new version of Ardoq. The client application has undergone a major facelift, with changes to information architecture, interactions, and the overall look and feel. (more…)