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…

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 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).

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

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:

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.

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?

3 thoughts on “ArchOps: a new paradigm for EA Toolsets”

The team I work with have been working with Archi since November last year.
Reading your post about needing people to “invest some time with us to discuss ideas in more details and beta-test our solution”, please indicate how I could assist.