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…

Fundamentals

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. And… and… and… – because everything connects with everything else, remember?

Yeah, something to help with that, please?

Jobs-to-be-done

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?]