Several "Versions" of the architecture model

Post Reply
wgoebl
Posts: 20
Joined: 09 Dec 2011, 11:08

Hi,

how do you deal with versions of the architecture model?
In reality we have releases (in our case twice a year) where we rollout certain versions of the applications.
One solution could be to add a version name and/or "in production since/until" date in the meta model. The problem here is that protege does not provide a kind of "top level filter" that makes it possible to view only applications that are in production at a certain point of time.

Another approach might be to take a snapshot of the whole protege project for each release. But
then it would be necessary to have a comparison mechanism between release A and B. Is this possible? How do you deal with versioning an releases of the architecture?

Thanks
Wolfgang
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

The development of elements in the architecture are managed within the project using Roadmaps, Architecture States and a new supersedes version slot.

The architecture states group a set of elements in the repository into a state and we can define roadmaps that demonstrate how and when we move from one state to the next.
New versions of e.g. a technology product or an application are captured as a new element and we typically use the version number as part of the name - in particular for technology products. This is a requirement because the new version may (a most likely will) have different relationships to other elements compared to a different version. However, we can link the two "versions" of an application using the supersedes version slot. Note that this is a new feature that appears in the about-to-be-released version 3 of the Essential Meta Model.

Versioning of the repository itself is managed by the Protege platform. Use the Project->Archive capability to manage snap-shot versions, e.g. two per year in your case. You can associate a commentary about the version that's just been archived to aid with selecting to load an archive.

In terms of comparing two repositories, the Prompt Tab provides a very powerful "diff" capability to show how the two repositories have changed. At a more granular level, the Collaborative Protege option provides very fine-grained change tracking with a full history of what has happened to the repository and who changed what. Note that this creates a separate ontology just for managing these changes and this gets very big. We recommend using a database "backend" for what is called the Change Annotations Ontology.

Finally, within Essential Viewer, although we haven't really done much with this, the platform supports the concept of working on multiple repository XML snapshots. This means that you can build a View that provides a perspective on the snapshot now and then run the View on, e.g. last month's snapshot to see how things have changed.

This is a bit of an introduction to lots of different things. It is important to separate versioning of the repository from the development/change of the elements in the repository (e.g. modelling Apache Tomcat 6 and Apache Tomcat 7).

Hope this helps

Jonathan
Essential Project Team
wgoebl
Posts: 20
Joined: 09 Dec 2011, 11:08

Jonathan,

thank you for your quick reply, it helps a lot.

>>New versions of e.g. a technology product or an >>application are captured as a new element and we >>typically use the version number as part of the name - >>in particular for technology products.

The problem I see with this approach that over the years the repository gets quite crowdy and the "Instances" browser of protege does not have a mechanism which can be used to filter in a way that only elements of e.g. the current version of the architecture are displayed. This filter mechanism could be a valuable extension of the protege Instance browser - maybe someone can implement this in the future? How do you deal with this issue?

Thanks
Wolfgang
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Hi Wolfgang,

I agree with what you are saying. I think it comes down to a repository content maintenance issue. If the old products are no longer relevant, then we can remove them from the current repository. We can (and should) take an archive of the repository before we do that so that we can recover them - or see what the repository held.

If however, we want to be able to see the historical aspects within the active repository and the Essential Viewer, then we need to keep these things in the repository. To help with this we added the Taxonomy class which enables you to define your own classifications of anything in the repository. We are using this more and more ourselves, in particular to provide the filtering within Essential Viewer - where it is very important to provide people with the information that is relevant to them.

We can also use these Taxonomies in the Query tab to filter the instances to those that we're interested in and that is quite simple and should go quite a long way. However, as the repository grows finding the instance that you are looking for becomes less simple in modelling activities - but I think that this is a problem that all repositories encounter.

I think any filter on the instance browser would need to use the Taxonomies so that arbitrary filters can be defined to suit the particular modelling activity.

How we deal with this is to make use of the fully-qualified names of instances so that we can be sure we are selecting the correct one in an instance field. The Protege Search capability (the binoculars button) is very useful and you can use wildcards in there, e.g. to find all the IBM Technology Products, you can search for IBM* in the instance browser or any instance selection dialogue.

Navigating the repository around key classes is another useful strategy. E.g. Business Capability, Business Process, Application Service, Application Provider, Technology Component, Technology Product and so on and then navigating the fields defined on the selected instances is much simpler than navigating to the Logical Technology Product Build Architectures - and I would recommend not navigating directly to classes such as the relationship classes or even the architectures unless performing repository maintenance.

Using the Architecture State class enables us to see which elements from across the repository are part of that state, and could be another way of looking at the repository from a particular state-based perspective, and then navigate from them. Note that Architecture States can be fine-grained or coarse-grained and could cover either broad or narrow scopes, so there could be (and should be) more than just "past", "current", "future". However, this approach still provides a well defined context and grouping of the relevant elements of the model.

I tend to make a lot of use of the Protege Search buttons, myself, simply based on the name of the thing I am looking from and from there navigate the relationships of the instance that I have started with.

The beauty of Protege is that it is open source and there are other tab plugins available. The Instance Browser is just one perspective on the repository. It could be worth a quick look at some of the other available tabs to see if there are any that help with this particular problem. And, being open source, it wouldn't be too hard for us to produce a taxonomy-based filter extension to the Instance Browser as a new tab.

Hope this helps

Jonathan
Essential Project Team
Kevin Campbell
Posts: 40
Joined: 13 Sep 2010, 20:26

I thought I'd chime in as we're puzzling over a similar question - an inevitability once you've had a model in place for a year or two. In our case the static architecture of application providers changes over time as applications are retired and replaced.

We're trying to decide what value there is to knowing the dependency that an application used to have, but no longer does. Because we tend to be quite granular in our documentation of APU to APU relation inforeps (helps with impact assessment and reporting on data requiring "special handling") we often find ourselves needing to report on where a data attribute might have been used in an interface in the past.

One possibility might be to version application providers using a naming convention, but that imposes quite a burden in recreating the various architectures that support each app provider.

Kevin
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Thanks Kevin,

Good points.
I would certainly recommend taking the same approach to versions of Application Providers as with Technology Products. If the Application Provider has changed in some significant way (functionality it provides, supporting technology architecture, etc.) it's worth considering capturing this as a new Application Provider instance, appropriately named as you say. Maybe it's a case of adding a version number or something similar to the 'new' Application Provider.

You can then use the supersedes slot (that we've added to the forthcoming version 3 meta model) to relate this 'new' application provider to the instance that reflects the way things used to be before the change.

We have added this slot to all classes but not to the relationship classes. I wonder if managing superseding relationships is realistically manageable - or are you finding that that level of change management is what you need. e.g. Do we need to understand the that relationship between Application A and Application B, defined by a :APU-TO-APU-STATIC-RELATION has changed - and to know what that relationship used to look like (i.e. what is the :APU-TO-APU-STATIC-RELATION that has been updated)?

Really appreciate your input on this

Jonathan
Essential Project Team
Kevin Campbell
Posts: 40
Joined: 13 Sep 2010, 20:26

Jonathan

It's less about the content of the relationship, and more the fact that the relationship used to exist. We work in a very heavily regulated industry with a strong track record of litigation. During discovery we often have to report on sources and targets of data, in some cases going back 7 years. Litigants are keen to know who might still have data related to a transaction even if the prime party has purged it.

We already version our application providers to mirror the suppliers versioning in the case of COTS, so what this would mean would be our own, internal, "sub-version" that we'd update anytime there was a qualifying change to the architectures. We toyed with the idea of using a status attribute on the relationship class, but were daunted by the scope of changes to the report generator and reports themselves that this would require.
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Hi Kevin,

Thanks for the feedback - really good to hear about your requirements.

I agree that tracking this sort of thing on the relationships adds a lot of management overhead. The impact on the Views might not be too bad - but I'd like to make sure we look at this from a few angles.

Out of interest - do you make much use of the Essential Viewer environment? I remember you mentioned that you were also reporting against the Protege database.

Thanks again

Jonathan
Essential Project Team
Kevin Campbell
Posts: 40
Joined: 13 Sep 2010, 20:26

Jonathan

Yes, we use the delivered (and sometiems tweaked) views for quite a lot of our reporting, but we do also leverage a fully relational model based on the EssentialBaseline table. We have a nightly process that infers the class structure based on instances in the database and creates a table for every class, including the associative classes - 342 in total. We then have a series of views constructed to make the information more consumable to traditional reporting tools, and for synchronization with SharePoint.
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Thanks for this, Kevin. Great to hear how you are using the repository in terms of reporting against it. Hopefully, the new Essential Viewer 3 will provide much more in terms of out-of-the-box Views and we think that the framework for assembling those Views is much improved.

Apologies for not getting back to you sooner but we've been exploring a few ideas in the Team about the concept of the multiple versions.

A while ago, one of the guys came up with the idea of having Essential Viewer manage an archive of previous versions of the XML snapshot of the repository.
Currently, when you publish from Protege to the Viewer, the XML snapshot is replaced and the Viewer always uses the latest version. However, the Viewer engine and framework already supports the idea that you can use any XML snapshot as the repository that is queried to dynamically build the Views. In fact, with a bit of organised manual intervention and tweaked custom Views, this is possible right now. There is an impact on the definition of hyperlinks in the Views but we are just finalising a revised approach to this in the [about to be released] Viewer framework to make this far simpler.

What this means is that you would be able to step back in time through a suite of repository snapshots to see what the repository looked like last week, last month, last year etc. We are already exploring (although it will not hold up the version 3 release) how we add this capability to the Viewer. Current thoughts are to add a link to the header page to select the 'version' / 'snapshot archive' on which the queries should run.

To make this work properly, we would also need to tweak the ReportService component of the Essential Viewer (which receives the snapshot from the Reporting Tab in Protege) to perform the archiving in a sensible way. Should this be a manually-controlled option on the report tab - to select when to create an archive copy of the current repository XML snapshot - or whether it is managed automatically (every snapshot is archived)? Or should it be something this is performed on a time basis - e.g. every month an archive is made? Maybe there's something in the ReportService config that controls this automatically?

We'd be very interested to hear your thoughts on how to create / manage the versions of the repository and also whether this Viewer-based approach makes sense and would meet your audit requirements. We're quite excited about it as it solves a whole bunch of complex repository content-management issues trying to manage versions of relationships between versions of elements in the model.

Look forward to your thoughts!

Jonathan
Essential Project Team
ulfl
Posts: 15
Joined: 01 Feb 2010, 10:47

Hi Kevin,

can you share more information about your Sharepoint synchronisation? Do you access the relational tables with Sharepoint? Is the synchronisatsion two-way, can you edit the information in Sharepoint and send it back to Essential?

Best regards,
Ulf
Post Reply