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?
). Reason is not only that it’s horribly technical and applicable to a very specific field of interest, but it’s also too incomplete to be usable as-is, it’s in text form only when it urgently needs some descriptive graphics (my apologies, but I couldn’t find any way to do them…), it assumes an underlying layer (OMG MOF) that relatively few people would know, and it is, well, still a Tom-tangle of useful ideas and probably-impenetrable assumptions… Oh well. But it’s there, anyway.