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.
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.