Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic System Architect (steve huntington)
Decrease font size
Increase font size
Topic Title: Best Practise on SA in managing As-is Architecture and To-be Architecture
Topic Summary:
Created On: 28-Oct-2008 07:38
Status: Read Only
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
 28-Oct-2008 07:38
User is offline View Users Profile Print this message


Jeffrey Mak

Posts: 16
Joined: 28-Aug-2008

Should I hold them in separate Encyclopedia?
Report this to a Moderator Report this to a Moderator
 28-Oct-2008 08:46
User is offline View Users Profile Print this message


Peter Crabb-Wyke

Posts: 73
Joined: 3-May-2007

Yes

If you keep them all in one encyclopaedia then over time what was planned to go live but hasn't gets confused with what really is live. That reduces the trust placed in SA and people will become reluctant to maintain the as-is properly,.
Report this to a Moderator Report this to a Moderator
 28-Oct-2008 09:20
User is offline View Users Profile Print this message


Natty Gur

Posts: 14
Joined: 14-Jun-2007

Fully agree with Perer on it. it also enable you to use SA compare between different encyclopedias, though enable to see the gap between as-is and to-be.
Report this to a Moderator Report this to a Moderator
 7-Nov-2008 07:16
User is offline View Users Profile Print this message


Jeffrey Mak

Posts: 16
Joined: 28-Aug-2008

Hi Natty,

The reason for asking this question is that there's a difficulty to manage the migration roadmap of the Enterprise Architecture if I'm strictly separating them into different encyclopedia.

Enterprise Architecture not just about a set of models of As-Is and a set of models of To-Be. Its also about a set of artifacts that help us to model the migration plan of the Enterprise Architecture.

Our job is not stop at getting a As-Is and To-Be architecture and a list of diff result about which symbol and property value are varying. A lot more to do is to group these varying part into migration projects. During these phase, the dependency of these varying part should be taken into account. My view is all these should be captured and recorded in the SA as well.

E.g. a definition "Project" that relates input (as-is architecture elements) and output (to-be architecture elements). Through the in-service date of the "project", I can know the migration plan of our EA.

Separating them into two separate encyclopedia will be failed to capture this dimension of knowledge as the "project" definition is something that sits between "As-is" and "To-be". Which is one of the core part of EA work that needs to be supported by EA tools. SA doesn't take this into account, does it?
Report this to a Moderator Report this to a Moderator
 7-Nov-2008 10:11
User is offline View Users Profile Print this message


Peter Crabb-Wyke

Posts: 73
Joined: 3-May-2007

there isn't an as-is to to-be mapping "out of the box" but you can create one in usrprops in a few minutes.

Your proposed route is certainly the ideal and is technically very simple but it needs a lot of discipline over a long time period.

As-is and to-be are both moving targets and you need to be sure that resource will be available to keep complex mappings up to date for years to come even when budgets get tight and people are being laid off.

Most organisations can't guarantee that sort of stability and once you loose it your encyclopaedia becomes a mess with a random selection of changes to as-is and to-be undocumented.



Edited: 7-Nov-2008 at 10:12 by Peter Crabb-Wyke
Report this to a Moderator Report this to a Moderator
 15-Nov-2008 13:06
User is offline View Users Profile Print this message


Natty Gur

Posts: 14
Joined: 14-Jun-2007

Hi Jeffrey,

I totally understand what you after and I still can argue that it achievable by using two encyclopedias (since i'm using this approach).

one encyclopedia is holding the as-is and indeed this is used as the "input" of projects. the sec encyclopedia is holding the to-be and the projects. projects getting from the as-is the current situation and from the to-be a list of principles, standards and blue prints. the projects might be "related" to to-be artifacts that explain what are the project outcomes. then we're using macro to generate documentation that holds all the data mentioned above for projects.

from my point-of-view a projects is describe in the to-be encyclopedia until it deployed to production. when it deployed to production I'm updating the "as-is" encyclopedia, since the project is now part of the enterprise "as-is". using this approach (together with SA compare i'm keeping track of architecture and manage transition as well).

I also saw that you mentioned that you need more time to develop then to use SA. well, SA is like a platform exactly as a database or a ESB solution. for all of those platforms you need to develop in order to adjust the platform to your own needs. is it make sense to buy an oracle DB and to use it as-is (without writing any code to adjust it)? the same goes to SA.SA is a platform that save you time, but on the other hand required some coding in order to adjust it to your own enterprise needs.

HTH,

Natty.
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic System Architect forum.
There are currently 1 users logged in.
The most users ever online was 16 on 30-Oct-2008 at 14:46.
There are currently 0 guests browsing this forum, which makes a total of 1 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.