I aired my interest in IDEF0 as a diagramming language in May and August this year. First time in passing as one of the needs slowing my own writing progress, second time as a kind of “spec” for what I might expect from a community interested in systems thinking (the Active Inference group killing two birds with one stone?)
Nothing’s changed, and I’d kinda given up on better tools, resigned to simply “drafting” the diagrams in standard drawing tools. It’s an old language (late-70’s / early-80’s) in the earliest days of “CAD” and it was back in the mid-80’s I first discovered I was a fan. A drawing standard – symbology and layout conventions – for representing functional “systems”. What’s not to like? But I’ve found very few people who use or recognise its value in my 45 year career.
Today I found another present-day fan – Aaron Gillespie with his “AaronGillie” blog. Now even Powerpoint and Visio have pallettes of boxes and arrows with sticky connectors, so “drafting” has never been the problem if you understand the language and the system you’re representing. Indeed drafting is part of the thinking tools to improve the understanding and representation.
AaronGillie has a simple summary – and suggests one of its strengths is its simplicity, so advises against creating additional symbology and semantics. It’s a fair policy when it comes to standardisation but, in this case, I rarely see people actually using it in practice and indeed later standards (eg Archimate) claim greater power and interest. So I am keen to extend it for my own needs.
For purely practical drafting and sharing / communicating purposes one of the conventions is to limit system decompositions to 2 levels only, with the occasional 3rd level, and 3 to 5, max 6 modules per level. It’s about how much a human can get their head around in one diagram, one large “page”.
IC(C)OM – Inputs, Controls, (Calls), Outputs and Mechanisms – are really just different classes of Inputs and Outputs, in terms of what they do and in terms of how their state and/or identity change during the process(es). So, I’d prefer an I/O taxonomy that reflected that even more generically. Why? Because I want to represent “the whole word” in such a process model.
Which leads to my second problem. I can’t have any arbitrary limits to breadth and levels of decomposition. All taxonomy is binary at root – this / not-this – repeated as many times as we need. So, what I need to exploit are decomposition rules so that any level of abstraction / compression of any part of any such model can be presented or not by selection in the user interface. I want “one model” but I don’t ever want to see “the whole on one page” except at a one-page level of abstraction.
AaronGillie has a wonderful, manually drawn, worked example on his IDEF0 page – which is scarily (meta-)close to my whole project – (Maslovian) “Actualisation” of a human life. The aim of this human life is a process model of the whole world. I need both drafting tools and presentation tools (or one tool with edit and present modes, how hard can it be) that exploit the decomposition rules horizontally and vertically.
I’m more convinced than ever that the “IDEF0 Style” will do the job for me, even if I have to tweak the previously standardised conventions. Anyone who could programme through API’s to PowerPoint, Visio, Sparx-EA, MagicDraw, Modelio, Archi … more?
Another present-day fan here on LinkedIn says:
“There is much formalism in the IDEF0 spec, which is great as it can therefore be used in a formal way when needed. I tend to use it in a slightly looser way, keeping to the core principles but not worrying too much about the decomposition rules and process numbering”
That’s my essence too. I just want a tool that can implement more generic rules, rather than the standard set of conventions.