What do we need from our EA tools?

What do we actually need our enterprise-architecture tools to do? What are the ‘jobs to be done’ with which we need their help? And if our existing tools aren’t delivering that help, what can we do about it?

[Update: While writing this, Phil Beauvoir put out a brilliant post that addresses some of the same concerns – see the update at the end of this post.]

I’ve come back to this question because tomorrow I’m going to a mini-conference by a vendor of one of the larger and better-known EA toolsets. (I’ll be there solely as a participant this time, not as a presenter.) Their toolset is seriously expensive – a minimum of several thousand of dollars per seat – and in part I want to see if there’s much that’s been added there recently that truly justifies that kind of expense. But even more I just want to see if any of the vendors has started to understand what we as enterprise-architects actually need in order to do our jobs – or whether, as has been the case for too long, these ‘tools’ are almost more of hindrance than a help, for most of what we really do.

Or, to be blunt, surely we can do better than this?

The more astute observer might recognise the above diagram as an output from Phil Beauvoir‘s Archi toolset. Yet this isn’t a critique of Phil’s work – far the opposite, in fact. Horribly-constrained though Archimate might be, at least it’s something towards the messy everything-connects-with-everything-else-ness that we work with every day: and not only is Phil’s Archi one of the best implementations of the Archimate notation (in my opinion, anyway), it adds key features such as the ‘magic connector’ and its ‘canvas editor’ that at last go some way to supporting the real workflows that we have in our work.

Archi is not only one of the best EA toolsets, it’s also one of the cheapest. (Yes, it’s nominally ‘free’, but Open Source still incurs very real costs for the developer – donate!) One of the next-best is Sparx EA, which is a commercial toolset, but still way down in the low-end of cost – low-hundreds of dollars, not high-thousands – and very capable, for diagram-development at least. To be blunt, at present there seems almost to be an unwritten rule that the higher the cost of the toolset, the further detached from an EA’s real work it becomes, and the less usable it becomes, until we end up with hundred-thousand-dollar-and-up monstrosities so unwieldy and so user-hostile that they can only be worked at all by specialist staff – forcing us a long, long way, at absurd expense, from the much-needed ideal that enterprise-architecture is the real responsibility of everyone in the enterprise.

So let’s get back to some basics here, to see if we can get some way towards something that might actually work…


Let’s make some assertions here, to set the core requirements and expectations.

First, let’s say that all of enterprise-architecture is about providing support for a single qualitative aim and idea: things work better when they work together, on purpose. Which, in turn, we could summarise in a single word: the effectiveness of the overall shared-enterprise. There are a fair few important riders to that, of course – for example, it also needs to take into account a whole swathe of other effectiveness-factors such as efficiency, reliability, human-factors, environment, security, safety and more – but it’s probably a good enough start, and one that I’d hope just about every enterprise-architect would be able to agree with.

Second, the scope is always ‘the everything’. That assertion might be a bit more problematic at first for some folks: but if we think about it, it’s clear that even if we’re working only on architectures for IT-infrastructures, for example, there’s a lot more than just IT-infrastructure that we’d need to take into account. Whatever scope we think we’re working with, we choose the nominal boundaries of that scope: but reality is that everything is ultimately connected to everything else, whether we like it or not – and Reality Department may have very different ideas than ours about what the real scope might be for any architecture-project. We forget that fact at our peril…

Third, and perhaps most important: architecture-development is always ‘messy’. If we pretend that it isn’t – and, bluntly, most of those existing EA-toolsets seem to pretend that it isn’t – than we’ll really find ourselves in a mess. Which, in turn, means that we need toolsets that help us in working with the ‘messiness’, rather than pretending (or hoping?) that it doesn’t exist.

(Most of the toolsets are good – occasionally even excellent – at doing final-models and final-diagrams: but by the time we’ve reached that stage, the most important and most difficult part of the work is already long since over and done. Just what use is it to spend vast amounts of money on tools that do only the easy bit of architecture – and, too often, make it harder to do the hard part – whilst spending near nothing at all on tools that would help us with the hard part? It doesn’t make sense, does it? – but that’s the ridiculous situation we’re in right now with most of those toolsets…)

The ‘messiness’ comes from dealing with people and their necessarily-changing needs, and with the inherent-uncertainties of the future. Anyone who asks for ‘proof’ of the certainty of a future outcome, is frankly, deluding themselves: and that kind of pseudo-certainty has no place in architecture, even though that’s what those tools really seem most designed to support. Instead, what we need most is ways of dealing with the development-sequence from scrappy first-ideas and wild changes of direction and learning-experiments and all of the rest – and all the back-and-forth that takes place in all those endless explorations with all of those different stakeholders with all of their different expectations and terminologies and fears and ego-driven delusions and the rest. And then link all of that to the pretty-looking final-models that we hand of over to solution-architects and the like. Oh, and link with the CMDB. And the current-strategy. And all the laws and regulations. Andandand… – because everything connects with everything else, remember?

Yeah, something to help with that, please?


Let’s look at this from a start-up type of perspective, a customer-orientation, and ask the customer – in other words, us – what are our jobs-to-be-done, the real-world tasks and needs with which we’d need a toolset to provide us with the right (i.e. genuinely-useful) support.

Here are some examples I’m working on right now – all of which I would describe as being about that key theme of ‘things work better when they work together, on purpose’:

Build a knowledge-base out of my own work: On this blog, in my books, and in other items such as my bookmark-lists, my downloads-lists, and the stream of tweets captured and stored at present in monthly Word files, I have a vast amount of material on enterprise-architecture and related topics. At present I have no way to crosslink all of this together, to show what connects with what, what references what, what extends what, or to build trails that guide someone else through, say, the early stages of learning EA, or naming-standards, or management-models, or the relationships between SCAN and other frames for context-space mapping. I need a tool to help me do all of that, with a user-interface that not only makes search and navigation simple, but enables me and others to create user-defined ‘trails’ that are knowledge-objects in their own right. And I’m well aware that a lot of people are craving for a tool of this kind – even though they may not know it yet.

Show how to work with ‘meta-‘ objects: In particular, show the relationships between metamodels and models, metaframeworks and frameworks, metamethods and methods; and also the distinction between meta (instantiated at the same level of abstraction, as a specialisation) and class (instantiated at the next level of abstraction, as a concrete-instance).

Show how to extend CRUD (create/read/update/delete) to other asset-types, and support those requirements and distinctions within the toolsets, so as to illustrate the implications of substitutability between IT-based and non-IT-based capabilities in disaster-recovery, skills-escalation and suchlike.

Link across the whole of a business-architecture: Not solely the IT-specific parts, or ‘anything not-IT that might affect IT’ – which is just about all that Archimate or any of the existing toolsets will allow us – but a smooth, consistent integration between, for example, trust-maps to culture-maps to value-maps to empathy-map to value-propositions to business-models to customer-journey maps to customer-support design to service-design to data-models to finance-architectures to product-architectures to brand-architectures to… – well, you get the picture. Enitities and relationships viewed and cross-referenced within and from multiple notations, multiple ‘canvas’-types and multiple schemas, all handled in a consistent way, and all interlinkable, whilst still retaining their integrity within any one single notation or schema.

Model when we don’t yet know what it is that we’re modelling: In other words, we need full support for ‘thing’ – an indeterminate-entity – and fully-modal ‘association’ – a ‘maybe is-a’ or ‘sometimes is-a’ or ‘sometimes is-not-a’ or, so often, an ‘it depends’. Although Archi is one of the best so far, I don’t know of any EA-toolset that comes anywhere close to giving us what we really need for this: instead, we’re forced back to general drawing-tools such as Visio or Powerpoint, that have no means to support any kind of cross-reference or model-integrity – causing an inter-toolset mess of incompatibilities that is not helpful at all.

Describe system-loops and other whole-of-context systemic-structures, to surface and highlight thinking-gaps and unquestioned-assumptions: One of the key problems here is that it’s often ‘politically-incorrect’ to identify such flaws, because a lot of people’s supposed status and more depends on those errors not being noticed – no matter how damaging and destructive they really are. Three examples I’m working on right now are Taylorist myths of managerialism, the current stream of decidedly-sexist ‘gender-equality‘ initiatives, and, of course, the seemingly-inevitable IT-centrism of so much of EA – all of which are guaranteed only to make things worse for everyone in the respective context. We urgently need tools to help us make sense of all of these, and so many other systemic problems like them – but they need to be tools that don’t automatically get us thrown into the wrong end of a ‘shoot-the-messenger’ syndrome…

Describe the full range of dimensions applicable to assets and more: In part this relates to my business-name ‘Tetradian’, as a literal ‘four dimensions’ – physical, virtual, relational, aspirational – and the various ways in which we have to handle each of those dimensions in their expression in assets, functions, locations, capabilities, events and the rest of the elements of an architecture. But at present I’m also exploring ideas relating to analogies with the physics ‘four forces’ – weak-nuclear, strong-nuclear, electromagnetic, gravitational – and also concepts such as mutability, across the electromagnetic space, and between mass and energy, and how such analogies and metaphors might play out in an architecture-type context. Kinda abstract, yes, I know: but it feels like it might lead to somewhere useful, and I need a tool to support that kind of conceptual-level exploration – at the same time as handling the mappings to more-concrete ideas about assets and so on, as in Archimate and the like.

Describe the sensemaking/decision-making/action loop, in context of an architecture and its various elements: This would provide crosslinks between Archimate and suchlike on one side, and tools such as OODA, SCAN and PDCA on the other. Again, all of these need to support us in the sheer messiness of any exploration of that type.

Support storytelling in any required form: This might include visuals such as a DoDAF OV-1 overview-diagram, or Ondrej Gálik’s change-story described in the previous post on EA-roadmapping; or a broader approach, such as described in the series of posts here on narrative-oriented enterprise-architecture.

Support a more sensory approach to describing an architecture: Not everyone is oriented solely to visual or verbal descriptions – some people understand things much better through more tactile or tangible forms. One of the best IT-architecture descriptions I’ve ever seen was by the CIO of a government-department: a keen amateur-woodworker, she built a model of the layered architecture as a multi-layered jigsaw-puzzle, with the security-layer, for example, as a literal layer that could be removed from the top of the frame. Or, to give a couple of other examples, how might someone dance a business-model, or describe a customer-journey in song, as a duet from inside-out and outside-in? I’m quite serious when I say that, if we want to cover the full range of communication we might need, the toolsets may well need some way to support all of those as well.

Plenty more examples I could throw in: those were just those that I happen to be working on at the moment, as a maker of tools and techniques for real, everyday enterprise-architecture. Quite a lot broader than just doing fancy diagrams in a jumped-up software-modelling tool, I think?

Implications for implementation

One thing is certain in all of this: there needs to be a common interchange-format for everything – all of the different notation-types, scratchy-drawings, videos, text-items, whatever. (The internet concept of MIME-type or Internet media-type gives some guidance on how this could be done.) Whatever file-type we end up with, it must be open, non-proprietary and fully public-domain: the only permissible role for a patent would be similar to that which Philips used for the tape-cassette and CD (compact-disc) specifications, to protect it from deviation or privatisation. (There’s plenty of space for commercial value in user-experience, navigation and search, and in extra capabilities such as simulation – just not in privatisation of what needs to be a truly shared base file-format.)

It needs to support that full range of content, from sketch-drawings to standard-notations to graphic-recording to OV-1 type overview diagrams to CMDBs, all within the same framework. (One way to do this would be to ensure that formats and notations are themselves implementable via the same base file-format – there’s a suggestion for how this might be possible in the posts ‘More detail on EA metamodel‘ and ‘EA metamodel – a possible structure‘, from about three years back.)

Whichever way we implement it, it needs to available in some form or other, in a consistent way, across the entirety of the toolset-ecosystem, from ‘war-room’-type multiscreen all the way down to dumb-phone.

And all of this needs to help us in dealing with ‘messiness’ – such as via a ‘rewind’ mechanism, which I need to describe somewhen in a separate post. There’s also the point that, in the end, models and diagrams are really no more than ‘decision-records‘, almost a kind of talisman to hold the shared-memory of what was agreed on, what was decided: the hard part is in all of the work that leads up to that point – and it’s in that, rather than just the diagrams, that we most need help from our toolsets.

Overall, there’s that one theme, one idea, that we most need as a guide here: that enterprise-architecture is really about ‘things work better when they work together, on purpose‘. Anything that our toolsets can help us with this – rather than hinder us, as so much at present – would, I’d hope, be a step in the right direction.

As usual, any comments, anyone?

[Update: Just before I pressed the ‘Publish’ button, I saw a Tweet from Phil Beauvoir about a new post:

  • ArchimateTool: Senseless Figures in Front of a Mirror http://t.co/pwKr8ZVDFk  @tetradian will understand. #entarch

Although it’s in Phil’s somewhat-cryptic DadaBeatnik style, yes, I do indeed understand his point there: the emptiness and pointlessness of so much of what’s (not) happening at present in the EA-toolset space – or EA in general, for matter. As I said above, Phil is certainly of the relatively-few toolset-makers who really understand what we need: he’s just released Archi 3.0, which I’m definitely looking forward to playing with. But it’s the upcoming discussions around the future Archi version 4, and its all-new repository-model, that I really want to be involved with – because with Phil at the helm, we might at last have an EA-toolset that’s genuinely worthy of the name. Watch That Space, perhaps?]


14 Comments on “What do we need from our EA tools?

  1. My current favourite EA tool is ABACUS, because it is very easy to create ones very own meta model, including for SCAN. I have already created a meta model for supporting Tom’s great ideas and many others.
    Anyone who is interested, just drop me an email.

    • Many thanks for that, Adrian – and yes, I do need to get in touch with you again re what you’ve done with SCAN, ECanvas and so on, on Abacus and in general.

      Beyond that, though, the point for this blog-post here is almost less about individual tools, as a better grasp of the entire toolset-ecosystem, and – since no one tool is going to be able to do everything – how we get them to all play nicely together. More on that in another post, I think?

  2. Hi Tom,

    Compared to other project and design oriented professions EA is young.

    I keep returning to experiences I have had of working in the building and film industry. Because, a) they make things that have a high degree of novelty – usually no two outputs are the same, and b) they have pretty much solved the problem of separating management (resource allocation and control) from design and implementation (what to make and how).

    My years in EA have convinced me that confusion and befuddlement over the boundaries between management and design thinking are a root-cause of much waste in daily practice.

    The value of Archimate does not proceed from the efficacy of its meta-model. (Though there is a minimum-utility threshold that it stays well above). Rather, Archimate allows the product of EA to be reified. And that goes a long long way to articulating the design problems independently of the management issues.

    Such shortcomings as Archimate has, stem from it’s lineage in software engineering, and its adoption of functional models of organisations – which for example preclude elegant abstractions of things like black-box services, appliances, and consortia.

    The idea of Archimate itself however is brilliant. And I hope it gains increasing traction in EA practices everywhere.

  3. I know it can be perceived as being expensive, but Mega can either do most of these things and provides a sufficiently open, tailorable platform to support any meta model enhancements, diagram specification, report specification, GUI configuration changes.

    However, it does not yet directly support performance art or 3D printing although it can link sound files, documents and film of people doing these things to any object.

    The flip side of this flexibility is that it requires expertise – tool specific and generic modelling – and effort in order to get the value from the difficult stuff … it is not just point and click, which makes it difficult for most EA powerpoint jockeys. But as a box of Lego, it can be very powerful in the right hands.

    I would dispute the dream of getting one, common architectural language i.e. Archimate (my pet hate so I need to be careful). I think it is an unrealistic aspiration, after all, there is a reason humanity has, and always has had, multiple languages … people will always find unique ways of expressing their precise world views, which can never be the same. Look at the success of Esperanto and the multitude of common standards that were aimed to end all standards.

    This after all is the true heart of EA – supporting and embracing multiple views of reality.

    • Thanks, David. As I said above to Adrian, I do believe, and strongly, that this is not so much about the perceived-value of one tool over another, but much more about how we tackle the needs of the entire toolset ecosystem for EA. To take your example of Mega, can we access information from all the way down to a dumb-phone, and all the way up to a ‘war-room’ setup? Even more to the point, does it ‘play well’ with other toolsets – including those that wouldn’t generally be considered as ‘EA’ tools at all? If it doesn’t – and I doubt very strongly that it would cover more than a quite small subset – then that’s not the fault of the toolset as such, for the simple reason that no toolset would be able to cover everything. That’s why we need to talk about a toolset-ecosystem here, rather than individual tools.

      @David: “I would dispute the dream of getting one, common architectural language”

      Very strong agree – and that’s the point here. Instead, we need to go at least a couple of steps deeper, with compatibility and/or interconnectivity enabled significantly deeper than any single ‘architectural language’ or suchlike.

      @David: “This after all is the true heart of EA – supporting and embracing multiple views of reality.”

      Yep, exactly: yet they also need to be interrelatable ‘multiple views of reality’ – otherwise there’s no integrity or sense to the architecture, or arguably no architecture at all. Which is the kind of mess we suffer too often at present…

  4. Thanks for this post, Tom.

    You say, “to be blunt, surely we can do better than this?”

    I absolutely agree! And I feel somewhat guilty about Archi – that it’s still only really a “boxes and lines” tool. Given that there’s really only been one main developer over the few years of its life-span I suppose I can make an excuse for that. 🙂 I would love to take it much further…but you know, money and all that.

    I actually regard Archi as a “proof of concept” tool. Proof that you don’t need a horde of developers in order to create software that is used by thousands of people globally. Proof that you can make a cross-platform, open source, tool that “just works”. Proof that simplicity trumps complexity. Proof that you don’t have to be employed by a dinosaur company to have an impact in the EA toolset world. And the biggest thing for me, proof that you don’t have to subscribe to corporate BS – but that’s because I don’t take the corporate coin 😉

    Having said that, a little investment would go a long way. You know, Archi is built upon the Eclipse framework, and it’s possible to connect ArchiMate, BPMN, BMC et al. to a wider more inclusive ecosystem that could embrace the “higher” way of thinking that you describe. The important thing is to start with the essential underpinning principles – for me these are beautifully described in Fried and Hansson’s book “Rework”.

    The idea I had with Archi, but never really fulfilled, was to provide an open sketching/capture/brainstorm type functionality; perhaps “boxes and lines”, or perhaps some other paradigm. After a “capture” stage would come an “organise” stage and a “make sense” stage, looping round and round, iteratively. If this process ultimately resulted in an ArchiMate model, or a Business Model Canvas, or something else would depend on how the user interacted with the tool and how the tool offered certain opportunities for developing one’s ideas individually and with others (and I’m thinking of on-line sharing as well).

    That idea is still pre-nascent in Archi.

    Tom, I love your synaesthetic idea of dancing a business-model! A sublime oblique strategy. Perhaps we ought to invite Brian Eno to the EA world (he is a keen cybernetician).

    I don’t think I would be able to fulfil all of the ideas outlined in this post, Tom. But yes, EA and the associated toolsets need to embrace the bigger picture – indeed, “everything is ultimately connected to everything else”. Tinkering with your Application Portfolio Management system while your company delivers a shit front-facing service is just “senseless figures in front of a mirror”.


    • @Phil: “And I feel somewhat guilty about Archi – that it’s still only really a “boxes and lines” tool.”

      Oi!! – back off a bit on the self-deprecation!!! 🙂 For what it does, and given the real circumstances under which it was an is created, Archi is brilliant – no other word for it. And as I’ve said a couple of times already above, this isn’t about individual tools – it’s about the toolset-ecosystem as a whole.

      The big difference with Archi is that it goes a long way further than most tools in dealing with the ‘messiness’ part – the ‘canvas’-creator, the ‘sketch-development’ aspect, the magic-connector and more. Compare that with a certain infamous toolset (not mentioned by anyone above) that is only usable for final-models, and for building reports on final-models – more like a cross between a badly-designed software-documentation tool and a badly-designed CMDB, with almost no grasp of change-over-time, an abysmally-clunky approach to metamodel management, and a huge, huge price-tag. On every one of those counts, Archi is much, much better; to be blunt, the only things that the ‘big tool’ does better is that it handles (if usually not well at all) a wider range of models-types, and it has a relatively-robust multi-user repository. So please, don’t knock yourself, you’ve done a brilliant job on this, especially given the constraints you’ve had to deal with.

      One of those constraints was/is the initial requirement to align with Archimate – which, with its rigid yet utterly half-assed ‘BDAT-stack’, all but forces you into an IT-centric ‘EA’, whether you intend it or not. (The latter, in your case, as I know.) For any EA tool to be worthy of the ‘EA’ name, it must be able to break free of that inane constraint. Which, for Archi, would actually be quite simple: have the Archimate ‘standard’ as an option that sits on top of a better-designed, wholly-open repository-metamodel – rather than Archimate as an arbitrarily-constrained base-metamodel to which everything else is forced to conform. To be utterly blunt, stuff Open Group and OMG et al on this: they’ve messed up enterprise-architecture for too damn long, and as an industry we really do need to put them back in their place, as each of them merely one sometimes-useful standards-body in an industry that is necessarily a lot larger than they are…

      Same applies to OG’s would-be interchange-standard for ‘architecture information’: they’ve been dithering on it for years – last I heard stalled into a do-nothing since at least 2006 – and unless something significant has happened on it in the past year or so, we’d best presume that it’s still dead-in-the-water. Not wise holding our breath for it, anyway – especially since many of OG’s membership would have significant vested-interest in it not happening. Even if OG or someone else do finally get their act together on this, it’ll still miss the point: EA is a lot broader than their still inanely-IT-centric view of the ‘trade’, so all they’d do is foist onto us yet another IT-centric mess that assume that everything in the entire context-space begins and ends with computer-based IT, and blocks out the view of everything else – once again trapping us into something that’s actually worse than useless. EA is much, much larger than IT: and unless that fact is built right into the roots of any interchange-format, or description-standard – which as sure as heck it isn’t in just about anything we have right now in ‘EA’ or BPM or anything else – then, again, it’d be more of a hindrance than a help. Grump grump harrumph bah…

      And in any case, would that interchange-standard help us deal with ‘messiness’ – or would it be usable only for ‘final’-models? If the latter, it’s not much use to us. To solution-architects, yes, very probably: they need nominally-final models. But for those of us dealing with the ‘mess’ – to me, the real core of EA – final-models come at the very end of our work. To work with the rest of our work – the really hard part of our work – we need tools and interchange-formats that support a very different way of working, a very type of process and outcome. That’s what’s still missing here; and much understanding of that point is painfully still-missing in too much of ‘the trade’, too. Sigh…

      @Phil: “That idea is still pre-nascent in Archi.”

      Quite a bit further on that that, I’d suspect – quite a lot more than you might have noticed, perhaps, though it’s quite evident, to me at least, in your published thinking and in the topics you Tweet on, for example. So perhaps meet up somewhen soon to talk on this, and to make sure that these ‘pre-nascent’ ideas do not become stillborn? 😐

      @Phil: “I don’t think I would be able to fulfil all of the ideas outlined in this post, Tom.”

      Maybe not, but I’m darn sure that you could get a heck of a long way towards it, simply because your thinking is already in the right place. There are a few other key ideas about the ‘messiness’ UI would work that I know I could help you with, and there are some real challenges around the deep working of the repository, and UIs for navigation and search, that we’d need help on from others: but other than that, the core of it is already there in Archi. Yeah, okay, I could sort-of do it myself, eventually: but what I could do, badly, in a year, you could do really well in a week – and we both know that.

      @Phil: “Having said that, a little investment would go a long way.”

      Painfully aware of that: I’m in much the same boat, much of the time, as you know. Still, there may be ways round some of that: discuss, perhaps? Over to you, anyway.

    • Maybe not HTML itself (too format-oriented), but a combination of ideas from HTTP, MIME, MOF, semantic-web, modal-logic ORM and a few other things – taken down a couple of notches in the repository/interchange, and up a couple of notches for model-types – might well do it. Something to discuss, perhaps? (and discuss a fair bit broader than just the two of us, too, of course)

    • David: yes, sure. Ideas from all of those. In somewhat different combinations, and with a few importantly-different twists – mainly around working with ‘messiness’, rather than pretending it doesn’t exist.

      More to follow in other posts, I think.

  5. Algebra (from Arabic al-jebr meaning “reunion of broken parts”.
    Common language need
    Discipline from an organisation to ensure ongoing utilisation of the information, management and knowledge is the key here. In 1988 I saw my first enterprise architecture. Binders of shelf ware. All agreed – signed off and then dust collectors.
    Tools aside – they key here is to get an organisation to modify it processes to keep the knowledge current and utilised by attaching it to critical processes and to have exec and jnr staff respect the fact that ONGOING accounting is occurring.
    Accounting for the lifeblood of the people – information, knowledge and wisdom.

Leave a Reply

Your email address will not be published. Required fields are marked *