Solve:Change Modernization Guide

Solve:Change was a change management system primarily used on z/OS mainframe environments. It facilitated the process of managing and tracking changes to systems, applications, and data. The goal was to ensure changes were implemented in a controlled and auditable manner.

Solve:Change was an application designed to manage change processes. It provided a structured framework for planning, implementing, and tracking changes within an organization's IT environment. It was not a system in itself, but rather a tool to manage changes to systems.

Organizations that relied on mainframe systems, particularly those running z/OS, were the primary users of Solve:Change. These organizations typically operated in industries such as banking, finance, insurance, and government, where stability and controlled change management were critical.

Organizations should have considered Solve:Change when they needed a structured and auditable process for managing changes to their mainframe systems. This was especially important in highly regulated industries where compliance required detailed tracking of all system modifications.

Alternatives to Solve:Change include other change management solutions such as CA Endevor, Compuware Topaz, and IBM Rational Team Concert. These products offer similar capabilities for managing and tracking changes in software development and IT environments.

Solve:Change was designed to run on z/OS mainframe environments. It required access to specific subsystems and datasets within the mainframe environment to manage and track changes effectively. It was tightly integrated with the z/OS operating system.

Solve:Change ran within an LPAR (Logical Partition) on a z/OS mainframe. It was dependent on the z/OS operating system and required specific subsystems to be active and configured correctly. It was not a standalone product and needed the mainframe environment to function.

The core components of Solve:Change included the change request management module, the approval workflow engine, and the audit trail reporting system. These components worked together to provide a comprehensive change management solution. The specific names of these components may vary.

Solve:Change used a combination of ISPF panels and batch jobs for user interaction and background processing. Users typically interacted with the system through 3270 terminals, using ISPF to navigate menus and enter commands. Batch jobs were used for tasks such as generating reports and processing change requests.

Solve:Change helped organizations reduce the risk associated with system changes by providing a structured and auditable process. This resulted in fewer errors, reduced downtime, and improved compliance with regulatory requirements. It also improved the efficiency of change management processes.

Without a change management system like Solve:Change, organizations faced a higher risk of errors, system outages, and compliance violations. Changes to systems could be implemented without proper planning or testing, leading to instability and potential data loss. Auditing and tracking changes became difficult.

The typical licensing model for Solve:Change was likely a perpetual license with annual maintenance fees. The total cost of ownership included the initial license fee, ongoing maintenance, and the cost of training and support. Vendor lock-in was a consideration, as migrating to a different change management solution could be complex.

Solve:Change supported authentication through standard z/OS security mechanisms such as RACF, ACF2, or Top Secret. Access control was typically role-based, with different users having different levels of access to change management functions. Audit logging was a key security feature.

Solve:Change leveraged the security features of the z/OS operating system, including RACF, ACF2, and Top Secret, for authentication and authorization. It also provided audit logging capabilities to track all changes made to the system and data. Encryption was not a primary focus.

Solve:Change provided audit trails that tracked all changes made to the system, including who made the change, when it was made, and what was changed. These audit logs were essential for compliance and security purposes. The logs could be used to investigate security incidents and ensure accountability.

Ongoing operational requirements for Solve:Change included monitoring the system for errors, performing regular maintenance tasks, and managing user access. The system required skilled mainframe operators and administrators to ensure its smooth operation. Staffing requirements depended on the size and complexity of the environment.

Common implementation challenges included integrating Solve:Change with existing systems and processes, configuring the system to meet specific organizational needs, and training users on the new system. Data migration from legacy systems could also be a challenge. Careful planning and testing were essential.

Administrative interfaces for Solve:Change typically included ISPF panels and command-line interfaces. User management was handled through z/OS security systems such as RACF, ACF2, or Top Secret. Configuration parameters were stored in datasets and could be modified using ISPF editors.