6\VWHP $GPLQLVWUDWLRQ 0DGH (DV\

Chapter 11: Security AdministrationSecurity LayersIn the development pipeline, changes are:1. Made in the development system2. Tested in the development system3. Transported from the development system to the test system4. Tested in the test system5. Transported from the test system to the production systemThis procedure ensures that changes are properly tested and applied to the systems in thepipeline. (A pipeline is the environment where development is moved from thedevelopment system to the quality assurance system, and finally to the production system.)Configuration changes should not be made directly into the production system. Thisrestriction maintains the integrity of the production system. If changes are made directlyinto the production system, it may “break” because the change: Was not tested Is not the same as the one made in the development systemThe goal is to protect the production system from changes, without the changes beingproperly tested and to preserve the integrity of the pipeline. If changes are made into theproduction system, the development and testing pipeline could become out of sync with theproduction system. If the pipeline is out of sync, it get difficult to develop and test with anycertainty that things will not be different in the production system.All changes should be made in the development system and then transported through thepipeline into production. In this way, all systems get the same changes. A common excuse isthat making changes directly into the production system, “takes too long to transport thefix.”By making changes directly into the production system, you: Create an “out of sync” landscape, where the change made to the production system isnot the same as the changes made to the development or test systems. Allow emergency transports to occur at any time, with coordination.Infrequent exceptions occur when: There is no mechanism to transport the changes. An SAP note requires the direct change.11–12Release 4.6A/B