Right Number of Environments

[jdel6654]

Let me start by saying I have worked in E1 CNC for over 10 years. The question has come up about the number of environments needed to support a new, phased implementation.

This is a new install for a customer new to E1. This is a non-coexistant configuration for a customer going from World to E1 9.0. AS400 enterprise server with WebSphere web servers. No windows clients. Mfg, Fin, SC, Dist modules. ~750 concurrent users. ~15 Full-time developers. 3 AS400 partitions and 5 subsystems.

I have the following standard environments setup:

PS/JPS
DV/JDV
PY/JPY
PD/JPD

Over the course of the project I have set up several other non-std environments:

DVSAVE - Save environment for DV code
ES/JES - ESU Environment for pristine + ESUs (ES pathcode)
TR/JTR - training environment (QA pathcode)
DV2 / JDV2 - For developers that uses some World integration (DV pathcode)
XX/JXX - Environment that uses Windows enterprise servers for specific E1 features. (PY pathcode)
QA/JQA - custom pathcode for pre-production testing
MD/JMD - master data staging environment for pre-production setup (PD pathcode)
CV/JCV - conversion environment for Phase 1 (DV pathcode)
CV2/JCV2 - conversion environment 2 for Phase 2 (DV pathcode)

I have been asked to set up another environment. This environment is for "production bug fixes". This environment will use the prod pathcode and a daily copy of the production data. I really don't know exactly what production bug fixes are in distinction to regular bug fixes tested in a different environment. We can copy our data selectively to most of the environments at just about any time.

I have a handful of other environments that were aborted not too long ago. I am of the opinion that given OCMs, ESUs, etc., we are about right for environments. More environments, IMHO, will contribute to more inpredictability.

Long story short, I am curious to know what other CNC people consider the "right" number of environments for a similar situation. While I would appreciate any comments, "it depends" and "every company is different" doesn't really help.

Let me know what you think.

 

[Terry DeMoure]

Well for my ten years and seven implementations and migrations I have only seen DV, PY, and PD needed. However, for my current company the addition of one additional environment was suggested for pristine code seeing that they have been a little naughty with some limited customization. ALL of our implementation testing was accomodated in PY Test Environment with no additional environments needed.

 

[Jotto]

The number of environments you have listed looks way overboard. But, that's where your cliche "every company is different" could come into play.

We use the standard DV/PY/PD for our development chain.

We had a TR for training, but it became an administrative burden, so we just changed testing and training to PY. We have a Pristine, and a Pristine + ESU, but they really never get referenced. Once you have any modest amount of functional customization, it really renders the pristine environments mostly useless. We have a DVSAVE for development, and we added an internal PYSAVE and PDSAVE for copying the "previous" objects to before promotion so that we have a clean back-out ability.

Due to the fact that we are currently performing a worldwide migration of several of our sites and from several different other ERP systems, we have created a PYB, which is a clone of the PY Data, so that we can test and configure two different data conversions simultaneously. They both share the same PY pathcode for objects, so there is no break in the development chain.

Once we have converted them all, I can foresee PYB being removed.

Our final environment is UA (User Acceptance) which is probably functionally similar to your QA. It is just a mix of Production objects against PY data. This allows users to use and interact with the live Production applications and code against non-production data for final system testing. Once it was established, it adds no additional overhead to developers or administrators.

To me, it looks like you may have more environments than are really necessary, and need a couple red-tape dispensers on your desk.

In my opinion, too many environments just becomes confusing, a burden on developers, users, and administrators alike, and introduces too much room for loss of object/development chain integrity.

Hope that helps,

-John

 

[Tom_Davidson]

I think it depends on the situation, I was at one large implementation where they were rolling out in 22 different contries. We had something like 15 environments, due to the need to keep data static for testing, training, etc. Having multiple environments just plain made things easier.

Tom

 

[gregglarkin]

[ QUOTE ]
I think it depends on the situation, I was at one large implementation where they were rolling out in 22 different contries. We had something like 15 environments, due to the need to keep data static for testing, training, etc. Having multiple environments just plain made things easier.

Tom

[/ QUOTE ]

Tom,

Ditto in my shop. We have one DV pathcode and one PD pathcode. In PY, we have six environments. The environments share the same code, but have different business data to allow us to have multiple projects going on in parallel. We have pristine which is sledom used. We have an ESU pathcode (Pristine plus patches) that is never used for testing. The Pristine pathcode is used for applying ESUs against only. I apply the ESUs there, and then the developers take the objects they want from the ESU pathcode and move them into DV.

- Gregg

 

[Larry_Jones]

6654,

I think it really does depend on the requirements . . . AND the size of staff you have. To me all those environments you have seem to be much more complicated then really needed. We're small, and we NEED the KISS principle. Just the standard 4 environments plus a SAVE environment.

 

[ice_cube210]

Here's what I have usually seen / would like / setup

The Usual std out of the box 4 (Environment / pathcode)

PS / PS
DV / DV
PY / PY
PD / PD

Non Std as below

DEVSAVE - Just a pathcode

ESU ( Copy of pristine , but all ESU's get applied here) - This can usually just be a pathcode, doesn’t need an environment , only use it to do a ER compare before applying an ESU to see if object needs any custom retrofits

QA /QA (This is an extra environment, larger sites typically have it. Only things that have passed all testing in PY make it here. QA could be the Cross Application Testing. May not make much sense for a small implementation)

Training (TR / TR) - Again for large sites , or sites still having roll outs etc. TR could be a copy of QA for the objects , you can configure OMW to move objects to TR also when moving from PY to QA). Once a System reaches its maturity in terms of modules and users , TR can usually be retired or at least the resources can freed at the minimum

Support / Prodtest ,what ever you want to call it - Basically PD pathcode , but not the live data (usually copied nightly /weekly etc from Prod. Some sites have this , some do fine without. But if you do set this up , it's a good idea for it to have its own Versions datasource and not point to that of Production


There can be a lot of temporary environments added and removed to DV/PY during migrations / conversions etc , but that "would really depend on the site"

 

[jdel6654]

Thanks for everyone's opinion.

As a point of clarification, we have about 6 production locations in 5 countries. Although we have several business units, all business units will ultimately share a single production instance.

E1 environments are one of those things seems to have a lot of benefits but noone really considers the costs.

 

[jdel6654]

Larry,

Can you say how many users you have ? CNC admins?

 

[Larry_Jones]

Sure . . . about 250 users (max 100 concurrent).

As far as CNC admins . . . Business applications support headcount is 2.25 supporting JDE, Oracle DB, and other - non JDE - business apps. So we wear multiple hats like many out there. One guy is the main CNC admin (along with analyst, developer, and support roles). He has a .25 backup from our Notes Admin/Developer. I'm mainly developer and DBA role with just enuff CNC to be dangerous.

 

[Terry DeMoure]

Hey Larry...how effective is the CNC support person classisified as .25? lol

It was great to see all the feedback for you jdel6654 and it is true...every company is different and so is the "right" number of environments. I hope that all of our input has been helpful and we wish our best to those JDE Team members that certainly have their work cut out for them.

 

[jdel6654]

Yeah, JDELIST is very good for this kind of thing. Sometimes you have to be a full-time CNC to see the bigger picture. I think environments are one of those things. Most CNC people understand that you have to have a balance between meeting the users testing needs and sustaining the stability of a given environment.

Its really not that hard to create a new environment, most people don't realize there is a lot of care and feeding of the environment after you create it.