![]() |
Telelogic System Architect (steve huntington) | ![]() |
Topic Title: How to manage the versioning of Applications in SA? Topic Summary: Created On: 26-Oct-2008 04:33 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Our company has new release of 200 something applications in each quarter.
In the repository, we have definition "Application" which represent these release. Therefore, we have definitions like "CRM v 1" and "CRM v2"... etc. The problem is that an application (e.g. CRM v1) has a huge amount of relationship with other systems. They may also involved in a many diagrams which show the data flow with other applications etc. Often, when a new release come (e.g. CRM v2), most of these relationship maintains the same as CRM v1. Only a few functions inside the system changed. So, how can I introduce the CRM v2 into the model with all those relationship the same as CRM v1 and also with diagrams having CRM v2 without doing it from stratch again and again for each quarter? What are the best practise in SA to handle the change of architecture for each quarter? |
|
![]() |
|
![]() |
|
I think the answer to that one might be "with difficulty".
A lot depends on how many releases are live at any one time and how much "as was" and "to be" as opposed to "as is" data you need. I would consider a separate change event definition type that can be linked to both node and relationship definition types. Every relationship has a "birth" and a "demise" which can be reported with VBA and each release is identified through the dates on the change event object. May work for you or may not but its probably the least worst approach. |
|
![]() |
|
![]() |
|
We have just been addressing this recently.
Alongside Application as a Definition, we have defined an "Application Release" - where an application will have one or more releases over time. SO there is only one Definition for an Application ie. "CRM System" but multiple releases CRMv1, CRM V2 etc. Each Release has a first and last quarter date defined - so that we don't need to duplicate the release for every quarter. The reporting then uses the first and last quarter values to show a) What are the new information flows between applications in each quarter b) What are the information flows at a point in time We are using System Architecture Diagrams to build up the picture of individual application / information flows and we are then able to show these on an Explorer diagram of applications. It is necessary to query the dates for applications at both ends of the information flow as different applications will be coming on stream at different points in time. |
|
![]() |
|
![]() |
|
Thanks Ted.
Some place i have question is: App (e.g CRM) --has listOf--> App Release (e.g. Collection of: CRM v1, CRM v2 and CRM v3) However, in the System Architecture Diagram, you use CRM instead of a particular release. How do you find out which release does the System Architecture Diagram actually refers to (i.e. CRM v1, CRM v2 or CRM v3)? |
|
![]() |
|
![]() |
|
Hi Jeffrey,
I would implement it with one definition that has all the common attribute and a set of symbols. each symbol represent the app version and holds all the attribute related to this instance (even relationships). something like the idea behind capabilities that we discussed. HTH, Natty, |
|
![]() |
|
![]() |
|
Jeffrey
Yes - as you have pointed out, I have added Application Release to the System Architecture diagram and the information flows are defined between these. The Explorer Diagram contains applications, so the object report is along the lines of App > App Release > App Release Symbol > Connects Information Flow > App Release Symbol > App Release > App - with date queries on both App Release definitions... |
|
![]() |
|
![]() |
|
Hello Ted,
Don't you see the problem here? App > App Release > App Release Symbol > Connects Information Flow > App Release Symbol > App Release > App The Information Flow links up to the "Release". Imagine it, if App1_v1 have a 100 information flow to App2_v1, and you have a new release App1_v2 which has some attribute change but nothing about information flow. What do you need to do to ensure all reports that go through the above path still works? You will need to construct all those 100 information flow from App1_v2 to App2_v1 in a new diagram. Otherwise, any report that needs to go through the path you suggested doesn't work for App1_v2. This is a huge amount of tedious work that doesn't add value to the EA. Not counting that an application release hardly involve in a small amount of diagram in practise. I don't see how this work for you. |
|
![]() |
|
![]() |
|
Version management can easily degenerate into documentation for its own sake.
After a lot of pain we no longer try to track versions in detail. We know the current version of each application and regard routine upgrades as "business as usual" rather than as changes to the architecture. I am still trying to untangle some of the more "over versioned" applications in SA where things have got out of sync between different models. I would only concern myself about a new version in more detail if there was a replatforming or significant change in business functionality involved. |
|
![]() |
|
![]() |
|
Agreed it can get complicated, but in this case, we really do need to understand the information flows between applications.
We are using the term release rather than version - we are not tracking every version change of every application, but only changes to applications that result in changes to information flows... We can just take a copy of the existing diagram e.g. CRM v2, and make any changes on this - can we not? The date querying is more complicated than we first thought - if there are two applications, App A and App B - an information flow is only "live" when both App releases are live - they may have different release dates... |
|
![]() |
|
![]() |
|
We use a similar system. We use a heavily tailored definition for interfaces and this carries a lot of data about the interface itself as well as links to the both the "live from" and "live until" releases. The release definition carries its implementation date.
If the only visible effect of a release was to change interfaces then I wouldn't touch the application definitio at all, just update the appropriate diagrams with the new interfaces. In a complex architecture it is useful to create some macros that verify diagram content and identify any missing objects plus some orphan reporting of course. We did get a Popkin (as it was then) consultant to write us a VBA application that will allow us to update the same field across multiple definitions on a diagram. This saves us a lot of time when creating or changing multiple interfaces. Edited: 10-Nov-2008 at 11:39 by Peter Crabb-Wyke |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.