One of the most essential tasks in enterprise-architecture is that of enabling conversations on architectural issues, with any groups of stakeholders, anywhere across the enterprise.
Our toolsets play an important role in those conversations. The right tool used in the right way can really help the conversation, help create new shared understandings across the silos and the specifics of each distinct discipline.
But the wrong tool – or even the right tool used in the wrong way – may instead act as a real barrier against awareness and understanding. Getting the balance right is critical to creating the clarity we need – yet the requirements, and the balance, are different for every type of architecture-conversation.
We’ve long had a good range of frameworks and toolsets for IT-oriented architectures. Some were aimed more at systems-development; others more at taxonomy and ontology and metamodel-development; others again at modelling dependencies across IT systems and ‘business/IT-alignment’; and yet others at requirements-traceability, governance and project-management. Yet they all had one thing in common: their whole focus was about precision, about certainty – because that’s what system design and development really needs.
But as enterprise-architecture at last begins to break out of the IT-centric box that it’s been trapped in for the past couple of decades, we start to hit up against some real limitations of those toolsets:
- most of the underlying metamodels and model-types are still very IT-centric
- user-interfaces are usually complicated, abstract, often intolerant of error, and in some cases even downright ‘user-hostile’
- most of the tools – especially at the high-end – are too expensive for general use
- diagramming is usually abstract (‘boxes and lines’) rather than ‘real-world’ (trucks, people, machines, servers, cables etc)
- support for versioning and for tentative ‘what-if’ experiments ranges from poor to non-existent
- none of the user-interfaces are well-suited for use in real-time exploratory conversations
There’s also still no common exchange-language to transfer architecture-information between the tools that we already have – and even when we get one, we’ll need it to go wider than that, anyway. A lot wider.
When we look at how we actually work with executives or process-designers or security-architects or the like, the tools we most often use at present are a whiteboard or a sketchbook – nothing else has the flexibility that we need. None of the existing tools allow us to play ‘what-if?’ as well as we can on a whiteboard; and the precise formal rigour of model-validation is far more of a hindrance than a help in this kind of work, where half the time we don’t even know what kinds of architectural-entities are involved – the whole point is that that’s what we’re aiming to find out!
But we still need some kind of toolset-help here: images on whiteboards and sketchbooks aren’t easy to share – I’ve often seen people simply photograph the results and pass the image-files around as ‘the model’ – whilst office tools such as Visio and Powerpoint give a spurious illusion that the results have been captured with enough rigour to be re-usable (which they’re not), and are usually too slow and cumbersome for an across-the-table discussion anyway.
So here’s our challenge: develop a toolset for the ‘conversations’ end of the enterprise-architecture spectrum – one that will work on laptops and netbooks, on the new tablet and touchpad systems, and preferably right down to smartphones as well.
It needs to be able to cover any aspect of enterprise-architecture – from business-models to skills to security to process to disaster-recovery to operations to knowledge-management to applications to service-management to IT-infrastructure to building-infrastructure and anything in between.
It needs to be able to adapt itself to the needs and worldviews and language of each of those groups of stakeholders – and provide some means of translation between each group, too.
It needs to be fast, easy to use, engaging, enjoyable, preferably tactile too – yet have a fully-structured methodology and metamodel behind it.
It needs to allow freeform development of models and diagrams – yet still be capable of linking to the formal rigour of the ‘top end’ systems.
Coming the other way, it needs to help us explain the structures and reference-models that we already have in our ‘top-end’ systems – and explain the reasoning behind those models, too – whilst still keeping people actively engaged in the conversation.
And more and more, architects are beginning to recognise that spurious certainty is a real risk for the enterprise – so this also toolset needs to help our stakeholders become more comfortable with uncertainty and change.
- preliminary metamodels and file-structures
- probable user-interface workflows on tablet (mouse/stylus) and touchpad (finger) interfaces
- probable user-experience interactions in multi-stakeholder conversations
- some suggested methodologies
- some key features, such as AudioNote-style synchronised voice-recording and Prezi-style zooming ‘infinite’ workspace
- support for a broad user-extensible range of model-types – potentially-unlimited, including user-defined types
- support for indefinite nesting/layering of models and model-types
- support for freeform-drawing, notes, embedding of user-selected icons and images
- support for reports that enable us to describe some or all of the enterprise as a story
There’s a lot more to do to get this even to an alpha-release state in any format or platform; and whilst all of us, in the group so far, have ‘done our time’ in software-development and the like, none of us is sufficiently available (or, in my case at least, really up to the speed or quality needed) for professional-level app-development on current systems. So we’re going to need help to make this happen.
I for one would prefer to see this as an Open Source or at least freeware/shareware type of development, so as to get this out into as general a usage as possible. (As I see it, this kind of toolset should have many other applications outside of enterprise-architecture, such as in strategy-development, tactical planning etc.) But if some commercial developer wants to take it on, that would be fine too, as long as we can keep the final end-user cost down to app-levels (perhaps $10-30 at most) rather than the three-, four-, five- or even six-digit sums we sometimes see for other toolsets.
So: over to you. Any offers of help or advice? Any other comments or suggestions?