Sparx Systems Forum

Enterprise Architect => General Board => Topic started by: ssands on May 16, 2014, 08:04:01 am

Title: Modeling As-Is and To-Be
Post by: ssands on May 16, 2014, 08:04:01 am

Apologies in advance if I missed this while searching...

I need to create both As-Is and To-Be architectures. There will be many common components between the two models, but in some cases connectors between components in one model will not be present in the other. That is, the Future state will redefine some component integrations.

Given that, how can I best model this while accessing a common package of components (or can I)?

I could make a copy of the components for the new model, but then I have duplicate packages of components across the models, which I prefer not to do.

Thanks in advance,
Stu

Title: Re: Modeling As-Is and To-Be
Post by: Glassboy on May 16, 2014, 08:56:39 am

Hi Stu, I duplicate components precisely to avoid linkages to my current state components.  It just takes one project that doesn't finish to make a mess of your current state.  Also the future state is never the target state, so you end up having to reconcile two models back to you current state

Title: Re: Modeling As-Is and To-Be
Post by: Nizam Mohamed on May 16, 2014, 01:25:45 pm

Stu
You might also consider this,
For some of my clients, we've setup two repositories, one, the prod and one being the dev repository. We created this by copying the dev from prod, to start with.
All the changes, including new relationships to as-is components are added in the Dev repository, which is shared by all the projects in progress at any point of time.
When the project is ready for deployment, the changes are merged to the Prod repository (using diff / merge in EA, as these models are just a copy of each other, with same element GUIDs).
They are finding it useful, 'cos

• All the projects that are in progress will share the to-be system.
• Merging the changes is relatively easier with the  Diff/Merge tool
• The Prod (BAU) systems are safe, and isolated from unwarranted changes.

Title: Re: Modeling As-Is and To-Be
Post by: qwerty on May 16, 2014, 04:07:56 pm

I'd only model the to be and highlight there critical paths. Nobody wants to pay for two models as it's double the work. Eventually you could make a sketch of the as-is to highlight what could be re-used.

q.

Title: Re: Modeling As-Is and To-Be
Post by: Nizam Mohamed on May 16, 2014, 07:16:31 pm

Quote

Nobody wants to pay for two models as it's double the work

May be not, it depends on how important is your as-is model, and who all refers to those as-is models or where it is published.
Not sure if business users would want to see and understand whatever is gonna be there in the next decade!

IMHO its not double work, as long as it is planned properly and done by the right team

Title: Re: Modeling As-Is and To-Be
Post by: qwerty on May 16, 2014, 10:41:52 pm

YMMV

q.