More detail on EA metamodel
Moving on to more detail on that EA metamodel.
(By the way, a quick thank-you to Nic Plum and Sally Bean for really helpful peer-reviews on this. 🙂 )
The legal bit: There’s a heck of a lot of unpaid work that’s gone into this, and also a lot of my own ‘prior art’ on these themes, dating back to at least September 2008, with more detailed specification dating from at least mid-2009. Although it’d be nice if someone actually paid me for some of the work that’s gone into this 😐 it really needs to be something that’s shared in the most open way possible, such as via open-source, so consider this for now to be published under a Creative Commons Attribution-NonCommercialShareAlike (CC BY-NC-SA) license. I don’t really want to see any restrictions on it at all, but unfortunately we do need some kind of protection here: it’s definitely not okay for some commercial organisation to lift it, put a couple of minor tweaks on it, pretend that the whole thing is and always has been their own private ‘intellectual property’, and then demand money from everyone else for the privilege – because we’ve seen way too much of that already, thankyouverymuch. Sigh…
What follows is deliberately broad and abstract. It’s missing quite a few implementation-details, in part because I’ve probably missed a few key items, but even more because some is still a bit hazy and needs proper review by folks who really know what they’re doing with implementable metamodels. As all too usual, it’s also long: my apologies… Oh well!
Core concepts
Right at the root of the metamodel is a single object, with just two attributes:
- globally-unique identifier
- ‘instantiable’ boolean (if true, is ‘type’; if false, is ‘instance’)
We also create a special-purpose variant of this:
- collection – a container for objects
And, from that, another special-purpose variant:
- tag – an object that contains a collection of attributes
From this, we create our three core specialisations:
- entity – a ‘thing’, which may also contain collections or tags
- relation – an entity that may link between two tags
- model – an entity that incorporates a collection of allowable relation-types and (references to) entity/relation instances, together with any required validation-rules
Fundamentally, everything is based on the same root entity-type. This commonality enables us to have a single standard repository-structure and exchange-format that can be used for every possible notation, re-used across all model-types and toolsets.
Collections
A collection is just a container. It can contain any types of objects, including tags and other collections. A collection is always embedded within another object, which provides its identity and supports any additional attributes (via tags) that it may need.
Example: every object (certainly every entity) will need a RACI collection to identify object-owners and people or roles responsible for or affected by the real-world item represented by the model-object type or instance.
Tags
A tag is a container for attributes. At the simplest level, an attribute is a name/value pair, but it might be better to implement it with somewhat more content, to include a distinct non-editable unique-identifier, an editable name, a value-type (simple, MIME-type or other), validation-rules and the attribute-content itself.
A tag is also optionally a target for relations (links between objects). Every object will need to be able to support at least a default ‘isAssociatedWith’ link to arbitrary other objects; the target-point for this would be a default tag embedded in every object.
More explanation later of how the tag-system would work in practice, and how it could be implemented.
Versioning and ‘inheritance’
Every object would need to support in-depth versioning. As I see it, the simplest way to envision this is that every object is in effect its own wiki-page. The surface view of the object represents the current state of all the attributes and suchlike of that object, but it accretes a history of changes over time, and the entire history is always still available if required.
A ‘snapshot’ of ‘current state’ or suchlike consists simply of attaching a tag to one or more objects that signals the option to revert (usually temporarily) to the state that applied at that time.
Since there is only one root-object, with everything else defined by add-on tags, ‘multiple-inheritance’ consists simply of importing into a single ‘child’-object the tags that represent the state (attributes, relation-anchors etc) of the respective ‘parent’-objects. This may be done selectively, to enable partial-multiple-inheritance. De-inheritance can be done in much the same way, by removing or disabling selected tags within a child-object.
(One point not yet resolved is whether a ‘child’ incorporates an entire copy of its ‘parent'(s), or whether it simply points to them and builds its own versioning thereafter. In terms of data-storage, the latter is probably preferable, but does imply certain risks. However, it’s not critical at this preliminary design-stage, and decisions on this can probably be left until initial implementation.)
Entity
An entity is an object that incorporates (‘contains’) tags that define and maintain its attributes.
Attributes supported by an entity (i.e. via tags) may include any number of media-items of any appropriate type, including audio, video, images, URLs etc.
An entity will support one or more presentation-types. The default presentation-type is a summary of content in text-form (i.e. ‘wiki-page’), plus, for graphic display, a simple rectangle enclosing the entity-name. Other presentation-types may include images or bit-maps, SVG or other scalable/vector images (perhaps via a Visio-style layered-spreadsheet or equivalent). A model-type may specify a default presentation-type via an appropriate tag associated with the model-type (i.e. the presence of the tag on entities would suggest or enforce a specific presentation for that entity), such that the same entity would appear in different visual forms on BPMN or UML diagrams or concept-maps.
Relation
A relation is a specific type of entity that can connect to tags on other entities.
At present, I assume that relations can connect only between two entities (or, where the relation itself has embedded link-tags, between entities and/or other relations). A ‘one-to-many’ relation is actually a set of nominally-identical relations, but may be displayed in ‘branched’ form (as often used in concept-maps, for example) if the respective model-type supports that display-format.
Because relations connect to tags rather than to specific entity-types, the number of relation-types expands almost linearly with the complexity of the underlying metamodel, rather than exponentially or near-factorially as in conventional relation-to-entity metamodels. In general, sub-types ‘inherit’ the tag-set from their parent entity-type(s), hence no new relation-types need be created for each new sub-type.
Relation-types are typically associated with a notation, which in turn is typically associated with one or more specific model-types.
As for entities, each relation will support one or more presentation-types. The most common default graphic presentation-type for relations is a one-dimensional line, with optional arrowheads. Line-routing, collision-avoidance and the like are an aspect of user-interface and graphic display rather than a function of the relation itself: the only explicit function of the relation is to indicate that two entities are related in some way.
For some purposes, and in some user-interface contexts, creating a relation that is not anchored at one end will cause a matching null-entity to be created, according to the tag(s) associated with that relation and the applicable rules of the model-type currently in use. (See the Archi ‘Magic Connector‘ for an example of this type of user-interface functionality.)
One important optional tag for relations (e.g. ‘isFlow’) indicates that the relation also represents a ‘flow’ – a transaction or other exchange between entities. This is typically used to model simulations. The directionality, content and other aspects of the flow would be indicated by other tags, as mediated by the respective model-type within which the simulation is executed.
Model-type and model
A model (graphic, text, simulation etc) is an instance of a model-type.
A model-type is an entity that maintains a collection of tags and relation-types that define the allowable content. Note that, via this mechanism, a model-type does not need to specify the allowable entity-types – hence enabling extension of metamodels without requiring alterations to the list of relations or to the model-type.
A model-instance maintains a collection of references to entity- and relation-instances, together with any context-specific information required for graphic displays. (In some cases a model-type might also include templates for default entity- and/or relation-instances, such as for page-headers and other displayable model-identifiers.)
By default, any instances created within the model-type would be assigned all of the respective tags for that model-type or notation (i.e. initially constrained to that notation and usage). For example, a BPMN model-type would create only entities that are tag-compatible with the BPMN standard, and that can be displayed in accordance with the BPMN notation. However, since ultimately these are all still just entities with tags, and further tags can be added if required, potentially any of these entities may be re-used in any way in any other compatible notation. For example, we could re-use a BPMN Event in an Archimate model, representing the same Event in a different way for different modelling-purposes; a BPMN Swimlane entity might be re-used in Archimate as a Device, an Application or an Actor, with all of its BPMN relations carried through transparently to the Archimate model.
Full validation of models and entity-relationships is a function of the model-type, not the metamodel. This makes it possible to relax formal rigour during development or for certain types of simulation.
Crucially, a toolset and model-type must preserve any entity-tags and/or relations that it does not use or display. This is required to enable ’round-tripping’ between model-types and toolsets. Any toolset that does not support this will be able to import existing entities and relations, or export new entities and relations, but will not be able to ’round-trip’ amended entities and relations.
Model-types and models are often described in terms of views or viewpoints. For this purpose, a viewpoint or view is simply another standard entity, which is then associated with the model-type.
Models would typically display their results, in whatever form required, by ‘calling’ the appropriate presentation-type for each entity and relation in its scope (i.e. referenced within its instance-collection).
Non-semantic entities
Many types of models require or would support a variety of ‘non-semantic’ entities – in other words entities which do not in themselves add to the semantics of a model. Typical examples include:
- annotation – an arbitrary explanatory note attached to an object or relation
- group – a ‘box’ or other container to cluster a group of entities together for ease of reading
- model-caption
An annotation would typically be implemented as an instance of a fairly low-level entity (i.e. one with few tags), optionally associated only with the model or model-view, but more usually with a connected relation that may be linked to any other entity or relation. (In other words, similar to an ‘annotation’ entity in Visio or Powerpoint.)
A group may be displayed just as a box, but in fact it has an implicit relation with all of the ‘contained’ entities. (See the Archi ‘Automatic Relationship Management System‘ for an example of how this would work in practice.)
A model-caption is a container for information about a model or model-view (such as used in several of the Visio templates, and in most types of controlled-diagrams). In effect, this is an entity that is attached to the model-instance, rather than actual content for the model, but would be displayed in the normal way.
Glossary and thesaurus
The total collection of entities and relations within the repository forms the content ‘holograph’ for the respective scope.
A glossary and thesaurus represent different views into that ‘holograph’, in part to answer the questions ‘Tell me about yourself?’ (glossary) and ‘Tell me what you’re associated with?’ (thesaurus).
The glossary for the context, or for any selected subset of the context, consists of a live report derived from the ‘definition’ tags of all entities in scope.
The thesaurus consists of a report, usually starting from a single entity, of all thesaurus-type relations from that entity. These would typically include standard relations such as synonym, antonym, broader-term, narrower-term, conflicts-with and so on. (In some cases these relations between entities may be automatically generated.)
Frameworks and notations
Taxonomy frameworks such as Zachman, or the layered structures used in TOGAF or Archimate, can be represented very simply via sets of tags, and (in the case of supposed ‘layers’) explicit rules around relations that connect to those tags.
Notations consist of sets of tags that define (or extend) specific entity-types, and matching sets of representation-types.
Governance and change-management
Governance regimes such as used in the TOGAF ADM, PRINCE2, PMP and the like, and models such as Gantt-charts, can be represented by sets of entities, collections, and relations between them and other entities and/or relations within the scope covered by a particular change-project, change-programme or whatever. In short, everything is just an entity, or a relation between entities.
A governance method would in effect be the usage of a specific model-type which uses a governance-set, using the validation-rules defined within that model-type.
As described above, every entity, relation and model should have an associated RACI (responsibility-assignment) collection.
Governance-artefacts such as reference-models may be created by ‘freezing’ an existing model as a new model-type, and then enabling relations from there to other entities that represent the implementation of the respective items described in the reference-model. A waiver or dispensation (i.e. an accepted and documented breach of the validation-rules for the reference-model) in effect consists of a descriptive entity that is linked to the non-compliant item and to the respective section of the reference-model.
Toolset-ecosystem
The full toolset-ecosystem for enterprise modelling and sense-making covers a huge range, including:
- enterprise-wide repository, supporting specialist edit/moderation tools and simpler client-server interfaces (e.g. static or annotatable web-pages)
- team-based tools – essentially a smaller-scale version of the enterprise-tools, with a repository shared across the team
- single-user repository-based tools
- non-repository tools (such as Visio or Powerpoint)
- tablet-style systems with gesture-based interface, often thin-client only or with limited local repository
- handheld tools (smartphone etc) primarily used as thin-client
- pencil and paper
Given this scope and range, it is extremely unlikely that there would ever be ‘One Toolset To Rule Them All’. However, this metamodel can link between them all, by providing a means to share information and models between them. Each toolset-type could also use any of the model-types, frameworks and notations supported by the metamodel, and link between all of those as well. In that sense, not ‘One Toolset To Rule Them All’, but possibly ‘One Standard Data-Structure To Link Them All’. 🙂
Conceptually, the metamodel described here is best suited to the enterprise-wide repository. Merge and data-cleansing would be important moderator/curator activities at this level.
For team-based tools and single-user repository-based tools, these would support the metamodel directly. They would need to be able to import and export individual models and/or selected sections of the entire repository. Again, merge and data-cleansing are important activities, though this is likely to be the scope within which most actual specialist modelling takes place.
For non-repository tools, distinct import and export functions will be required. These tools do not actually have any real concept of ‘entity-type’: everything is an uncontrolled instance, in essence without any layering or depth. Import into these tools is relatively straightforward, simply by ‘flattening’ the internal structure of existing instances and selecting an appropriate representation for the respective notation; but real care will be needed when importing into a repository-based system an exported model from a non-repository tool, because much of the underlying structure may have been lost, and connection to a parent entity-type will be questionable at best.
Tablet-style tools may or may not be repository-based – the main distinction here is the interface-metaphor (gestural rather than text/visuals or keyboard/mouse) rather than the underlying metamodel. If repository-based, or thin-client only where the repository is maintained only on the source server, the usage is much the same as for a team-based or single-user tool. If essentially a non-repository-tool (equivalent to Visio or Powerpoint), then the respective constraints apply. If solely graphic (i.e. a ‘draw’ application), the image-file should be handled much as for pencil and paper.
Most handheld tools would be used as thin-client, with primarily for local consumption and with little to no original information-capture. The thin-client relationship would, however, enable update of uncontrolled sections of information – such as the free-form ‘wiki-page’ section for each entity or relation.
Pencil and paper will still remain one of the most common tools for idea-capture and initial development. Some applications already exist to scan paper-based drawings and create the respective entities and relations; these will always need subsequent moderation and data-check, but it is feasible. The layered tag-based structure for this metamodel should make that process easier than for some other existing metamodels and notations, particularly as it allows information-capture in ‘non-standard’ forms.
Implementing the metamodel
Implementation could be relatively straightforward, because at a fundamental level there is only one entity-type, and only one relation-type – everything else is created via the ‘tag’ concept, which itself should be reasonably simple to implement. The only fundamental difference between entities and relations is that relations can link to things, whilst entities cannot (in their own right, anyway). The ‘wiki-page’ concept is also fairly straightforward.
This could be implemented via a conventional relational-database, although an object-database would probably be a better choice in practice. I’ve implemented something fairly similar to this in PHP, with a MySQL back-end: it’s used as the base for several of my existing websites, such as tomgraves.org, tetradian.com, sempermetrics.com and the OS-EA Tools site. (It’s versatile, as you’ll see; but yes, as you’ll also see, it’s, uh, clunky – which is why I’m definitely not the person to be writing the code for this… 🙁 )
As I see it at present, the common file-format can be a straightforward XML or JSON text-file. The core, and each notation or framework or the like (each, in effect, little more than a set of tag-definitions) would be specified as the equivalent of an XML DTD (data-type description), with a defined namespace, conceptually similar to namespaces in XML or Java.
Each notation and associated model-type is therefore a ‘plug-in’, conceptually similar to plug-ins in Eclipse and the like, except that in principle it could be possible (and in practice may indeed be possible) to implement these ‘plug-ins’ via a simple configuration-file, without requiring any embedded plug-in-specific code.
There’s a tricky area around how to specify representation-types for model-types, and how to define validation-rules within model-types, but I don’t see that it’d be a ‘deal-breaker’. It just needs someone who’s more experienced than I am about designing a configuration-language.
The other key point, though, is that because everything is in effect defined via an equivalent of a DTD, this means that any toolset that can interpret that configuration-file would also be able to implement and use any model-type or notation that can be defined via that form of DTD – and as far as I can see at present, that includes just about every notation or framework that I know of in general use in current enterprise-architecture, strategy, sense-making and the like. In other words, not quite ‘One Toolset To Rule Them All’, but in practice not far off it.
Summary
The metamodel described here can, in principle, cover just about all enterprise-architecture needs, and many other related needs, with one very simple structure.
The core of the structure is a single entity-type; a single relation-type; a very simple ‘collections’ structure that can be used within any of these; a concept of ‘tags’ that carry attributes and/or presentation-types, and to which relations may be linked; and a structure for model-types that inverts the usual structure by focussing on relation-types rather than entity-types.
Because the structures are so simple, it should be straightforward to implement in practice, for different toolsets using a range of different user-interface metaphors, across the whole of the toolset-ecosystem.
Okay, that’s it: over to you? Any comments/advice/suggestions, anyone?
(And many thanks for reading this far, of course! 🙂 )
Tom, you mention visio a few times in your post, but it seems to me that many of the requirements that you detail are quite well supported by Visio itself, and perhaps it could form the base of your toolset
a single object, ie. the shape ( instances complete with UID) would be your base entity, connectors are your binary relations, the ability to group shapes into concentric sets handles your notion of collection and custom properties handles your notion of tags. stencils which store shape masters would hold your types, visio templates which would group stencils ( and hold proto type shape structures ) could serve as your model type etc, and visio documents themselves would store the content. version control, collaboration etc would certainly be a challenge with visio, but with an appropriate governance structure, i think this might be workable as well.
Hi Tom, just a thought – there’s a *lot* of text to digest.. you might have a better chance at garnering feedback if you could build together some visual representations of these concepts?
Another suggestion would be to build a worked-example of the metamodel – both as a communications tool but also as a nice way of bench-testing the model itself.
Is it worth breaking this out into a Wiki or some other collaborative platform?
@Mike Burke
I agree that having a visual representation will be useful for absorbing the concepts and gathering feedback. I’ve given thought to getting some of the ideas down on paper myself when I have time as I tend to need to look at concepts like these as diagrams to check their validity and internal consistency.
A wiki or other collaborative tool would be great too.
I wonder if others agree?
@Mike Burke I agree:
I will try to capture some of Tom’s ideas in tubemaps which I will put on my own weblog under http://peterbakker.wordpress.com/tubemapping-the-enterprise/. That will be sketches of how I perceive Tom’s work so far, plus some of my own insights about sketching. So I will focus mainly on the pencil & paper part and will “prove” that: “Pencil and paper will still remain one of the most common tools for idea-capture and initial development.” 🙂
@Robert Phipps – Yes, Visio would make a good prototyping tool for some of the visuals on this. For general use, though there are several catches that make it near-unworkable for this purpose.
– Visio is proprietary, and relatively expensive.
– Visio has no underlying repository or accessible metamodel. (It does have the ShapeSheet functionality, but in the main it handles only the display part, and applies only to a single Shape: there is no means to handle shape-inheritance, for example, other than by manual hacking.)
– Visio has no distinction between type and instance: changes to the parent type have no effect on its child-instances.
– Visio does not enable re-use of instances in multiple models or views: an instance is constrained to the diagram in which it appears.
– There is no means to change the display-presentation of a single instance: the whole point is the single usage in a single diagram-view.
– I believe there is still is no direct means to support multiple-user access to the same object.
It’s possible to build limited workarounds for some of these issues – such as Orbus’ repository for Visio – but they still cannot properly address the fundamental problem that Visio’s modelling metaphor is oriented to surface-visuals, not to the underlying structure.
@Mike Burke – Well, yes, that’s the whole point, isn’t it? 🙂
There’s a bootstrap problem here. I wrote it out in text (as I would have to anyway in an ontology tool like Protege, for example) because it’s still too vague to put into a visual model; and I need the complete implemented metamodel in order to describe the metamodel visually.
Likewise there’s a bootstrap problem with building a working model: I need the model implemented and working in order to start developing a working model. As I said in the text, I do have an existing wiki-based framework which could be used for very preliminary prototypes: but these days I’m definitely not the person to do that work. I could spend perhaps a year doing something badly when a good programmer with access to the right tools would be able to knock up a working prototype in a day.
To be blunt, I’m not a programmer: I’m not good enough. Does anyone know anyone who is good enough, and who would be able and willing to do the initial work?
Agreed on the wiki, other than that I set up a wiki on this (OS-EA Tools) a couple years back, to which precisely no-one else was interested. A bit dispiriting, bluntly. It’s still there, and it’s a bit clunky, but it works. If anyone’s interested.
But much better than a wiki would be a proper whiteboard/SCRUM session with a programmer or two who really know what they’re doing. It’d take me about half a day to do a proper ‘brain-dump’, and the whole thing could be up and running in usable prototype form by the end of the day, or a couple of days at most. It’s not hard. We just some way of doing it, rather than merely talking about doing it… 🙁
Apologies if I sound too much Mr Grumpy: it’s just so darn frustrating not having access to the right tools and the right people. I know how simple this could be, and I’ve already implemented many aspects of it over the years: it’s just I have no idea how to do it with modern tools and modern display-systems, and I don’t know where or with whom to get it started. Oh well.
@Anthony Draffin – As with Mike’s notes above, it’s not so much the finished rough-diagrams that would help here, but more the collaborative process of thinking-whilst-drawing.
The core entity is dead easy: it’s just a bare UML class-diagram. The ‘relation’ entity is just a variant on that with a couple of extra in-built attributes. The tags are just a collection of objects that are linked to entities and relations: that’s easy in UML too. And yet the UML diagram says almost nothing at all about how it actually works. That’s the problem. Hence having to resort to describing it in text. Which also doesn’t work well, but it’s all I have at present?
I’m struggling with this: I freely admit it. In short, if you can do better than text, please do it? Many thanks… 😐
@Peter Bakker – Tubemapping is probably a good way to explore this – thanks.
It’s also a really good illustration of why this type of metamodel would be valuable, and also illustrates some of the modelling/presentation challenges.
On the ‘value’ side, a tubemap is in essence just a variant of concept-mapping (with an emphasis on linear/sequence relationships, rather than the ‘focus on a central theme’ of mind-maps). In a tube-map, there’s as much emphasis on the categories of relations (the ‘tube-line’) as on the entities (the ‘stations’). In this type of metamodel, these could be re-modelled/redisplayed as Archimate, or BPMN, or UML structure or sequence, or risk-map, or whatever, with all of the original tubemapping relationships preserved in the background.
Handling the entities is straightforward: each entity represents a concept (usually one that’s implementable in some real-world form), and we’d display it just as its name. (There are a few visual tweaks we might apply, such as alignment to the grid, and bold-font for ‘interchange stations’, but it’s all easy enough.)
The relations between ‘stations’ are actually quite a bit trickier. In principle, for each ‘tube-line’, they’re all just the same relation – but there’s also the idea of sequence. Each time we add a concept, we have to split the line and insert the ‘station’ into the sequence with its own relations; if we remove a concept, we need to re-link the relations to the ‘stations’ either side. And during development, it’s likely that we’ll have concepts (i.e. would-be ‘stations’) floating around on the model-workspace without any connection to anything. From a metamodel perspective, that means that we have ‘orphan’ entities floating loose without any connection to anything else (other than perhaps the parent model), which is always a bit problematic.
Anyway, tubemapping provides a really good test-case for a lot of these ideas. Discuss further, perhaps?
And thanks to all, of course.
@Tom G
“It’s also a really good illustration of why this type of metamodel would be valuable, and also illustrates some of the modelling/presentation challenges.”
That was exactly my idea! Using tubemapping to visualize the story, or more precise the hero’s/heroes journey, behind “The EA Meta-Model That Binds Them All” 🙂
I don’t think I would use tubemapping as a kind of formal modeling method. Therefore I would use Petri Nets…
@Peter Bakker
““Pencil and paper will still remain one of the most common tools for idea-capture and initial development.”
That’s so true. And of course, whiteboards and sticky notes, too.
But I don’t think if I will visualize all 510 stages of the journey http://www.clickok.co.uk/index4.html 🙂
I will use the template from page 33 from Resonate: http://www.duarte.com/books/resonate/assets/
@Tom G
I agree, and to that end I did a quick sketch of the concepts (apologies for the trial version watermarked on the background – I haven’t paid for a copy of my tool of choice, Enterprise Architect, yet). Emphasis is on sketch, because I did it in ten minutes and I know it’s not a perfect representation of your text above. It helped me think about it though and I floated it with a friend who has experience in developing tools using metamodels. In short, he has confirmed that it wouldn’t take much time to develop a basic working prototype. The tool of choice being Holocentric Modeler’s metamodelling facility.
The part that is still confusing me is the utility of these ideas. I understand that your intent is to balance a tension between rigour and lack of constraint. My worry is what this would mean to an everyday user. There’s a huge danger that the lack of constraint would result in artefacts that aren’t consistent with the subject the user is modelling. So on one hand while this metamodel is trying to be as flexible as possible, it is also enabling laziness. In the right hands a tool such as this extremely powerful, but this will only be a tiny subset of users in the world. Anyone else who uses the tool is likely to at best only use a fraction of the power of the tool and at worst create a horrible mess. I was bouncing some of your ideas off a friend and he commented “Maybe I have the wrong end of the stick but it looks to me like trying to write a program using assembler, great for god, but poor for anyone else as they need help in reasoning, remembering and understanding (being human!)”.
There is a solution to this problem: multiple metamodels. So only allow the more advanced users to instantiate the metamodel you described above. For the rest of the users impose at least one and quite possibly several intermediary metamodels that have more constraints so that you get meaningful pictures out users who need those constraints. Quite possibly this is another element of the metamodel you have a “modal level of constraint” which can tighten or loosen the constraints as necessary. I think that’s quite doable. What do others think?
Hi Anthony – on the ‘quick sketch’ for the metamodel – yeah, that’s the right sort of idea, and yes, I need to do some sketches myself, will aim to do so later today and put them up in another post.
My ‘tool of choice’ for development here would not be a UML-tool but probably some kind of wiki-framework – because that’s actually what conceptually it most closely resembles. We would use something like Sparx for the code part, perhaps, but the danger with a UML tool is that it leads us down the “it’s a database” path rather than keeping the focus on the usability.
On utility, yeah, I admit I haven’t made it clear enough that whilst we use the term ‘metamodel’, we’re actually talking about a metametamodel at least, and probably deeper (i.e. it’s at or below the level of MOF rather than the UML specification). This part is not usually visible to the everyday user, in fact we definitely need to hide it. What they see – as you’ve said in your comment – is what appears to be ‘multiple metamodels’, though in reality that ‘metamodel’ is actually a set of model-types, containing a bunch of tag-definitions and the associated relation-definitions. In other words, essentially the same as the UML metamodel, for example, except that there are metamodel-specific entities – instead, everything is built around the one standard entity-type. That’s what enables us to re-use entities in any number of model-types. And since there’s only one entity-type for everything – plus tags and relations that can be ignored if they’re not supported in the respective surface-level ‘metamodel’ – that means that we can have just one file-type to support exchange between any variations of toolsets. That’s the real point here.
So on the surface, it looks like ‘multiple metamodels’ – a complication which makes it sort-of easier to use. Under the surface, it’s actually a lot simpler: a single ‘holograph’ to which arbitrarily-selected filters and views can be applied. The ‘multiple metamodels’ are predefined filters: but you can also ‘roll your own’ as required.
One point you alluded to is security and access-control – and I’ll have to admit that I’d completely forgotten about that. 🙁 It does indeed need to be built in right from the start, and right from the root, and I’ll admit that I don’t know how to do it. (There’s all sorts of really nasty ‘deadly-embrace’ problems to deal with there, such as where the only people with the technical skills to resolve a problem don’t have the access-rights to go in and fix it.) But that’s a good reason to start from a ‘wiki-page’ concept, because many of these problems have already been resolved in wiki-designs, especially wikis for high-security contexts. Another point that would help here is the design-principle of ‘safe ignorance’: if a model-type doesn’t recognise a tag, it should simply ignore it, yet also preserve it. But yes, there’s a lot to think about there: another whole can-of-worms set of complications. Hmm… thanks for the reminder? 🙁 🙂
@Anthony. About constraints and different access levels. The problem with constraints is that they nearly always turn out to constrain part of what you actually want to allow and can nearly always be worked round by those who don’t understand why they’re there. And the people who do know why they’re there don’t need constraints but rather, I suggest, a set of patterns (and perhaps anti-patterns). Access levels suffer from the same problem.
At the end of the day this approach, like any other good method, will work if people understand what they are trying to achieve with it and why the semantics support that objective(s). You simply can’t legislate for people who do not understand or who knowingly mis-use the method.
So the better we (i.e. Tom with our support) can explain the why and the what, the greater the chance that the how will get used properly.
Stuart, re “the problem of constraints” – yes, exactly.
A pattern-based approach is certainly the way to go. (In effect, UML or Archimate are just pattern-based filters with a few extra constraints thrown in.) As you say, we also need to get more clarity on method and workflow and governance and so on right from the start (though I’m not sure how much of that we could or should build into the metamodel itself).
And yes, at this stage we really need to keep the focus more on the Why of the metamodel, rather than rushing straight away into the How or What. In some ways that’s why I’ve kept the description mostly to text, because visuals (and especially any formal entity-models) tend to push us too far into the How/What space, before we’ve had enough of a chance to really clarify the Why.
@Tom G I think we really need a meeting place, see my post at http://peterbakker.wordpress.com/tubemapping-the-enterprise/the-fellowship-of-the-enterprise-architecture-meta-model/
Peter – Thanks for the tubemapping, and yes, we definitely need somewhere other than this blog as a ‘meeting-place’.
(Am a little worried about where tubemapping might lead us, though: strange ‘Mind The Gap’ monsters and tube-stations that fade away without trace? – see Neil Gaiman’s ‘Neverwhere‘ for more on this… 🙂 )
@Tom G Tom, thanks for the link to “Neverwhere”! Through that link I found this quote from the writer of the Neverwhere book:
“For the dreaded journey ever-downward — through bizarre anachronisms and dangerous incongruities, and into dusty corners of stalled time — is Richard’s final hope, his last road back to a “real world” that is growing disturbingly less real by the minute.”
(source: http://www.neilgaiman.com/works/Books/Neverwhere/in/191/ )
Don’t we all feel like Richard? And is “the EA Meta-Model that binds them all” our last road to reality?
You see, tubemapping does strange things with my mind, it starts to create strange, previous hidden, lines of thought by itself 🙂
Tom. I can help you on the security/access control side. Not the actual programming but getting the architecture right, so it doesn’t lead to the problems you mention. That’s one techie thing I actually do know something about.
On the other topic, I completely agree that method and governance should be kept separate from the meta-model. It may, however, be useful to develop those (informally) in parallel. The one can be a useful litmus test for the other.
Stuart – advice on the security/access themes would really help all of us – many thanks (in advance) for that!
And yes, method and governance is something we do need to work on in parallel, for the reasons that you say – that they and the metamodel would cross-test each other. Will aim to rough out some notes on that over the next few days.
Tom, i think visio certainly would present a challenge, at just those points that you identified, but the fact that it covers much of what you have asked for is i think quite interesting. Other products, such as protege (which was mentioned above by others at some point ) similarly has a root object, and operate a frame style implementation that lets you elaborate on the empty root through the progressive derivation of more involved concepts, and instances of concepts. The MOF 2.0 framework, as another example also tries to capture metamodel primitives , and many modelling tools claim to be MOF compliant which i take it means that models constructed in one metamodel should be translatable into other meta models through a transformation defined on their meta models. So i think that what you are looking for is really the holy grail of our craft, and is the goal of many a cruscading architect!!!
Tom following up on your last reply to Stuart, that we need to keep the why of the meta model in mind, – i am inclined to consider meta models as simply higher order articulations of conceptual frameworks, so that a metamodel is simply a body of prior thinking, that simplifies subsequent thinking. having a simple metamodel, merely defers the hard thinking further down the conceptual food chain. A complex multi layered meta model does most of the thinking up front, and subsequent thinking can perhaps be more automatic. ( this is the chief motivation behind much of the work in ontology construction, which aims to facilitate machine inference and Web 2.0 could probably be mentioned in the same breath). In the end, the goal of all of this is the general intelligibility of the representational final-product, and metamodelling merely a technique for layering the articulation of the subject matter. Philosophers have been the traditional keepers of such prior thinking, but information technology and the like has democratised this function so that every data-modeller, is effectively metamodelling when they define their table structure. I think perhaps their is nothing special about meta models, and that they are appropriate to the extent that the subject matter under consideration permits prior thinking. Could you imagine constructing a non-trivial metamodel to cover discourse about a chaotic domain ?
Robert – on “lets you elaborate on the empty root through the progressive elaboration of more involved concepts” – that’s what I’m aiming for with the ‘tags’ concept. The crucial distinction is that whilst instances of tags are embedded in or associated with an entity, the tags themselves are distinct from entities – in effect, they’re sort-of entity-types in their own right, and associated more with a ‘plug-in’ sort-of-metamodel than with entities as such.
Entities accrete tags, depending on how they’re used and the model-types in which they’re used. Every entity-type and entity-instance is sort-of-different, but underneath it there’s only one core type of entity, to which tags (and, from there, relations) are attached. And because there’s only one entity-type, that provides the basis for a common data-structure and common exchange-file format, which can be used with any compatible toolset. That to me is the ‘holy grail’ we’re aiming for here.
Another point about the ‘tags’ concept is that we can structure relations between tags, such that they form categories or sets – hence a Zachman-style taxonomy, a TOGAF-style layering, alignment with a particular notation, or the ‘dimensions’ you describe in your ‘Vectors’ post at http://www.modalthought.com/wordpress/?p=30 . A translation between metamodels would in effect be a set of relations between tag-types from the different metamodels, following the same thesaurus-type mapping that would be one of the core relation-sets for the root metamodel.
On “Could you imagine constructing a non-trivial metamodel to cover discourse about a chaotic domain?” – yes, I can, and actually it’s almost trivial, because it’s the same metamodel that underpins CMapTools and the like: a root-level entity than can be assigned any name or term, and a relation that can be assigned any name or term. To go a bit deeper, you might want to build a metamodel that maps to Southbeach: that’s a small set of about a dozen defined entities (most of which are just minor variations on the same theme), and rather more than a dozen allowable relation-types (most of which again are minor variations of each other, which in effect represent different combinations of tags). At the interface level, something like Southbeach MyCreativity would be very useful, but note that that’s derived from the content of the instances, rather than embedded in the metamodel as such. In principle it doesn’t need anything more than that, though in practice I would recommend that all of the entity- and relation-types can support attachment of arbitrary media items (audio, video, photo, URL etc) to help in contextualised information-capture and in storybuilding.
It’s not hard – I’m sure of that. What is hard is keeping the focus on simplicity, and defeating the seemingly-irresistible temptation to add special-cases or other layers of complication to what is actually a very simple core.
Metamodel evokes such passion!