Development Landscape

[Van der Burg, Jeroen JA SITI-ITPSEE]

Hi Bill,
 
There are a couple of serious drawbacks to a multi-development system =
approach. One of the main issues is how to synchronise your systems =
after changes in your production stream.=20
 
This can be done either manually (loads of admin overhead and delays for =
even small changes on your production stream; and serious consequences =
if a typo or mistake is made during the sync effort) or automatically =
(with transports, which obviously has a high potential for overwriting =
any release stream developments).=20
 
>From personal experience I would never decide for such a landscape setup =
due to the overhead costs, administrative delays and risks with your =
next go live that will be the result. That is not to say that you will =
not experience any problems when trying to implement major developments =
in a one-stream environment, but at least these problems will not result =
in a major waste of resources as they are focussed on the end goal =
(getting stuff correctly implemented into your production environment) =
and not on non-value adding overhead like transport procedures, =
regression testing and transport management teams which will only =
increase the cost base of your project team.
 
In a one-stream environment with major developments underway Workflow is =
the least of your worries as, due to the versioning and triggering =
functionality, it is not difficult to prepare a major new workflow =
development, test it extensively and only have it replace the existing =
functionality on production after you are completly happy with it; while =
still being able to maintain the existing workflow during development of =
the new functionality. The abap developers do not have those options and =
have to be intelligent (or try to convince their customer that, yes, he =
really really really needs an extra development stream to reach the =
deadline for release 2 blahblahblah).
 
I am unclear what you mean with 'duplicate workflow numbers', when new =
versions are transported to your production environment they will just =
become new active versions of the workflow task definition.
 
 
Hope this helps,
 
 
Jeroen
 
 
 
-----Original Message-----
From: Craig, William [mailto:william.craig at gwl.com]
Sent: 06 May 2003 17:36
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Development Landscape
 
 
All,
I have a general question about development and how other companies have =
set
up their SAP landscape.  Our company just went live with SAP and they =
have
proposed a new landscape because we are going to have a phase 2 go live =
with
some more functionality.  What they have proposed is to have a DEV, QAS, =
and
PROD layout for all existing ABAP and workflows, then they want to =
create
DEV2 and QAS2 by making a copy of DEV and QAS where they will be doing
development work for the next phase.  When they are ready for phase two =
they
will overlay DEV and QAS with DEV2 and QAS2.  They have proposed this
because they are modifying some ABAP code that they are currently using, =
but
it would be incompatible with the current production environment.  The
problem that we see is that for workflow, any modifications or fixes =
would
need to be done in both places, but more importantly if we develop a new
workflow that needs to go into PROD prior to the Phase 2, and we create =
new
workflows for Phase 2 we will have duplicate workflow numbers when Phase =
2
goes into effect.
 
I am guessing we are not the only company in this situation and I would =
like
to hear how other companies have done this.  Perhaps this approach of =
two
DEV and QAS boxes is not a good idea?  If you have any comments or
suggestions we would appreciate it.
 
Thanks,
 
Bill Craig
SAP - Workflow Team
Great-West Life & Annuity
Desk Phone - (303) 737-4053
Email - william.craig at gwl.com