Meanderings on metamodels
Been spending the past couple of days thinking long and hard about what’s needed for an Open Source kind of enterprise architecture toolset.
On the one side, there’s the work by people such as Charles Edwards and others at Agile EA, who’ve focused on tools (the Eclipse framework, in their case) to manage the architecture development process. What it’s lacking, however, is any kind of modelling or information-repository.
On the other side, there’s the Essential Project, which uses the Protege toolset to manage the repository and metamodel – but has no real method-support to speak of, and uses the same tired old TOGAF-style ‘four architectures’, which just does not work for anything beyond a bottom-up IT-centric view of ‘enterprise’ architecture. And whilst there are a handful of auto-generated model-types, it isn’t a generic modelling environment such as we need for architecture problem-solving.
So what do we need? As I understand it, we need something that merges all of the following:
- a structured yet iterative architecture method (or preferably support for several of them)
- a user-extensible metamodel, describing model-entities, relation-types and model-types
- a set of repositories for requirements, for risks/opportunities and other issues
- a glossary and thesaurus – preferably auto-generated in some way
- a modelling environment that allows us the link all of these together in both structured and unstructured ways
- tight, explicit version-management for everything
It’s clear that the core of all of this would be the underlying metamodel – because everything else derives or devolves from that.
In a couple of days of hammering and head-scratching and scribbling and the rest, two main metamodel themes seem to have come up.
The first is that the usual way of building the modelling part of an architecture metamodel is the wrong way round. The usual way starts with entity-definitions. We then define individual ‘legal relationships’ from one entity-type to another. Once we’ve done that, we than build model-types which use specific entities, which then implies the ‘legal relationships’ we can use within the model.
There are at least two things wrong with that approach. One is that this doesn’t allow for the kind of loose-coupling that occurs between entities – the variability of what I call ‘bindedness’, particularly in reference-models, in which some items are mandatory, others are strongly recommended, others are merely desirable, and so on. It also means that we have vast numbers of relation-types, many of which may be relevant only in specific contexts, and which increase in number exponentially as we add entity-types to the metamodel. And worse, there’s no clear way to enforce compliance in a model-type: if the relationship is ‘legal’, it can appear in just about any model – which wrecks the consistency of a BPMN model, for example.
A better way round is to start with the model-types. These define a list of relation-types that are ‘legal’ within the context of the model. The relation-type itself identifies the entity-types that can be at either end of the link – which, for most real-world modelling, would also have to include an entity-type of ‘Unknown’, to support the very common development case where we know something is needed but we don’t yet know what it is.
This is made to work via the second of the themes that have come up over the past couple of days. The core ideas here are:
- most (but not all) root-level entities need to be identified as ‘primitives’ within a Zachman-style frame of rows (responsibility and timescale), columns (asset, function, location etc) and segments (physical, virtual, relational etc)
- most things we deal with in architecture are ‘composites’ that straddle framework segments and/or columns, or patterns that can also bridge framework rows
- display should not be rigidly linked to the entity itself – or rather, an entity should allow any number of display-methods
Taking this a few steps further:
- above the base-level, anything can be a composite
- a composite inherits not only the attributes and display-methods of its included ‘parents’, but also their hooks for the respective inter-entity relations in model-types
- links connect to any member of the composite – hence, for example, we could have an abstract entity-type called ‘BPMN Data-Object’, which could be attached to any entity for a virtual-object (form, message, database-record etc), or for that matter any physical or relational object, which would enable that entity to be displayed in a BPMN diagram as the ‘dog-eared page’ BPMN symbol for ‘Data Object’
- an ‘instance’ of an entity-type is simply something which can itself no longer be sub-typed – e.g. “Oracle 9i database application” – but can still be subtyped if it’s incorporated into a composite with something that isn’t an instance – e.g. instance “Oracle 9i” + entity-type “server” form a composite entity-type “Oracle 9i server” which can then be instantiated (or sub-typed) as “Oracle 9i production-server”, “Oracle 9i development server”, “Oracle 9i fallback server” and so on
- categorisation into the respective framework cells, rows, columns and segments is done by attaching the respective objects and/or (for e.g. a whole row or column) composites into the composite-set for the entity – which also allows us to define relation-links that only connect to specific rows or columns or suchlike
This is all very much a work in progress, but it does seem to open up a whole realm of possibilities. A few initial ‘thought experiments’ with workflows suggest that despite the underlying richness, it would actually be easier to drive than most of the big behemoths such as Troux Metis or IBM/Telelogic System Architect.
More on this later, but I thought it was worth posting for discussion as it is now, anyway. Comments / suggestions, anyone?
I’m no expert, but have you seen ADLs? Does that influence the work you are trying to do with the meta-model.
As for legal relationships, my initial response is a relationship between two entities is either always legal or always illegal. Now, whether it is displayed in a view or not is a different concern based on the stakeholder who is viewing the view. My thoughts here would be counter what you say above so I must ask: am I way off or do we have a mismatch on terms?
Cheers!
Thanks Eric
No, I hadn’t properly thought in terms of Architecture Description Languages (I presume that’s what you mean by ‘ADLs’?), other than a discussion with one of the Open Group crew who said that an ADL for TOGAF has been ‘coming Real Soon Now’ for about a dozen years.
The catch is that all of the ADLs I’ve seen to date are designed for software, which is great for explicit rule-based relationships, but can’t handle the complexity of real-world ‘ifs and buts and perhapses’ relationships between entities.
That’s the point about ‘legal’ versus ‘non-legal’ relationships in your comment above. It’s not so much about whether it appears in a specific view or model, as whether and how it should be used within the whole architecture. From a requirements perspective, a ‘legal’ relationship is a “shall”; but we also need a whole slew of levels of bindedness, such as the MoSCoW set ‘must’, ‘should’, ‘could’, ‘would be possible’ – which is the kind of range that we get in reference-frameworks and in architecture dispensations.
Ultimately, yes, we _must_ be able to express all of this in an XMI-like ADL, but that’s going to take, again, a whole slew of separate work. What I’m trying to do right now is get my thinking straight on what a metamodel should look like and what attributes and methods would be needed to make it work. Any suggestions on that would be much appreciated!
Some interesting ideas here. There are many similarities to the work of Reenskaug in OOram – which focused on modeling object roles in context and less on defining a universal model. See http://en.wikipedia.org/wiki/Object_Oriented_Role_Analysis_Method or an obsolete draft here heim.ifi.uio.no/~trygver/documents/book11d.pdf.
Your ideas strongly relates to work I’m involved in at OMG in the areas of:
a) ‘MOF for Semantic Structures’ which allows the entities to evolve over time to adopt different entity types
b) Diagram Definition which allows the definition of what diagrams can contain and which are valid.
Thus, to take your example, an instance of entity type RelationalTable could be given the additional Entity Type BPMN Data Object to allow it to participate in BPMN models/diagrams.
However I think you do need to distinguish subtyping (a relationship between 2 types) from instantiation (a relationship between a type and an instance): to talk of an instance being subtyped does not really make sense IMHO.
And I don’t quite get “a composite inherits not only the attributes and display-methods of its included ‘parents’ ” – what do you mean by ‘parent’ (seems unintuitive for the entities included in the composite)? And I think any ‘display meatods’ would be associated with the composte itself not to the entities included in it: as you say elsewhere this needs to be context-driven.
Finally, I agree versioning is important, but it should be metamodel-independent. The OMG Versioning standard is defined at the metametamodel level (MOF) so automatically and implicitly applies to models in any MOF-based metamodel (UML, CWM, BPMN etc). This gives a clean separation of concerns, does not muddy individual metamodels with versioning details, and most importantly, provides a capability for versioning composites of entities from many different metamodels.
Hi Pete
Many thanks – this really does help. On last item first, will follow up on OMG Versioning, and definitely agree that it’s so fundamental that it needs to be right at the root (metametamodel), which is probably the level of what I’m describing here anyway.
I’m probably not being clear enough on subtyping versus instantiation. To give a concrete example, using Zachman-style layering, imagine I have a type ‘database application’. I might then either instantiate or subtype it, Protege-style, to give an entity ‘Oracle database application’. I take that to full instantiation as ‘Oracle 9i database application’. That all sits at the layer-4 ‘Physical’ or ‘Develop’ in Zachman-style layering. When I take it down one Zachman-layer, to the real-world ‘Deploy’ level. I need to re-convert that instance to an instantiable subtype as a composite with the subtype ‘server’, as ‘Oracle 9i server’; I can then instantiate that as ‘Oracle 9i develop server’, ‘..test server’, ‘..production server’, ‘..fallback server’ and so on (each of which might again need to be re-instantiable as ‘..server #1’, ‘..server #2’ and so on).
On inheritable display-method, what I’m thinking of here is that some model-types would want to list everything that is, for example, a physical-asset either in whole or in part (such as a paper form, which is both a physical-asset [paper] and virtual-asset [data]). If the display-method is an attribute of the attached inherited-entity – which I’ve rather loosely described as the ‘parent’ – then it would / could be available to the subtype. I’m currently working on how that sort-of-inheritance would work in practice, but it seems doable. It’s certainly close in concept to your notion of Diagram Definition as yo describe above, though perhaps not quite the same.
I’ll admit I’ve been working almost entirely on my own at a ‘thought experiment’ level; as yet haven’t really mined from or aligned with the available information from other important sources such as OMG, and it’s clear I need to do so. Any suggestions as to where I ought to start on that, or who else to work with?
Many thanks again, anyway.