Jun 262016
 26th June 2016  Posted by at 11:57 am 2 Responses »

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

Jun 052016
 5th June 2016  Posted by at 11:56 am Comments Off on 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 Zappos.com, 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


May 312016
 31st May 2016  Posted by at 2:49 pm Comments Off on Archi 3.3.2

We’ve just released Archi 3.3.2 which fixes a few bugs and add a Viewpoint and direction filter to the Visualiser, and also tag support for customisable reports. Thanks to Jean-Baptiste Sarrodie for the work on the reports and the Visualiser!

May 162016
 16th May 2016  Posted by at 7:48 pm Comments Off on Archi Spotlight – Archi Supports the Government of New Brunswick’s EA Program

In this Archi Spotlight, Peter Gee talks about how he introduced ArchiMate and Archi to the government of New Brunswick in Canada.

Peter, tell us a little about yourself and how this initiative came about.

Several years ago, the Office of the CIO for New Brunswick embarked on an Enterprise Architecture (EA) program. I was brought in as a consultant to help build a Business Architecture framework, which was considered to be an important foundational piece of the EA landscape. While working with them, I introduced ArchiMate as the recommended modeling notation. Since they had no “official” tool in place I also introduced them to Archi as a means to learn the language and start on the development of some Business Architecture models.

How do you find working with Archi?

Archi is very easy to install and much quicker to learn than most of the commercial tools I have worked with. It also had “just enough” functionality to support our modelling needs at the time. Archi’s CSV import/export functionality allowed us to quickly import model content from external sources as well as utilize an export-update-import approach to manage bulk updates to the model. Its support for the Open Group’s ArchiMate Model Exchange File format further guarantees the portability of model files and mitigates the risk of vendor lock-in. Its sole limitation is that it does not support external image files in a diagram.

What is the nature of the project?

The key deliverables for the project included a Business Capability Map which was developed as a hierarchical, nested diagram based on a set of ArchiMate “business function” elements. Since ArchiMate 2.1 does not include a “capability” element, we followed the prevailing practise of using the “business function” element for this purpose. We also used the Jasper Reports module included with Archi to generate a supporting Business Capability Reference document which contained the capability descriptions, as well as other supporting information.

New Brunswick is officially bilingual (English/French) so we were required to publish these deliverables in both official languages. You can view the resulting deliverables in the following links:

English Capability Map / English Capability Reference www.gnb.ca/OCIO
French Capability Map / French Capability Reference www.gnb.ca/BCSI

(the Business Capability Map and Reference Model are accessible via the “Quick Links” section on each page)

What techniques were used to produce these artifacts?

This is a summary of some of the techniques:

  • The Capability Map was created as an ArchiMate view and then the diagram was exported as a PDF file.
  • Pages that include graphics were created using blank Business Canvas pages.
  • The Provincial logo was added to the PDF using the open-source Inkscape graphics editor – https://inkscape.org
  • The Reference document was 100% generated from Archi using a customized set of Jasper control files.
  • The Jasper report was generated in MS Word format in order to fine tune page breaks and add headers and footers.
  • User-defined properties for “French:name” and “French:documentation” were added to the French versions.
  • The model was exported to CSV files, using some Excel tricks to swap the French and English values, and re-imported to Archi before repeating the above steps

Many thanks to Peter Gee for providing us with an insight into how he uses Archi and ArchiMate. It’s interesting to see from the summary of techniques used a specific work-flow emerging when using Archi. This work-flow is valuable in determining possible features in future versions of Archi.

If you’d like to share your story about how you use Archi and ArchiMate and you’d like to be featured in this “Archi Spotlight” series please contact us.

Sep 282015
 28th September 2015  Posted by at 9:05 am 1 Response »

In this blog post I describe how to generate a basic standalone HTML report from an XML file exported in The Open Group’s ArchiMate exchange format using an XSLT stylesheet.

In my last blog post I wrote about The Open Group’s ArchiMate exchange format and how its main purpose is to allow the exchange of ArchiMate models between conforming tools. I also mentioned that it could be possible to do more with an ArchiMate exchange file, and use XSLT (Extensible Stylesheet Language Transformations) to display the contents of the file in a human readable format. XSLT is a language for transforming XML documents into other documents or other formats such as HTML, plain text or PDF, and as an ArchiMate exchange file is in a fairly straightforward XML format this should be possible.

This idea was first brought to my attention (via Andrew Josey of The Open Group) by Thorbjørn Ellefsen, Security Architect for the Agency for Public Management and eGovernment (Difi) in Norway. Thorbjørn had suggested that this would be an avenue worth exploring and provided a simple XSLT file that demonstrated the process. This piqued my interest and so I took Thorbjørn’s XSLT file and played around with it to see if I could produce some interesting HTML that could be used as a proof-of-concept ArchiMate report. In this blog post I want to share the results of my experiments.

Generating the ArchiMate Exchange XML file

The first thing we need is an ArchiMate model saved in the correct format. In Archi I exported the “Archisurance” example model to The Open Group’s exchange format:


I named the output file as “Archisurance.xml”. You can download a copy of the file here.

Here are the first few lines of the file:

As you can see, it’s not exactly user-friendly, but we can use this file as the data input for something more useful. If you have exported the file yourself and viewed it, you may notice a slight difference between your copy and the one above. Note that the following line has been added near the start of the file:

This line is important. I manually inserted it in my copy of “Archisurance.xml” in order to denote that the contents of the XML file should be processed using the “elements.xsl” XSLT stylesheet. If you are using your own copy of the file, you also need to manually insert this line into the file using a text editor.

Adding the XSLT stylesheet

Next we need the XSLT stylesheet that will transform the data in the XML file into HTML. For this first example, we’ll display a table of all the elements (concepts) in the model. The file is called “elements.xsl” and you can download it here. Here’s what it looks like:

This stylesheet is basically an XML file with some HTML tags and XPath queries that will generate HTML using data from the “Archisurance.xml” file. There is a <style> section for some simple CSS, a <html> and <body> section for the HTML structure, and a <table> to display all of the ArchiMate elements. If we put the two files together we should see a result. But how do we do that?

Displaying the result

Normally, we would use a special processor or tool to combine the two files in order to generate an HTML file (the command line tool xsltproc on Linux/Mac, for example) but for this demonstration we can very easily display the result in a browser. However, be warned that this may only render correctly in Firefox or Internet Explorer. If the two files, “Archisurance.xml” and “elements.xsl” are in the same directory on your computer you can open the “Archisurance.xml” file in Firefox or Internet Explorer. It should look like this:


We can see the model name and description, the ArchiMate elements, their IDs, name, documentation (if any) and their type. The XSLT code generates a table of elements by looping through each <element> tag in the XML file and displaying the contents of the “identifier” attribute, the <label> tag, the <documentation> tag, and the “type” attribute. The table is sorted alphabetically on the “type” attribute because it is specified in this line:

Note that XPath is used as the query language for selecting the elements in the XML file.

It’s a good start. Perhaps we could also display the relationships in the model? Yes we can, by applying the same principles as we did with the elements. To demonstrate this I’ve created another XSL stylesheet, a file named “elements_relations.xsl” and you can download it here. This file is the same as the first XSL file, but I’ve added some code to display the ArchiMate relationships:

The code iterates through each <relationship> tag in the XML file and, using an XPath query, finds the relevant tags and attributes needed to display the data. Notice that there are two XPath queries that reference elements elsewhere in the file in order to display the Source and Target element names of each relationship. The code uses XSLT variables, “Source” and “Target”, to make things a little easier to create the XPath queries.

In order to display the results of this new XSLT stylesheet, we need to replace the line in the “Archisurance.xml” file so it references this new file:

Open up “Archisurance.xml” in Firefox or Internet Explorer again (or refresh).

Here’s a sample of some of the output that is generated:


As before, we can see the ArchiMate relationships, their IDs, name, source and target elements, and their type.

Displaying the structure

One of the features of The Open Group’s ArchiMate exchange format is to be able to (optionally) represent and exchange a given structure of the ArchiMate elements and relationships in the model. By this we mean an organization of elements, relationships, and views much like a table of contents in a book. Most ArchiMate tools allow you to organise ArchiMate elements and relationships in some kind of hierarchical structure. In Archi this is the tree in the “Models View”. This is something that can be usefully exported and imported into another tool.

So far we have displayed the elements and relationships as flat lists, but we can use this structural, or “organization”, information in the XML file to display a tree of links to the elements and relationships.

We need to use a new XSL file containing the new code, named “structure.xsl”, and you can download it here.

Once again, we have to replace the line in the “Archisurance.xml” file so it references the new file:

I won’t show the new code here this time, but you can take a look at it in a text editor. The XSLT code iterates recursively through each <item> tag in the XML file and then generates a hierarchical HTML list of elements, relationships and views with links to the corresponding entry in the tables of elements and relationships.

Open up “Archisurance.xml” in Firefox or Internet Explorer again (or refresh).

Here’s a sample of some of the output:


If you click on one of the links, it will jump to the corresponding element or relationship in the tables.

Further experiments – displaying the diagrams

Once I’d reached this point with my XSLT experiments I felt ready for a new challenge. I wanted to know if it would be possible to generate the actual ArchiMate diagrams (views) using XSLT. It turns out that it is possible, to a certain extent, by using SVG (Scalable Vector Graphics). What I achieved is only proof of concept, and I only got as far as displaying the elements as coloured boxes without connections, but it may be possible to take this further, or even come up with an alternative method perhaps by using a combination of Javascript and CSS.

To demonstrate this, we need another XSLT file, this time it’s named “views_experimental.xsl” and you can download it here.

Once again, we need to replace the line in the “Archisurance.xml” file so it references this new file:

Open up the “Archisurance.xml” file in Firefox (sadly, the SVG does not display in Internet Explorer). If you scroll to the end you should see some basic diagrams. Here’s an example:


As I said, this is very much proof of concept, and it needs much more work. It may turn out to be too onerous to generate the full diagrams using SVG, particularly when it comes to creating connections (they need bend-points, anchor points and so on) and I’m sure there is a better way to do this. This does, at least, demonstrate the possibility of generating diagrams from the raw XML file.


I’ve tried to show that it’s possible to use The Open Group’s ArchiMate XML exchange file and display some of the data as HTML using XSLT stylesheets. I’ve also shown that it’s possible to generate some basic diagrams from the data. All of this needs much more work, and I’m aware that this work is at proof-of-concept level.

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.

Personally, I think this is very cool and it would be nice to see some XSLT stylesheets created to display ArchiMate models in more interesting ways. For example, one might display a summary and preview of a model. Or it may be possible to take advantage of a model’s Properties (attributes) and use them as variables that could be parsed conditionally for output formatting. I think that the potential inherent in The Open Group’s ArchiMate exchange format is very exciting and I’d love to see if anyone can take this further.

Many thanks to Thorbjørn Ellefsen for drawing my attention to the potential power of utilising XSLT with The Open Group’s ArchiMate exchange format.

(All files can be found in GitHub)

Sep 142015
 14th September 2015  Posted by at 12:34 pm Comments Off on The Open Group’s ArchiMate Exchange Format and Archi 3.3

Some of you might have noticed that Archi 3.3 has been released. This latest version of Archi includes a new plug-in which supports The Open Group’s ArchiMate file exchange format. This represents the fruits of some years and months’ labour! I’ve been collaborating with The Open Group, and representatives from associated parties and tool vendors, for some time now to produce a file format that can be used to exchange single ArchiMate models between conforming toolsets. Finally, version 1.0 has been released!

The file format uses XML, which is backed by a validating XSD Schema. Why is this? Wouldn’t XMI be better? Well, yes it would if we had a MOF representation of ArchiMate. Currently, one doesn’t exist. Also, it’s very hard to agree exactly what should be formally represented in a persistence format, as against what can be usefully represented and exchanged using a persistence format. For example, ArchiMate symbols use colour to denote the different layers, and custom colour schemes can be employed to convey meaning. Clearly, this is not something that can be enforced in a specification. Probably the only things that can be enforced are the ArchiMate concepts and relations themselves. Views, viewpoints, and visual arrangements of those concepts and relations are, arguably, optional. A valid ArchiMate model could simply consist of a set of concepts and relations. However, this is probably not very useful in the real world, and so the exchange format seeks to provide a file format for describing and exchanging the most used aspects of ArchiMate models, optional aspects as well as mandatory aspects.

So, simply put, the aim of The Open Group’s ArchiMate file exchange format is to provide a pragmatic and useful mechanism for exchanging ArchiMate models and visual representations between compliant toolsets. It does not seek to create a definitive representation of an ArchiMate model. For that to happen, I believe many things would have to be formally declared in the ArchiMate specification. For this reason, many of the components in the exchange format are optional. For example, the ArchiMate 2.1 specification describes the use of attributes as a means to extend the language and provide additional properties to the concepts and relations. The specification does not rigidly mandate their use. However, many toolsets do support and encourage the use of attributes to create model profiles, for example. To support this, the exchange format provides a properties mechanism, consisting of typed key/value pairs. This allows implementers to (optionally) represent additional information for all of the concepts, relations and views.

Even though I have emphasised that the main use for the exchange format is exchange (the name is a bit of a giveaway here ;-)), another advantage of using XML/XSD for the file format is that it is possible to use XSLT to transform the XML ArchiMate model instances into HTML documents, reports, as input for a database, and so on. I would say that the potential for exploiting ArchiMate data in this way is huge.

The exchange format could also help with learning the ArchiMate language and Enterprise Architecture – imagine a repository of ArchiMate models (tagged with Dublin Core metadata to facilitate search and description) that could be used as a resource pool of model patterns and examples for those new to the language. One thing that I personally would like to see is an extensive pool of example models and model snippets as examples of good modelling practice. And using the exchange format, these models and snippets can be loaded into any supporting toolset.

Here are my five “winning features” for the ArchiMate exchange format:

  • Transparent
  • Simple
  • Well understood format
  • Pragmatic
  • Open

I’m sure that The Open Group’s ArchiMate exchange format will contribute to, and encourage the use of ArchiMate, and perhaps reassure users that their valuable data is not locked into any one vendor’s proprietary tool format. I personally think that this is a great initiative and that we have achieved a great result. Of course, nothing is perfect and the exchange format is still at version 1.0, so user feedback is welcome. With greater uptake the format can be improved, and we may see it being exploited in ways that we have not yet thought of!

(For more information about the exchange format, see here)