Publishing Options
Sparx Enterprise Architect Publishing Options
Enterprise Architect models can be published in several ways, ranging from static documents to interactive browser-based views and programmatic integrations.
Web and browser publishing
Depending on the EA and Pro Cloud Server configuration, stakeholders may access:
- Browser-based model navigation
- Package and element browsing
- Diagram viewing
- Search
- Traceability and relationship navigation
- Controlled, read-only stakeholder access
Advantages
- Accessible without installing the full EA desktop client
- Useful for architecture portals and requirements reviews
- Can provide a more current view than static documents
- Supports broad stakeholder access when properly secured
Disadvantages and considerations
- Availability depends on product configuration and licensing.
- Requires authentication, authorization, HTTPS, and secure network design.
- Performance can be affected by latency and repository size.
- Access must be separated appropriately between authors and readers.
HTML documentation
EA can generate HTML documentation for deployment to an intranet or website.
Advantages
- Easy distribution through a browser
- Searchable model documentation
- Readers do not need EA installed
- Suitable for formal project deliverables
Disadvantages
- Usually a snapshot rather than a live model
- Must be regenerated to reflect changes
- Web-platform access control may be separate from EA
- Large models can produce substantial output
RTF, PDF, and document generation
EA supports document-oriented publishing for:
- Requirements specifications
- Architecture descriptions
- Design documents
- Review packages
- Compliance evidence
- Formal project records
Templates can standardize headings, diagrams, element fields, tagged values, and relationship information.
Advantages
- Familiar formats for business and governance audiences
- Suitable for approvals, reviews, and archival records
- Templates improve consistency
- PDF is convenient for controlled distribution
Disadvantages
- Output is static and can become outdated
- Traceability and navigation are weaker than in a live model
- Documents may require repeated generation and review
- Large reports can be difficult to manage
XMI and model exchange
XMI supports package-level exchange between repositories or compatible modeling tools.
Advantages
- Useful for migration and interchange
- Supports package-level export and import
- Can help distribute model content between teams or tools
Limitations
- Tool-specific extensions may not transfer perfectly.
- Diagrams, scripts, profiles, linked documents, and external references may require additional handling.
- Import/export can create duplicates or broken references without governance.
- It is primarily an exchange mechanism, not a stakeholder publishing portal.
APIs and automation
EA and Pro Cloud Server APIs and interfaces can support:
- Documentation generation
- Requirements or data import
- Synchronization with external systems
- Validation rules
- Reporting and analytics
- Custom portals and dashboards
- Extraction for data warehouses, CMDBs, or ALM platforms
Advantages
- Enables repeatable and customized publishing
- Supports integration with existing enterprise systems
- Can automate quality checks and report generation
- Makes model data available for dashboards and downstream processes
Disadvantages and considerations
- Requires development and ongoing maintenance
- Authentication and authorization must be designed carefully
- Integrations need error handling and monitoring
- EA upgrades may require compatibility testing
- Published data may need filtering to prevent unintended disclosure
Choosing a publishing method
| Need | Recommended option |
|---|---|
| Live, interactive stakeholder access | Browser-based publishing through an appropriately configured Pro Cloud Server environment |
| Intranet documentation snapshot | HTML documentation |
| Formal approval or archival record | PDF or generated document |
| Exchange with another repository or tool | XMI |
| Dashboards, synchronization, or custom portals | API-based automation |
| Broad read-only consumption | Separate published or web-accessible view rather than direct authoring access |
Recommended publishing architecture
Keep publishing separate from the production authoring workflow:
- Maintain a controlled repository as the authoritative source.
- Define which packages and properties are publishable.
- Generate HTML, PDF, or web views on a controlled schedule or release event.
- Apply appropriate authentication and authorization to live or browser-based access.
- Label static outputs with their generation date or model baseline.
- Automate extraction and reporting where recurring publications are required.
- Retain published artifacts when they serve as formal records.
A combination of a live read-only web view for current navigation and generated PDF/HTML snapshots for formal communication usually provides the best balance between accessibility, currency, and governance.