Sep 142015
 
 14th September 2015  Posted by at 12:34 pm No Responses »

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)

Dec 222014
 
 22nd December 2014  Posted by at 5:23 pm No Responses »

Solstice Greetings! I thought I’d write a review of the latter half of 2014 and a brief update of where we are now before we move into 2015. So, what’s happened since the last blog post in July?

New Forums

In August we moved the forums to a new home at http://forum.archimatetool.com. The Google Groups that we had been using before were cumbersome to manage and not very user-friendly. We hope that the new forums offer a better experience in sharing your discussions related to Archi and ArchiMate. The new forums allow you to upload screen-shots, share models, and open polls. If you’ve not already joined the new forums, we invite you to do so.

Archi 3

Archi version 3 was released at the end of September. This was the biggest and most important event of this year as we had been working on this version of Archi for some time. The main reason why this update is so important is that previous versions of Archi had been built upon the older Eclipse 3.x framework. However, Eclipse 3.x is no longer supported since version 3.8.2 released in 2013. Eclipse 4.x is now the new supported version and, after the elimination of some bugs in Eclipse, we managed to migrate the Archi code-base to this new Eclipse framework with only a relatively few changes. This means that we can move forward with development. At the same time we introduced some great new features including a new look and feel, import and export to CSV files, an improved Magic Connector, Find/Replace, export image to PDF and many other features and fixes. Personally, the migration to Eclipse 4.x has been a great relief because there was a point where I wasn’t sure if it was going to be possible due to a range of issues and bugs in the Eclipse code.

Archi 3.1

Archi 3.1 was released at the beginning of December and represents a fine-tuning of the work delivered in Archi version 3. This is a maintenance release that fixes a number of bugs and adds some useful, new features. The focus of Archi 3.1 has been to improve the user interface response time when working with larger models, and to implement stronger integrity checking when loading and saving models to disk. This work came about at a time when I was working with a relatively large ArchiMate model. I noticed a sluggishness in response in the Models Tree when many nodes were open and when changing Viewpoints in the diagrams. I spent about three or four weeks experimenting with different threading techniques and algorithms before finding the perfect combination that improved overall response times. At the same time I added some defensive measures that checked the integrity of models and files before saving to disk. Archi 3.1 provides a more robust and smoother user experience.

The Open Group ArchiMate Model Exchange File Format

An important initiative concerning ArchiMate itself has been the ongoing development of The Open Group’s ArchiMate Model Exchange File Format. This initiative is being led by Andrew Josey of The Open Group, and I have been contributing to the development process, as have some other ArchiMate tool vendors. The exchange format is a specification for a standard file format for the exchange of ArchiMate models between different tools. It is not intended to be a definitive persistence representation of an ArchiMate model as you might find for a UML model, for example, since the ArchiMate language has not been formalised enough to create something like a MOF or XMI representation. It is, however, an XML format (validated by a XSD Schema) that so far has proved that it is possible to exchange basic ArchiMate models and diagrams between ArchiMate-aware tools. To date these tools are Archi, BiZZdesign Architect, and Corso’s System Architect ArchiMate plug-in. Clearly this is good news for all stakeholders and I think is important for the ArchiMate language itself, particularly from the point of view of those learning the language. The exchange format will allow users to exchange their models without worrying about target tools and proprietary formats, which is very important for those who may be new to ArchiMate and who do not want to be locked into one tool or framework.

Futures

What now for Archi? As it is, Archi is great for the single, file-based, user. But of course the number one request is for repository and multi-user support. This is not a trivial feature to implement, and one that would require many months of hard work. In order to support a transactional-based and multi-user work-flow Archi will need to be re-implemented in a new (Eclipse-based) framework. This has been under investigation over these last few months and we are moving slowly towards this goal. This will be our focus in 2015. Archi 3.x will continue to be supported with bug fixes and small features, but at the same time we will shift our focus onto the longer term aim – Archi 4.

Thanks

And finally I’d like to offer some thanks. I’d like to thank all Archi users for their support and encouragement in 2014. Also, a special thank-you is due to Jean-Baptiste Sarrodie for his incredible support, encouragement, evangelism, contributions and vision. I’d also like to thank Gerben Wierda, author of the essential book, Mastering ArchiMate, for his support and advice. Thanks are also due to David Rose, and Andrew Josey of The Open Group who have allowed me to participate in The Open Group’s ArchiMate Exchange Format project. And finally, I’d like to say a big thank-you to everyone who has kindly donated to Archi by Paypal. These donations have kept the wolf from the door and encouraged me to continue developing new features in Archi. So, once more…thank-you!

Jul 302014
 
 30th July 2014  Posted by at 1:38 pm 2 Responses »

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

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

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

Model

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

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

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

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

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

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

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

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

Jul 252014
 
 25th July 2014  Posted by at 8:42 am 4 Responses »

If you know ArchiMate, there’s a good chance that you know Gerben Wierda‘s post series “What is wrong with this picture?”. This blog post is both a tribute to his work and an attempt to explain the importance of why you should be aware of the difference between core relations and derived ones.

In his book Mastering ArchiMate, Gerben presents several beginner’s pitfalls and especially the (bad) use of derived relations. I can only recommend that you follow his advice, and I will explain why, but let’s start at the beginning…

Core vs derived relations

When reading the ArchiMate Specification you might notice that the relationship tables contain a lot more relationships than those described in the metamodel pictures (such as this one for the business layer). The latter are the “core” relationships. In a detailed ArchiMate model, you could just use only these ones. But in real life, you will certainly have to create some high level views hiding some elements and using derived relationships.

In general, ArchiMate tools implement all of the possible relationships based on the tables in the Appendix of the specification, but don’t tell you which kind of relation you are creating, core or derived, and this may lead to problems.

Infrastructure Service used by Data Object

Today I was working on a model for a new project. For this, I used our standard pattern for a database:

whatswrong-dbpattern

This pattern basically shows a shared server which hosts several databases. In order to be able to move one database from this shared server to another one in the future without having to reconfigure applications using it, each database is accessed though a dedicated DNS alias pointing to the real server name (for those who know Oracle, we assume the service name and the port will not change).

Following our pattern, I then added some additional elements from the application layer, notably a Data Object realized by an Artifact. As I am testing the Archi 3 Early Access Preview, I played with the new Magic Connector functionality and found the following possible relationship – Infrastructure Service used by Data Object…

whatswrong-usedby

Wait a minute! What does “Infrastructure Service used by Data Object” actually mean? In natural language it seems to be OK because, after all, my database is managed/presented through the “DB1 (Infrastructure Service)” and therefore relies on it, so I could use it. But let’s examine this situation more closely first.

The first question to ask is whether it is a core or derived relation. That’s the easy part, the Application-Infrastructure Alignment Metamodel clearly shows that it’s not (only Realization from Artifact to Data Object is permitted). So it turns that it must be a derived relation, and we need to find it.

In order to understand what this Used By relation means, let’s start at the endpoint – the Data Object. Only a few core relationships are defined – Realization from Artifact, and Access from both Application Function and Service. A Used By relationship can only be derived from relationships having a strength at least equal to Used by, so this excludes the Access relationship.

After some time checking the Infrastructure Layer Metamodel, I ended up with the following (derived relation in blue):

whatswrong-explanation

“DB1” used by “Shared DB server”? Not what I intended to show, and clearly false in my case (there’s nothing on my database server that make use of the DB service).

Conclusion

All this came about because I used a helpful and nice feature in Archi – the Magic Connector. This can really help you a lot and shows you all allowed relationships between concepts, but it doesn’t tell you which relationships make more sense in a given context. As it is, I know ArchiMate well enough to ask such questions, but what if I were new to ArchiMate? I would have kept the Used By relationship and never have understand its real meaning, a common beginner’s pitfall.

So what can we do? As an Architect, I can make sure that I really understand what I’m doing by learning (and Gerben’s book is perfect for that). As an Archi contributor, I can suggest to enhance the Magic Connector to show me whether it is proposing a derived relation or a core one. We could also envisage that Archi could warn me when I manually create relations or reveal their nature (as with the “Show Structural Chains” option). Adding such a feature would really help a lot of Architects master ArchiMate.

Just for fun, re-examine some of your models and take 5 minutes to see how many derived relations you use, and then check their exact meaning. Do you find some strange things?