Author Topic: Modeling As-Is and To-Be  (Read 5141 times)

ssands

  • EA User
  • **
  • Posts: 91
  • Karma: +0/-0
    • View Profile
Modeling As-Is and To-Be
« 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

Glassboy

  • EA Practitioner
  • ***
  • Posts: 1367
  • Karma: +112/-75
    • View Profile
Re: Modeling As-Is and To-Be
« Reply #1 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

Nizam Mohamed

  • EA User
  • **
  • Posts: 193
  • Karma: +1/-0
    • View Profile
Re: Modeling As-Is and To-Be
« Reply #2 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.

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +396/-301
  • I'm no guru at all
    • View Profile
Re: Modeling As-Is and To-Be
« Reply #3 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.

Nizam Mohamed

  • EA User
  • **
  • Posts: 193
  • Karma: +1/-0
    • View Profile
Re: Modeling As-Is and To-Be
« Reply #4 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

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +396/-301
  • I'm no guru at all
    • View Profile
Re: Modeling As-Is and To-Be
« Reply #5 on: May 16, 2014, 10:41:52 pm »
YMMV

q.