archi-logo

ArchOps: a new paradigm for EA Toolsets

Last week I had the great opportunity to co-present at The Open Group’s October Conference in Paris, France. After Phil Beauvoir presented a summary of Archi’s history and we described the challenges of ArchiMate 3.0, I spoke about a vision for the future of Archi, EA and the ArchiMate ecosystem, taking ideas from DevOps and applying them to Archi and ArchiMate tooling. For those that weren’t with us, here is a 2nd chance…

New tools for a new EA practice

For the past 10 years, a strange thing happened: while (Enterprise) Architects used to have some of the best tools for their work, tool vendors seem to have forgotten to innovate, while at the same time, tools for Software Developers started to take off and offer some really new and exciting features. Why? How?

While I can’t speak for EA tool vendors, I can at least look at what happened in the software development domain. It seems to me that it all started back in 2005 when Linus Torvalds (yes, the same guy who created the Linux kernel) decided to create his own version control system, Git. Did Linus decide to change the world at that moment? No. Did he decide to create a whole new ecosystem for development? Again, no. What Linus did was simply to create a small piece of software for his own needs, but a free/open piece of software with some great features. Basically, what Linus created was a software version control system which allows easy creation of branches, and the ability to merge those (sometimes conflicting) branches. These simple but powerful features then became the building blocks for a powerful new toolset, which in turn laid the foundations for a whole ecosystem now known as DevOps. If I had to summarize what DevOps is, I’d say that it is a software development Capability. In short, a great mix of knowledge, processes and tools. Furthermore, most of these are open – open-knowledge, open-tools.

The GRAFICO plugin

The GRAFICO plugin for Archi

Between 2012 and 2014, there were many discussions on Archi’s Forum about how to make Archi usable in a multi-user environment. While most people tried to solve the problem using the same approach that existing commercial tools took (save the model in a database, and require user to lock part of the model to avoid conflicts) some users suggested to workaround this issue using existing tools like Git. Some early attempts proved that it was feasible, but no plugins were maintained after the initial proof of concept. That’s why in 2015 I decided to work on it with the help of Quentin Varquet. What we created then was a really simple plugin for Archi whose only goal was to save and load an ArchiMate model in a way that makes it manageable by Git, thus the name GRAFICO (Git FRiendly Archi FIle COllection). With the help of this plugin and some GitHub-like solution (e.g. GitBlit or GitBucket) I was able to work with my colleagues on the same model at the same time without any issues.

This work could have stopped at that point, but I decided to make this plugin available under a Creative Commons licence (the choice of a non really open licence was driven by the fact that too few people have donated to Archi, and that this was one opportunity to get some funding for it).

Experiment turned into crazy idea

When the experiment turned into a crazy idea

The great thing about open source is that there are always some people that think out of the box and then take your ideas and use them in an unexpected way. That’s what happened with the GRAFICO plugin. Despite being a proof of concept in beta, some people started to use it, and then shared with me this crazy idea:

Do with Enterprise Architecture what developers did on DevOps

OK, but what does this mean?

ArchOps explained

ArchOps explained

Let’s think out of the box… Ready? Go!

Imagine that there exists a solution to share an ArchiMate model. And that this solution doesn’t require you to lock in advance part of the model before you change it. Imagine that you are free to clone this model, to create branches and then to merge your work with your colleagues. Imagine that you can keep a local copy of the model, work offline and send your changes to the central model when your want (or can). Imagine that there is in fact no “central model” because you can choose to create multiple copies of this model and sync them. Imagine a toolset that allows you to create conflicting changes because it can then raise a warning, allowing your team to discuss the issues, and understand why and how they arose. Wouldn’t it be great? If your answer is yes, then you’ll be happy to know that this is what you can already do with GRAFICO and Git (the only drawback is that it requires you to have Git skills).

Now, imagine that these exact same features could be used with models saved in the Archi native file format but also the ArchiMate Open Exchange File Format designed by The Open Group. Imagine that all these features are packed in a single open-source solution that never requires you to know Git but still provides the powerful interoperability features. What you now have is a solution that can trigger some events when (part of) the model changes. What you can do from here is up to you, but what about:

  • generating a static HTML rendering of the model in order to share it,
  • exporting the model to another repository, such as CMDB,
  • automatically checking that no changes appear in the as-is/baseline branch that could affect a project branch (automatic gap analysis).

If you find it useful, then you have an idea of what ArchOps could be. But the most important is that this is not about tools, it’s about opening new opportunities for our EA work, defining new way of working.

A Boundaryless Information Flow

How to move on?

As Archi is open source, we can’t really provide a definite roadmap for this work, but the key point is that we’d really like to make all this happen in the near future. For this to happen, we are looking for passionate people that could sponsor our work and invest some time with us to discuss ideas in more details and beta-test our solution. I heard that some companies could help us but for the moment no one has really decided to do so. Do you want to be the first?

archi-logo

“ArchiMate® 3.0, Archi 4, and Open Source – Open Standards in Action” – The Open Group’s October Conference in Paris, France

Last week, at the invitation of Andrew Josey, I attended and co-presented at The Open Group’s October Conference in Paris, France. My co-presenter was Jean-Baptiste Sarrodie of Arismore. The title of our presentation was “ArchiMate® 3.0, Archi 4, and Open Source – Open Standards in Action”. The following is the official summary of our presentation:

ArchiMate® 3.0 was released in June 2016. This latest version of the language represents an important evolution of the popular open standard that is used by Enterprise Architects globally. It is now possible to model the strategy of the enterprise using new concepts such as Capability and Resources, and also to model the physical world with the Equipment, Material, and Factory concepts.

Archi® is an open source modelling tool that provides an open and free implementation of the ArchiMate language. It has been downloaded many thousands of times since its introduction in 2010 and provides a low cost to entry solution to users who may be making their first steps in the ArchiMate modelling language, or who are looking for a free, cross-platform ArchiMate modelling tool for their company.

In this presentation we show that Archi has been an important enabler of ArchiMate globally, why it’s important to continue to develop and support the tool, and the challenges faced in implementing ArchiMate 3.0. We also discuss the importance of open source and open implementations for an open standard. We will provide a review of progress and new features in the next version of Archi, and progress on its implementation of The Open Group’s ArchiMate exchange format.

Furthermore, we will provide an example of how Open Source developments based on Archi within Arismore have made a DevOps approach to Architecture work possible and allowed the company to rethink their EA practice.

The key takeaways of the presentation were billed as:

  • ArchiMate 3.0 represents an important evolution in the language
  • Archi continues to provide an open and accessible implementation of ArchiMate lowering the barrier to entry
  • The latest version of Archi and its associated initiatives represent new developments that benefit all stakeholders and continue to promote and support ArchiMate and Enterprise Architecture

So, how did the presentation go?

Well, had I been doing the presentation on my own I would probably have defaulted to the usual informative, but slightly boring, PowerPoint slide deck, and that would have been that. Fortunately, Jean-Baptiste (J-B) had the idea of livening up the party by using a hand-crafted Sozi presentation and so, with the vehicle of our improvised double-act, the delivery was a lot of fun and, I think, well received by the audience. Here’s the static overview image of the presentation that J-B created:

Paris Presentation

Paris Presentation (created by J-B Sarrodie)

In our joint presentation, J-B and I gave a brief summary of Archi’s history, how it started from a modest UK-funded project with the aim of helping staff in UK universities making their first steps in EA and modelling, and how it has developed over the last six years to a position where it is downloaded around 5,000 times a month. J-B made an important point that probably applies to many ArchiMate users – if it had not been for Archi he would not have started to use the ArchiMate language. And, I assume, if J-B had not started with Archi and ArchiMate, perhaps Arismore might not have got on board with it, and we would not be doing this presentation. And I think this was one of our key messages – that Archi has been an important enabler for the uptake of ArchiMate, and perhaps EA in general.

I made the point that, as a free and open source tool, Archi is not in competition with any other ArchiMate-based tool. We are not in the business of exclusion, but, rather, as part of our “Archi Philosophy” we aim to be inclusive. In fact, it has been mentioned several times to me that if Archi, or at least any open source ArchiMate tool, had not existed then the tooling ecosystem would probably not be as active as it is now. We aim to open up and enable the market for all stakeholders. There is room for everybody, and an open source offering is essential for an open standard. Furthermore, as part of this inclusive vision, the ArchiMate Exchange Format has proven to be a key enabler for many end users who need to ensure that their ArchiMate data is accessible, transparent and interoperable between toolsets and services. I’ve written about the importance of the ArchiMate Exchange Format in my previous blog post and, at the conference in Paris, it was obvious how important this has become.

Raul Mario Abril Jimenez of the European Commission and the European Interoperability Reference Architecture (EIRA) project was also presenting at the conference and he told me that the ArchiMate Exchange Format was a key decider in the project’s use of ArchiMate. The EIRA project has even taken things a step further by developing a plug-in add-on for Archi – the Cartography Tool. In the presentation I emphasised how Archi and the Exchange Format has enabled rich cross-pollination of ideas, methods, and tooling enhancements, and so it’s great to see this in action.

J-B gave us a quick overview of some of the new features in ArchiMate 3.0, and I spoke about some of the challenges these have presented in implementation in Archi, and the importance of sustaining and supporting the development of Archi and associated initiatives given the huge number of end users and stakeholders. This led us onto some exciting news:

Archi 4 beta with support for ArchiMate 3.0 is available now!

I’ve been working on implementing the main new features of ArchiMate 3.0 in Archi over the last few months. There’s still a few loose ends, and documentation and testing to do, but please give the beta a try. You can download it from the Archi website.

J-B spoke about his vision for the future of Archi, EA and the ArchiMate ecosystem, taking ideas from DevOps and applying them to Archi and ArchiMate tooling – something he calls “ArchOps”. You can see from the presentation summary image above where J-B is going with this. Hopefully, J-B will elaborate upon these ideas in a separate blog post.

So, I think it was a positive and fun presentation. At least J-B and I had a lot of positive feedback afterwards. And, for the record, here are my personal key takeaways from attending the conference:

  • Andrew Josey and The Open Group are doing a great job curating the ArchiMate language as an open standard, whilst managing a variety of (sometimes conflicting) stakeholder concerns
  • Everyone I met was very generous in their praise of Archi and what it has achieved
  • I am amazed at the way end users have been empowered by access to open source tooling, open standards, open data, and their positivity in sharing and working together
Phil Beauvoir and J-B Sarrodie

Phil Beauvoir and J-B Sarrodie presenting at the Paris Conference

You can view the full Sozi presentation here.

archi-logo

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.

Open

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 “peterson.br” (presumably from Brazil) tells us what they used in the process:

  • Archi (with OpenExchangeFile plugin)
  • OrientDB (Graph and Document Database – http://orientdb.com)
  • 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

Rackspace

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)

archi-logo

What Have the Romans Ever Done for Us?

It’s that classic line from Monty Python’s film, “The Life of Brian”:

And I was thinking about how to answer this question if it was re-phrased as “What has Archi ever done for us?” or even, “What has Archi ever done for ArchiMate?”

Well.

I’m not going to presume anything about the global impact that Archi might have made during its 6 years existence, it might be better if its thousands of users attested to its apparent ubiquity, usefulness and popularity.

But, first, here’s a quote from an Enterprise Architect that someone sent me:

Archi does more to popularize the use of ArchiMate…In my practice as an EA I regularly encounter professionals who refer to Archi as ArchiMate. They are often quite stunned when I point out the difference.

It’s certainly true from my experience that very many people seem to think that Archi and ArchiMate are synonymous. I wouldn’t wish to perpetuate this misunderstanding and I do try to make clear the distinction between Archi® the tool and ArchiMate® the language (both are registered trademarks), but perhaps it’s a bit like the immediate association that we make with internet search and “Google” – “to Google”. The key is in strong branding, clear product and The Power of Pull.

We’re asking users to tell their stories here on this blog about how they use Archi and ArchiMate to model the enterprise, and there are many other stories being posted on-line, but for now I’ll provide some plain statistics. Here are the download figures for Archi as provided by Google Analytics for the Archi website from January 1 2014 up to yesterday (July 12 2016). Note that the Archi website only started to host the downloads from about January 2014 onwards, before that they were available from the old website.

Download figures

Download figures for Archi from Jan 1 2014 to July 12 2016

And here’s the global picture of site access for the top 30 countries:

Archi website access by country

Archi website access by country

Adjusting for duplicates and other factors there seems to have been about 3,000 – 4,000 downloads a month of Archi. The Netherlands (the birthplace of ArchiMate) is top of the list in the countries league, followed by the United States and the UK. Russia comes in at 4th place, and I know for a fact that Archi is really popular there, since it has been translated into Russian.

So, what has Archi ever done for the global uptake of ArchiMate? Or, to put it another way, I wonder how popular ArchiMate would be now if, in a parallel universe, Archi had not existed.

I won’t answer that but I will say this – it’s probably a good idea to keep going with Archi.

What do you think?

archi-logo

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-logo

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