Full UML support enables you to diagram solutions at any level. Enterprise Architect goes one step further and provides templates for context-specific languages such as ArchiMate. It also includes tools for GoF Patterns, MindMapping, a Whiteboard and several other tools that constitute quite an impressive list.
Click here for larger image
Figure 3. A Truly Impressive List of Tools Within the Tool
Down in the Weeds with .NET and J2EE
While a business architecture should never include implementation-specific details, there are scenarios where an Enterprise Architecture should include at least some technology-specific principles. Whichever side of that debate you find yourself on most often, the majority of enterprises are going to use J2EE or .NET or a combination of both (without ruling out other options) at some level. It is a handy feature of Enterprise Architect that the reverse engineering tools can be used to create a bottom-up baseline model starting from the source code of .NET and J2EE current capability solutions.
Once a target model has been created, the gap analysis performed (Enterprise Architect has a tool for that, too!) and a transition architecture described, the design can be elaborated on through the IT capability layers until source code is generated from the lowest-level model.
For the smaller enterprise where the architects wear many hats to the global corporations where the architect and developer may literally speak different languages, it is advantageous for an architecture tool to integrate with an IDE. Sparx sells integration tools for Eclipse and Visual Studio at a reasonable price and provides trial editions to give you a chance to evaluate the effectiveness for your particular IT practices. This ability to integrate with other tools as well as exchange information with other applications using XMI allows enterprises multiple strategies for implementing and adopting Enterprise Architect within their EA practices.
The All-In-Wonder Trade-Offs
Enterprise Architect is the Swiss Army Knife of architecture tools. It does many things well though none of them as well as single focus tools. For example, I first came across Enterprise Architect looking for a tool that would do reverse engineering. On the plus side, Enterprise Architect does an excellent job of creating detailed class diagrams with relationships and dependencies with only a few clicks of the mouse. The downside is that the generated diagrams are limited to a single package. To build an application-level class diagram requires importing the packages one at a time, which can be a tedious task.
While the entire source can be imported as a whole, this does not result in a diagram containing all of the classes, as one might hope. Enterprise Architect does, however, support XMI for exchanging models between standards-compliant UML applications, and it would be quite common for enterprises with complex application structures to have such tools around.
Click here for larger image
Figure 4. Highly Detailed Class Diagram Generation Is Limited to One Package at a Time
For an enterprise architect who also works on a project level, having a lot of functionality in a single application can be advantageous from a dollar cost point of view. Even if cost is not a major factor (such as when licenses for individual tools already exist), the performance of Enterprise Architect is a nice improvement over the resource drag that can occur when running even a few of the functionally-focused applications it conceivably replaces. Productivity can rapidly fall if there are long pauses every time you need to switch between applications. Worse yet, running multiple high-powered applications can lead to lock ups that require a reboot. At best this can be a loss of 20 - 30 minutes in rebooting and then bringing back up the various views you are working on. If you have not developed the habit of preceding every ALT+TAB with a CTRL+S, you could lose hours of work.
The best of all possible situations is to have specific tools for each level of productivity and detail as necessary and then to utilize Enterprise Architect when working with multiple artifacts at the same time where a little heavy-lifting is required. Because of the standards support in Enterprise Architect, as long as the other tools support the same standards (and they would not be high-quality tools if they didn't), the limitations of Enterprise Architect are overshadowed by its value as a bridge tool.