This PowerUp blog entry was written by Bruce Guetzkow. He has been an IT professional for more than 25 years, mostly with Power Systems servers running IBM i and its predecessors. He is currently Webmaster for the Wisconsin Midrange Computer Professional Association, an advisor for the Programmer/Analyst Track and Adjunct Instructor at Gateway Technical College in Kenosha, Wis., and an independent consultant for GmanTech Consulting in Delavan, Wis.
Proper management of source and objects is crucial to delivering quality applications. Having mismatched source and objects mean never being sure that the changes you’re making will work as planned. Even the most carefully planned manual process can be prone to errors.
Change management is an application designed to ensure a consistent, reliable process to maintain business environments. This is important whether you are part of a large team or the sole developer in an organization.
All developers should know that objects need to be created in a well-defined sequence: physical files, then logical files, printer and display files, etc. The sequence does not change with each update unless new objects are added to the mix, as happened when the Integrated Language Environment (ILE) introduced modules and service programs to IBM i. The sequence is logical and not difficult to understand, it is just tedious to deal with when installing application changes. These rules, which can be defined within change management tools, will be followed for each application update. They can also be modified should a future need arise.
When IBM first launched the AS/400 server, its applications were typically very simple. Companies could easily build their own tools to manage source and objects. Today's applications involve complex designs, incorporating components that may not even reside on a Power Systems box. Even those that exist solely within the IBM i framework may include parts stored on the Integrated File System (IFS), which may require special handling. While companies may still be able to build their own tools, as new technologies continue to emerge and be adopted, these tools must also be adapted to meet those challenges.
Without endorsing any specific vendor, several excellent change-management products are available that not only manage traditional source and objects but also newer Web-related ones. In addition, many of these tools also make it easy to keep various working environments in-sync, such as production, development and multiple test environments. If your development or test environment is different from your production environment, are you sure you know what you’re developing or testing?
Change management is not a function of the size of a development team. Some people believe that change management is not necessary for a small development team as everyone knows what the others are doing and contention for source and objects can be resolved simply by shouting over the cubicle walls. Even as a one-man development team, I felt that having change management tools was a necessity to keep environments viable. In addition, I could always be assured that source and objects were installed in a consistent manner. If a particular object had special requirements, such as an override or temporary creation of a dependent object, the change-management solution, once instructed, would always remember those requirements for subsequent changes.
If you aren’t using any change-management process (homegrown or vendor-developed) to manage your development process, consider how much time you spend with each application update. I believe that the return on investment will be quickly recovered with the time savings and certainty of knowing that your process has properly updated all environments.
Proper management of source and objects is crucial to delivering quality applications. Having mismatched source and objects mean never being sure that the changes you’re making will work as planned. Even the most carefully planned manual process can be prone to errors.
Change management is an application designed to ensure a consistent, reliable process to maintain business environments. This is important whether you are part of a large team or the sole developer in an organization.
All developers should know that objects need to be created in a well-defined sequence: physical files, then logical files, printer and display files, etc. The sequence does not change with each update unless new objects are added to the mix, as happened when the Integrated Language Environment (ILE) introduced modules and service programs to IBM i. The sequence is logical and not difficult to understand, it is just tedious to deal with when installing application changes. These rules, which can be defined within change management tools, will be followed for each application update. They can also be modified should a future need arise.
When IBM first launched the AS/400 server, its applications were typically very simple. Companies could easily build their own tools to manage source and objects. Today's applications involve complex designs, incorporating components that may not even reside on a Power Systems box. Even those that exist solely within the IBM i framework may include parts stored on the Integrated File System (IFS), which may require special handling. While companies may still be able to build their own tools, as new technologies continue to emerge and be adopted, these tools must also be adapted to meet those challenges.
Without endorsing any specific vendor, several excellent change-management products are available that not only manage traditional source and objects but also newer Web-related ones. In addition, many of these tools also make it easy to keep various working environments in-sync, such as production, development and multiple test environments. If your development or test environment is different from your production environment, are you sure you know what you’re developing or testing?
Change management is not a function of the size of a development team. Some people believe that change management is not necessary for a small development team as everyone knows what the others are doing and contention for source and objects can be resolved simply by shouting over the cubicle walls. Even as a one-man development team, I felt that having change management tools was a necessity to keep environments viable. In addition, I could always be assured that source and objects were installed in a consistent manner. If a particular object had special requirements, such as an override or temporary creation of a dependent object, the change-management solution, once instructed, would always remember those requirements for subsequent changes.
If you aren’t using any change-management process (homegrown or vendor-developed) to manage your development process, consider how much time you spend with each application update. I believe that the return on investment will be quickly recovered with the time savings and certainty of knowing that your process has properly updated all environments.
Recent Comments