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.
Tom,
Thank you for another good post. I agree with your assessment and particularly “which is why most of us end up abandoning the search for ‘the perfect EA tool’, and accept the mess (and, at times, misery)”
I took a course in the spring and was exposed to a methodology called “Issue Mapping”. There is a standard IBIS http://www.cleverworkarounds.com/category/issue-mapping/
I was directed to use a tool called Compendium http://compendium.open.ac.uk/institute/about.htm which is an open source project and free to download.
I used this tool successfully to capture conversations, link ideas from those conversations to actions and create high level action plans.
Cheers Leo
Thanks for the pointer to issue-mapping, Leo – and good point about Compendium, I’d forgotten about that one, I need to revisit it again, I’d guess.
A tool I recommend is printing off a huge sheet of paper with the segments of your EA framework … will work very well with your postits … make sure your postits come in different colors too!
Still the best tool to begin with … then your iphone or any smart phone can simply take a picture of the results.
Good point, Pat – that way, the framework becomes a literal frame for the development-conversation.
A colleague gets a bureau-service to print his frameworks on 3’x4′ sheets of whiteboard-vinyl so that they can use whiteboard-markers on it, either on the wall or a table – works very well indeed. A lot less expensive than it used to be, too – definitely worth it for a framework that’s going to be used a lot in workshops and the like.
Glad I checked in… Had a conversation recently with an IT Leader who gets it and we concluded that the most important role of an Architect EA, Business etc… is to change the way people think about ends and the ways in which we get there. This doesn’t require software. Once again great post!
@Adam – many thanks for that. 🙂
“This doesn’t require software.” – yes, agreed, though good software-based EA-tools may well be useful. The practical problem is that too many of the present software-tools are more likely to hinder rather than help in the real task of “to change the way people think about ends and the ways in which we get there”… the ones that often do work the best for that specific task are plain old pen and paper. Where the software tools come into their own is in the background support for that task – but it’s essential that we we don’t let the tool take priority over the task itself.
Man! You hit the nail on the head! When thinking of all of the tools I have used over the decades, I can feel myself going comatose. None of them rise to building-architecture’s tools’ capabilities; much less, finesse. But here is the rub, I think. When what we are assembling as reality through EA analysis processes (tools or paper or …) gets implemented, it is operational in a 3-dimensional workflow environment, yet was captured as 2-dimensional. The foundation for the DoDAF/MODAF frameworks is Four Dimensionalism. It takes multiple diagrams being interwoven to describe one aspect of one thing. Perhaps we need some sort of a fly-through of the 3D which we have described in 2D?? This is not even considering what 4D means. Can we use our EA skills to create a useful, sufficient EA tool?? How about this question: Given that two or more successful, pertinent system implementations exist as qualified and quantified, what were the generalized, repeatable processes and information, in patterns, which, after being performed, resulted in these systems?
@Myron – re “going comatose” – yeah, I know the feeling all too well…
My very strong opinion is that most of the so-called ‘EA-tools’ we have at present are at best only slightly better than useless for the actual tasks we face, and in some cases actually worse than useless, both by costing far more in effort to maintain than they ever give back in terms of (re)usable information, and also by being actively misleading in terms of scope and modelling-constraints.
With regard to the real 4+ dimensionality of the issues that we face, the only method that one very-high-price toolset offers to manage change is that ‘current state’ and ‘future’ must be modelled as two separate databases – with no possible means to link between them. And almost all of the toolsets are almost uselessly IT-centric: some are barely more than jumped-up UML tools for software-design, and almost all of them use the absurd TOGAF/Archimate-style pseudo-layering where anything not-IT – anything to do with people, machines or even non-IT electronics – is (if acknowledged at all) all jumbled together in the random grab-bag labelled ‘business-architecture’. The only tools that do handle inter-item linkage and dynamics correctly are modified CMDB tools, which are not really suited to handling the blurry uncertainties of ‘what-if’ ideation and design. In short, the EA-toolset space at present is a sad mess…
But if it’s a mess, then it’s definitely ripe for disruption. The actual underlying needs are relatively simple to describe: the core of it is just two very simple entity-types at the metametamodel or metametametamodel layer, interlinked and arranged such as to support a dynamic n-dimensional holograph with a potential infinity of required views. (Which may sound a lot, but it’s actually a lot simpler than the arbitrary constraints that the current tools place on the toolset-space.) Navigation and search will be real challenges – particularly in terms of finding the right interface-metaphor – but once past that barrier, the whole space is wide open. And as I’ve said several times here, the first toolset-vendor who actually ‘gets it’ will wipe the floor clean of pretty much all of the current ‘providers’. I just wish someone would take up the challenge, that’s all… :sigh:
HiYa Tom.
As you know – I’m a tool content NUT and support many of your points.
HOWEVER
To my way of thinking, the value of any tool is in the acceptance by multiple stakeholders of its content as a way of supporting decision making ONGOING (yes I am shouting).
You’ve listed a similar point with “..social process by which…”. i.e. If your client / org is small or the issue is small and one off / short term – charts, sticky notes etc on a wall or window are fine. If however content has come from a broad social group, electronic records for discussion, overlays and amendments are required almost to the extent of a General Ledger accounts and transaction list.
When companies start considering the content of which ever ‘tool’ they use as an asset (a knowledge management asset in this instance) – they can begin to move beyond content as just “a bunch of diagrams” and focus on the ‘why’ and ‘what if’ through overlays.
For companies that don’t or won’t think in KM terms – papers, tools will come and go….
@Peter – shouting happily acknowledged – I fear we are in violent agreement here? 🙂
Yes, exactly: all of this is a KM concern – a dynamic KM, to support ‘why’ and ‘what-if’. And, yes, far too few of the current tools give anything resembling proper support for the ongoing nature of what’s required.
Where tools should come into the picture is to take over from the whiteboard etc. In particular, we need proper support to transition from rough-sketch to detail-design and back again; and real-world models typically hundreds or thousands or even millions of often-dynamic inter-item links – which ain’t exactly practical to portray on a whiteboard… But the current tools do barely any of this: all they can do is ‘pretty pictures’, sometimes with a variously-useful repository behind it to keep track of some of the interlinks. Bah. 🙁
Surely we can do better than this? Surely someone has the wit to bring us something that actually works? :sigh: again…
Hi, This is a very interesting conversation. I am currently working on finding “the perfect EA tool” for my organization. Would like to know your thoughts and opinion on the progress made by EA solution providers since 2012 and also thoughts about open source tools like Archi or Essential projects ? Thanks in advance