There are lots and lots and lots of EA users who don't write code. And don't have access, any more, to people who can write code for them. They are business analysts and process modellers and even actual Enterprise Architects, and they just don't write code.
So any document creation mechanism which relies, even in a small way, on writing code, or even requiring understanding of the increasingly complex EA internal data model, just is not fit for purpose. When these people are told they need to write code to make a document, they go straight back to Visio and Word, and those tools are the completion here.
Well, I can not agree with you. Not all BAs and EAs fall back to Visio and Word. Which is terrible on so many levels that I don't even want to follow that idea more.
I am an Enterprise Architect (TOGAF and ArchiMate certified) and Business Analyst (OCEB, CCBA certified), I've been using Sparx EA for many years and I would never want to do my documentation in Word or draw pictures in Viso (in Visio you can not model!).
Anyway, recently I created needed set of templates for UseCase documentation generation. It is described verbosely here
Nonlinear generation of documentation in Sparx Enterprise Architect. The main aim of doing it was ease of use. I agree with you that not every EA user must understand how the tool works uder the hood, I also think that Virtual Documents are a little bit too complicated for many modelers (BAs an EAs included). That's why
I created complex template that is easy to use. I did it not because I think BAs and EAs are allowed to not understand their tools, I did for people who very rarely use Sparx EA, like developers, PMs and junior BAs/designers.
On the other hand I agree with Geert:
Sometimes it pays off to get the help of EA consultant before venturing into a custom-build adventure.
Or just moving back to Word or Visio. Yes, Sparx is challenging on many levels, but it can gratify you with many things that will amaze you!
On the other hand BAs and EAs are quite spoiled, organization allow them to use bad tools and practices (way they work, not methodologies they use) even though it's waste of time and money.
For instance, I cannot imagine that Java developer would complain on IDE and try to change whole project setup because he does not know how to do something in it. If you're good you should learn it or reconsider your career :-) On contrary, I worked on few projects when it was extremely hard (months of discussions and presentations) to convince BAs that Word in not a tool for creating & managing requirements / documentation. Sorry for digression.
Anyway, I just wanted to say, that some of you may find some answers about Doc generation in my article, so please check it out here
Nonlinear generation of documentation in Sparx Enterprise Architect.
