9 Comments on “The toolset-ecosystem

  1. I don’t see a problem in using different tools for different views/stakeholders. Most important is having a good story with well designed visuals. How they are created is irrelevant, important is the impact they make. Diagrams never make much of an impact, better is to look at the stuff XPLANE (www.xplane.com) or JAM (http://www.jam-site.nl/) are doing, or look at the visualizations done with the business model canvas e.g. at http://businessmodelsinc.wordpress.com/2009/08/11/sellaband-business-model-visualized/.

    Tools are just tools, stories change the world… (where are the good enterprise architecture stories?)

  2. My first response to that set of requirements was “Whew…bit of a tall order.” Then I started thinking about whether part of the problem is that the tools listed above are desktop-based (or desktop-bound) applications rather than web-based. Are we not sharing? And by not sharing perhaps we haven’t found a common, unified language or discourse.

    The main points that I’ve taken away from this post are:

    – Separation of concerns.
    – A unified Metamodel
    – Interchange standards

    And, of course, getting enough people together to work on this proposal.

    A very modest (and nowhere near what you propose 🙂 ) feature I’m working on in Archi (ArchiMate tool) is the “Sketch View”. It’s simply a drawing canvas for Stickies (Post-Its) and 3 types of line. The entities are simply “the blue sticky with text”, or “the green sticky with text”, “the plain line”, or “the dotted line”. It’s the stuff we do on flip-boards every day, with no meaning attached to an entity other than that which you give it via the text therein (or image, perhaps). This is useful for brainstorming and quickly capturing ideas or the essence of a process or model.

    So what? Well, now I want to implement a mechanism so the user can ascribe given attributes to those entities that can result in, or generate, a more formal (ArchiMate) model or View. Of course, the key is in the attributes, and they come from the meta-model (ArchiMate in this case); but with a different set of attributes perhaps we can end up with a different type of model or viewpoint? Perhaps we can specify things like “target audience”, “concern”, “layer”, “interaction”, and so on. Perhaps these attributes can be defined, applied and un-applied – think about layers of attributes that can be shown and hidden like layers in Photoshop, for example. What would that look like? Perhaps, too, we could go the other way and generate “Manager friendly” representations from the constrained ArchiMate model.

    Disclaimer for my naiveté – I’m not an EA expert, I make software tools, this is just my very modest 2 cents…but even in my world we have the Eclipse Modelling Framework (EMF) that we use in Archi. The EMF defines a (meta-)meta-model from which we can generate a number of artifacts – UML, Java code, XML Schema, Annotations, Editors, and so on. The UML is useful for discussion, the Java code for application generation, the Schema for validation and binding. But at the core is the “eCore” metamodel.

    So, in my own small way, I’m all for this.

  3. Peter – thanks very much for the pointers to XPLANE, JAM etc – will gladly follow those up.

    And that “where are the good enterprise architecture stories?” one-liner of yours is simply brilliant 🙂 – have happily reTweeted that (with credit to you, of course).

    On “I don’t see a problem in using different tools for different views/stakeholders. Most important is having a good story with well designed visuals.”, strongly agree with you about the importance of the story – see e.g. the posts ‘The enterprise is the story’ or ‘If the enterprise is a story, what is its backstory?’. And it’s true that if we’re only concerned with story-as-story, interchange between tools probably doesn’t matter. But if we’re intending to use any kind of repository with managed entities – as most EA tools do need, not for the ‘story’ phase but for subsequent design and development – then we do need concern ourselves with information-transfer and all the rest. The story is crucially important: yet it’s merely one application for an EA-type toolset, and there are many others: I’d aimed to cover as much of that scope as practicable here, rather than solely the part that deals with story-as-story.

  4. Phil – much to discuss, though there’s probably nothing like enough room to do so here… 🙁

    Just one point I’ll pick up on: “Perhaps, too, we could go the other way and generate “Manager friendly” representations from the constrained ArchiMate model.” I would guess that the simplest way to do this in Archi would be to allow people to attach one of more graphics (JPG, PNG etc) to an instance, together with a matching ‘visible’ boolean. You then build a custom diagram (which Archimate allows – it’s not UML in which only specific items can appear in specific diagrams), and switch the visibility of the graphics on or off as required. That means that end up with a fully-managed entity whose representation can be anything you like. The Archimate representation (of which there are at least two for most entities, as I remember?) is simply the default in each case.

    Again, would be good to discuss this offline – preferably in-person after I come back to Britain in late Feb?

  5. Tom,

    I would like to add simulation-oriented tools like those based on Petri Nets (e.g. CPN Tools), System Dynamics (e.g. Vensim) or Agent-Based Modeling (e.g. NetLogo). These kind of tools are a must if you are trying to understand complex systems like enterprises…

    I agree that a good toolset is critical, but I think it is best to keep tools loosely coupled. So that each tool will help you seeing your system under design in a different perspective and scale. A kind of “toolstorming” (like brainstorming)….
    People who saw “Sketches of Frank Gehry” will probably understand what I mean.

    BTW: “When a thing has been said and well said, have no scruple; take it and copy it” (Anatole France)

  6. Peter

    Thanks again – will admit I know of these tools, but haven’t used any of them as such.

    The main point I was trying to get over, I think, was the idea of an ‘ecosystem’ of tools, platforms and user-interfaces, each optimised for the respective purpose, yet all able to exchange information with each other, in much the same way that resources are shared out and used in different ways across a biological ecosystem. In that sense, it’s not so much what each tool is capable of, and what tools each platform should support, but more about how the tools/platforms communicate with each other and enrich the ecosystem as a whole.

    As you say, the key there is to keep the tools loosely-coupled, yet with an underlying commonality that enables them to ‘talk’ with each other. It’s there that the metametametamodel comes in – providing the commonality – rather than a more surface-layer metamodel (an individual model-type) or metametamodel (a class of model-types, such as your Petri Nets etc).

    I haven’t yet seen “Sketches of Frank Gehry” – sounds like I need to. 🙂

  7. Tom,

    Maybe I’m wrong, but your comparison of the ecosystem tools with the sharing of resources across a biological system made me think of how our nervous system is working. The neurons are the underlying commonality of the nervous system.
    But I have a hard time seeing how the tools would fit in the nervous system as metaphor. Maybe the tools are a bit like our senses (our senses also filter out information before it is transported to our brain, just like the tools do).

    I think I’m just rambling a bit here, too much reading of brain-related books lately 🙂

  8. The analogy with biological systems would not solely align with the nervous system. Perhaps a closer cross-map would be with the whole of the information-systems (plural), including the nervous system, the limbic system, adrenal system, other hormone-based ‘information-systems’, chemical-feedback loops (in the stomach etc), mechanical-feedback loops (muscles etc) and so on.

    A nice antidote to “too much reading of brain-related books” would be to remember that other cultures place intelligence very much elsewhere in the body. The ancient Greeks, for example, placed the intelligence in the heart: and it’s interesting to note that apparently there’s more heart-tissue in the brain than there is brain-tissue in the heart.

    Quite how all of this fits with enterprise-architecture I’m not sure, but I’m certain someone could invent a suitable excuse! 🙂

  9. I am interested in the brain because that is the place where our models of the world are formed, stored and altered (in real-time or during sleep). You are right that intelligence is more of a whole-body emerging thing. Although I think that the quality of the models in your brain do influence your level of intelligence just as I think that better architectural models will improve the “intelligence” of architecture. This is also my link with “Sketches of Frank Gehry” where he shows us how using better models lead to “better” architecture (realizing shapes not possible before within time and within budget”.

    Off-topic: Nice test to see how intelligent a robot is: throw it in the water and look if it is trying to survive 🙂

Leave a Reply

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