As Is- To Be modelling

[Davenader]

Hi, I'm new to the forum. Hoping you can help.

My organisation is putting together an Enterprise Architecture model.  We are using EA as a knowledge management tool to capture and model actors, roles, processes and architectures into a single respository. Utilising the rich linking and functionality EA provides with links to external items (wiki's and the like)
We are new to using EA. Our model is set up a shared environment an oracle database.  
A challenge to operationalizing the model is around our approach to current vs target state models.  We want to reuse the artefacts in our proposed project models that are within our enterprise model.  Both views may be relevant to clients but we want to ensure we maintain integrity of the enterprise view, should the to be view not proceed.
I am aware of the baseline and version control features but have not used them in great detail. Are these the features we should be exploring in more details or is there anything else we should look at?
Any advice would be appreciated.

[Ian Mitchell]

I share the same question: how to model multiple options in the same EA model. This is applicable to lots of the higher-up models: business architecture, business process, tech. architecture, and is something my customers ask for quite often. Especially as they use EA for more of their business knowledge.
It might help to enumerate some of the ways it MIGHT be done, then perhaps we can work towards how it SHOULD be done.
I'm assuming that, like us, you have multiple versions (not in the EA sense) of a model: for example, a Business Architecture model. Two ways that a future world might look. Sure, we can take an EA baseline of the world "today", then model Plan A as a delta on top of that, and we can use EA Baselines to do some (crude) comparisons between 'today' and Plan A.
We can then do he same for Plan B, but plans A and B are now in two copies of the same model, sharing the same baseline.
I don't know of a way to compare Plan A with Plan B: they are in two models, and may have elements with the same identity (EA GUID) so importing the Plan A elements into the Plan B model risks making a real mess of things.

We thought about a more manual 'branch' approach, where we take the 'today' case, and create ALL NEW elements for Plan A and Plan B - in the same model. As we do so, we relate, say, an element in the 'today' model which gets modified in Plan A as a special kind of connection between the two elements.
This is really time-consuming, and very error prone, and doesn't model elements which get deleted from 'today' to 'plan A' at all.

So that's one way to NOT do it: does anyone have a practical, scalable, sharable way of doing this?

Seems to me that perhaps EA needs to be given a new dimension: make 'version' a much more powerful idea, like it might have in a full-scale CMVC system, and so allow the same element to exist in the same model but linked to multiple versions, or have variations of the same element, not held as EA baselines, but in the model itself. Hard.

So that's my contribution: anyone else?

[qwerty]

Have a look on Zachman (and similar architecture frameworks). Simply speaking the matter is complicated so the answer can't bee simple ;-)

q.

[Ian Mitchell]

Well thanks for that profound insight Q :-)
Now we agree it's hard, can we move on to the answer? What's your view Q ?
I think we need the EA Big Brains on this one!

[qwerty]

 8-)

What I did once was the following: The as-is was reverse engineered from an existing system. This took quite a while (more than a year). Once established, this model was sent to some location in the VC system and then imported into a new repository. There the model was made r/o to all modelers except a core product team. Now this root was cloned to a couple of project roots. That is they got new GUIDs but looked identically to the master model. Now each project team was able to model the individual project roots (we used Require User Lock to Edit). The next step was to identify core elements of the master model. These parts were then eliminated from the clones and replaced by references to the master. Where needed some development done in the project could influence the master model. In that case the new parts were moved from the project to the master and replace by links to the master. The nice thing was that master and project roots could be developed more or less independently.

We did not use baselining. While that makes sense for code it does not make so much sense for models. You can not easily see the semantics of a change. Instead we had tasks forces for changes which influenced either the root or the project models. They had to create a documentation of the identified changes so it was possible to have architectural decisions.

YMMV!

q.

[Ian Mitchell]

Interesting.
The use case I'm trying to figure out (sorry for hijacking the original posting..) is to allow the user to model different alternatives, then compare them, all in the same model.
What I'm imagining is a solution something like:

• Allow user to 'clone' a Package and its contents (including diagrams)
• This creates a new group of elements, but ones which know (via a TV?) who their original Element was ("parent")
• I can do this again to make a clone of clone, or clone the original again to get parallel alternatives
• Cloned elements get their links to other cloned elements (in same group) cloned, but not ones to elements outside the group. This keeps all elements outside the group un-changed - need to play nicely
• Then allow the cloned elements to be changed, deleted, added-to, to form the 'to-be' world
• Allow comparisons of the various 'to be' groups to be compared, using something like the Baseline Compare view
• Finally, and most dangerously, allow a 'to be' group to replace the 'as is' one, once that represents the new world. This would make the solution useful for when we have proposed, but not yet accepted, changes

This seems to use mostly existing EA functions, and a fair bit of bespoke Add-in code.
Anyone have any thoughts on this ?

[qwerty]

I need to cool you down a bit. Comparing code is quite difficult unless it's a single line modified. Even that might make you think hard. A UML model is by far more complex. Adding a single element (and of course its relations!) will change a whole world. You need to make clear why the element has been introduced. That's the challenge. Not finding out which element has been added.

q.

[Davenader]

Sweet, glad this has generated discussion and we are not alone in this challenge.  

To my mind the challenge is around creating branches that we can be quarenteed and then checked back in, updating all links with minimal rework.  The ability to compare branches with each other and the baseline is something my colleagues are quite keen on as well, so interesting thoughts Ian.

qwerty, I'm familiar with the concept of a baselined Master Model library  and then sub libraries which act as the branches.  I've seen that in use with other tools but more at a project level than at the enterprise level.  

Our organisation went with the database set up rather than the team check in check out feature. Perhaps we need to change how we have set this up....?  

[YogaMatt]

Consider this approach:
Use a common library area in your model containing master definitions (classifiers) of all elements (instances) found in in each of your AS-IS and your TO-BE state(s).
To work with library elements in the different temporal model(s):

• For each of your temporal model(s), instantiate only the master elements needed i.e. if an AS-IS application "WIDGET" isn't going to feature in your TO-BE, do not instantiate the WIDGET. Obvious really, but worth saying.
• You can always navigate back to the classifier, and from the classifier you can always see where it is in use in each temporal model.
• Relationships between things in each temporal model are separate, as they should be.
• This enables Gap Analysis and Impact analysis between temporal states using EA's matrix tools.

Now we need to consider "churn".
One type of churn is where the AS-IS keeps evolving whilst you model your future state - where not all change goes through the same control procedures (there's nothing more constant than change). For this situation, if the changes have happened or are certain, you could simply update your AS-IS model. Where the changes aren't certain or haven't happened yet, you can create another branched TO-BE from your AS-IS. And then you move into the territory of multiple impact analysis. All possible. You need to work out the appropriate balance between increased effort and risk mitigation in your situation, in order to decide whether you need to add a branched TO-BE.
Another type of churn is when the designed TO-BE actually becomes the AS-IS. At this time, what was the AS-IS needs to be retired (as it will have been in real life), and the next TO-BE may arise. Taking each in logical order:

• Retiring the AS-IS: up to you what you do. You could leave it in your model, read only. You could baseline it and then move everything from your "was TO-BE now AS-IS" over the top. Either way, you'll have previously sweated the gap/impact analysis assets getting to this point therefore so long as they are documented sufficiently for audit or reviewing your decision making processes, you don't really have to angst about looking back and doing a model compare (that, I agree with forerunners, would be onerous).
• Making the "was TO-BE the now AS-IS": baseline it first then either rename or move it. The event has occurred - it is now your AS-IS. Why do more? It is sufficient for modellers to know this is the current baseline and needs to be maintained for measuring change in your next transition state. There is no ultimate substitute for skill and experience, after all.
• Your next TO-BE. Either you have one already (your project has multiple transition states), or you simply go about creating one. Take a holiday first.

Finally - how to branch one temporal model to create another? Export to XMI and reimport into a new location by stripping GUIDS.

[Glassboy]

Hi there, you're not the first to ask this question here.  The thing that you and your organisation need to properly understand before you embark on this journey is that the target state is never the future state.  Any "to be" modelling you do needs to be completely disposable without leaving any ghosts on your "as is" model.

People also assume that you can move an element from your "to be" into your "as is" and your "as is" will be up to date, but your model will never totally reflect reality.  If you want an accurate "as is" model you have to model what was implimented not the planning for implementation.

So what does this mean?  My advise is never reuse elements from your as-is model.  Clone the element and use a trace relationship back to it.

[Paolo F Cantoni]

Hi there, you're not the first to ask this question here.  The thing that you and your organisation need to properly understand before you embark on this journey is that the target state is never the future state.  Any "to be" modelling you do needs to be completely disposable without leaving any ghosts on your "as is" model.

People also assume that you can move an element from your "to be" into your "as is" and your "as is" will be up to date, but your model will never totally reflect reality.  If you want an accurate "as is" model you have to model what was implemented not the planning for implementation.

So what does this mean?  My advise is never reuse elements from your as-is model.  Clone the element and use a trace relationship back to it.

That is EXACTLY the approach we have taken.  So much so that when a project needs to change an AS-IS element for the future TO-BE, they HAVE to create a clone since the AS-IS is locked to prevent them changing it.


Glassboy is ABSOLUTELY right in emphasising that the design model is NOT the implementation model.  The implementation model should, wherever possible, be a reverse engineer of the real world, passed through the various abstractions to trace back to the other models.


Paolo

[YogaMatt]

Thank you both

There is no conflict in the propositions here:

Hi there, you're not the first to ask this question here.  The thing that you and your organisation need to properly understand before you embark on this journey is that the target state is never the future state.  Any "to be" modelling you do needs to be completely disposable without leaving any ghosts on your "as is" model.

Instantiation means there are no ghosts - merely that the AS-IS and TO-BEs each have a heritage in the building blocks in the common architectural repository (such as described in TOGAF (OK, I've just been on the course  )).
You could dispose entirely of your TO-BE (or your AS-IS for that matter). Hence my statement that things are entirely separate in each temporal model.

People also assume that you can move an element from your "to be" into your "as is" and your "as is" will be up to date, but your model will never totally reflect reality.  If you want an accurate "as is" model you have to model what was implemented not the planning for implementation.

I'm not amongst said people. Instead, the idea is that the TO-BE becomes the AS-IS (when indeed it is).

So what does this mean?  My advise is never reuse elements from your as-is model.  Clone the element and use a trace relationship back to it.

Classifiers and instances does this, but having a common library allows for re-usable components that are not part of the AS-IS but could be part of a number of candidate TO-BEs.

[Viking]

• This creates a new group of elements, but ones which know (via a TV?) who their original Element was ("parent")

Could somebody tell me what is meant by TV? I can only think about Trace Relationship.

[qwerty]

Tagged Value

q.