Hi all,
I was wondering how to model different versions of application providers.
Imagine an application, that in the current version is a strategic element of the application landscape, but will be replaced by a next version that will provide new functionality, thereby supports additional business processes, etc.
That means, we want to maintain both versions of the application (of special interest regarding the Strategy Mgmt.), without duplicating all information from the first to the next application version.
Looking forward any recommendation how to deal with that.
Regards, Andre
Modelling versions of Application Providers
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Hi Andre,
Thanks very much for your post.
The way we model a new version of an Application Provider is to create a new instance of an Application Provider meta class and name it accordingly. E.g. I have an application provider, called 'MyApp', then I create a new Application Provider, 'MyApp version 2'.
We take exactly the same approach, by the way, with the Technology Products. So, Oracle 9i and Oracle 10g are captured as separate Technology Products.
This might sound like a rather simplistic approach to versioning of the applications but actually, it is very powerful as it enables us to capture in detail what's different about the new version.
So, if the new version adds new functionality, we can add the new functionality, the relationship to the new processes that it supports. However, if the underlying technology architecture for the application remains the same, we relate the new version of the application to the same technology build as the original version. And this principle applies to the other relationships from the Application Provider, e.g. the static application architecture, high-level software architecture and so on.
So, the level of re-work/duplication involved in this approach is really quite low. Mostly, it's about connecting the new version to the architectures that apply to it - reusing what things are the same between the 2 (or more!) versions and then describing what's different.
Maybe the technology platform for the new application has changed, in which case we need to define the Technology Build for it and relate this new build to the new version of the Application Provider.
If you name the new version along the lines of what I've described above, then it's very easy in both Protege and in the Essential Viewer to see the versions next to each in the various catalogues. However, it could be that the new version of the application has a totally new name. In this case, we would use that new name - the organisation will know this new version by the new name - and it's through the Application Service(s) that it supports that we can understand that this new version provides the same or similar functionality as the previous version.
Hope this helps.
Jonathan
Thanks very much for your post.
The way we model a new version of an Application Provider is to create a new instance of an Application Provider meta class and name it accordingly. E.g. I have an application provider, called 'MyApp', then I create a new Application Provider, 'MyApp version 2'.
We take exactly the same approach, by the way, with the Technology Products. So, Oracle 9i and Oracle 10g are captured as separate Technology Products.
This might sound like a rather simplistic approach to versioning of the applications but actually, it is very powerful as it enables us to capture in detail what's different about the new version.
So, if the new version adds new functionality, we can add the new functionality, the relationship to the new processes that it supports. However, if the underlying technology architecture for the application remains the same, we relate the new version of the application to the same technology build as the original version. And this principle applies to the other relationships from the Application Provider, e.g. the static application architecture, high-level software architecture and so on.
So, the level of re-work/duplication involved in this approach is really quite low. Mostly, it's about connecting the new version to the architectures that apply to it - reusing what things are the same between the 2 (or more!) versions and then describing what's different.
Maybe the technology platform for the new application has changed, in which case we need to define the Technology Build for it and relate this new build to the new version of the Application Provider.
If you name the new version along the lines of what I've described above, then it's very easy in both Protege and in the Essential Viewer to see the versions next to each in the various catalogues. However, it could be that the new version of the application has a totally new name. In this case, we would use that new name - the organisation will know this new version by the new name - and it's through the Application Service(s) that it supports that we can understand that this new version provides the same or similar functionality as the previous version.
Hope this helps.
Jonathan
Essential Project Team
