How to get enterprise-architecture on TRAK

At last – at last – there’s now a ‘framework for enterprise-architecture’ that’s actually worthy of that title.

(Many thanks to Craig Martin of Australian consultancy Enterprise Architects for the Tweet that brought this to my attention, though I suppose I ‘should have’ known about it already… 😐 )

The framework is called TRAK, (The Rail Architecture Framework) originally developed in 2009 for the London Underground, but now published as an open-source project on Sourceforge:

There’s more detail on TRAK’s background and the MDG add-in on the website for Eclectica Systems – the originators of TRAK – and also a brief project-description from IET (The Institution for Engineering and Technology).

The framework is based on MoDAF, the architecture framework used by Britain’s Ministry of Defence (which in turn was adapted from DoDAF, the [US] Department of Defense Architecture Framework). As the TRAK Wikipedia page explains:

The TRAK Metamodel is a simplification of the MODAF 1.2 metamodel. It has removed and redefined stereotypes and any defence-specific constructs have been removed. … Significant changes include:

  • System is central to TRAK and can represent hard systems and soft systems (in MODAF 1.2 System is an artefact and part of the Physical Architecture and cannot include non-physical parts)
  • TRAK can represent any type of interface / flow – information, energy or materiel
  • TRAK can represent exchange characteristics associated with human resources – Organisations, Jobs and Roles
  • other types of dependency and associations can be represented – physical, membership, responsibility extent
  • addition of ISO/IEC 42010 concepts to represent the architectural task
  • addition of consistency rules that constrain how and in what order relationships can be made

With MoDAF’s defence-specific items removed, the TRAK metamodel covers the full scope of an enterprise – for example, clear distinctions are made between information-resources, machines and people:

Although in a few places this does show its physical-engineering heritage, in effect this is a generic high-level metamodel suitable for use in enterprise-architectures for any type of organisation. (This is a very important contrast to the metamodels in TOGAF or even in Archimate [Business, Application and Technology layers], which at present are effectively usable only for IT-centric architectures in information-oriented enterprises such as banks, finance, insurance and the like.)

Note also that, as I’d argued in my post on ‘A question of Who‘, the Human Resources section of the metamodel does not include any reference to real-people. It describes what people do (Job, Role), their relational location (Organisation) and their capability (Competence), but – correctly, to my mind – it does not attempt to include people as themselves.

There’s a lot of detail in this framework: 90+ pages in the metamodel description, another hundred pages or more in the description of the viewpoints. I’ve haven’t read all of it as yet, but so far feels solid, comprehensive and, well, just right, really. (Part of that, I suppose, may be because I’ve spent so much time in engineering and logistics environments – where the information is often more about physical things than merely information-about-other-information – and in other contexts where people need to be viewed as people, rather than solely in terms of information-about-people.)

What’s missing? Well, it’s based on DoDAF and MoDAF, and hence, like them, it only covers the information-description side of  an enterprise-architecture framework: it doesn’t provide any methodology. One option for a methodology would be to use the TOGAF ADM, as described in an Open Group white-paper by Terry Blevins et al on bridging TOGAF and DoDAF: the catch there is that the ADM’s structure is inherently IT-centric, which would rather work against the whole point of TRAK as covering a broader scope. Another (and arguably better) alternative would be to combine that with the modified version of the ADM that I use in my own architecture-work, because – like TRAK – it’s explicitly designed to cover any architecture scope. And another good option – as Craig in fact suggests in his Tweet – would be to link it to the methodology in PEAF, Kevin Smith’s ‘Pragmatic Enterprise Architecture Framework’.

Anyway, definitely worth a detailed look. Even from a fairly cursory review to date, my own strong opinion is that for TOGAF-type architecture-developments that could touch any space beyond IT, we should all standardise on something like this as a base-metamodel, rather than the as-yet unusably-incomplete one provided in the TOGAF 9 specification.

Recommended – very recommended.

Comments, anyone?

[Update: 15Aug10] Philip Allega of Gartner tells me via Twitter that even though it was only developed and released last year, TRAK is already considered obsolete: “EA leads at TfL [Transport for London] and LU [London Underground] presented at [Gartner’s] London EA Summit, noting that TRAK retired” – kind of embarrassing, considering how much I’ve gushed about it above… 🙁 I still feel it’s of real value, though, because it provides a good example of what’s needed in an enterprise-architecture metamodel once we finally break out of the IT-centric deadlock. No information yet as to what (if anything) has replaced TRAK, but will post another update here as soon as I found out.

[Update 2: 15aug10] And have now had a detailed set of replies from Nic Plum of Eclectica Systems (see Comments section below) explaining that TRAK definitely is very much still in use, and also does have a methodology derived from ISO 42101. More details from Nic below, anyway. (Many thanks.)

15 Comments on “How to get enterprise-architecture on TRAK

  1. Thanks to Rich Hilliard for pointing this out to me (via the TRAK LinkedIn Group)

    Glad someone likes it! 😉 It’s perhaps because you haven’t got to the right point yet, To, but there is a methodology based on ISO 42010. It’s quite simple – the task holder has a set of concerns and (because each viewpoint addresses concerns) you select the appropriate viewpoints to create the views needed. Beyond this is some additional considerations for consistency and keeping a design record which are outlined in the “Bye Laws” and Minimum View Sets.

    The trouble with TOGAF is that is it a rolled up process and hence using it everyone could legitimately have their own metamodel. Since we want to maximise the chances of being able to re-use/share models (recognising that framework definition is only part of the problem) we needed a fixed metamodel that everyone uses.

    In terms of documentation this is an experiment – as indeed a lot of it is. I separated the Viewpoints (which in ISO 42010 terms are specifications for an architectural view) from the metamodel to allow for the possibility of re-use of the metamodel with a different set of viewpoints. Both are logical definitions i.e. not defined in terms of any notation like UML, BPMN or whatML. Again this is to allow for the possibility that an implementation is wrong and it also means that any implementation can’t drive the definition of the framework itself.

    I’ve tried hard to specify each viewpoint’s contents in terms of tuples – those which must be shown and those which can be shown (usually to provide additional context or overlapping content to help people navigate between views). We also mandate colour to give readers a clue of where they are and also mandate that each relationship has a text label as not everyone is a UML etc expert. What we are trying to achieve is to use the metamodel as a controlled and explicit language – the tuple sets form sentences which can simply be read. Specifying this way also ought to make it easier to form rules and, I hope, make it easier for someone (help please!) to translate the metamodel etc into something like OWL.

    I’d encourage anyone/everyone, if they feel like helping improve things, to sign up on the sourceforge sites. It is deliberately open source to keep the thinking in the open and to allow the maximum number of people to interact and help. We don’t have a monopoly on good ideas and this thing is supposed to be user- rather than specifier-centric.

    I’d also encourage folks to look at the site. This doesn’t just cover TRAK – it also covers DODAF, MODAF, DNDAF and NAF as many of us flip between frameworks and a lot of problems are unique or indeed to do with the framework itself – they’re modelling ones. I’ve set it up so that any site member can contribute an article, a wiki entry etc. As an experiment I’ve also set up a model registry to allow folks to characterise a model that is stored in the open elsewhere on the internet e.g. in a sourceforge or google repository.

    For completeness of record TRAK was created for London Underground Limited and co-conspirator/ally there was Colin Wood. It took a lot of people and a lot of effort to get it out of the door as open source. I hope this was worth it.

  2. Sorry. Just noticed the ‘update’


    I don’t know where Phillip Allega gets his information from but it’s complete nonsense. The UK Department for Transport have taken TRAK under their wing as a enabler for a major systems engineering push.

    At the end of July we had our first Steering Group meeting chaired by the DfT. We’re only just starting out and are set to grow.

    If you look at the likes of Atego (used to be Artisan) you’ll see that they are behind TRAK. Soon we also hope to have a template for MooD. If anyone else has a tool of choice and would like to throw in some help getting an implementation just head over to Sourceforge and make yourself known.

    Please warm up a red hot poker and apply it to Mr Allega’s soft parts … absolutely no basis in fact. I’d like to see the source from which he gets this information as this just seems to be mischevious.

  3. .. and the reason TRAK isn’t IT-centric is that Colin and I are systems engineers. It’s system-centric and there are things like physical dependencies, membership, standards precedence etc that we need in the real world. It’s very much lead by demand from the project floor (not pushed down).

  4. Nic, et. al. –

    “The reports of my death are greatly exaggerated” – an imprecise quote by Mark Twain

    “I’m not dead yet”: Monty Python and the Holy Grail.

    I apologize, whole-heartedly, for any confusion. Unfortunately, it appears that I have misconstrued or misunderstood well-meaning suggestions from some within various departments about the use of TRAK.

    Indeed, it’s a “framework” that I have on my very unofficial list of frameworks/approaches I am tracking.

    I am very pleased to hear of its use, and very interested in its support of MooD.

    My soft parts are appropriately red, as is my face. I do not believe that my source is mischievous, but perhaps just not using TRAK even if they happen to be within the TfL family.

    Please feel free to contact me directly at

    Again, I apologize if I’ve been informed of the demise of TRAK incorrectly and am happy to see its continued use and support.



  5. Hi Nic – many thanks indeed for the clarifications and additional info.

    There’ve been quite a lot of people responding and reTweeting on Twitter, so with luck we’ll get the word out more about TRAK.

    I still haven’t had a chance as yet to go into the documentation in depth, but it’s obviously something I need to do urgently. At the very least, it’s clear there’s a lot to talk about.

    A few quick comments from the above:

    – You’ve described what sounds like a methodology for deriving views, yet to me that’s only a small part of the architecture process. There’s all the work (and rigour/discipline) in comparing as-was / as-is / to-be, deriving options, dealing with bottom-up real-world constraints, assisting in implementation-time trade-offs and so on. Then there’s all the often-undocumented processes around building a common glossary and thesaurus (the latter required because there are always ‘alternate terms’ in use in real-world contexts), the creation and maintenance of ‘strategic conversation’ across the enterprise, and the sheer mess of dealing with multiple changes happening simultaneously at multiple levels on multiple timescales. The TOGAF ADM does actually describe that side of it very well, as long as you ignore its absurd IT-centrism (hence my rewrite of the ADM for whole-enterprise use). Kevin Smith’s PEAF is probably even closer, though it’s not yet as well known. Seems to me that some careful thought could usefully bring these method-sets together.

    – The TRAK metamodel covers the top layer for whole-of-enterprise really well: from a first perusal at least, it does seem to fill in all of the items that are so obviously missing in the TOGAF and Archimate metamodels, and that make the latter two almost unusable for whole-enterprise use. Seems to me there’s an urgent need to get you guys, some of the MoDAF/NAF guys, the TOGAF metamodel crew and especially the Archimate metamodel crew together, so that we can start to get a common core-metamodel defined. It shouldn’t be hard: you’ve done all the core work already. (The only part that I can see will be tricky is getting to a single term for each core object, and the simple way round that one is to allow thesaurus-definitions.) There are quite a few folk around the Archimate space who can help with OWL etc – or there’s the Essential project, who use OWL/RDF metamodels in Protege as their architecture-toolset.

    – What we all need, urgently, is some kind of common file-sharing/model-sharing standard so that we can exchange architecture models between different toolsets. Open Group were working on a proposed standard (XAML?) some while back, but it’s been dormant for years: we need to get it revived. I know that some of the toolset-vendors will be unhappy about this, because it encourages escape from lock-in, but too bad, frankly – we need it. And no vendor as yet covers the whole toolset-ecosystem, from whole-enterprise repository right down to handheld, so their current lock-in also locks us in to a subset of the toolset-ecosystem (usually only one layer of it, in fact), and actually makes it much much harder to do our job.

    Would also like to talk with you somewhen about what I’ve been doing with the Enterprise Canvas concept and the ‘single-row modified-Zachman’, and also the crosslinks, for example, to Nigel Green’s work on VPEC-T or my own work on effectiveness and the like.

    And would also very much like to talk about whole-enterprise architectures in an engineering context, and other ways to break out of the stranglehold of IT-centrism.

    As I say, much to talk about! 🙂 – hence many thanks again.

  6. Hi, Tom – you need to be careful about ‘process’ and also where things fit together. The (indeed ‘a’) framework definition is part of ‘the whole’ and therefore there are some things that make sense to be defined within the framework itself and some that sit outside. When putting together TRAK I took the view that “wikitecture glueware” which involves the processes for exchange, centralised definition etc it a separate part. I call the whole “The TRAK Enterprise” (not wishing to get into debate about the E word but I couldn’t think of a better term). The article at albeit that we’ve changed the view number. This is also why I’ve implemented a model registry to make discovery, exchange and re-use easier.

    Anyway the view referred to (The TRAK Enterprise) should provide confidence that we’re not just thinking about one part. Even though we only have direct control over the definition we understand well the interactions. For example if we make the definition hard to use or we’re not clear in the scope of each view or we offer too much choice of representation then it’s likely either that folks will cheat/bend the rules or use different stereotypes the net result of which is incompatibility. Equally the tool vendors might step in if they feel more rigour is needed and essentially create definition within the toolsets. All of this has happened e.g. the adoption of the UPDM (which adds constraints/artefacts from UML that aren’t in the framework definitions). This isn’t all bad but the limitations and the sources of them needs to be clearly stated so that the user can understand what is a problem with the definition, what is a problem with an exchange standard and what is a problem with a particular tool.

    The whole point of TRAK, MODAF and the fixed metamodel AFs is to try and make it easier to exchange models.

    Yes, I’ve had contact with the Essential Project but it still comes down to getting a small (2/3 max) group to do the work – this is the idea of Working Groups. In TRAK (and IETF terms) these are the guys/gals that pose problems/possible solutions, form a WG and get stuck in. The SG co-ordinates and make sure the proposed work fits in with the strategy.

    One of the major advantages we have being open source is a small ‘management’ overhead. We can (and do) make small changes and are able to release often and the ability to interact directly makes it a much more responsive way of managing and developing. I’m also not keen on tying ourselves rigidly to anything whether a solution or another standard – this has been a major problem I believe for MODAF et al wrt DODAF. Mappings are OK, hence the OWL possibility.

  7. Philip Allega :

    I do not believe that my source is mischievous, but perhaps just not using TRAK even if they happen to be within the TfL family.
    Please feel free to contact me directly at
    Again, I apologize if I’ve been informed of the demise of TRAK incorrectly and am happy to see its continued use and support.

    TfL is a big company. Even within London Underground TRAK was/is used on the Sub Surface Upgrade Programme (the largest) and on an upgrade for the Central Line. With the best will in the world there’s only so much you can do from within and even SE isn’t fully accepted everywhere let alone EA. With the DfT behind it there might be some “encouragement” as the DfT are mightily fed up with end up as the defacto System/Integration Authority and picking up the can for any failures therein, hence the push for SE and, as part of this, TRAK.

    The DfT have much better pokers than any I might muster … and they can put them where it really hurts …;-)

  8. Nic,

    That is helpful. Yes, TfL is very large. I have had the pleasure of spending a lot of time at TfL over many years, with only a little time at LU. My wife used to work right down the street from St James’s Park and I had some friends that worked upstairs there as well (since retired).

    If I could be so general for a moment, it appears that TRAK is in use by operations/engineering programmes and not (perhaps) by the ICT types of folks I have typically spoken with over the years.

    That is, as far as I can tell, the source of my confusion: it’s lack of widespread use, but its usefulness for specific programmes. In an inquiry I had with two ICT EA leaders within a department of TfL, I was told that TRAK was “retired”. I shared that information with Tom who quoted me here.

    All that said, I am truly pleased to see this in use in what Gartner would term “the operations side” of the organisation. And, I do appreciate the clarification. It’s very helpful and, indeed, instructive that, in an organisation as large as TfL, one perspective does not speak for the organisation writ large.

    As I wipe the last vestiges of egg from my face, I do appreciate the opportunity to be corrected and learn more about how TRAK is applied at TfL. Thanks, Nic, and Tom.


  9. Philip: “As I wipe the last vestiges of egg from my face…” – to put it at its simplest, y’ain’t the first, and ya sure ain’t gonna be the last… 😐

    It was only a minor ‘mistake’ anyway, but in case it might make you to feel better about it, note that I screwed-up a lot worse than this, only a couple of weeks or so ago: see my post ‘How to screw up in one easy lesson…’ and a later follow-on post, ‘Intimations of hubris’. Mea culpa etiam… oh well! 🙁 🙂

  10. Yes, it arose from the depths .. what some of us call “engineering”. I realise it’s a dirty word and I should crawl back into the dark but TRAK is very much something that arose from the pragmatic needs of those on the floor plate – Colin and I were having to deliver other tasks for the ongoing development whilst doing the TRAK definition. It therefore has been developed to meet the needs we had.

    We’ve also gone to a lot of trouble to make the “user interface” or the “user experience” as good as we can – possibly not something you hear of other frameworks. It might be trite or obvious but if we can get the UI (to the bigger thing) sorted then this will ease learning and make it more likely the right things are produced and are consistent. This affects all sorts of things from the number of views (by far the smallest of the lot – see ) to the names of the views (short, based around the primary stereotype) to the presentation of the metamodel (no clever notation, just read), the colours … In short if we get the UI right the rest will probably sort itself out.

    The key to keeping it simple and consistent is keeping it small. Too many views and too much overlap and the framework has no real affordance – it becomes hard knowing which view to use. The bigger it gets the more patches and corrective stuff you have to apply. One of the big problems with architecture frameworks is that they never get smaller with time. Even from my attempts at software I know that after a number of patches you can lose sight of the structure and you then have to take it apart and rebuild from scratch. This never seems to happen with AFs and you end up with large caddis fly-like things.

    There is probably a difference in emphasis compared with you IS/IT guys and EA specialists. With TRAK we don’t aim to create a model of the world (or the enterprise) that is complete – we aim to provide views that answer simple questions for a particular problem. Of course we’re interested in exchange as we’d like to re-use and share models rather than starting off from scratch each time. I’m not saying that you can’t or won’t build up a picture of the world but that’s an outcome rather than the prime objective. It’s for day to day engineering development and stopping surprises when the product hits the street. It just happens that it makes sense to put the enterprise etc around it in order to help those in solution-land understand what they’re doing by providing context. This way we hope to encourage people to look up and outwards rather than inwards and to see how they all contribute.

    This is also a difference wrt DODAF, even DODAF 2 where I think I’m correct is saying that the CADM (underlying data model) still exists and everything is about populating this. I suppose what I’m saying is that if we can address collaboration and re-use the rest will come. Hence my use of the term “wiki-tecture”.

  11. Thanks, Nic. That explanation was very helpful. I think that it’s very cool that it’s used by “engineering” (not a bad word, IMHO). I think it would be interesting to see how this could link up with a more “enterprise” perspective. Your penultimate paragraph is spot-on; now, if only we could get it all connected…

  12. Tom G :
    There’s all the work (and rigour/discipline) in comparing as-was / as-is / to-be, deriving options, dealing with bottom-up real-world constraints, assisting in implementation-time trade-offs and so on.

    Tom, there are a number of things here and, I suspect, again a difference in emphasis or possibly scope.

    The element of time in TRAK comes mostly via the Project Activity that introduces or removes System and hence affects the capability realised etc. Project Activity has a finish date so by using System in conjunction with Project Activity we know when something is added/removed by virtue of the solution(s). This is dealt with in the Procurement Perspective.

    As Enterprise has attributes for time and has Capabilities that are required to support Enterprise Goals you can then compare required capability vs realised through solutions.

    In the sorts of work we do there is no single project and indeed no single enterprise or single solution. Each repository contains a multitude of these which consist of in-house design but also a lot of externally provided systems/solutions and representations of external organisations e.g. government, other commercial companies, standards etc. Everything beyond your local project is always “the residual world” be it in house or outside. No one single organisation can model this which is where we come back to having to facilitate sharing – hence the need for an interchange standard which is what TRAK is in a sense. This was also the case within the MoD. In my mind everyone contributes their bit – in house this might mean one part of the company owning the upper enterprise/strategic levels whilst PMs own the Procurement one and Engineering the Solution one (with quite a lot of overlap).

    The value is then in the repository in exploring the links established. I think here that there is a difference in focus between a tool that is good for software development/design and one that is good for EA (the latter tends to focus on relationships rather than objects).

    Constraints are easy. You can define a logical model to represent an implementation-free definition of what you require (Concept Perspective). Atomic requirements are captured using the Requirement stereotype and can be attached to anything – structure, function, interaction. Requirements attached to Concept stereotypes are in essence user requirements (URD in MoD speak). A body of requirements is represented by a Standard stereotype – any normative collection. A Contract applies a Standard (so that we have a date & issue at which the set is applied which can be different from the current issue). Standards can have all sorts of relationship/dependency e.g. ‘enacts’, ‘equivalent to’, ‘depends on’, ‘supersedes’, ‘has part’ etc so TRAK is quite rich in being able to show constraint and precedence.

    The same is also true in the Solution, the only difference being that Requirement, Standard are attached to stereotypes in the Solution Perspective.

    We have to bear in mind that it isn’t the job of the AD to manage requirements – there are better tools such as DOORS for this. There are often far too many requirements in such tools. We need just enough touching points to be pragmatic. Often several requirements will be attached to a single AD element e.g. a Function and in a sense they justify why the AD is structured as it is. In the reverse direction the AD suggests requirement document structure and top level requirements. Again I’d hope a significant outcome is either the AD being used in requirement documents to provide context or for different specialities to use the views to highlight, discuss, solve problems. It isn’t sensible to think that there should or could be enough detail to completely specify at the push of a button (or if it could it wouldn’t be humanly understandable or verifiable).

    The whole point is that is is just good enough – adequate rather than perfect. The big bonus for me is showing how things fit together (or not) – we have many ways of breaking down hierarchically but too few things that show integration (hence composite structure diagrams are the spawn of the devil in my books – not good for navigation and encourage the view that more detail = more complete).

  13. Nic Plum :

    Yes, it arose from the depths .. what some of us call “engineering”. I realise it’s a dirty word and I should crawl back into the dark but TRAK is very much something that arose from the pragmatic needs of those on the floor plate – Colin and I were having to deliver other tasks for the ongoing development whilst doing the TRAK definition. It therefore has been developed to meet the needs we had.

    Strongly agree with you there: this sounds very similar to what we went through with Australia Post (where again the need for the models arose primarily from the ‘mail network’ – i.e. trucks and depots and sorting-machines and manual processes and the like), and with Telstra (which likewise started from engineering rather than IT). In fact in both cases our main problem was to keep the IT-folks reined-in and to not assume that the world began and ended with IT… In one of those two examples we ended up taking over the ‘enterprise’-architecture unit and allowed most of them to return to a new IT-architecture unit where they could remain within their comfort-zone; in the other case the IT-centric ‘enterprise’-architecture unit pretty much imploded into increasingly-futile ‘analysis-paralysis’, spiralled into irrelevance, was disbanded, and was not replaced. In both cases we ended up using the term ‘Business Transformation’ to hide the fact that what we were really doing was a true whole-of-enterprise architecture.

    Nic Plum :

    Tom G :
    There’s all the work (and rigour/discipline) in comparing as-was / as-is / to-be, deriving options, dealing with bottom-up real-world constraints, assisting in implementation-time trade-offs and so on.

    Tom, there are a number of things here and, I suspect, again a difference in emphasis or possibly scope.

    I fear we may be talking somewhat at cross-purposes here: I’m talking about the actual process used to develop the architecture itself – in other words, the equivalent of the TOGAF ADM – whereas you seem to be talking about how process is described within the TRAK metamodel/model, which is not the same. Creating views is only a small part of the architecture-process: there’s a vast amount of one-on-one or small-group discussions and the like with the various stakeholders and change-managers and project-developers and so on, all of which – for governance purposes, if nothing else – need to be understood and tracked as part of the architecture-process. But never mind, I think it’s fairly clear from your description what the practical process will be.

    Again, strongly agree about ‘just-enough’ for modelling of views and requirements etc. There are time when we do need to go right down into Zachman’s ‘excruciating detail’, but it’s usually better if that fine-detail is held in some other toolset that’s more explicitly built for the purpose (such as DOORS, as you say, or the UML tools or process-modelling tools. What we do need to be able to do in the architecture-tools and/or models, is maintain a link or reference to those more-detailed models in the other toolsets – which is where wiki-type cross-reference protocols become really useful.

    Another metaphor I use a lot is the comparison between photograph and holograph. If we cut up a photograph, we end up with a kind of jigsaw puzzle of very small pieces, each in very fine detail, but with nothing to link them together. If we add more detail in one place, it only applies and adds richness to that one place – it doesn’t help us much to make sense of anywhere else. But if we cut up a holograph, every one of those tiny fragments contains a picture of the whole – but in less detail. Each time we add a bit more detail in one place, it adds to the richness of every other view. The conventional metamodels and toolsets – such as Zachman, and the ‘EA’ toolsets that were derived from software-development tools – all emphasise a ‘photograph’-type concept: a swathe of fragmentary views, each of varying granularity, layering and depth of detail, yet with nothing much that would link them together. The upcoming generation of metamodels and tools, fortunately, seem to be much more oriented towards connection – such as the Archimate metamodel, for example, or what you’ve been doing here.

    What we really need, as you say, is something that will help us navigate around the holograph, and orient ourselves within it, whilst always helping us to make sense of the integration across the layers and intersections and interdependencies of systems. That’s why I really like what I’ve seen so far of TRAK. 🙂

    I still haven’t yet had a chance to burrow deep into the TRAK documentation and wiki – but am very much looking forward to doing so, and would certainly like to keep in touch with you on that.

Leave a Reply

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