> Do you mean you update PlantUML source files by hand in order to follow software changes, instead of generating them from a real model or from a reverse engin

> Do you mean you update PlantUML source files by hand in order to follow software changes, instead of generating them from a real model or from a reverse engineering tool? Sorry, I didn't explain it clearly enough. In our project, it's not only about components/classes. We have architectural documentation which describes a high-level architecture of the whole project: services, deployments, interfaces, devices, middlewares, files, virtualized environments, databases, and their relations across different domains and software clusters so it's not possible to generate diagrams for such things. >> there is no way to control the position and layout of elements on diagrams > This is a feature: there is no way to waste time fiddling with diagram layout Yep, I understand but... As I just said, when a project is big, and it has a big architectural document that describes different software clusters, their relations, deployments, and so on, then it's totally unacceptable when all teams on each sprint/release are getting such an important document with brand-new diagrams because of "that feature" since some new architectural piece was added to the diagrams. > you can tell that to the cheapskates who made you switch from Enterprise Architect to PlantUML. After all, we didn't make a full switch to puml. We are still using both. There were some problems with the Enterprise Architect so lead architects decided to check how puml will play in that role but they quickly rejected the idea after the evaluation of pros/cons.