Our team likes to be responsible data architects and have asked our software vendor ("vendor") for their data dictionary so that we can ensure our data warehouse fields can accommodate their data. We were having trouble getting a data dictionary from the "vendor". The application is a Software as a Service (SaaS) and they provide an API to access the data. Their response to us was: "Why would you need a data dictionary; this is a SaaS."
My first reaction was: "Oh, they're a SaaS, powered by unicorns." Not that I have anything against unicorns. Frankly, I wish I had access to unicorns in my database development efforts. But since when do data professionals not need data dictionaries? They're the backbone of any successful data-related development effort**. How would a team otherwise communicate the definition and intent of each data element?
Please enlighten me if that standard practice has gone by way of the dinosaurs. Perhaps I shouldn't be so ridiculous. The "vendor" could have a highly evolved team of Vulcans, in which case their mind-melding abilities would make the practice of data dictionaries obsolete.
All kidding aside, documentation is truly very important. How you accomplish it varies in each environment. You don't need to spend tons of money on special modeling software. A simple Excel spreadsheet can accomplish the job in a pinch.
** [See Chapter 2 of Pro SQL Server Relational Database Design and Implementation by Louis Davidson and Jessica Moss. The authors make an impassioned argument for requirements gathering and documentation along each step of the development process. One might argue that a SaaS is not an RDMS system and therefore not subject to data dictionaries because there are no data relationships. But that argument is a weak one at best.]