Apr 262018
 26th April 2018  Posted by at 1:40 pm No Responses »

A is for Archi, an open source tool
B is for Business, in which you must school
C is for Cartel, that threatened to sue
While D is for Downloads, that so many accrue.

E is for Enterprise, that grows and it grows
F is for Function, that each person knows
G is for Gerben who wrote a great book
And H is for Holland from where this all took.

I is for Imagine, Ideas and Inspire
J is for J-B who kindles that fire
K is for KISS, a concept to aspire
While L is for Licence, that’s sometimes a mire.

M is for Meetings, so many a waste
N is for Network, in which we are placed
O is for Open, though closed it may seem
And P is for Phillipus who brought you this dream.

Q is for Quality, that’s something we’ve got
R is for Rocketry, a science it’s not
S is for Simplicity, and as easy as pie
While T is for Thought Leader, who tells you a lie.

U is for Users, of which there are many
V is for Value, worth more than a penny
W is for Work, that makes us all dumber
And X is for X, that mysterious number.

As Y is for Yield, the money you make
So Z is for Zero, the profit I take.

Mar 062018
 6th March 2018  Posted by at 10:38 am 1 Response »

Apple’s “it just works” tag-line is probably best confined to the Trash can. All of the problems and silly little bugs in Archi (well, actually the Eclipse framework) have been on the Mac, especially the later versions of OS X.

“It just works “- this bug cost me three days of testing, trial and error, googling, updating Eclipse, and trying different configurations.

“It just works “- this bug (a major showstopper) still hasn’t been fixed yet.

“It just works “- this bug still hasn’t been fixed yet.

And I’m not sure for how long I can continue to support MacOs. A 2010 Macbook is probably not going to support the latest versions of Mac for a lot longer. And no, I’m not getting a new Mac any time soon.

Aug 302017
 30th August 2017  Posted by at 1:40 pm No Responses »

I’m trying to make life easier for Archi users who install official Archi Plug-ins but differences in Operating Systems are making things tricky. A plug-in consists of either a single “jar” file or a directory containing several files which need to be placed in the “plugins” folder of the Archi installation. This could be done manually by the user, but I want to make it possible from inside Archi, and certainly for Mac users it’s a pain to have to right-click on the app, select “Show Package Contents”, and then copy it to the “plugins” folder in the app bundle.

So I’ve added a menu item in the Help menu to “Install Archi Plug-in”. This lets the user select the bundled plug-in zip file from a dialog box and install it one simple operation. The installer checks that it is a valid Archi plug-in and then copies the contents to the target “plugins” folder and asks the user whether they want to re-start the app now or later. Simple.

Except it’s not so simple for the following cases:

  1. On the Windows version that has been installed with the Inno installer
  2. On Mac OS X 10.12 and later

For (1), Archi needs to have administrator write access to the “plugins” folder. With Windows 32-bit, this can be circumvented by the VirtualStoreĀ  mechanism, but this doesn’t work on 64-bit Windows. So, the installer will ask the user to restart Archi with the “Run as administrator” option and try again. This grants the app the rights to copy the plug-in to the installation folder.

For (2) Apple’s implementation of translocation for unsigned apps means that Archi can’t write to the “plugins” folder for a different reason. Archi is an unsigned app so OS X copies it to a read-only area and executes it from there. To stop this happening, the user needs to move the Archi app to a different location from where it was saved when downloaded (for example, move it from the “Applications” folder to “Desktop” or vice-versa.)

This is how it works for now. Maybe there’s a better way. If you downloaded the portable zip version on Windows or Linux you won’t have this problem, provided it’s unzipped to a writeable location.

(This post is one in a series of “boring as f*** but I’ll put it here anyway”)

Aug 202017
 20th August 2017  Posted by at 4:58 pm No Responses »

ArchiMate defines a set of 11 relationships between elements. How these relationships can be used is also defined in the specification in the metamodal diagrams and in a table of allowed relationships given in an appendix.

Here’s an example of a metamodel diagram for the business layer:

And here’s an excerpt from the relationships table in the appendix:

If you’re creating an ArchiMate tool one of the first things you want to do is represent the ArchiMate metamodel and the rules for the allowed relationships (core and derived) in code. So it’s probably best to regard the tables as provided in the appendix of the specification as the single point of truth, right?

Wrong. For the past few years these tables have been incorrect and there have been inconsistencies between the rubric and the metamodel diagrams. But that seems to have been fixed now with the latest 3.0.1 version of the documentation. Good news. But surely there’s a machine readable format for the relationship rules to ease the burden of the developer? Wrong again.

When I developed the first version of Archi I had to read each line of the relationships table and manually type every “a”, “f”, “t” and so on into an XML file. I’ll never get those dead brain cells back…

Fortunately, this time round I was saved by Ed Roberts of Elparazim who has generated the relationship tables in an XML format with some mysterious Prolog scripting voodoo.

Taking the example table above we can read the first cell as “an Assessment element can connect to another Assessment element using the Specialization (s), Composition (c), Aggregation (g), Influence (n), and Association (o) relationships”. So what’s the best way to represent this in a tool?

I use an XML file that, in its simplified form, looks like this:

<relationships version="3.0">
  <source concept="Assessment">
    <target concept="ApplicationCollaboration" relations="o" derived="" />
    <target concept="ApplicationComponent" relations="o" derived="" />
    <target concept="Assessment" relations="cgnos" derived="cgn" />

It has a “source” section for each of the ArchiMate elements and a “target” line for each element. The allowed relationships are denoted by a single letter as in the table, above. The “derived” attribute declares those relationships that are not core relationships. This is not currently used in Archi, but I have plans for this in a later release. You can read up on derived relationships here.

The whole XML file is available to view here.

When I first designed Archi I pondered the best way to do this. I knew that it had to use an external file so that it could be easily updated, and it also had to be human readable. I thought about using a CSV file but scrapped that idea when I tried to edit it. So I went with the XML file because it fulfilled the following requirements:

  • Has to be an external file
  • Easily understood by end users
  • Favour verbosity over conciseness
  • Easy to maintain and edit by end users
  • Order of elements doesn’t matter (that ruled out CSV)
  • Common format (CSV, XML, JSON, whatever…)

So there it is. An XML based, verbose file format. Could it be done better? Perhaps. But it’s worked for the last 7 years in Archi.

All we need now is for an agreed open format that The Open Group can publish with the official ArchiMate specification. Once again, this is being crowd sourced, but I can’t say whether the XML format that I use will be adopted. It might be in CSV format. But, to be honest, anything is better than nothing.

(Oh, if anyone wants to check the accuracy of the XML file against the published table, please feel free to do so!)

Aug 102017
 10th August 2017  Posted by at 7:51 pm No Responses »

Another day, another “proposal” from a training organisation. šŸ™„

Over the years I’ve received quite a few “proposals” relating to Archi. They’re usually some variant of:

  • Hey Phil, why don’t you advertise my (money-making) site for free, and I’ll promote Archi!
  • Hey Phil, we use Archi to make loads of money training people in ArchiMate and have come to rely on it. We’d love to donate to Archi but….[fill in crummy reason here] and, by the way, could you just add this feature?
  • Hey Phil, when are you releasing the next version of Archi so we can continue to make money off the back of it? We’d love to donate to Archi but….[fill in another crummy reason here]
  • Hey Phil, why don’t you…
  • Etc, etc, etc.

Well, guess what? I’ve got my own proposal for you:

  • Why don’t I put the whole lot of you out of business by providing our own online training? šŸ™‚

Oh, and another thing. ArchiMate training is way over-priced. I consider that a bug that needs fixing. And I have a fix for it…

Aug 012017
 1st August 2017  Posted by at 8:18 pm No Responses »

This post follows on from my previous post where I said:

Overpriced ā€œenterpriseā€ software that can only be accessed from behind a paywall may as well not exist.

I want to talk about the concept of “Executable Standards”, something that the curators of ArchiMate are keen to promote.

The difference between a “Paper Standard” and an “Executable Standard” is probably obvious – it’s the difference between an open standard existing in theory and it manifesting in practice. I can easily give you an example of a Paper Standard – IMS Learning Design. All bark and no bite. No one implemented it properly and now it’s dead.

But surely the same is not true of the ArchiMate standard? Well, yes and no. Let’s state the following maxim:

If an Open Standard does not manifest in an Open Implementation it is not an Executable Standard.

And furthermore:

Archi is the manifestation of the Open Implementation of ArchiMate.


Archi has made ArchiMate an Executable Standard

Now, this is fortunate. But if Archi had not come about, we might be in a situation where ArchiMate was only implemented by the members of The Cartel, resulting in closed, overly expensive, proprietary software which, in turn, may have eventually killed off the standard or, at least, relegated it to a niche market. In other words, not an Executable Standard, as it is defined above. In fact, The Cartel would have preferred that ArchiMate had remained a niche standard implemented only by them. In my personal experience, The Cartel have demonstrated an alarming ignorance of, and utter contempt for, open source. Readers might consider why they have little or no interest in the ArchiMate Open Exchange Format (the clue is in the words “open” and “exchange”).

But Archi, being free and open source, has provided the Executable Standard that may otherwise have not existed. And this is why an Open Implementation such as Archi requires, let’s call it, “Executable Support”.

Jul 302017
 30th July 2017  Posted by at 8:14 pm No Responses »

I was reading this post on Quora, “Why did Borland fail” again today and re-thinking the whole Borland Business. The post rightly asserts that Borland failed because they tried to appeal to the “Enterprise” market instead of sticking with the successful market that they were catering to at the time (late 1990s, early 2000s).

The company was founded on the idea of making mass-market software – products that can be used by a large number of people in a variety of different scenarios, and at reasonable prices.


In the height of the enterprise transformation, I asked Del Yocam, one of many interim CEOs after Kahn, “Are you saying you want to trade a million loyal $100 customers for a hundred $1 million customers?”Ā  Yocam replied without hesitation “Absolutely.”

I agree, because I was there at the time and I was one of Borland’s customers. I was using Borland’s Turbo C Compiler in the early 1990s and then, when I got into Java a bit later, I used Borland JBuilder. Yes, I was a big Borland fanboi. I loved Borland products, they were reasonably priced, well-written, and accessible. And then Borland fucked up.

The executive team decided to take a talented development team with lots of experience building innovative consumer products and retask them to build enterprise software.

From my perspective, they blew me out. I was paying a reasonable and acceptable price for a very nice product (JBuilder) and overnight I was no longer a developer that they wanted. They wanted to cater to big companies who had $$$ to waste on bloated “Enterprise” subscription models. I could no longer afford to continue with their products, nor did I want to since the smell of phoney corporate bullshit became too strong.

I’m not sure if it was around 2002 or 2003 that I discovered Eclipse. What I do remember was that it was (a) free, (b) open source, and (c) intriguing. The Eclipse IDE at that time had a quite basic feature set, at least compared with JBuilder, but I felt that it had potential and, more importantly, I felt welcome. I was no longer a JBuilder customer.

Borland had, at that time, a newsgroup of which I was a member. I wrote a message on the newsgroup, asking what people thought about Eclipse and whether Borland saw this as a threat. A Borland employee replied to the effect that no, they didn’t see Eclipse as a threat, and dismissed my idea and Eclipse itself disparagingly.

Borland are now dead.

What has this got to do with Archi?

Quite simply, I hate corporate bullshit and bloated software that purports to implement open standards and that is not open itself.


Overpriced “enterprise” software that can only be accessed from behind a paywall may as well not exist.

This is my own personal driver, I guess – to produce open, elegant, non bloated software that users want and can use. No phoney “sign up here for our white paper” lies, no press-ganging into expensive subscription models, no vendor lock-in, no crappy proprietary data formats (why do you think The Cartel so vehemently oppose the ArchiMate Exchange Format?). Just open, accessible software. I like to believe that Archi is on the way to fulfilling that goal. It’s still relatively early days but, with an average of 1,000 downloads of Archi every week, I think we’re getting there.

I look forward to the day when this bogus “enterprise” software model goes the way of the dinosaur Borland.

Jul 282017
 28th July 2017  Posted by at 10:51 am 3 Responses »

As I outlined in the Archi Roadmap, one of the things I’m working on is the Archi Command Line Interface (ACLI). This has been requested by users for some time, it’s just that I never got around to figuring out a good way to implement it. I’ve now got the bare bones of it coded.

Here’s how it will work. You’ll be able to invoke and launch Archi (probably installed on a server) in “headless” mode via a command line with various aguments to perform certain tasks. For example, to load a *.archimate file and generate a HTML report in a given folder:

Archi -consoleLog -console -nosplash -application com.archimatetool.commandline.app -HTMLReport_InputFile "~/pathtofile/test.archimate" -HTMLReport_OutputFolder "~/ouputfolder"

So this could be part of a bigger batch job triggered by a certain action hosted on a server.

I’m also working on another “Acling” that can be invoked whenever a new version of an Archi model is published using the Archi Collaboration plug-in. This can be triggered from a git hook so that the repository is then cloned or pulled, the model assembled and loaded into Archi, and a new report generated and uploaded to a given location.

How does this work under the hood?

The command line launches a new application, com.archimatetool.commandline.app, which, in turn, hands over to a controller class, the CentralScrutinizer. This avoids loading the UI and other bloat. From here theĀ CentralScrutinizer dispatches the command line arguments to any registered command line providers who can then scan the list of arguments for anything of interest and act accordingly.

If you have any use cases for the ACLI that you would like to see, leave them in the comments below.

Jul 262017
 26th July 2017  Posted by at 11:03 am No Responses »

Since The Cartel threw their toys out of the pram, and started turning the screws and threatening The Organ Grinder, I notice that TOG are not allowed to mention the dreaded name “Archi” on Twitter and suchlike. So, to help them out, I had the great idea of dropping the name “Archi” and just using the logo , you know like Prince did with his symbol . But Prince grew tired of that and he eventually dropped it and adopted the moniker, “The Artist Formerly Known as Prince”. But that was a mouthful, so it was reduced simply to “The Artist”. And then he probably thought “screw this” and reverted back to “Prince” again.

So maybe I should rename Archi to “The Software That Dare Not Speak Its Name”, or “TSTDNSIN” to keep things simple? Suggestions in the box below, please.

Jul 252017
 25th July 2017  Posted by at 3:09 pm No Responses »

With two lines of code I think I’ve improved Archi model load times by about 4000%.

Some users had been complaining of very long load times of several minutes but I’d always assumed that the slow load speed was due to EMF taking its sweet time to load a monolithic XML file, and had resigned myself to the notion that this doesn’t scale with large models. I was then planning on making deep changes to the persistence format to save and load multiple XML files and load them on demand.

Then, while testing the new repository plugin using JB’s “grafico” format, we noticed that large models loaded very quickly. The grafico format uses multiple XML files for each object. I started to think…

So I Googled “EMF slow load” and found this:



So I added:

resource.getDefaultLoadOptions().put(XMLResource.OPTION_DEFER_IDREF_RESOLUTION, Boolean.TRUE);
resource.setIntrinsicIDToEObjectMap(new HashMap());

and made some adjustments elsewhere and bingo!

Now, the thing is, I want to know that if storing the IDs in a separate HashMap has any side effects. So far I don’t think it has, because the Resource is discarded once the model is loaded.

User feedback is encouraging – 17 minutes reduced to 13 seconds.