Link: http://weblog.tetradian.com/2012/07/21/which-ea-tools-and-why/
Over on LinkedIn, on the EA People list, Frank Guerino asked about EA tools:
Question about EA Tools… What tools do you use to help you with EA tasks and why? What do you perceive their Pros and Cons to be?
Here’s my reply:
For me the most important EA tools I use are pen and paper or whiteboard, and sticky-notes.
Less visibly, the real tool there is conversation, as a means to get myself and others to think and re-think about what we’re doing, what we want to do, why we’re doing it, and how to get from here to there.
In a social context the space is often an important tool, too: it often makes a lot of difference as to whether it’s in a meeting,room, someone’s office, a cafe or a bar.
That’s probably not the sense that you mean for ‘EA tool’, but it’s probably one we need to remember… 
In the sense that you probably do mean – namely a variously-expensive chunk of software whose visible end-product is a bunch of diagrams – well, yes, I’ve used a fair few of them in my time: System Architect, Troux, Mega, Casewise, Bizzdesign, Sparx and Archi, to name a few. And Visio, of course.
Outside of the nominal EA space, but very much for EA, I use Southbeach (relationships and dependencies), CMapTools (concept-maps), FreeMind (mind-mapping) and many others.
The core advantage of all of the computer-based tools is that they deliver clean, professional-looking diagrams. The purpose-built ‘EA tools’ also do this in accordance with defined modelling rules, link everything together in consistent ways, and provide a consistent, known place to store everything. The more expensive tools justify their sometimes very high price-tags by the quality of their collaboration-features and of the information-repository beneath the surface – making them appropriate for shared use across large organisations.
Disadvantages too, though. The simpler graphic tools such as Visio don’t really support consistency or structure: it’s just a diagram, with nothing much behind it. The so-called ‘EA-tools’ often aren’t much about EA at all, but more about solution-architecture and system-design – the activities that happen after EA, or around EA, but not the real core of EA itself. And some of those tools, to be blunt, are not so much difficult to use as actively user-hostile: there’s a lot that needs to be done to make them more usable, more resilient, more tolerant of user-error.
The other real danger of computer-based tools is that they can beguile us into thinking that the real product of EA is a bunch of diagrams. Those diagrams and their notations are useful, of course, and often important for communication. But they’re just the ‘how’ and ‘with-what’ of EA; what we need to keep the focus on, much more, is the ‘why’ of the architecture.
The real product of EA is not the diagrams, but the often social process by which we arrived at those diagrams – which is not the same thing at all. And unfortunately it seems that the better the ‘EA tool’ is at managing the diagrams and the repositories behind them, the worse it seems to be at supporting the messy, always-uncertain thinking-process that is at the core of EA. Tricky, that…
Getting the balance right is not easy, and each type of tool does it in a different way – which is why most of us end up abandoning the search for ‘the perfect EA tool’, and accept the mess (and, at times, misery) of working with a swathe of individually-useful yet often infuriatingly-incompatible tools. (There’s a desperate need for an information-interchange language for EA tools that actually works… 
)
Take a look at building-architecture. They have all their fancy CAD tools too, with 3D-flythroughs and collision-detection and auto-generation of bill-of-materials and the rest. But there’s a very good reason why building-architects spend years learning how to draw, how to sketch, how to use pencil and paper in any client-space: it’s worthwhile remembering that whenever we look at EA tools.
