The Open Group’s July Conference in Austin, Texas – “The ArchiMate® Exchange Format in Use”

I just got back to the UK from five days networking and presenting at The Open Group’s summer conference in Austin, Texas. It was a hot one – hot weather, hot food, and hot conversations. On Monday I gave a 45-minute talk entitled, “Making Standards Work – The ArchiMate Exchange Format in Use” and on Tuesday I was a member of the open panel discussing Open Standards, Open Source, and the concept of “Executable Standards”. More of the latter in another blog post, for this one I want to summarise my talk about the ArchiMate Exchange Format.

The main themes of the July conference were “Making Standards Work” and “Open Standards and Open Source”. The key message and theme of the conference was this:

We should be taking advantage of [Open Standards and Open Source] to support infrastructures that can enable the kind of Boundaryless Information Flow™ today’s digital enterprises need.

This event will focus on how organizations can use openness as an advantage and how the use of both open standards and open source can help enterprises support their digital business strategies.

When I first read this I knew what I needed to say in relation to ArchiMate and the ArchiMate Exchange Format. I took the words “open” and “boundaryless” as my two main riffs and spoke about how the exchange format has opened up the boundaries between tools and ArchiMate users.


The big question posed by this conference was “What does it mean to be open?” Indeed. Well, let’s see what we have:

  • Open Source
  • Open Standards
  • The Open Group
  • Open – “Allowing access. Not closed or blocked.”

My job was to try and partly answer the more particular question – “What does it mean to be open in relation to ArchiMate?” Sure, ArchiMate is an Open Standard to a large degree, and there are those who might argue that more needs to be done in this area but, in my talk, I tried to show that the ArchiMate Exchange Format really has moved things on toward this “Boundaryless Information Flow”.

Having an Open Standard is the first thing that’s needed. When that happens, you can build interoperable tools. But tools need to make sure that they work together via that Open Standard. Consider web browsers and the old “browser wars”:

They're Great Browsers

Indeed, they’re all great tools…

Browsers Need Open StandardsIt’s the same in the ArchiMate world. There are some great ArchiMate modelling tools, but they need open standards in order to work. But here’s the thing – an open standard is not going to be interoperable unless there is an interoperable data format. Web browsers use HTML as their main interoperable language. In terms of interoperability, ArchiMate, up until recently, only existed on paper – a “paper tiger” as someone called it at the conference. Unless it is “executable” in terms of interoperability you’re just going to strengthen the silos in the tools world. This is not what we want.

Go back a couple of years. We find a variety of tools and services supporting the ArchiMate language; some are proprietary, some are open source, but all of these tools are storing their data in different formats, including Archi. Nothing wrong with that…

…unless you’re the customer.

Clearly, if you value your users and customers you need to satisfy the following:

  • The possibility to use more than one ArchiMate toolset or provide options
  • The certainty that one’s data will be accessible now and in the future
  • Ensure one can access one’s data at all times without vendor lock-in
  • Recognise that an open standard should support an open data format

This is where The Open Group’s ArchiMate Exchange Format fits in.

The ArchiMate Exchange Format

The ArchiMate Exchange Format (AEF) project got started in late 2012 and included contributors from major ArchiMate tools vendors (including myself representing Archi) and other experts. Over the following few years, many discussions and technical meetings were held to solve the various issues that arose. Some commentators felt that it was an impossible task, pointing to the problems in the UML and XMI world. My own take on this was that we needed to focus on providing a pragmatic solution and that we should try to remember what the great musician and guitarist, Robert Fripp, once said:

We begin with the possible, and move gradually towards the impossible

After a couple of false starts, the project made great headway during late 2014 and through most of the following year resulting in version 1.0 which was released in August 2015.

Essentially, the AEF is an XML data format that represents the core components of an ArchiMate model. It acts as a container for conveying the following things:

  • Elements
  • Relationships
  • Properties
  • Organizations (structure)
  • Metadata
  • Diagrams

Here’s an XML snippet:

austin2016 xml

AEF XML Snippet

The project’s statement of purpose made clear what the AEF is not:

  • It is not the definitive representation (binding) of the ArchiMate language
  • It is not a declaration of the ArchiMate metamodel (XMI)
  • It is not intended to make demands that are not in the language
  • It is not trying to change the language from outside in

And also what the AEF is:

  • A pragmatic approach to exchanging ArchiMate models between tools
  • Flexible
  • Optional
  • Accessible
  • Straightforward to implement

In my presentation at Austin I gave a brief summary of the previous topics and then went on to ask the following question:

So, does it work?

To address that question I told two stories where we can see the AEF in use. The first story concerns the European Interoperability Reference Architecture.

The ArchiMate Exchange Format in Action – The European Interoperability Reference Architecture

The European Interoperability Reference Architecture (EIRA) is a reference architecture designed to guide public administrations in their work to provide interoperable European public services to businesses and citizens.

Here are the key phrases that you can find in their mission statement (emphasis is mine):

  • “The need for interoperability in Europe is higher than ever”
  • Building an “interoperable Europe”
  • Interoperable Software”
  • “Agree on the language and the format to use to exchange information

Sounds good. The project has chosen to use ArchiMate to model their architecture. Here’s a high level overview of the EIRA:

EIRA High Level Overview

EIRA High Level Overview

Archi has been used to create the ArchiMate models, diagrams and reports. It’s clear that they’re using an Open Standard together with an Open Source tool. As the Archi Product Manager I think this is great to hear but, as I pointed out in my presentation at Austin, this might not be enough.

Back in July 2015 John Gøtze reviewed and analysed the EIRA project for a Qualiware blog post. I think it’s a balanced and constructive piece. Further on in the review, John Gøtze makes this point:

The EIRA model is available as an Archi file. The data is also available in Archi-produced HTML and images.

From a maturity standpoint, this is only just acceptable. Even an Excel sheet version would be better, but better would be “raw data” available in a range of formats, possible as an api.

John’s point is important, and I agree with him. As I said in my talk in Austin, even an Archi file is “proprietary”. That’s right folks, “Archi Inc.” is a tools vendor just like the others, the only difference is that Archi is free and open source. As with the other tools, the data that Archi produces is not standardised.

Remember, this piece was written in July 2015. John goes on to note:

Of course, The Open Group is working on an ArchiMate Model Exchange File Format, and has sponsored the development of an Archi plugin for exporting to that format.

One month later, in August 2015, The Open Group released version 1.0 of the ArchiMate Exchange Format, with initial implementations coming from Archi (sponsored, as John notes, by The Open Group), Corso, and BiZZdesign.

Going back to the EIRA project website at this point in time we see this:

EIRA Website

EIRA Website

Here we can see that the ArchiMate model is available as an AEF file. Hopefully, this goes some way towards addressing John’s concern. But, for me, this may not go far enough, as we shall see.

You can see from the screenshot of the website that the EIRA project now has the ArchiMate model available as an AEF file. So, we have an open European project using an Open Source tool, Archi, with an Open Standard, ArchiMate, delivering an Open data format file. However, some of the other EIRA artefacts (the report and model diagrams) are still produced using a tool, in this case, Archi. So there’s still a dependency on a tool to generate the reports and diagrams.

Here’s the important part. The AEF is an open data format represented in a standalone XML file, validated by an XSD Schema, and hosted and maintained by The Open Group. It has now become an accepted standard (albeit in its early stages) that is fast being recognised as a key part of the whole ArchiMate project. Now, an ArchiMate model can exist outside of any given tool. Think about that. That’s an obvious thing, right? Obvious, yes. Simple, yes. And also profound.

The ArchiMate Exchange Format in Action – The Thorbjørn Story Arc

Here’s the second story I told in Austin. I call it “The Thorbjørn Story”. Actually, it’s a story arc that starts with Thorbjørn and looks set to run for a quite a few more episodes.

Thorbjørn Ellefsen is a cyber security expert who, back in 2015, was working for Difi, the Agency for Public Management and eGovernment in Norway. Thorbjørn is currently working for Capgemini and is a great advocate for Open Source, and has been using Archi and ArchiMate in his work, and sharing some of his ideas via GitHub. Actually, Thorbjørn spoke about all of this at The Open Group conference in London in April this year.

Some time in 2015, Thorbjørn highlighted the potential of using XSLT (Extensible Stylesheet Language Transformations) to work directly with an AEF file. As I said in a previous blog post, XSLT is a language for transforming XML documents into other documents or other formats such as HTML, plain text or PDF, and because an AEF file is in a straightforward XML format this is entirely possible. Thorbjørn did some initial experiments with XSLT and the AEF XML files and generated a basic HTML report displaying all of the concepts in an ArchiMate model. I was inspired by Thorbjørn’s work and took things a little further and managed to generate basic ArchiMate diagrams in SVG format. You can read about all of this in my blog post.

Here’s the key conclusion that I came to in that blog post:

But for me the important thing is that this clearly demonstrates that by using existing technologies based on XML, XSLT, HTML, and CSS one doesn’t have to resort to a proprietary tool in order to display and share that data. Both the data and the representations of that data can exist in an open, standalone format.

For me this is simple yet profound.

I also suggested that it should be possible to run with the ball even further, by using XSLT to generate full diagrams and representations of ArchiMate data in new and unexpected ways.

Guido Janssen

The next character in this story is Guido Janssen. Guido works as Lead Architect with PharmaPartners in the Netherlands. He contacted me earlier this year to say that he had indeed picked up the ball and was generating better SVG diagrams and adding additional functionality. Here’s a screenshot of how far he’s got:

Guido's SVG from XSLT

Guido’s SVG from XSLT

Remember, all of this is generated from the original XML file in the ArchiMate Exchange Format, and then transformed by the XSLT to produce the output in HTML and SVG format. The diagram is rendered by SVG that’s taken from the source XML file. It’s a standalone process that you can do from the command line using open and standardised tools.

If you’re interested in following Guido’s great work he’s put the code on GitHub.

The Cathedral and the Bazaar

When addressing the big question, “What does it mean to be open?” I’m reminded of Wittgenstein when he said, “the meaning of a word is its use”. And the meaning of something like the ArchiMate Exchange Format is its use. Put another way, it’s as Eric S. Raymond proposed in his great essay, The Cathedral and the Bazaar:

Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.

The “tool” in our case is the ArchiMate Exchange Format. The “expected way” is that the AEF allows ArchiMate models to be usefully exchanged between software implementations. And the unexpected uses are just beginning to appear. I never expected the uses that I just described. And I never expected the next part of the story.

Synchronicity is a thing. This happens when the time is right and a notion occurs more than once crystalizing in a magical moment. With regard to the AEF this happened very recently with three occurrences of using the AEF data as a feed for graph databases (actually there may be a fourth occurrence, but I can’t find the reference on Twitter right now.)

Graph Databases

What’s a graph database? I’m no expert on the matter, even though I have a nascent interest in the subject, so I’ll let Wikipedia explain:

In computing, a graph database is a database that uses graph structures for semantic queries with nodes, edges and properties to represent and store data. A key concept of the system is the graph (or edge or relationship), which directly relates data items in the store. The relationships allow data in the store to be linked together directly, and in most cases retrieved with a single operation.

Now, clearly an ArchiMate model holds exactly this type of raw data with its nodes, edges and properties. Except that it doesn’t – if we can’t get at that raw data. Enter once again the ArchiMate Exchange Format.

Take a look at this post in the Archi User Forum. Poster “” (presumably from Brazil) tells us what they used in the process:

  • Archi (with OpenExchangeFile plugin)
  • OrientDB (Graph and Document Database –
  • Java language

And what they did:

  1. Generated Java classes from OpenExchangeFile XSD (using JAXB)
  2. Exported .archimate file to OpenExchangeFile format (XML)
  3. Created a program in Java that imports the generated XML file and exports it to OrientDB

They took this:

ArchiMate Process

ArchiMate Process

And got this:

OrientDB Result

Now look at the next post in that same Archi User Forum thread. Here, Thomas Michem gives us a link to a blog post where he describes some similar work that he’s been doing with ArchiMate and graph databases. Here’s a summary:

At our recent Information Architecture event, we highlighted the important role of Information Modelling. One important aspect we emphasized was network or relation modelling. An upcoming trend is the usage of graph models. In this blogpost we will apply graph modelling to the Archimate modelling language. Archimate is used in Enterprise Architecture to model architectural elements (business processes, data objects, applications, etc) and the relations beween them. The classic way to explore an Archimate model is to create diagrams that show a specific perspective (‘viewpoint’). In this blogpost we show you how an Archimate model can be explored and queried as a graph.

In his blog post, Thomas walks us through the process that he used. He did the initial modelling in Archi, exported the model using the AEF and then used XSLT to get the data into another XML format, GraphML. Using Neo4J the ArchiMate model can then be queried as graph data.

It’s a great blog post and I don’t want to spoil the show, so I recommend you go and read it. To give you an idea of how cool all of this is, I’ll just leave this here:

Archi & Neo4J

Archi & Neo4J


Talking of cool, I met a couple of interesting guys at the Austin conference, Ben Truitt and Mark Morga, both working for Rackspace in Texas.

I spent a lot of quality time talking to Ben and Mark and they showed me some really cool things that they have recently been doing with Archi, graph databases and Cayley, an open source graph. The conversations that Ben, Mark, and I had (together with Ed Roberts of Elparazim) showed me that, once again, open initiatives such as Archi and the AEF really do open doors to innovation. Hopefully, we can continue working together in the coming months.

So, what happened? What next?

I’ve tried to describe here the key points that I made at the conference in Austin and I’ve tried to address the question, “what does it mean to be open?” in the context of ArchiMate, Open Source, Archi, and the ArchiMate Exchange Format. I said earlier that this is part of a bigger story arc, and that this is really the start of opening up the standard to a wider audience and opening the door to innovation. I’ve given a few examples of how a seemingly simple thing can lead to innovation in unexpected ways, and how the AEF is turning out to be more than the sum of its parts.

What’s interesting, for me at least, is not so much the AEF in itself but what arises out of this “bold endeavour”:

  • Conversations and sharing of ideas
  • Development of new ideas and technologies
  • Innovation
  • “Boundaryless Information Flow”

This is just the start of what’s possible and there’s more to do. We need to keep improving the exchange format, and come up with a new version that supports ArchiMate version 3.0. Also, ArchiMate tools may be required to implement the AEF in the future as part of The Open Group’s ArchiMate tools conformance process.

I’m upbeat about the whole thing, as are most of the people I talked to at the conference in Austin. The AEF provides a level playing field, solves the problem of interoperability and, I think, provides the missing piece of the puzzle for an open standard. And when I say “level playing field” I include Archi in that because, with the AEF, no particular tool is required to access, view and analyse the ArchiMate data, open source or otherwise. Using the AEF means that your data is open and standalone.

For me, all of this is exciting stuff. We began with what was possible, and by working together, we now find ourselves creating things that really do enable a “Boundaryless Information Flow”.

(Many thanks to Andrew Josey and the team at The Open Group for inviting me to the conference and sponsoring my visit)


Sharing ArchiMate Models

Are you sharing your ArchiMate models and design patterns with the rest of the ArchiMate modelling community? Or are you hiding them in company silos? What are good and useful examples of ArchiMate models currently in circulation? How does one start with the ArchiMate language as a beginner?

Interesting questions. I often get emails from newcomers to the language asking for examples of ArchiMate models, or snippets of models, to repurpose as design patterns of best practice for learning and training, or to use as a starting point in real-world modelling scenarios. What currently exists in the public domain? Well, there are some excellent and helpful blogs and books with examples of ArchiMate modelling patterns, and there’s always the old favourite, Archisurance (which is probably getting a bit long in the tooth now), and maybe some I’ve missed, but I can’t find a whole lot out there.

Wouldn’t it be great to have a place to share ArchiMate models and parts of models, say, in a public repository? And even better if this repository was searchable by keywords and properties, and maybe even showing a thumbnail preview of the diagrams in the model? And perhaps also supporting user ratings and comments? And, of course, the model files should be in The Open Group’s ArchiMate Exchange Format, so one could open them in any ArchiMate tool.

Well, I did take a stab at this some time ago by creating a public GitHub repository for just this purpose:

ArchiMate Models at GitHub

ArchiMate Models at GitHub


As you can see, there are only three models there at the moment (and, yes, I included that old chestnut, “Archisurance”), and GitHub doesn’t really support user ratings or comments, but maybe it’s better than nothing, and of course Git and GitHub does support versioning.

Would you like to share and upload ArchiMate models? If you’d like write access to the GitHub repository, contact us. I’m not asking you to share your company secrets by posting confidential model data, but rather to share basic model patterns, anonymised models, or even processes taken from domestic life (feeding the cat was a popular modelling exercise).

GitHub might not be the best place to share ArchiMate models, but it’s a start and, who knows, maybe one day we might have a public “ArchiMateHub” available tuned to this specific task?

Let’s help each other out 🙂


Archi Update – A Midsummer Night’s Dream

Slightly belated Summer Solstice Greetings! It’s time to provide an update on the latest events and progress from Archi world. These are interesting times we live in, and it’s an interesting time of the year. Hence the title of this update – referring of course to Shakespeare’s play dealing with the themes of confusion, trickery, and dreams. And hopefully, as in the play, after a night of foolery and ambiguity, it all works out in the end.

Archi 3.3.2

I released a maintenance release of Archi, version 3.3.2, at the beginning of June. This contained a few bug fixes and some new features for the Visualiser and HTML reports. Both contributions were provided by Jean-Baptiste Sarrodie, now working for Arismore in Paris, who has over the years proved to be an absolutely amazing supporter for me personally, and tireless evangelist for Archi. As we move forward, J-B’s vision and involvement in the project will prove to be more vital. It was a pleasure to finally meet J-B in London at The Open Group’s event earlier this year.

There was quite a gap between the previous release, version 3.3.1 in October 2015, and 3.3.2 released this month, and the reason for this was to allow the dust to settle on last year’s release of The Open Group’s ArchiMate Exchange Format, and to wait for the official release of ArchiMate 3.0.

ArchiMate 3.0

The latest version of ArchiMate was officially released on June 14th. This is a significant development, as we shall see. I won’t go into all the details of what’s new and what’s changed but it’s as if a new broom has come in and swept up all the bad stuff, and re-arranged all the furniture at the same time, hopefully for the better. There are new concepts, such as Capability, Resource, Course of Action, a new Physical layer, relationships to relationships, and a whole lot more. This is a major update to the language. There’s a summary of what’s new here.

Archi, ArchiMate 3.0 and the future

Archi does not currently support ArchiMate 3.0, only version 2.1. I’m now seeing the same question being asked repeatedly on Twitter, in forums, in webinars, in emails, and in person – “When will Archi support ArchiMate 3.0?”.

As I type this, I’ve stopped to consider my response to this burning issue. There are a number of possible responses and I’m not sure which one to choose. Should I mention the significant amount of work involved in this? Should I ask where I might find the time for such a non-trivial task? Should I question whether I am prepared to work for several weeks, if not months, to single-handedly code, document, test, deploy and support a major new update to a piece of software used by hundreds (although it’s probably thousands) of professional enterprise architects. For free?

Let’s be clear about one thing – since it’s initial release in 2010, Archi has become an extremely popular tool in this domain, and many organisations (and some very major ones, too) use it and depend on it. Archi is downloaded on average about 3,000 times a month. Every month. Archi is a game changer and it is a major contributor, if not the major contributor, to the uptake of ArchiMate globally. This is a significant responsibility for one person. For free?

And let’s be clear about another thing – updating Archi to support ArchiMate 3.0 is not a trivial undertaking. It is not simply a matter of adding a few new concepts, compiling the code and then heading down the pub to celebrate. There are many factors to consider – a whole new refactoring of the code, backward compatibility, documentation, testing, asset management, build processes, and of course providing unpaid support. Typically, this process is managed by a team of employed developers, not one (unpaid) person. Some people have suggested that the work can be done in a weekend, or that their nephew has just learnt Java and will do it for a packet of chewing gum.

This has to change, and I have personally come to a crunch point. To be blunt, either I get funding to continue with Archi or I’ll do something else.

Having said that, there is hope. As Robert Fripp says:

In strange and uncertain times such as those we are living in, sometimes a reasonable person might despair. But hope is unreasonable and love is greater even than this. May we trust the inexpressible benevolence of the creative impulse.

Indeed, there is hope. But there are dark clouds, too.

Consider the overall strategy of promoting and supporting the ArchiMate language with an open source implementation and data format. A central plank in this strategy is The Open Group’s ArchiMate Exchange Format. This has proved to be a significant thing, with more and more tools supporting the format, and users discovering further uses for it and realising many benefits of an open data format.

However, the introduction of ArchiMate 3.0 means that a new version of the exchange format needs to be developed, and, indeed, this initiative is ongoing.

But this means that I will need to develop a new implementation of the exchange format in Archi. Archi currently supports the exchange format for ArchiMate 2.1. But, here’s the thing – Archi cannot implement and support a new version of the exchange format if it does not implement ArchiMate 3.0. Obviously, implementation of ArchiMate 3.0 is a pre-requisite for implementation of a new ArchiMate exchange format in Archi.

Furthermore, we need now to recognise that Archi has become an Enterprise in itself. Jean-Baptiste Sarrodie made the compelling case for this with reference to Tom Graves. To use Tom’s definition of an “Enterprise”, Archi has become

a bold endeavour; an emotive or motivational structure, bounded by shared-vision (purpose), shared-values and mutual commitments.

And, to me at least, it’s clear that Archi incorporates a powerful shared vision, and one held by many stakeholders. It is too important to fail.

As I said, there is hope. Hope lies in the fact that funding may have been secured from a benevolent source so that we can proceed with our bold endeavour. On the other hand, the dark clouds that I mentioned are manifesting as opposition to this funding from some not-so-benevolent quarters.

So, please, if you feel that you are part of this “bold endeavour”, speak up and assert your support for Archi. The future is open.

Phil Beauvoir, June 2016


The Archi Philosophy

Jean-Baptiste Sarrodie and I have been emailing back and forth for some time with some positive ideas and we now agree on what amounts to an “Archi Philosophy”, a set of principles that guide our future development of Archi and associated services. But these principles have already been written about in detail in the book, Rework, so all I can really do is talk about key points that relate to Archi and quote relevant passages from the book that resonate with us. I want to expand upon these principles and where we see Archi going (a.k.a the “roadmap”) in future blog posts, but, for now, regard Rework as our manual of truth and guiding light.

In this post I want to talk about open source and some of these guiding principles.

Archi’s code has a liberal open source licence, the MIT licence. It means that anyone can take the code and build a commercial product based on it. You can build a commercial product from the code, Microsoft can build a commercial product from the code, and your great aunt Edna can build a commercial product from the code. Heck, even I can build a commercial product from the code. So, what’s to stop somebody else from hijacking Archi and making something commercial from it? Actually, nothing. And, in fact, we want this liberal licence to stay in place because many organisations and developers have already built some interesting things based on Archi’s code, and they use it in a commercial setting. Also, the MIT licence is compatible with other licences.

Here’s a relevant passage from Rework that summarises our view:

Decommoditize your product

If you’re successful, people will try to copy what you do. It’s just a fact of life. But there’s a great way to protect yourself from copycats: Make you part of your product or service. Inject what’s unique about the way you think into what you sell. Decommoditize your product. Make it something no one else can offer.

Look at, a billion-dollar online shoe retailer. A pair of sneakers from Zappos is the same as a pair from Foot Locker or any other retailer. But Zappos sets itself apart by injecting CEO Tony Hsieh’s obsession with customer service into everything it does.

It’s unlikely that somebody would sell a product that has the exact same functionality as Archi using the code but, even if they did, here’s the thing:

Make you part of your product or service.

You see, Archi is a way of doing things and this is what sets it apart. So let’s list some of the guiding principles that make my and Jean-Baptiste’s philosophy part of the product:

  • There will always be a free and open source version of Archi
  • Archi is agile, intelligent and lightweight
  • We believe in elegant and simple design
  • We do not ask you for your contact details (but please get in touch!)
  • We believe in “open”, in open standards and in open source, and are therefore open and transparent in what we create
  • We want to build services based on trust
  • We believe in sharing
  • We want to create new ways of doing things
  • We want to make Archi and its services fun

So, if somebody does take the code and tries to sell another product based on Archi, then good luck to them because they ain’t us!

But let’s be perfectly clear about one thing. When we say that “there will always be a free and open source version of Archi” this does not mean that we will necessarily work for free or that we might not develop some paid-for services that would support Archi in the future. ArchiMate 3.0 will be released on June 14th and it’s important that Archi implements it, both for itself, for its thousands of users, and for the sake of The Open Group’s ArchiMate Exchange Format. This work is not trivial and will take a lot of effort, but unfortunately I cannot do this unpaid as I like to eat and pay bills. So we are now seeking sources of funding that would support this development. We are also thinking about how we can generate some form of income that would help sustain Archi for future support and features. Jean-Baptiste and I have some great ideas for Archi, but first we need to implement ArchiMate 3.0. Let’s work together in bringing you some great tools with the Archi Philosophy.

Image courtesy of Jean-Baptiste Sarrodie

Image courtesy of Jean-Baptiste Sarrodie



Archi, ArchiMate and Open Source

The Open Group recently published an interesting case study on their blog, ArchiMate, An Open Group Standard: Public Research Centre Henri Tudor and Centre Hospitalier de Luxembourg. In 2012, the Centre Hospitalier de Luxembourg allowed the Public Research Centre Henri Tudor to experiment with an access rights management system modeled using ArchiMate. According to the article, the Public Research Centre needed to find an architecture modelling language that met their stringent requirements for this project. After evaluating some modelling languages, they chose ArchiMate to help them visualize the relationships among the hospital’s employees. The Case Study is interesting in itself, but what struck a very loud and resonant chord with me was the following statement:

…the Public Research Centre also chose ArchiMate because it is an open and vendor-neutral modelling tool. As a publicly funded institution, it was important that the Public Research Centre avoided using vendor-specific tools that would lock them in to a potentially costly cycle of constant version upgrades.
“What was very interesting [about ArchiMate] was that it was an open and independent solution. This is very important for us. As a public company, it’s preferable not to use private solutions. This was something very important,” said Feltus.

In referring to “vendor-specific tools” versus “an open and independent solution” it is not clear whether Christophe Feltus is referring to ArchiMate the language itself as a “tool”, or whether he is referring to an open source ArchiMate software tool, perhaps Archi. My inclination is to infer the latter, particularly as he refers to “a potentially costly cycle of constant version upgrades” and also because some of the diagrams in this document look suspiciously like they were created using Archi:


However, the important thing here is that this is yet another example of public organisations and government bodies choosing to use open source software and open data formats to ensure open data interoperability and to avoid costly vendor lock-in.

Last year, the City of Munich rejected Microsoft’s Office and Windows software in favour of open source alternatives. Munich says the move to open source has saved it more than €10m. And very recently, the UK Government chose the Open Document Format, the OpenOffice-derived file format, as the best solution for all government documents. The Minister for the Cabinet Office, Francis Maude, said:

I want to see a greater range of software used, so people have access to the information they need and can get their work done without having to buy a particular proprietary brand.

And the same thing is now happening in Enterprise Architecture with the Open Group’s ArchiMate language and the open source ArchiMate modelling tool, Archi. Archi is used not just by individuals, it is used as a core tool by many large organisations – banks, telecoms companies, insurance companies, you name it. I was recently asked, “Which companies use Archi?” I replied that it would be better to ask “Which companies *don’t* use Archi?”. Archi is, to the chagrin of some EA tools vendors, annoyingly ubiquitous.

Having had several years experience working in the domain of open interoperability standards in the UK and in Higher Education, I welcome this move to open standards and open software. This brings me to the main point of this blog post…

For some time, The Open Group has been engaged in a project to design and implement an open and vendor-neutral interoperability file format for the exchange of ArchiMate data. I have been involved in this initiative since it began, and it pleases me greatly to see that good progress is being made.

This is important for organisations who are currently engaged in Enterprise Architecture and who use the ArchiMate language. Organisations will not have to concern themselves with the headache of migrating sensitive data to another free, or less expensive, tooling solution. Organisations can be assured that their data can be safely imported and interoperate with a variety of software solutions. As the Public Research Centre in the Open Group’s case study found, there are viable open alternatives to expensive and non-cross platform software. OSS Watch, the UK-based independent advisory service maintains a comparison matrix of open source options for education. But this list is not limited to the UK, or to education. Here is an example.

The take-home from this blog post is this – if you want to future-proof your processes and your data then ensure that your organisation uses open data together with open source solutions such as Archi.