Multiple versions of a Component

[jdavid]

1: We use a Component to define the overall application (Component Name = Middleware)
2: We have 10 team that are adding new features to this component

What is the best approach to manage this
1: Make copy of the component and change version for each team
2: Create an instance for each team
3: Use Clone Structure as a new version for each team?

[PDC]

I assume the Features are not mutually-exclusive, and there is no 'integration' feature in between them (i.e. they share a common interface and are basically plug-and-play into the Component). So you are essentially managing a PLE problem with multiple possible variations.
When I have done this kind of thing in the past with EA (and not saying this is the best, simplest or only way to do it) we would define each Feature in its own Package. Then each 'Product' (for you, 'Component') would be defined as a separate Block in its own Package, and would be comprised of each Feature as required. I'm sure there will be other ways to do it (e.g. I haven't used any dedicated PLE plugins for EA...), just sharing one way that we tackled this with EA.

[Geert Bellekens]

The problem I have with all of your approaches, is that it results in multiple elements all representing a single component.
Now if I want to get a complete view of the impact of this component, I somehow have to merge all versions of this component together.

Wat we do, is use a single element for a component. If needed, we mark the relations to future or past states.

Try "the simplest thing that could possibly work" first, and only if you really encounter a problem start thinking about solutions.
I've seen too many times that people think of "potential" problem, and implement very complex solutions for these "potential" problems that never really where a problem in the real world after all.

Geert

[Modesto Vega]

This indeed looks a PLE or feature release problem, as noted by PDC.

Although I agree with this comment from Geert, it was actually the first thing I thought about.

The problem I have with all of your approaches, is that it results in multiple elements all representing a single component.
Now if I want to get a complete view of the impact of this component, I somehow have to merge all versions of this component together.

I think that you need to consider a couple of additional things:

1) Are any features going to be developed in parallel? If they are, I would not use multiple components or packages.
2) Are any features going to be developed sequentially, supersede existing features, and released as separate versions? If they are, I would use multiple components or packages.

For any features developed sequentially and released as separate versions, if you have a starting baseline component architecture I would suggest cloning baseline components as a new version to track their evolution overtime.

Three other comments/considerations are:
3) What modelling language are you using? UML and SysML are very different from ArchiMate. I think your approach needs to be adapted to your modelling language.
4) Packages in Sparx EA have a dual personality, they are elements and folders. This adds additional complexities to problem like the one you are trying to resolve.
5) As hinted by Geert, Sparx EA has no mechanism to merge features into a new baseline. (But cloning as a new version can be used to split a baseline).

[jdavid]

So, we have 1 application - Middleware

We have 10 different development teams that are working on different features to add to the Middleware application or update an existing feature of the application.

The release process is very flexible where 1 or more of the team may be releasing their new / update feature at the same time.

[PDC]

The problem I have with all of your approaches, is that it results in multiple elements all representing a single component.
Now if I want to get a complete view of the impact of this component, I somehow have to merge all versions of this component together.

I see your point - but from a PLE perspective, if we assume that 'standard 1' of the Component is for CustomerX/ProductX, 'standard 2' of the Component is for CustomerY/ProductY (etc...) then it is almost 'useful' to have different Elements representing them - it *could* make overall PLE integration easier if we are only using the native EA features and no specific PLE plugins etc. For one thing it keeps Customer requirements/IPR more neatly confined with less risk of one customer's dirty laundry to bleed into another customer's product (to use a mixed metaphor ).

Wat we do, is use a single element for a component. If needed, we mark the relations to future or past states.

This would be a good approach. I'm glad you have faith in your Config Management team

Try "the simplest thing that could possibly work" first, and only if you really encounter a problem start thinking about solutions.

100% best mindset for all of MBSE, especially where there is an element of business evolution (switch from paper to MBSE) and/or no requirement to implement a particular approach/framework etc.