As-Is and To-Be modelling

Post Reply
aducci
Posts: 14
Joined: 14 Oct 2011, 13:42

Hi,

what is the best method for as-is and to-be modelling in Essential, Specifically to maintain an application portfolio as well as business processes.

I am thinking that the applications will have life-cycle attributes associated to them (ie, operational, review, decommissioned)

the problem comes with the processes, i would like to model the variations in the processes specific to the as-is and to-be scenarios? Would i need two databases?

Thanks
paulmcmahon
Posts: 16
Joined: 01 Aug 2012, 05:19

No need for two databases, you use architecture states to assist with this.

Paul
aducci
Posts: 14
Joined: 14 Oct 2011, 13:42

Hi,

Thanks Paul, I will try the architecture states.

I also find the architecture state may not handle process variants, where elements of the process deviate from the norm (ie, some remaining portion of the process remain the same) The architecture state attribute assumes only one state at a time.

Also, child objects do not inherit the parent's architecture state properties in Essential so using Architecture State means manually changing each and every object to match it's parent's state which is prone to errors, conflicts and omissions as the repository grows
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Paul is right. Architecture States is how we manage as-is and to-be.

Process variations are defined using the Business Process class.
If we discover that we have, e.g. two variants of the Invoice process, we create a new Business Process that defines how this varies from the existing one. This means that we can track the specific dependencies on each variation, e.g. who is performing which variant, which systems support which variant and so on.

In terms of the architecture state, you can have as many elements in a state as you need and of course an element can appear in more than one architecture state. Everything is added to the default state (by default ;) ) but we can define as many different states as we need.
Of course, each state need not reflect the entire architecture and it's often more effective to focus on specific perspectives, e.g. Regional MDM Implemented state (that describes the people, processes, applications etc. that we need for regional master data management), rather than current, future across the whole enterprise architecture.

You can add and remove elements to/from architecture states from either end of the relationship - from the element itself or from the architecture state. When defining a new architecture state, it's probably simpler to come at it from the state as you can quickly multi-select the elements that you want to add to it - but note that you do this by separate 'layers' of the architecture, e.g. Business Logical things, Business Physical things.

I like to think about architecture states as like drawing a line around a group of things in the architecture into a specific context.

Jonathan
Essential Project Team
Post Reply