US20110209115A1 - Computer software implemented framework for configuration and release management of group systems software, and method for same - Google Patents

Computer software implemented framework for configuration and release management of group systems software, and method for same Download PDF

Info

Publication number
US20110209115A1
US20110209115A1 US13/098,710 US201113098710A US2011209115A1 US 20110209115 A1 US20110209115 A1 US 20110209115A1 US 201113098710 A US201113098710 A US 201113098710A US 2011209115 A1 US2011209115 A1 US 2011209115A1
Authority
US
United States
Prior art keywords
layer
business processing
libraries
source code
custom
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US13/098,710
Inventor
Michael S. Weil
Steven N. Nau
Wayne P. Webb
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
HSBC Technology and Services USA Inc
Original Assignee
HSBC Technology and Services USA Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by HSBC Technology and Services USA Inc filed Critical HSBC Technology and Services USA Inc
Priority to US13/098,710 priority Critical patent/US20110209115A1/en
Publication of US20110209115A1 publication Critical patent/US20110209115A1/en
Assigned to HSBC TECHNOLOGY & SERVICES (USA) INC. reassignment HSBC TECHNOLOGY & SERVICES (USA) INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: HSBC NORTH AMERICA HOLDINGS INC.
Assigned to HSBC NORTH AMERICA HOLDINGS INC. reassignment HSBC NORTH AMERICA HOLDINGS INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WEBB, WAYNE P., NAU, STEVEN N., WEIL, MICHAEL S.
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/70Software maintenance or management
    • G06F8/71Version control; Configuration management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
    • G06Q50/10Services
    • G06Q50/18Legal services; Handling legal documents
    • G06Q50/188Electronic negotiation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q90/00Systems or methods specially adapted for administrative, commercial, financial, managerial or supervisory purposes, not involving significant data processing
    • G06Q90/20Destination assistance within a business structure or complex

Definitions

  • the present invention generally relates to a framework for configuration and release management of group systems software. More particularly, the present invention relates to a framework for configuration and release management of group application systems software in an application-based software system such as, for example, an account management system; financial system, or banking system.
  • the framework of the present invention provides for configuration and release management of group application systems software both globally to the software system and locally to business units within the software system.
  • the configuration and release management of group systems software, and in particular group application systems software in an account management system of a large banking entity, can involve software changes and deployment at both the global level and at the local level.
  • a global bank such as HSBC conducts business in 76 countries and territories around the world. These operations are managed in four geographical regions: the Americas; Europe; the Middle East and Africa; and Asia Pacific. Each of these regions encompasses multiple countries, and each country includes several strategic business units, or SBUs, which are HSBC's smallest business operating divisions.
  • SBUs strategic business units
  • HSBC deploys mainframe-based “group systems” software applications. These software applications may be developed in-house, or may be based around commercially-available software packages which are supported by a vendor and enhanced by HSBC as necessary.
  • a difficulty in employing an account management system of the complexity and scope of the HSBC system is the amount of overhead that accompanies deployment of a complete copy of the system for each of the SBUs using the system.
  • a complete copy of the software system may include, for example, source code, copybooks, and job control language for each of the software application components within the software system.
  • source code for example, source code
  • copybooks for example, job control language for each of the software application components within the software system.
  • job control language for each of the software application components within the software system.
  • much of the group application systems software is common for all SBUs, with only a relatively small amount of customization necessary for an application to effectively support an individual SBU.
  • FIG. 1 An example of a computing system deployment planning method is disclosed in Tseng et al. International Patent Publication No. WO 03/098490, published Nov. 27, 2003, shown in FIG. 1 , and incorporated herein by reference.
  • the computing system deployment planning method of FIG. 1 is implemented using deployment planning system 10 , which resides on a computer-based system that is networked for access to a component profile server 12 .
  • User 14 interacts with deployment planning system 10 through a graphical user interface 16 .
  • Deployment planning system 10 includes a plurality of component profiles stored in a component profile repository. Deployment planning system 10 allows for the deployment of services or a computing system with just the component profiles of the required components. The component profiles are used for deployment testing prior to implementation of the actual system components.
  • the method starts at step 20 .
  • a new software package is introduced.
  • the software package and its description are entered in a service distribution server and stored in a global software repository.
  • target regions for distribution of the software package are selected. This step is performed by the software distribution server to determine all the region servers whose service profiles match the service that is going to be provided by the new package.
  • the software is distributed from the software distribution server to a region server.
  • the software distribution server For each region in the target set (computed in step 22 ), the software distribution server prepares a package that is suitable for target machines in that region. This package is then transported to the region.
  • the region server determines if each of the potential targets has the appropriate resources (e.g., CPU, RAM, disk space, swap space, etc.).
  • the region server retrieves the target roles.
  • the software is distributed from the region server to the target machines.
  • the results of the software distribution are gathered, and tests are done on the installed software. Installation results are gathered at the region server.
  • the region server sends the status of the distribution step to the software distribution server, and the method ends.
  • Application operation definition storage files are removed from application server computers 30 , 32 , and 34 and are instead provided on management server computer 36 .
  • Management server computer 36 includes application operation definition storage file 38 to systematically manage application computers 30 , 32 , and 34 via network 40 .
  • application management section 42 looks up the operation definition data of the requested application from application operation definition storage file 38 .
  • Application management section 42 executes a to-be-managed application 44 .
  • Application management section 42 stores the state of executed application 44 in application current state update file 46 .
  • application management section 42 When application management section 42 receives an interrupt message indicating an end event of the executed application, application current state update file 46 is used to store the application execution history. The application execution request is then transmitted to all application server computers in server computer group 48 via network 40 . Upon receiving the execution request, application management section 42 looks up the operation definition of the requested application in application operation definition storage file 38 . Except when the operation definition of the application indicates that the application operates in the requesting computer, application management section 42 discards the execution request in application server computer 30 . The application execution request is then processed using an application management section in another application server computer (e.g., application server computer 32 or 34 ) by accessing application operation definition storage file 38 .
  • application server computer e.g., application server computer 32 or 34
  • Software building and deployment system 62 manages the deployment of software and content to a development environment 64 , a testing environment 66 , and a production environment 68 .
  • development environment 64 contains all of the code and content that hosts the web site for the public.
  • a component is promoted from one environment 60 to another when that component meets the required quality assurance test criteria assigned to each particular environment 60 .
  • One or more servers 70 host each environment 60 .
  • Software building and deployment system 62 handles all aspects of the deployment of software and content to environments 60 .
  • System 62 interfaces directly with one or more source code repository systems 72 .
  • System 62 also interfaces with external builders 74 , which handle the compilation of source code.
  • system 62 interfaces with content deployment and replication engines 76 which handle the actual movement of source code and content to environments 60 .
  • System 62 controls interactions between source code repositories 72 , external builders 74 , and content deployment and replication engines 76 so as to manage all changes to one or more computing environments 60 . In this way, every change to an environment 60 is handled and tracked by system 62 as a separate release. System 62 is instructed to create a new release in an environment 60 through a manifest 78 .
  • Manifest 78 includes the instructions necessary for system 62 to select the correct source material from repositories 72 , compile the material, if necessary, using builder 74 , and deploy the compiled versions to the appropriate environment 60 using a deployment and replication engine 76 . All changes to an environment 60 are initiated by a manifest 78 , and therefore each manifest 78 is considered to define a new release for the environment 60 specified by the manifest 78 .
  • the system architecture includes a total of five layers: business applications layer 90 , application bus layer 92 , application services layer 94 , technology bus layer 96 , and technology platform layer 98 .
  • Business applications layer 90 includes common application services that provide needed common application functionality to the business applications.
  • Application bus layer 92 provides the necessary communication protocols and configuration information to allow any application to invoke any needed service, regardless of the physical location of that requested service. For example, there may be requests from business application layer 90 to services within application services layer 94 .
  • Application services layer 94 includes a number of modularized service engines and common application services, which may be invoked from business application layer 90 or from within the application services layer.
  • Technology bus layer 96 provides access to technology platform layer 98 . This layer insulates the business applications and application engines from the physical hardware, the network, and the physical data storage mechanisms.
  • Technology platform layer 98 includes a number of different technology platforms.
  • a framework for configuration and release management of group application systems software may provide for the configuration and release management of group application systems software in an application-based software system such as an account management system, both globally to the account management system and locally to business units within the account management system.
  • an application-based software system such as an account management system
  • the framework of the present invention is described herein primarily in the context of an account management application-based software system, and in particular a credit card account management system. However, this is merely illustrative, and one of skill in the art will realize that the framework of the present invention may be applied to any suitable application-based software system that requires the configuration and release management of group systems software.
  • SBUs strategic business units
  • HSBC For a global bank such as HSBC, numerous group systems may be used within a credit card account management system. HSBC, for example, designates about 18 application systems within the credit card account management system as group systems. These group systems may be in use in more than one of a group's SBUs.
  • the framework of the present invention has been built and enhanced on the premise that common functions can be provided through a single set of “base” source code, while allowing country- or SBU-specific processing through modifications, control parameters, and the integration of locally-developed solutions.
  • the present invention provides a global framework to manage the source and execution components that provide and support the production environments to support business software applications. (The framework of the present invention may be referred to interchangeably herein as both a “framework” and a “global framework.”)
  • the global framework of the present invention is both a structure and a set of associated tools and processes that allow a single base of program code and related components to be managed and modified, thereby meeting the processing needs of business units within the account management system.
  • the global framework provides flexibility to incorporate software changes as business needs evolve, while keeping code release versions consistent and current across all business units within the account management system. This flexibility results in an improved speed-to-market for changes to the account management system.
  • the elements of the global framework include:
  • the global framework of the present invention includes various features and components for configuration and release management of group systems software.
  • the global framework includes source, copybook, load module, and related libraries used to contain components of the card system. Such components may include, for example, JCL, PROCs, control cards, etc.
  • the global framework includes naming conventions to ensure segregation and control of both global and SBU-specific components, libraries, and datasets for development, testing, and production.
  • the global framework includes a comprehensive change management structure that controls the use of software version promotion levels.
  • the framework supports the concurrent development of components within the framework.
  • the component change management tool used in conjunction with the framework is ChangeMan®, sold by SERENA Software, Inc. of San Mateo, Calif.
  • the global framework of the present invention and its associated tools, processes, and procedures effectively deliver group application systems software within an account management system.
  • the global framework provides standardized tools and techniques for concurrent development of software for multiple SBUs from a single source platform. In doing so, the global framework significantly reduces the number of system components for which changes need to be managed for users of a particular group system.
  • a complete deployment of group application systems software supporting a credit card account management system may include about 21,000 components of source code and copybooks. Of these 21,000 components, only about 2,500 (or about 12%) may be specific to a large SBU, with smaller SBUs having significantly less customization.
  • the framework of the present invention may be used in connection with any entity (e.g., vendor, governmental agency, in-house developer, etc.) that provides updates or changes to the credit card account management system.
  • Possible software updates may include, for example, compliance updates, enhancement releases, and fixes.
  • Compliance updates address any changes to operating regulations by a credit card provider (e.g., Visa, MasterCard). These operating regulations change on a regular basis to meet the needs of all credit card issuing and acquiring members. As a result, payment card association members, banks, and processors must comply with these amendments on a set schedule. These mandates are usually effective on the first of April and the first of October of each year.
  • a software vendor or in-house developer develops compliance updates for all components within a credit card account management system. These compliance updates are delivered by the vendor or in-house developers typically in mid-February and mid-August. The bank then accepts these updates for integration into the bank's specific version of the credit card account management system.
  • Enhancement releases address any new features and functionality that are added to the credit card account management system. These releases may be created by a vendor, or may be created in-house. (Various updates, enhancements, and fixes may be described herein as “vendor” or “in-house.” It should be noted that the framework of the present invention may be used in conjunction with any changes to the software, whether developed by a vendor or an in-house developer. The description of vendor or in-house developed code is for illustration only.) Typically, vendor enhancements are delivered every twelve to eighteen months, and are packaged as a new release of the business system. The vendor's enhancement releases are integrated with a bank's version of the credit card account management system for delivery in an internal enhancement release.
  • Fixes may be released by a vendor or by in-house developers to correct any specific software problems or to update system processing based upon the business needs of the bank or a specific SBU.
  • the framework of the present invention controls the libraries and environments used in production and release testing.
  • the framework supports the current version of the card system in production, and one or more additional versions to support the development and testing of a new software release to be implemented at the SBU level.
  • Once the software release is certified as “production ready” it may be implemented by one or more SBUs as the result of a conversion.
  • At any one time up to, for example, three (3) versions of the group application systems software may be used in production operation.
  • the framework of the present invention includes multiple layers to segregate globally-applicable software from software that applies only to specific SBUs.
  • the layers of the framework permit the use of a single base of global source code and components to be used as a foundation for all card system users, while supporting the specific needs of each SBU.
  • the framework may include six layers: global, base, regional, custom, environment, and local. However, these layers are merely illustrative, and the framework may include some, all, or additional layers to the six layers recited above and described hereinbelow.
  • the global layer of the framework provides a development environment for credit card system developers.
  • the global layer acts as the initial point at which vendor source code and/or copybook enhancements are integrated with the custom enhancements developed by in-house developers on behalf of all SBUs.
  • the global layer supports the process of merging two compatible sets of source code and copybook libraries into a full set of merged programs (e.g., source code and copybooks) that forms the foundation of the global credit card system, so that these programs can be compiled and preliminarily tested, prior to staging of the applications into the base layer.
  • enhancement releases, and fixes at the global layer of the framework changed components are staged to the appropriate libraries at the base layer for integration, testing, and subsequent installation in the production environment. Changes that are specific to only certain SBUs, and not to the entire card system, may follow a similar staging process at the custom layer of the framework.
  • the base layer provides support for the development and installation of sub-systems within. the card system. Vendor and homegrown solutions are integrated into the global credit card system at the base layer. In addition, in-house developers may apply further fixes and modifications to the credit card system, as appropriate, at the base layer. This process requires the merging of homegrown changes with vendor-supplied source code and copybooks to create the merged base set of libraries for source code and copybooks.
  • card system global load modules are baselined and installed at the regional layer. In addition, all related and required components for the abovementioned card system global load modules are also baselined and installed.
  • the regional layer provides a point at which SBU production load libraries are distributed to support execution in batch or online.
  • the regional layer contains the execution libraries for base layer load modules, so that individual SBUs can easily access the appropriate components in a local operational environment. This is accomplished through concatenations of load module libraries.
  • the regional layer load module libraries eliminate reliance on a single physical set of base layer libraries for load modules. In some embodiments, developers are prevented from changing the contents of these load libraries, except through the authorized promotion/installation processes defined within the change management software at the base layer.
  • the custom layer provides the ability to maintain the integrity of the global card system through code management tools and infrastructure.
  • the custom layer provides enhanced ability to minimize time to market for minor releases and fixes to the card system, and more particularly to the software applications utilized by specific SBUs.
  • the custom layer also provides support for the evolution of solutions that have been proven and tested at the SBU level to be deployed globally as a part of a major release.
  • the custom layer provides the ability for each SBU to identify and implement processing rules and data that are specific to local market needs. New or modified components that exist in the custom layer are accessed during execution at the environment layer by use of concatenations of the load module libraries within JCL that point to the custom layer libraries first. If any given component is not found at the custom layer, then the regional layer load module libraries will be used.
  • the environment layer is the operational processing environment in which all card system applications execute and where data files and databases are controlled and updated.
  • the environment layer includes batch and online processing environments that support testing and production requirements.
  • the environment layer includes a complete set of databases, files, and execution environments for each SBU. A distinct environment (e.g., batch and online) is created for each testing level required to support the SBU, as well as for production.
  • the data files and databases are updated only by card system applications.
  • the local layer is a complete environment created for each SBU that contains non-card system application load modules that are used by an SBU and are dependent on card system data and may use data from other sources. These non-card system applications receive interface data from the environment layer during or after execution of card system applications. The definition, development, and maintenance of these local applications may be managed and controlled, for example, by staff at the SBU.
  • a global framework computer based architecture may be provided.
  • the architecture may include a source code management system that provides executable development and testing environments to support component applications in production.
  • the architecture may include at least one set of associated tools and processes, in operative interaction with the source code management system, providing a single base of program code for the component applications to be managed and modified by the source code management system using the executable production environments for multiple business processing systems using the global framework computer based architecture.
  • the architecture may provide functionality and may be adapted to manage modifications of the multiple business processing systems, while simultaneously maintaining software source code release versions consistent and current across the multiple business processing systems.
  • the architecture may, for example, reduce the number of source code management system components for which changes need to be managed for the multiple business processing systems.
  • the architecture may further include a single set of libraries that contain substantially all common source code management system elements applicable to the multiple business processing systems.
  • the architecture may further include individual code libraries for the multiple business processing systems that contain modifications specific to a business processing system to meet local needs of the business processing system and providing the multiple business processing systems the functionality of concatenation.
  • the architecture may further include individual online and/or batch execution environments to support data management and processing for each of the business processing systems.
  • the architecture may further include at least one set of associated tools and processes, in operative interaction with the source code management system, to enable consistent use of and modification to source code management system elements common to the multiple business processing systems.
  • the architecture may further include at least one regional load module library, in operative interaction with the source code management system, providing for installation of revised source code management system components for a specific business processing system or for multiple business processing systems within a particular time zone.
  • the architecture may further include a plurality of naming standards to control and identify components, libraries, data sets, and/or execution environments within the source code management system.
  • a global framework multi-layer computer based architecture including at least one source code management system that provides executable production environments to support component applications
  • the multi-layer architecture may include a base layer providing development and installation functionality for multiple business processing systems within the source code management system.
  • Source code for the multiple business processing systems may be staged to the base layer for integration with existing source code for the multiple business processing systems to create a merged base set of libraries.
  • the merged base set of libraries may contain substantially all common source code management system elements applicable to the multiple business processing systems.
  • the merged base set of libraries may be tested in the base layer prior to implementation of the merged base set of libraries.
  • the multi-layer architecture may include a custom layer, in operative interaction with the base layer, providing development and installation functionality for a business processing system of the plurality of business processing systems within the source code management system.
  • Source code for the business processing system may be staged to the custom layer for integration with existing source code for the business processing system to create a merged custom set of libraries.
  • the merged custom set of libraries contains substantially all modifications specific to the business processing system to meet local needs of the business processing system, and the merged custom set of libraries used to create the load libraries in the custom layer used in the concatenation.
  • the merged custom set of libraries may be tested in the custom layer prior to installation of the merged custom set of libraries.
  • the custom layer may, for example, reduce time to market for modifications specific to each business processing system of the multiple business processing systems.
  • the multi-layer architecture may further include a global layer, in operative interaction with the base layer, providing development functionality for the multiple business processing systems within the source code management system.
  • Source code for the multiple business processing systems may be developed within the global layer.
  • the source code developed within the global layer may include, for example, source code from a plurality of separate entities.
  • the source code from the plurality of separate entities may be merged for testing in the global layer prior to staging to the base layer.
  • the multi-layer architecture may further include a regional layer, in operative interaction with the base and custom layers, providing installation functionality for the merged base set of libraries.
  • the installed base set of libraries may support execution by the multiple business processing systems in batch and/or online by allowing the multiple business processing systems to implement the base set of libraries, if necessary, by concatenating the custom set of libraries and the copy of the base set of libraries maintained at the regional layer.
  • the base set of libraries in the regional layer may be protected, for example, such that contents of the base set of libraries cannot be changed at the regional layer.
  • the multi-layer architecture may further include an environment layer, in operative interaction with the custom layer, providing processing functionality for a business processing system of the plurality of business processing systems.
  • the installed base set of libraries support execution by the multiple business processing systems in batch and/or online by allowing the multiple business processing systems to implement the base set of libraries, if necessary, by concatenating the custom set of libraries and the base set of libraries.
  • the environment layer may include, for example, a complete set of databases and data files for each business processing system of the multiple business processing systems.
  • the multi-layer architecture may include a local layer, in operative interaction with the custom layer, providing application load modules for each business processing system of the multiple business processing systems.
  • the local layer load modules may be dependent upon source code management system data.
  • a global framework multi-layer computer based architecture including at least one source code management system that provides executable production environments to support component applications
  • the multi-layer framework may include a global layer providing development functionality for multiple business processing systems within the source code management system.
  • Source code for the multiple business processing systems may be developed within the global layer.
  • the multi-layer framework may include a base layer, in operative interaction with the global layer, providing development and installation functionality for the multiple business processing systems.
  • the source code for the multiple business processing systems may be staged to the base layer from the global layer for integration with existing source code for the multiple business processing systems to create a merged base set of libraries.
  • the merged base set of libraries may contain substantially all common source code management system elements applicable to the multiple business processing systems.
  • the merged base set of libraries may be tested in the base layer prior to installation of the merged base set of libraries.
  • the multi-layer framework may include a regional layer, in operative interaction with the base layer, providing installation functionality for the merged base set of libraries.
  • the installed base set of libraries may support execution by the multiple business processing systems in batch and/or online.
  • the regional layer of the multi-layer framework may include source code components and load module components as a copy of the base layer installed load module components.
  • the multi-layer framework may include a custom layer, in operative interaction with the regional layer, providing development and installation functionality for a business processing system of the plurality of business processing systems, wherein source code for the business processing system is staged to the custom layer for integration with existing source code for the business processing system to create a merged custom set of libraries.
  • the merged custom set of libraries may contain substantially all modifications specific to the business processing system to meet local needs of the business processing system and providing the business processing system the functionality of concatenation.
  • the merged custom set of libraries may be tested in the custom layer prior to installation of the merged custom set of libraries.
  • the multi-layer framework may include an environment layer, in operative interaction with the custom layer, providing processing functionality for the business processing system of the plurality of business processing systems.
  • the installed base set of libraries may support execution by the multiple business processing systems in batch and/or online by allowing the multiple business processing systems to implement the base set of libraries, if necessary, by concatenating the custom set of libraries and the regional copy of the base set of libraries.
  • the multi-layer framework may include a local layer, in operative interaction with the environment layer, providing application load modules for each business processing system of the multiple business processing systems.
  • the local layer load modules may be dependent upon source code management system data.
  • a source code management system may be provided.
  • the source code management system may include a first multi-layer framework for managing and maintaining an existing production environment for multiple business processing systems.
  • the first multi-layer framework may include a global layer, base layer and a custom layer in operative interaction with the base layer.
  • the base layer may provide a base set of libraries including source code management system elements common to the multiple business processing systems.
  • the custom layer may provide a custom set of libraries including source code specific to a portion of the business processing systems.
  • the first multi-layer framework may further include a complete set of change management software mnemonics, source libraries, copybook libraries, and/or load module libraries to support the base and custom layers of the second multi-layer framework.
  • the source code management system may include a second and subsequent multi-layer frameworks, in operative interactive with the first multi-layer framework.
  • the second multi-layer framework may provide functionality for development and testing of a source code enhancement release within the source code management system.
  • the second multi-layer framework may include a global layer, base layer and a custom layer in operative interaction with the base layer.
  • the base layer may accept the enhancement release.
  • the custom layer may integrate release modifications and test the enhancement release.
  • the custom layer may receive contents of the custom layer of the first multi-layer framework.
  • the second multi-layer framework may further include a complete set of change management software mnemonics, source libraries, copybook libraries, and/or load module libraries to support the base and custom layers of the second multi-layer framework.
  • the enhancement release may be tested within the second multi-layer framework prior to implementation within the first multi-layer framework.
  • the second multi-layer framework may revert to a testing environment upon certification and installation of the enhancement release.
  • the first and second multi-layer frameworks provide the ability to rollback changes to a previous version of the source code management system if there are any problems with the enhancement release.
  • first and second multi-layer frameworks may be independent of each other and can exist at the same time.
  • the second multi-layer framework may integrate code from the first multi-layer framework and then exist and function independently of the first multi-layer framework. This allows an SBU to be subject to a conversion from the first multi-layer framework to the second multi-layer framework without any rollback.
  • a method for configuration and release management of group application systems software within a source code management system may be provided.
  • One or more changed components of group application systems software may be received at a global layer of the source code management system.
  • the one or more changed components of the group application systems software may be integrated into a single set of merged programs at the global layer.
  • the single set of merged programs may be tested at the global layer.
  • the one or more changed components may be merged into a base set of libraries for source code and copybooks at a base layer of the source code management system.
  • the one or more changed components may be tested at the base layer.
  • the load modules for the merged components may be installed at a regional layer using base load modules.
  • the multiple business processing systems may be provided with the ability to implement the base set of libraries in batch and/or online by allowing the multiple business processing systems to concatenate a custom set of libraries at a custom layer and the base set of libraries.
  • a method for configuration and release management of group application systems software within a source code management system may be provided.
  • One or more changed components of group application systems software may be received at a custom layer of the source code management system.
  • the one or more components may be applicable to only a portion of multiple business processing systems within the source code management system.
  • the one or more changed components may be merged at the custom layer with a base set of libraries for source code and copybooks to create a custom set of libraries.
  • the custom set of libraries may be tested at the custom layer.
  • the custom set of libraries may be installed at the custom layer using custom load modules.
  • the multiple business processing systems may be provided with the ability to implement the custom set of libraries in batch and/or online by allowing the multiple business processing systems to concatenate the custom set of libraries and a base set of libraries at a regional layer.
  • FIG. 1 illustrates a prior art computing system deployment planning method
  • FIG. 2 illustrates a prior art method for service and role-based software distribution
  • FIG. 3 illustrates a prior art system and method for application management
  • FIG. 4 illustrates a prior art system and method for software building and deployment
  • FIG. 5 illustrates a prior art method and apparatus for software deployment
  • FIG. 6 is a schematic diagram of an illustrative global framework including a plurality of layers in accordance with some embodiments of the present invention.
  • FIG. 7 is a schematic diagram of an illustrative process for creating multiple sets of copybook libraries for the global framework in accordance with some embodiments of the present invention.
  • FIG. 8 is a schematic diagram of an illustrative process for creating multiple sets of online source code libraries for the global framework to support development and testing in accordance with some embodiments of the present invention
  • FIG. 9 is a schematic diagram of an illustrative process for creating multiple sets of batch source code libraries for the global framework to support development and testing in accordance with some embodiments of the present invention.
  • FIG. 10 is a schematic diagram of an illustrative process for scheduling of packages for installation at the base layer of the global framework in accordance with some embodiments of the present invention.
  • FIG. 11 is a schematic diagram illustrating the geographic distribution that takes place when an installation such as the installation of FIG. 10 is performed in accordance with some embodiments of the present invention
  • FIG. 12 is a schematic diagram of an illustrative process for change management software package installation and baseline processing in the global framework in accordance with some embodiments of the present invention.
  • FIG. 13 is a schematic diagram of an illustrative process for promotion of changed components within the custom layer of the global framework for testing in accordance with some embodiments of the present invention
  • FIG. 14 is a schematic diagram of an illustrative concatenation process for each testing level of the global framework in accordance with some embodiments of the present invention.
  • FIG. 15 is a schematic diagram illustrating the change management software mnemonics for each layer of the global framework and additional versions of the global framework for new releases in accordance with some embodiments of the present invention
  • FIG. 16 is a schematic diagram of an illustrative process for development and testing of the next release to be implemented at the SBU level using the shadow global framework in accordance with some embodiments of the present invention.
  • FIG. 17 is an illustrative flow diagram that demonstrates the configuration and release management of software globally to the account management system in accordance with some embodiments of the present invention.
  • FIG. 18 is an illustrative flow diagram that demonstrates the configuration and release management of software locally to specific SBUs within the account management system in accordance with some embodiments of the present invention.
  • a framework for configuration and release management of group application systems software is provided.
  • the framework of the present invention may provide for the configuration and release management of group application systems software in, for example, an account management system, both globally to the account management system and locally to business units within the account management system.
  • the global framework of the present invention includes various features that result in an improved method for configuration and release management of group application systems software in an account management system, and in particular a credit card account management system.
  • Such features may include, for example, a single set of libraries that contain common card processing system elements (e.g., the “global version” of the system); policies, processes, and procedures that allow for consistent use of and modifications to common card system elements; regional load module libraries to manage installation and distribute revised card system elements at a specific site or for a set of time zones; individual code libraries for SBUs that contain business unit specific modifications to meet local needs (e.g., local modifications that supplement or replace global business processing); individual execution environments (e.g., online and batch) to support data management and processing for each SBU; and naming standards to control and identify components, libraries, data sets, and execution environments.
  • common card processing system elements e.g., the “global version” of the system
  • policies, processes, and procedures that allow for consistent use of and modifications to common card system elements
  • regional load module libraries
  • the framework of the present invention has been built and enhanced on the premise that common functions can be provided through a single set of “base” source code, while allowing country- or SBU-specific processing through modifications, control parameters, and the integration of locally-developed solutions.
  • the present invention provides a global framework to manage the source code and related components that provide executable production environments to support business software applications.
  • the global framework of the present invention is both a structure and a set of associated tools and processes that allow a single base of program code and related components to be managed and modified, thereby meeting the processing needs of business units through the use of a common account management system.
  • the global framework provides flexibility to incorporate software changes as business needs evolve, while keeping code release versions consistent and current across all business units within the account management system. This flexibility results in an improved speed-to-market for changes to the account management system.
  • the global framework of the present invention includes various features and components for configuration and release management of group application systems software.
  • the global framework includes source, copybook, load module, and related libraries used to contain components of the card processing system. Such components may include, for example, JCL, PROCs, control cards, etc.
  • the global framework includes naming conventions to ensure segregation and control of both global and SBU-specific components, libraries, and datasets for development, testing and production.
  • the global framework includes a comprehensive change management structure that controls the use of software version promotion levels as described herein.
  • the framework supports the concurrent development of components within the framework.
  • the component change management tool used in conjunction with the framework and processes described herein is ChangeMan®, sold by SERENA Software, Inc. of San Mateo, Calif.
  • the global framework of the present invention in combination with its associated tools, processes, and procedures effectively deliver group application systems software within an account management system.
  • the global framework provides standardized tools and techniques for concurrent development of software for multiple SBUs from a single source platform. In doing so, the global framework significantly reduces the number of system components for which changes need to be managed for users of a particular group system.
  • the framework of the present invention may be used in connection with any entity (e.g., vendor, governmental agency, in-house developer, etc.) that provides updates or changes to an application-based software system such as an account management system, a credit card account management system, or other financial services system.
  • entity e.g., vendor, governmental agency, in-house developer, etc.
  • Possible software updates may include, for example, compliance updates, enhancement releases, and fixes.
  • Compliance updates address any changes to operating regulations, for example, by a credit card provider (e.g., Visa, MasterCard) or by a governmental agency (e.g., Sarbanes-Oxley, etc.).
  • a credit card provider e.g., Visa, MasterCard
  • a governmental agency e.g., Sarbanes-Oxley, etc.
  • Visa and/or MasterCard operating regulations change on a regular basis to meet the needs of all credit card issuing and acquiring members.
  • payment card association members, banks, and processors must comply with these amendments on a set schedule. These mandates are usually effective on the first of April and the first of October of each year.
  • a software vendor or in-house developer develops compliance updates for all components within a credit card account management system. These compliance updates are delivered by the vendor or in-house developers typically in late February and August. The credit card member then accepts these updates for integration into the specific version of the credit card account management system.
  • Enhancement releases address any new features and functionality that are added to, for example, the credit card account management system. These releases may be created by a vendor, or may be created in-house. Typically, vendor enhancements are delivered every twelve to eighteen months, and are packaged as a new release of the business system. The vendor's enhancement releases are integrated with a credit card member's version of the credit card account management system for delivery in an internal enhancement release.
  • Fixes may be released by a vendor or by in-house developers to correct any specific software problems or to update system processing based upon the business needs of a specific SBU.
  • the framework of the present invention controls the libraries and environments used in production and release testing.
  • the framework supports the current version of the account management system in production, and release versions of the framework which allows for the development and testing of a software release to be implemented at the SBU level. More than one version of the global framework can be created to support multiple SBUs each operating on a different release version of the account management system.
  • the previous software version of the account management system continues to be used by SBUs that were already using it in production, until such time as they are ready for conversion to a later release version of the account management system.
  • promotion features are provided in connection with the promotion of a software fix, enhancement, or release within the global framework.
  • the lifecycle of a fix, enhancement, or release starts with development of source code changes and ends with installation and implementation.
  • the developer of the software using change management software such as ChangeMan®, initiates a process that incorporates all software components affected by a change.
  • change management software such as ChangeMan®
  • the promotion process leads to the migration of the appropriate components from the current level of development or testing to the next higher level of testing (e.g., within the global framework). This process continues until the package is determined to be “production ready,” at which time the package is installed.
  • the installation process of the present invention is initiated after extensive testing to ensure that the load modules and related components are production-ready. This testing results in a certification by the system that the modules and components are ready for installation.
  • Load modules are installed via the change management software package into load module libraries, based upon a predefined schedule for the package.
  • the package of software changes is installed, for example, in the corresponding library or libraries for the global account management core system or in an SBU-specific library or libraries.
  • the global framework of the present invention is made up of component management structures, referred to herein as “layers,” configuration management and reporting tools, naming standards, and library types. Each of these features of the global framework is described in detail hereinbelow, in connection with FIGS. 6-16 .
  • the global framework of the present invention includes a number of layers to support segregation of globally-applicable software solutions from those that apply to specific SBUs. These layers advantageously permit the use of a single base of global source code and components to be used as the foundation for all account management system users, while still supporting the specific needs of each SBU.
  • the global framework may include any number of layers. As shown in FIG. 6 , for example, the global framework is illustrated as including six layers. This example is merely illustrative, however, and the framework may include some, all, or additional layers to the six shown in FIG. 6 .
  • FIG. 6 illustrates the following six layers: global layer 102 , base layer 104 , regional layer 106 , custom layer 108 , environmental layer 110 , and local layer 112 .
  • Global layer 102 provides a development environment for software developers in, for example, a credit card processing system.
  • Global layer 102 acts as the initial point at which vendor source code/copybook enhancements are integrated with the custom enhancements created by in-house developers on behalf of all SBUs.
  • Global layer 102 supports the process of merging the two compatible sets of source code and copybook libraries into a full set of merged programs (source code and copybooks) that forms the foundation of the global account management system, so that the merged programs can be compiled and preliminarily tested.
  • homegrown applications which are an integral part of the overall account management system , are developed, compiled and tested as part of the global layer 102 , prior to staging into base layer 104 (staging described in more detail hereinbelow).
  • Base layer 104 provides support for the development and installation of all sub-systems. Vendor and homegrown solutions are integrated into the global card system at base layer 104 . In addition, in-house developers may apply further fixes and modifications to the system at base layer 104 , as needed.
  • the process at base layer 104 involves the merging of homegrown changes with vendor-supplied source code and copybooks to create a merged base set of libraries for source code and copybooks. Upon completion of integration and testing of these changes in the appropriate base layer environments, system global load modules are installed at regional layer 106 .
  • Regional layer 106 provides a point at which production load libraries are distributed to support execution in batch or online.
  • Regional layer 106 contains an exact copy of the execution libraries for base layer 104 load modules, so that individual SBUs can easily access the appropriate components in a local operational environment (e.g., environment layer 110 ). This is accomplished through concatenations of load module libraries.
  • Regional layer 106 load module libraries eliminate reliance on a single physical set of base layer 104 libraries for load modules. These load libraries are protected such that developers cannot change their contents, except through the authorized promotion/installation processes defined within the change management software at base layer 104 (described hereinbelow).
  • Custom layer 108 provides a number of advantages to the SBUs in the system. For example, custom layer 108 minimizes the time to market for minor releases and fixes within the global framework. Custom layer 108 provides the ability to maintain the integrity of the global system solution through code management tools and infrastructure. Custom layer 108 provides support for the evolution of solutions that have already been proven at the SBU level to be deployed globally as part of a major release.
  • Custom layer 108 provides the ability for each SBU to identify and implement processing rules and data that are specific to local market needs.
  • a custom layer 108 exists for each SBU and includes of a set of component libraries that are used for development of SBU-specific source code/copybook changes and additions to the system.
  • Changes that are made at custom layer 108 by in-house developers are merged with corresponding source code and copybooks that have been created at base layer 104 , similarly to the changes made at global layer 102 . This merge is accomplished through change management software tools and promotion levels. Changes are developed, tested, and promoted through necessary environment levels, until they are ready for installation. At that point, in-house developers request an install of the package through the change management software. As a result of the installation via the change management software, the changes are baselined within custom layer 108 .
  • New or modified components that exist in custom layer 108 may be accessed during execution by use of concatenations of the load module libraries within JCL that will point to the custom libraries first. If any given component is not found at custom layer 108 , regional layer 106 load module libraries will be used.
  • Environment layer 110 is the operational processing environment in which all card system applications execute and where data files and databases are controlled and updated. It includes batch and online processing environments that support testing and production requirements. Environment layer 110 contains a complete set of databases, files and execution environments for each SBU. A distinct environment (batch and online) is created for each testing level required to support the SBU, as well as for production. The data files and databases are updated in at least one embodiment, for example, only by system applications.
  • interfaces e.g., typically files
  • Development required to create these interfaces may be done at custom layer 108 by in-house developers. This process ensures full operational control by the primary production systems while still permitting each SBU to access information required for additional processing functions to meet local requirements.
  • Local layer 112 is a complete environment created for each SBU that contains non-card system application load modules that are used by an SBU and are dependent on system data. These applications may receive interface data from environment layer 110 during or after execution of system applications, as well as from other systems sources. The definition, development, and maintenance of these local applications may be managed and controlled by staff at the SBU.
  • the framework of the present invention may include some, all, or additional layers to those layers illustrated in FIG. 6 , namely, global layer 102 , base layer 104 , regional layer 106 , custom layer 108 , environment layer 110 , and local layer 112 .
  • the framework may include only base layer 104 and custom layer 108 .
  • the use of base layer 104 and custom layer 108 allows global changes to be staged into base layer 104 , and local changes specific to only a portion of the SBUs to be staged into custom layer 108 .
  • Change management software e.g., ChangeMan®
  • ChangeMan® is the primary tool used to support the development and installation of various types of source code, copybooks, load modules, and other components in the mainframe environment.
  • the change management software tool automates the full lifecycle of movement of system development components from development/testing through quality assurance (“QA”) and installation into production.
  • QA quality assurance
  • Change management software provides a wide range of features. For example, the software guarantees coordination of all components of a defined package for simultaneous promotion.
  • the software supports concurrent development and maintenance of components by multiple developers.
  • the software prevents version discrepancy and out-of-synch relationships through the use of auditing tools.
  • the software provides notifications of activities and online access via reporting tools.
  • the software maintains historical records of changes to components.
  • the software supports the ability to rollback changes to specific versions.
  • Change management software uses the concept of a package of components created by developers to identify changed components. These packages are used for analysis and promotion to the correct testing environment or for installation into production. Change management software also provides automated back-out procedures for packages to support recovery of previous versions of components.
  • the change management software manages the correct creation of packages and their contents through the use of partitioned datasets (“PDS”) that store required components (e.g., source, copybooks, Job JCL, PROCs, etc.).
  • PDS partitioned datasets
  • a promotion level supports an environment occurrence (online and batch) to be used for a specific purpose, such as development/unit test, conversion, training, QA, etc.
  • Each promotion level includes a set of libraries that support the development/testing functions being performed.
  • the set of libraries that exist at the promotion level includes support for the online (CICS) region, batch processing procedures (JCL and PROCs), datasets, and the PDS libraries for load modules, source code, copybooks, and associated other components necessary to describe the overall execution environment.
  • Copybooks are managed through the use of partitioned datasets controlled by the change management software.
  • a copybook PDS contains a distinct member for each copybook.
  • Naming conventions for each copybook library are used to identify the origination point (e.g., vendor, card system, etc.) of the code created for each copybook and the type of code that it is.
  • Copybooks may be, for example, data division statements or procedure division statements. Copybooks may be used, for example, for one of two reasons: the code is a candidate for use in multiple programs (e.g., COBOL programs) or it is a modification/enhancement to an existing vendor module/program that exceeds five lines of code.
  • COBOL programs e.g., COBOL programs
  • Each global framework layer described hereinabove and shown, for example, in FIG. 6 may have a set of copybook libraries to support the testing, installation, and distribution of global system application software. Depending on the layer and the number of environments required, there may be multiple sets of copybook libraries created to support development and testing needs. The process is illustrated, for example, in FIG. 7 .
  • Source code is managed through the use of a PDS controlled by the change management software.
  • Source code may be, for example, COBOL, Assembler, or any other suitable procedural language.
  • Each global framework layer has a corresponding set of source code libraries to support the testing, installation, and distribution of the account management system application software. Depending on the layer and the number of environments required, there may be multiple sets of source code libraries created to support development and testing needs. These are illustrated in FIGS. 8 and 9 .
  • each component type requires the selection of the correct compile or assembly process to be executed to create load modules.
  • system modules based upon the vendor-supplied system and the in-house version of this are subject to a merge process to combine the respective source or copybooks. Members of these merged libraries are then compiled/assembled. Other modules can be compiled/assembled without the need for merge.
  • the change management software uses this component-type identification to determine which procedure needs to be invoked to create the corresponding load module.
  • ASM CMNMERGE Assembler code that is subject to the in-house version of the credit card system merge process COBOL3 COBOL370 COBOL source code that is not subject to the in-house version of the credit card system merge process
  • Load libraries (.PGM for CICS Online and .LNK for batch) are partitioned datasets (PDS) created to contain the programs that will be used for development, testing, installation, and execution in a production environment.
  • PDS partitioned datasets
  • An individual module in a load library is created as a result of a compile/assemble requested by, for example, the developer of a program.
  • the contents of these libraries are managed through the change management software promotion process, which controls migration through the use of promotion levels and change management software packages.
  • Each global framework layer has a corresponding set of load libraries to support the testing, installation, and distribution of the system application software. Note, however, that the global layer 102 set of load libraries is used for the migration process of merging vendor and in-house changes to form the system, and is used for development testing only. These load modules are not subject to promotion, migration or distribution to any other layer within the framework. System source code, etc. is staged into the base layer 104 change management software mnemonic before any compilation occurs at base layer 104 .
  • compliance changes may be made to the system. These compliance changes may be mandated by a payment card association on a semi-annual basis, or by a governmental agency.
  • Enhancements include major and minor modifications to the system that address business requirements not present or adequately provided at present. These enhancements are usually made on an annual basis as a major release.
  • Fixes include minor and concise changes to functionality that improve the capabilities of the system but do not prevent day-to-day operations. Fixes are usually made on an annual basis and may be included in the enhancement release. Fixes may also be implemented on an ad hoc basis, at either base layer 104 or custom layer 108 , as business needs demand.
  • Emergency fixes may be made to the system. Emergency fixes are changes required to system modules in the short-term to permit correct operations. These emergency fixes are infrequent but critical fixes.
  • Promotion levels are defined to accommodate the smooth transition of copybooks, source code, and other related components from the development environment through testing environments and for eventual installation in production. There may be, for example, six environments defined as standard for any SBU implementation (see, e.g., FIG. 13 ). This number of environments is merely illustrative, however, and any suitable number of environments may be used for SBU implementation.
  • the change management software promotion levels are used by the developer in conjunction with a change management software package to collect components to be grouped together as part of a unit of change. It can include any component type.
  • the developer is responsible for defining a package and then adding components to the package. These may be COBOL source code and copybooks, although the package may also include items such as JCL, Assembler programs, or BMS Maps (CICS screen definition macros).
  • the package is eligible for promotion.
  • load modules are automatically added to packages.
  • the developer will request promotion of the package to the next testing level as prescribed by the testing requirements of the overall project.
  • Packages progress through testing levels via promotion to the point of certification that the contents are production worthy and are then subject to install.
  • Custom Layer 108 Template Library Type Dataset Name(DSN) CICS Promotion First Second ChangeMan ® Level Region Purpose Level Node Node Environments Mnemonic 1 H@B0 Development/Unit L1DEV D++0. CP000000. D&&& W&&& Testing 2 H@B1 Systems/Integration Test L2SIT D++0. CP000000. R&&& W&&& 7 C@B0 Conversion L7CONV C++0. CP000000. C&&& W&& 9 T@B0 Training L9TRN T++0. CP000000. T&&& W&& 10 J@B0 Dress Rehearsal Q10UAT Q++0. CP000000.
  • the installation process includes multiple steps primarily controlled by the change management software package. While similar to a promotion, an installation is a prelude to the baseline process, which changes the status of the change management software package components and production execution libraries. Baselining a package and its contents permits components to be checked out by developer for further modification.
  • the change management software install process copies load library modules that have been created as part of the package to the regional layer 106 load libraries, thereby making the load library modules available for execution in the corresponding production environment or environments.
  • This install process takes place according to the schedule defined in the change management software.
  • Load modules in the package are installed to all occurrences at regional layer 106 (e.g., the Americas, Europe, etc.). Upon completion of the last installation step in the schedule at regional layer 106 , the load module is copied to the base layer 104 load module libraries and the baseline process of the package components occurs.
  • regional layer 106 e.g., the Americas, Europe, etc.
  • FIG. 10 illustrates the scheduling of packages for installation at base layer 104 . Note that when scheduling the install, it is necessary for all steps to complete before the package contents are baselined at base layer 104 .
  • FIG. 11 illustrates the geographic distribution that takes place when the install is performed. Load modules are copied from, for example, the central development Sysplex to the remote production Sysplexes at which the regional layer 106 load module libraries are maintained.
  • the change management software completes the baseline process when it has certified that all regional layer 106 installation steps have been completed successfully. Note that a copy of the regional layer 106 load module libraries is also maintained at, for example, the development Sysplex for redundancy purposes.
  • the installation of a change management software package to production initiates an automatic process.
  • the installation results in load modules (batch and/or on-line) being copied, according to a pre-determined schedule, from the source load module libraries in the development LPAR to the destination load libraries - either regional layer 106 (using base layer 104 as source) or custom layer 108 (using custom layer 108 as source) LPAR(s).
  • load modules batch and/or on-line
  • the package components are baselined at the corresponding source layer.
  • the change management software install process copies load modules that have been created as part of the package to the custom layer production load libraries. These load modules are then available for execution in the corresponding SBU custom layer 108 production environment.
  • the install process takes place according to the schedule defined in the change management software. Upon completion of the custom layer 108 installation, the baseline process of the package components occurs.
  • the load modules in the package are installed to the production level set of load module libraries at custom layer 108 , based upon the schedule defined in the change management software by the developer.
  • the load modules are copied from, for example, the central development Sysplex to the remote production Sysplexes at which custom layer 108 load module libraries are maintained.
  • the baseline process of the package components occurs at custom layer 108 .
  • the change management software package installation and baseline process are illustrated in FIG. 12 .
  • Testing environments for certain layers of the global framework are created around, for example, the CICS region required for each level of testing and production for each SBU.
  • Each environment incorporates both online (e.g., CICS) components as well as the corresponding batch components to support online processing.
  • testing levels that are required for acceptable levels of quality in the production environment are described hereinbelow. Note that support for a primary development, systems test, QAJUAT, and production environment exists at both base layer 104 and custom layer 108 . There is a one to one correspondence of libraries and testing levels to allow for a timely and consistent progression of changes through each development/testing level. Promotion levels are defined within the change management software for each of the testing levels to support progression of modifications.
  • changes to source code/copybooks are assigned to a change management software package within the change management software. These changed components can then be compiled into load modules that are added to the package for use in the testing and promotion process. The contents of the package then advance to the next higher level of testing via package promotion using the change management software. This process of promotion continues until all testing is completed and the package is installed.
  • This installation occurs either at base layer 104 or custom layer 108 , depending on the global or local applicability of the software.
  • the change is global in nature, and applies to all SBUs, it is installed in the regional layer 106 load module libraries. If the change is SBU-specific, it is installed in the custom layer 108 load module libraries. The installation process is illustrated in FIG. 13 .
  • Naming conventions provide a convenient way for a systems development project to organize all of the components required during the process of creating solutions for a complex business problem. Naming conventions have many advantages. For example, naming conventions eliminate the likelihood of incorrectly naming an element. Naming conventions provide easy identification of what an object is used for. Naming conventions provide an improved ability to identify the SBU- or application-owner of the object.
  • Dataset names provide a way to identify files and databases that are used by batch and online programs.
  • SBUs operate a single base set of an application
  • Libraries are used to store key components including program load modules, specific tables and codes, and control cards (CTCs) that manage the allocation of resources and determine processing needed at a specific processing point.
  • CTCs control cards
  • Job names are used to identify the batch execution job streams. To segregate and control each environment for individual SBUs, it is important to have unique job names that identify execution units for the local business unit.
  • the job name is used in conjunction with job control language (JCL) to build specific batch execution streams.
  • JCL job control language
  • Each job name must be unique for scheduling purposes. This is accomplished through the use of the job naming standards in accordance with the present invention.
  • PROC Procedure (PROC) names are used to identify “blocks” of JCL statements executed as part of a batch job stream that has a unique job name. To segregate and control each environment for individual SBUs, unique PROC names are used to identify execution units for the local business unit. This is accomplished through the use of the PROC naming standards in accordance with the present invention.
  • An account code is a five character code required to establish allocation of charges for use of physical resources in a mainframe environment.
  • the account code identifies the environment, owner, country, and application to which the job belongs. This is accomplished through the use of the account codes naming standards in accordance with the present invention.
  • Load modules are stored in libraries.
  • the load modules that form part of the card system reside in the base layer 104 load libraries.
  • regional layer 106 contains a copy of the card system load modules maintained at base layer 104 .
  • This copy of the load modules eliminates reliance by all SYSPLEXES (which are geographically dispersed) on a single set of load libraries at a central location.
  • a “SYSPLEX” is a collection of mainframe processors that share resources and provide a processing platform for many batch and online environments. It is used as a management point for all resources required to meet the needs of many general purpose business systems.
  • a SYSPLEX may include, for example, CPU, memory, network connections, direct access storage devices (DASD), magnetic tape drives and other input and output media types.
  • DASD direct access storage devices
  • Each SBU environment may have customized versions of modules that are to be executed in lieu of the load module that resides in regional layer 106 .
  • libraries are concatenated in order from custom layer 108 to regional layer 106 . “Concatenation” means that, when the module is to be invoked, the system searches first in the custom layer 108 load libraries for the module. If the load module is not found in the custom layer 108 load libraries, then the regional layer 106 load libraries are used to provide the load module.
  • FIG. 14 illustrates a concatenation sequence for each testing level, as well as production environments. Examples of the concatenation sequence for the various test environments, to include regional layer 106 as well as custom layer 108 libraries, are shown in the table below:
  • the global framework requires the definition and creation of a change management software mnemonic, library types, and libraries.
  • Infrastructure components are composed of all technical aspects of the batch and online environment.
  • Changes made to card system source and/or copybooks using the global framework of the present invention can be at either base layer 104 or the custom layer 108 . Changes at base layer 104 are considered to be “global” in nature, and therefore affect all SBUs. The base layer 104 load modules are executed unless overridden by changes applied at custom layer 108 to meet SBU needs.
  • Changes made at custom layer 108 are specific to the needs of a single SBU.
  • the load modules created as a result are executed in preference to those that exist at base layer 104 . This is accomplished through the use of load module library concatenation, as described hereinabove.
  • a feature of the global framework of the present invention is a “shadow” framework for use in connection with enhancement releases.
  • An enhancement release of a system requires the ability to manage and maintain the existing production environment and the supporting testing environments, while at the same time permitting development and testing of the next major release of the system.
  • the nature and complexity of the system dictates that a separate and distinct framework, libraries and environments be created to provide a method to fully and successfully test global functions, as well as any SBU custom changes that have been made to the current version of the card system.
  • the shadow framework of the global framework is a “shadow” of all aspects of the existing global framework.
  • This shadow global framework provides environments for the acceptance of a new release of vendor source code and copybooks that constitute the next release of the system (e.g., at base layer 104 ). This is supplemented by any in-house changes to the system, at base layer 104 , for example, and additional functionality created for specific SBUs, at custom layer 108 , for example.
  • the shadow framework of the present invention provides various advantages.
  • the shadow framework permits the acceptance of new releases of the system into a set of environments separate and distinct from production baselined system libraries and change management software mnemonics.
  • the shadow framework supports end-to-end testing of new releases at both base layer 104 and custom layer 108 prior to installation/implementation in a production environment.
  • the shadow framework provides the ability to allow SBUs to begin using the new release of the account management system based upon their ability to manage the conversion to the new release.
  • the shadow global framework includes a complete set of change management software mnemonics, source/copybook libraries (using standard lib types), other source components, and load module libraries that support base layer 104 and custom layer 108 .
  • libraries also are provided at regional layer 106 to support geographic distribution of load modules.
  • a change management software mnemonic exists for each layer of the framework that contains components that can be created and maintained within the system (e.g., source code, copybooks, etc).
  • the global framework of the present invention is used to support the current version of the system in production.
  • the shadow global framework of the present invention provides the mechanism for the development and testing of the next release to be implemented at the SBU level. More than one shadow global framework can be employed depending on the speed at which SBUs are able to migrate from one release to another.
  • This aspect of the present invention is illustrated in FIG. 16 . (It should be noted that the release notations, e.g., Release 8.15, Release 8.16, etc., provided in FIG. 16 are merely for illustration.)
  • an enhancement release Upon delivery of an enhancement release from a vendor and/or from an in-house developer, it is staged into the shadow global framework base layer 114 for that release.
  • the contents of the existing custom layer 108 change management software mnemonics are migrated to the new release shadow global framework (e.g., to shadow custom layer 118 ). This duplicate copy is used as the foundation for integrating release modifications and testing the new release.
  • SBU-specific enhancements As changes can be introduced at custom layer 108 for an SBU-specific business requirement, it may be necessary to modify SBU-specific enhancements that will continue to be supported at custom layer 108 . For example, this could be due to changes to files, copybooks, or source code used from base layer 104 as the basis for custom layer 108 enhancements.
  • All application sub-systems may use the shadow global framework for development of the next release of the card system.
  • the release of any major enhancements to the system may be integrated and tested in the corresponding shadow global framework environments before installation into production.
  • the shadow global framework becomes available for use by SBUs, either as a conversion from a previous version or as a new SBU added to production.
  • the global framework may be implemented with, for example, an IBM mainframe environment using standard operating systems and tools, such as z/OS1.6, TSO, CICS, ChangeMan®, etc.
  • FIG. 17 is an illustrative flow diagram that demonstrates the configuration and release management of software globally to the account management system.
  • one or more changed components of the group application systems software are received at the global layer (e.g., global layer 102 of FIG. 6 ).
  • the one or more changed components are integrated into a single set of merged programs at the global layer.
  • An example of this integration is shown in FIG. 6 , with “Vendor” and “Card System” changes integrated into a single set of “Global Merged” programs at global layer 102 .
  • the set of merged programs are tested at the global layer. By testing at the global layer, developers are free to test and further develop the software components without disrupting the processing of the remaining portions of the global framework, especially of software components used in production by SBUs.
  • the one or more changed components are staged to the appropriate libraries at the base layer.
  • the “Card System” and “Vendor” changes are staged to base layer 104 .
  • the one or more changed components are merged into a base set of libraries for source code and copybooks.
  • FIG. 6 illustrates “Base Merged” as the merger of the “Gold Library Changes,” the “Vendor” changes, and any other changes integrated into base layer 104 .
  • the one or more changed components are tested at the base layer at step 310 .
  • An example of testing support at base layer 104 is shown, for example, in FIG. 13 , which illustrates the promotion of a component up to the installation step.
  • the merged components are installed at the regional layer using base layer load modules.
  • the “Base Load Modules” are used to install the “Base Merged” components from base layer 104 into the regional layer 106 libraries, for use by the SBUs.
  • FIG. 18 is an illustrative flow diagram that demonstrates the configuration and release management of software locally to specific SBUs within the account management system.
  • one or more changed components of the group application systems software are received at the custom layer (e.g., custom layer 108 of FIG. 6 ).
  • the one or more components may be applicable to only a subset of all SBUs (i.e., the components are “local,” rather than “global”).
  • the one or more changed components are merged at the custom layer with a base set of libraries for source code and copybooks from the base layer. As shown in FIG. 6 , for example,.“Custom” changes are merged with “Base Merged” to form “Custom Merged” at custom layer 108 .
  • the merged programs are tested at the custom layer.
  • An example of testing at custom layer 108 is shown, for example, in FIG. 13 , which illustrates the promotion of a component up to the installation step and the creation of testing environments to meet the requirements of the custom layer.
  • the merged components are installed at the custom layer using custom load modules (e.g., “Custom Load Modules” of custom layer 108 of FIG. 6 ).

Abstract

A global framework multi-layer computer based architecture is provided. The global framework may include a single set of libraries that contains common source code applicable to substantially all business processing systems using the global framework. The global framework may include individual source code libraries that contain modifications specific to a business processing system to meet the local needs of that business processing system. The business processing systems may execute the custom and base libraries through concatenation of the libraries.

Description

    CROSS REFERENCE TO RELATED PATENT APPLICATIONS
  • This application is a continuation of U.S. patent application Ser. No. 11/330,065, filed Jan. 12, 2006, now U.S. Pat. No. 7,937,685, which claims the benefit under 35 U.S.C. §119(e) of U.S. Provisional Patent Application No. 60/643,758, filed Jan. 13, 2005, both of which are hereby incorporated by reference in their entirety.
  • FIELD OF THE INVENTION
  • The present invention generally relates to a framework for configuration and release management of group systems software. More particularly, the present invention relates to a framework for configuration and release management of group application systems software in an application-based software system such as, for example, an account management system; financial system, or banking system. The framework of the present invention provides for configuration and release management of group application systems software both globally to the software system and locally to business units within the software system.
  • BACKGROUND OF THE INVENTION
  • The configuration and release management of group systems software, and in particular group application systems software in an account management system of a large banking entity, can involve software changes and deployment at both the global level and at the local level. For example, a global bank such as HSBC conducts business in 76 countries and territories around the world. These operations are managed in four geographical regions: the Americas; Europe; the Middle East and Africa; and Asia Pacific. Each of these regions encompasses multiple countries, and each country includes several strategic business units, or SBUs, which are HSBC's smallest business operating divisions. In order to address the needs of SBUs around the world, HSBC deploys mainframe-based “group systems” software applications. These software applications may be developed in-house, or may be based around commercially-available software packages which are supported by a vendor and enhanced by HSBC as necessary.
  • A difficulty in employing an account management system of the complexity and scope of the HSBC system is the amount of overhead that accompanies deployment of a complete copy of the system for each of the SBUs using the system. A complete copy of the software system may include, for example, source code, copybooks, and job control language for each of the software application components within the software system. In the majority of cases, much of the group application systems software is common for all SBUs, with only a relatively small amount of customization necessary for an application to effectively support an individual SBU.
  • Various approaches have been employed in the past in connection with software configuration and release management. An example of a computing system deployment planning method is disclosed in Tseng et al. International Patent Publication No. WO 03/098490, published Nov. 27, 2003, shown in FIG. 1, and incorporated herein by reference. The computing system deployment planning method of FIG. 1 is implemented using deployment planning system 10, which resides on a computer-based system that is networked for access to a component profile server 12. User 14 interacts with deployment planning system 10 through a graphical user interface 16. Deployment planning system 10 includes a plurality of component profiles stored in a component profile repository. Deployment planning system 10 allows for the deployment of services or a computing system with just the component profiles of the required components. The component profiles are used for deployment testing prior to implementation of the actual system components.
  • An example of a method for service and role-based software distribution is disclosed in Hellerstein et al. United States Patent Publication No. US 2002/0129356, published Sep. 12, 2002, shown in FIG. 2, and incorporated herein by reference. The method starts at step 20. At step 21, a new software package is introduced. The software package and its description are entered in a service distribution server and stored in a global software repository. At step 22, target regions for distribution of the software package are selected. This step is performed by the software distribution server to determine all the region servers whose service profiles match the service that is going to be provided by the new package. At step 23, the software is distributed from the software distribution server to a region server. For each region in the target set (computed in step 22), the software distribution server prepares a package that is suitable for target machines in that region. This package is then transported to the region. At step 24, the region server determines if each of the potential targets has the appropriate resources (e.g., CPU, RAM, disk space, swap space, etc.). At step 25, the region server retrieves the target roles. At step 26, the software is distributed from the region server to the target machines. At step 27, the results of the software distribution are gathered, and tests are done on the installed software. Installation results are gathered at the region server. At step 28, the region server sends the status of the distribution step to the software distribution server, and the method ends.
  • An example of a system and method for application management is disclosed in Nakamura U.S. Pat. No. 6,779,028, issued Aug. 17, 2004, shown in FIG. 3, and incorporated herein by reference. Application operation definition storage files are removed from application server computers 30, 32, and 34 and are instead provided on management server computer 36. Management server computer 36 includes application operation definition storage file 38 to systematically manage application computers 30, 32, and 34 via network 40. When an execution request for an application is generated on application server computer 30, application management section 42 looks up the operation definition data of the requested application from application operation definition storage file 38. Application management section 42 executes a to-be-managed application 44. Application management section 42 stores the state of executed application 44 in application current state update file 46. When application management section 42 receives an interrupt message indicating an end event of the executed application, application current state update file 46 is used to store the application execution history. The application execution request is then transmitted to all application server computers in server computer group 48 via network 40. Upon receiving the execution request, application management section 42 looks up the operation definition of the requested application in application operation definition storage file 38. Except when the operation definition of the application indicates that the application operates in the requesting computer, application management section 42 discards the execution request in application server computer 30. The application execution request is then processed using an application management section in another application server computer (e.g., application server computer 32 or 34) by accessing application operation definition storage file 38.
  • An example of a system and method for software building and deployment is disclosed in Custodio United States Patent Publication No. US 2003/0182652, published Sep. 25, 2003, shown in FIG. 4, and incorporated herein by reference. Software building and deployment system 62 manages the deployment of software and content to a development environment 64, a testing environment 66, and a production environment 68. In the context of providing a commercial web site, production environment 68 contains all of the code and content that hosts the web site for the public. A component is promoted from one environment 60 to another when that component meets the required quality assurance test criteria assigned to each particular environment 60. One or more servers 70 host each environment 60. Software building and deployment system 62 handles all aspects of the deployment of software and content to environments 60. System 62 interfaces directly with one or more source code repository systems 72. System 62 also interfaces with external builders 74, which handle the compilation of source code. Finally, system 62 interfaces with content deployment and replication engines 76 which handle the actual movement of source code and content to environments 60. System 62 controls interactions between source code repositories 72, external builders 74, and content deployment and replication engines 76 so as to manage all changes to one or more computing environments 60. In this way, every change to an environment 60 is handled and tracked by system 62 as a separate release. System 62 is instructed to create a new release in an environment 60 through a manifest 78. Manifest 78 includes the instructions necessary for system 62 to select the correct source material from repositories 72, compile the material, if necessary, using builder 74, and deploy the compiled versions to the appropriate environment 60 using a deployment and replication engine 76. All changes to an environment 60 are initiated by a manifest 78, and therefore each manifest 78 is considered to define a new release for the environment 60 specified by the manifest 78.
  • An example of a method and apparatus for software deployment is disclosed in Zelechoski et al. United States Patent Publication No. US 2004/0006537, published Jan. 8, 2004, shown in FIG. 5, and incorporated herein by reference. The system architecture includes a total of five layers: business applications layer 90, application bus layer 92, application services layer 94, technology bus layer 96, and technology platform layer 98. Business applications layer 90 includes common application services that provide needed common application functionality to the business applications. Application bus layer 92 provides the necessary communication protocols and configuration information to allow any application to invoke any needed service, regardless of the physical location of that requested service. For example, there may be requests from business application layer 90 to services within application services layer 94. Application services layer 94 includes a number of modularized service engines and common application services, which may be invoked from business application layer 90 or from within the application services layer. Technology bus layer 96 provides access to technology platform layer 98. This layer insulates the business applications and application engines from the physical hardware, the network, and the physical data storage mechanisms. Technology platform layer 98 includes a number of different technology platforms.
  • As described hereinabove, a number of past approaches exist in connection with software configuration and release management. It would be desirable to improve upon these past approaches and provide a framework for configuration and release management of group application systems software in a software system, providing for configuration and release management both globally to the software system and locally to business units within the software system.
  • SUMMARY OF THE INVENTION
  • In accordance with at least one embodiment of the present invention, a framework for configuration and release management of group application systems software is provided. In particular, the framework of the present invention may provide for the configuration and release management of group application systems software in an application-based software system such as an account management system, both globally to the account management system and locally to business units within the account management system. (It should be noted that the framework of the present invention is described herein primarily in the context of an account management application-based software system, and in particular a credit card account management system. However, this is merely illustrative, and one of skill in the art will realize that the framework of the present invention may be applied to any suitable application-based software system that requires the configuration and release management of group systems software.)
  • The complex nature of an account management system having numerous group systems requires a comprehensive set of policies, procedures, naming standards, and tools to permit management of both the similar and distinct needs of strategic business units (SBUs) using the system. For example, for a global bank such as HSBC, numerous group systems may be used within a credit card account management system. HSBC, for example, designates about 18 application systems within the credit card account management system as group systems. These group systems may be in use in more than one of a group's SBUs.
  • The framework of the present invention has been built and enhanced on the premise that common functions can be provided through a single set of “base” source code, while allowing country- or SBU-specific processing through modifications, control parameters, and the integration of locally-developed solutions. The present invention provides a global framework to manage the source and execution components that provide and support the production environments to support business software applications. (The framework of the present invention may be referred to interchangeably herein as both a “framework” and a “global framework.”)
  • The global framework of the present invention is both a structure and a set of associated tools and processes that allow a single base of program code and related components to be managed and modified, thereby meeting the processing needs of business units within the account management system. The global framework provides flexibility to incorporate software changes as business needs evolve, while keeping code release versions consistent and current across all business units within the account management system. This flexibility results in an improved speed-to-market for changes to the account management system. The elements of the global framework, in at least one embodiment, include:
    • a single set of libraries that contain all common card system elements (the “global version” of the system);
    • policies, processes, and procedures that enable consistent use of and modifications to common card system elements;
    • regional load module libraries to manage installation and distribution of revised card system elements at a specific site or for a set of time zones;
    • individual code libraries for SBUs that contain business unit specific modifications to meet local needs (e.g., local modifications that supplement or replace global business processing);
    • individual execution environments (e.g., online and batch) to support data management and processing for each SBU; and
    • naming standards that are defined to control and identify components, libraries, data sets, and execution environments.
      One or more of the above elements may be utilized in alternative embodiments of the global framework of the present invention.
  • The global framework of the present invention includes various features and components for configuration and release management of group systems software. The global framework includes source, copybook, load module, and related libraries used to contain components of the card system. Such components may include, for example, JCL, PROCs, control cards, etc. The global framework includes naming conventions to ensure segregation and control of both global and SBU-specific components, libraries, and datasets for development, testing, and production. The global framework includes a comprehensive change management structure that controls the use of software version promotion levels. The framework supports the concurrent development of components within the framework. In one example, the component change management tool used in conjunction with the framework is ChangeMan®, sold by SERENA Software, Inc. of San Mateo, Calif.
  • The global framework of the present invention and its associated tools, processes, and procedures effectively deliver group application systems software within an account management system. The global framework provides standardized tools and techniques for concurrent development of software for multiple SBUs from a single source platform. In doing so, the global framework significantly reduces the number of system components for which changes need to be managed for users of a particular group system. For example, a complete deployment of group application systems software supporting a credit card account management system may include about 21,000 components of source code and copybooks. Of these 21,000 components, only about 2,500 (or about 12%) may be specific to a large SBU, with smaller SBUs having significantly less customization.
  • The framework of the present invention may be used in connection with any entity (e.g., vendor, governmental agency, in-house developer, etc.) that provides updates or changes to the credit card account management system. Possible software updates may include, for example, compliance updates, enhancement releases, and fixes.
  • Compliance updates address any changes to operating regulations by a credit card provider (e.g., Visa, MasterCard). These operating regulations change on a regular basis to meet the needs of all credit card issuing and acquiring members. As a result, payment card association members, banks, and processors must comply with these amendments on a set schedule. These mandates are usually effective on the first of April and the first of October of each year. A software vendor or in-house developer develops compliance updates for all components within a credit card account management system. These compliance updates are delivered by the vendor or in-house developers typically in mid-February and mid-August. The bank then accepts these updates for integration into the bank's specific version of the credit card account management system.
  • Enhancement releases address any new features and functionality that are added to the credit card account management system. These releases may be created by a vendor, or may be created in-house. (Various updates, enhancements, and fixes may be described herein as “vendor” or “in-house.” It should be noted that the framework of the present invention may be used in conjunction with any changes to the software, whether developed by a vendor or an in-house developer. The description of vendor or in-house developed code is for illustration only.) Typically, vendor enhancements are delivered every twelve to eighteen months, and are packaged as a new release of the business system. The vendor's enhancement releases are integrated with a bank's version of the credit card account management system for delivery in an internal enhancement release.
  • Fixes may be released by a vendor or by in-house developers to correct any specific software problems or to update system processing based upon the business needs of the bank or a specific SBU.
  • For efficient release management of group application systems software within the account management system, the framework of the present invention controls the libraries and environments used in production and release testing. The framework supports the current version of the card system in production, and one or more additional versions to support the development and testing of a new software release to be implemented at the SBU level. Once the software release is certified as “production ready” it may be implemented by one or more SBUs as the result of a conversion. At any one time up to, for example, three (3) versions of the group application systems software may be used in production operation.
  • The framework of the present invention includes multiple layers to segregate globally-applicable software from software that applies only to specific SBUs. The layers of the framework permit the use of a single base of global source code and components to be used as a foundation for all card system users, while supporting the specific needs of each SBU. In at least one embodiment of the present invention, the framework may include six layers: global, base, regional, custom, environment, and local. However, these layers are merely illustrative, and the framework may include some, all, or additional layers to the six layers recited above and described hereinbelow.
  • The global layer of the framework provides a development environment for credit card system developers. The global layer acts as the initial point at which vendor source code and/or copybook enhancements are integrated with the custom enhancements developed by in-house developers on behalf of all SBUs. The global layer supports the process of merging two compatible sets of source code and copybook libraries into a full set of merged programs (e.g., source code and copybooks) that forms the foundation of the global credit card system, so that these programs can be compiled and preliminarily tested, prior to staging of the applications into the base layer. Upon successful testing and baseline of compliance updates, enhancement releases, and fixes at the global layer of the framework, changed components are staged to the appropriate libraries at the base layer for integration, testing, and subsequent installation in the production environment. Changes that are specific to only certain SBUs, and not to the entire card system, may follow a similar staging process at the custom layer of the framework.
  • The base layer provides support for the development and installation of sub-systems within. the card system. Vendor and homegrown solutions are integrated into the global credit card system at the base layer. In addition, in-house developers may apply further fixes and modifications to the credit card system, as appropriate, at the base layer. This process requires the merging of homegrown changes with vendor-supplied source code and copybooks to create the merged base set of libraries for source code and copybooks. When warranted and upon completion of integration and testing of these changes in the appropriate base layer environments, card system global load modules are baselined and installed at the regional layer. In addition, all related and required components for the abovementioned card system global load modules are also baselined and installed.
  • The regional layer provides a point at which SBU production load libraries are distributed to support execution in batch or online. The regional layer contains the execution libraries for base layer load modules, so that individual SBUs can easily access the appropriate components in a local operational environment. This is accomplished through concatenations of load module libraries. The regional layer load module libraries eliminate reliance on a single physical set of base layer libraries for load modules. In some embodiments, developers are prevented from changing the contents of these load libraries, except through the authorized promotion/installation processes defined within the change management software at the base layer.
  • The custom layer provides the ability to maintain the integrity of the global card system through code management tools and infrastructure. The custom layer provides enhanced ability to minimize time to market for minor releases and fixes to the card system, and more particularly to the software applications utilized by specific SBUs. The custom layer also provides support for the evolution of solutions that have been proven and tested at the SBU level to be deployed globally as a part of a major release. The custom layer provides the ability for each SBU to identify and implement processing rules and data that are specific to local market needs. New or modified components that exist in the custom layer are accessed during execution at the environment layer by use of concatenations of the load module libraries within JCL that point to the custom layer libraries first. If any given component is not found at the custom layer, then the regional layer load module libraries will be used.
  • The environment layer is the operational processing environment in which all card system applications execute and where data files and databases are controlled and updated. The environment layer includes batch and online processing environments that support testing and production requirements. The environment layer includes a complete set of databases, files, and execution environments for each SBU. A distinct environment (e.g., batch and online) is created for each testing level required to support the SBU, as well as for production. The data files and databases are updated only by card system applications.
  • The local layer is a complete environment created for each SBU that contains non-card system application load modules that are used by an SBU and are dependent on card system data and may use data from other sources. These non-card system applications receive interface data from the environment layer during or after execution of card system applications. The definition, development, and maintenance of these local applications may be managed and controlled, for example, by staff at the SBU.
  • In some embodiments of the present invention, a global framework computer based architecture may be provided. The architecture may include a source code management system that provides executable development and testing environments to support component applications in production. The architecture may include at least one set of associated tools and processes, in operative interaction with the source code management system, providing a single base of program code for the component applications to be managed and modified by the source code management system using the executable production environments for multiple business processing systems using the global framework computer based architecture. The architecture may provide functionality and may be adapted to manage modifications of the multiple business processing systems, while simultaneously maintaining software source code release versions consistent and current across the multiple business processing systems. The architecture may, for example, reduce the number of source code management system components for which changes need to be managed for the multiple business processing systems.
  • In one example, the architecture may further include a single set of libraries that contain substantially all common source code management system elements applicable to the multiple business processing systems. In another example, the architecture may further include individual code libraries for the multiple business processing systems that contain modifications specific to a business processing system to meet local needs of the business processing system and providing the multiple business processing systems the functionality of concatenation.
  • In yet another example, the architecture may further include individual online and/or batch execution environments to support data management and processing for each of the business processing systems. In still another example, the architecture may further include at least one set of associated tools and processes, in operative interaction with the source code management system, to enable consistent use of and modification to source code management system elements common to the multiple business processing systems. In yet another example, the architecture may further include at least one regional load module library, in operative interaction with the source code management system, providing for installation of revised source code management system components for a specific business processing system or for multiple business processing systems within a particular time zone. In yet another example, the architecture may further include a plurality of naming standards to control and identify components, libraries, data sets, and/or execution environments within the source code management system.
  • In some embodiments of the present invention, a global framework multi-layer computer based architecture including at least one source code management system that provides executable production environments to support component applications may be provided. The multi-layer architecture may include a base layer providing development and installation functionality for multiple business processing systems within the source code management system. Source code for the multiple business processing systems may be staged to the base layer for integration with existing source code for the multiple business processing systems to create a merged base set of libraries. The merged base set of libraries may contain substantially all common source code management system elements applicable to the multiple business processing systems. The merged base set of libraries may be tested in the base layer prior to implementation of the merged base set of libraries.
  • The multi-layer architecture may include a custom layer, in operative interaction with the base layer, providing development and installation functionality for a business processing system of the plurality of business processing systems within the source code management system. Source code for the business processing system may be staged to the custom layer for integration with existing source code for the business processing system to create a merged custom set of libraries. The merged custom set of libraries contains substantially all modifications specific to the business processing system to meet local needs of the business processing system, and the merged custom set of libraries used to create the load libraries in the custom layer used in the concatenation. The merged custom set of libraries may be tested in the custom layer prior to installation of the merged custom set of libraries. The custom layer may, for example, reduce time to market for modifications specific to each business processing system of the multiple business processing systems.
  • In one example, the multi-layer architecture may further include a global layer, in operative interaction with the base layer, providing development functionality for the multiple business processing systems within the source code management system. Source code for the multiple business processing systems may be developed within the global layer. The source code developed within the global layer may include, for example, source code from a plurality of separate entities. The source code from the plurality of separate entities may be merged for testing in the global layer prior to staging to the base layer.
  • In another example, the multi-layer architecture may further include a regional layer, in operative interaction with the base and custom layers, providing installation functionality for the merged base set of libraries. The installed base set of libraries may support execution by the multiple business processing systems in batch and/or online by allowing the multiple business processing systems to implement the base set of libraries, if necessary, by concatenating the custom set of libraries and the copy of the base set of libraries maintained at the regional layer. The base set of libraries in the regional layer may be protected, for example, such that contents of the base set of libraries cannot be changed at the regional layer.
  • In yet another example, the multi-layer architecture may further include an environment layer, in operative interaction with the custom layer, providing processing functionality for a business processing system of the plurality of business processing systems. The installed base set of libraries support execution by the multiple business processing systems in batch and/or online by allowing the multiple business processing systems to implement the base set of libraries, if necessary, by concatenating the custom set of libraries and the base set of libraries. The environment layer may include, for example, a complete set of databases and data files for each business processing system of the multiple business processing systems.
  • In still another example, the multi-layer architecture may include a local layer, in operative interaction with the custom layer, providing application load modules for each business processing system of the multiple business processing systems. The local layer load modules may be dependent upon source code management system data.
  • In some embodiments of the present invention, a global framework multi-layer computer based architecture including at least one source code management system that provides executable production environments to support component applications may be provided. The multi-layer framework may include a global layer providing development functionality for multiple business processing systems within the source code management system. Source code for the multiple business processing systems may be developed within the global layer. The multi-layer framework may include a base layer, in operative interaction with the global layer, providing development and installation functionality for the multiple business processing systems. The source code for the multiple business processing systems may be staged to the base layer from the global layer for integration with existing source code for the multiple business processing systems to create a merged base set of libraries. The merged base set of libraries may contain substantially all common source code management system elements applicable to the multiple business processing systems. The merged base set of libraries may be tested in the base layer prior to installation of the merged base set of libraries.
  • The multi-layer framework may include a regional layer, in operative interaction with the base layer, providing installation functionality for the merged base set of libraries. The installed base set of libraries may support execution by the multiple business processing systems in batch and/or online. The regional layer of the multi-layer framework may include source code components and load module components as a copy of the base layer installed load module components.
  • The multi-layer framework may include a custom layer, in operative interaction with the regional layer, providing development and installation functionality for a business processing system of the plurality of business processing systems, wherein source code for the business processing system is staged to the custom layer for integration with existing source code for the business processing system to create a merged custom set of libraries. The merged custom set of libraries may contain substantially all modifications specific to the business processing system to meet local needs of the business processing system and providing the business processing system the functionality of concatenation. The merged custom set of libraries may be tested in the custom layer prior to installation of the merged custom set of libraries.
  • The multi-layer framework may include an environment layer, in operative interaction with the custom layer, providing processing functionality for the business processing system of the plurality of business processing systems. The installed base set of libraries may support execution by the multiple business processing systems in batch and/or online by allowing the multiple business processing systems to implement the base set of libraries, if necessary, by concatenating the custom set of libraries and the regional copy of the base set of libraries.
  • The multi-layer framework may include a local layer, in operative interaction with the environment layer, providing application load modules for each business processing system of the multiple business processing systems. The local layer load modules may be dependent upon source code management system data.
  • In some embodiments of the present invention, a source code management system may be provided. The source code management system may include a first multi-layer framework for managing and maintaining an existing production environment for multiple business processing systems. The first multi-layer framework may include a global layer, base layer and a custom layer in operative interaction with the base layer. The base layer may provide a base set of libraries including source code management system elements common to the multiple business processing systems. The custom layer may provide a custom set of libraries including source code specific to a portion of the business processing systems. In one example, the first multi-layer framework may further include a complete set of change management software mnemonics, source libraries, copybook libraries, and/or load module libraries to support the base and custom layers of the second multi-layer framework.
  • The source code management system may include a second and subsequent multi-layer frameworks, in operative interactive with the first multi-layer framework. The second multi-layer framework may provide functionality for development and testing of a source code enhancement release within the source code management system. The second multi-layer framework may include a global layer, base layer and a custom layer in operative interaction with the base layer. The base layer may accept the enhancement release. The custom layer may integrate release modifications and test the enhancement release. The custom layer may receive contents of the custom layer of the first multi-layer framework. In one example, the second multi-layer framework may further include a complete set of change management software mnemonics, source libraries, copybook libraries, and/or load module libraries to support the base and custom layers of the second multi-layer framework.
  • The enhancement release may be tested within the second multi-layer framework prior to implementation within the first multi-layer framework. The second multi-layer framework may revert to a testing environment upon certification and installation of the enhancement release.
  • In one example, the first and second multi-layer frameworks provide the ability to rollback changes to a previous version of the source code management system if there are any problems with the enhancement release.
  • In another example, the first and second multi-layer frameworks may be independent of each other and can exist at the same time. In other words, the second multi-layer framework may integrate code from the first multi-layer framework and then exist and function independently of the first multi-layer framework. This allows an SBU to be subject to a conversion from the first multi-layer framework to the second multi-layer framework without any rollback.
  • In some embodiments of the present invention, a method for configuration and release management of group application systems software within a source code management system may be provided. One or more changed components of group application systems software may be received at a global layer of the source code management system. The one or more changed components of the group application systems software may be integrated into a single set of merged programs at the global layer. The single set of merged programs may be tested at the global layer. The one or more changed components may be merged into a base set of libraries for source code and copybooks at a base layer of the source code management system. The one or more changed components may be tested at the base layer. The load modules for the merged components may be installed at a regional layer using base load modules. In one example, the multiple business processing systems may be provided with the ability to implement the base set of libraries in batch and/or online by allowing the multiple business processing systems to concatenate a custom set of libraries at a custom layer and the base set of libraries.
  • In some embodiments of the present invention, a method for configuration and release management of group application systems software within a source code management system may be provided. One or more changed components of group application systems software may be received at a custom layer of the source code management system. The one or more components may be applicable to only a portion of multiple business processing systems within the source code management system. The one or more changed components may be merged at the custom layer with a base set of libraries for source code and copybooks to create a custom set of libraries. The custom set of libraries may be tested at the custom layer. The custom set of libraries may be installed at the custom layer using custom load modules. In one example, the multiple business processing systems may be provided with the ability to implement the custom set of libraries in batch and/or online by allowing the multiple business processing systems to concatenate the custom set of libraries and a base set of libraries at a regional layer.
  • There has thus been outlined, rather broadly, the more important features of the invention in order that the detailed description thereof that follows may be better understood, and in order that the present contribution to the art may be better appreciated. There are, of course, additional features of the invention that will be described hereinafter and which will form the subject matter of the claims appended hereto.
  • In this respect, before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not limited in its application to the details of construction and to the arrangements of the components set forth in the following description or illustrated in the drawings. The invention is capable of other embodiments and of being practiced and carried out in various ways. Also, it is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting.
  • As such, those skilled in the art will appreciate that the conception, upon which this disclosure is based, may readily be utilized as a basis for the designing of other structures, methods and systems for carrying out the several purposes of the present invention. It is important, therefore, that the claims be regarded as including such equivalent constructions insofar as they do not depart from the spirit and scope of the present invention.
  • These together with other objects of the invention, along with the various features of novelty which characterize the invention, are pointed out with particularity in the claims annexed to and forming a part of this disclosure. For a better understanding of the invention, its operating advantages and the specific objects attained by its uses, reference should be had to the accompanying drawings and descriptive matter in which there is illustrated preferred embodiments of the invention.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • Additional embodiments of the invention, its nature and various advantages, will be more apparent upon consideration of the following detailed description, taken in conjunction with the accompanying drawings, in which like reference characters refer to like parts throughout, and in which:
  • FIG. 1 illustrates a prior art computing system deployment planning method;
  • FIG. 2 illustrates a prior art method for service and role-based software distribution;
  • FIG. 3 illustrates a prior art system and method for application management;
  • FIG. 4 illustrates a prior art system and method for software building and deployment;
  • FIG. 5 illustrates a prior art method and apparatus for software deployment;
  • FIG. 6 is a schematic diagram of an illustrative global framework including a plurality of layers in accordance with some embodiments of the present invention;
  • FIG. 7 is a schematic diagram of an illustrative process for creating multiple sets of copybook libraries for the global framework in accordance with some embodiments of the present invention;
  • FIG. 8 is a schematic diagram of an illustrative process for creating multiple sets of online source code libraries for the global framework to support development and testing in accordance with some embodiments of the present invention;
  • FIG. 9 is a schematic diagram of an illustrative process for creating multiple sets of batch source code libraries for the global framework to support development and testing in accordance with some embodiments of the present invention;
  • FIG. 10 is a schematic diagram of an illustrative process for scheduling of packages for installation at the base layer of the global framework in accordance with some embodiments of the present invention;
  • FIG. 11 is a schematic diagram illustrating the geographic distribution that takes place when an installation such as the installation of FIG. 10 is performed in accordance with some embodiments of the present invention;
  • FIG. 12 is a schematic diagram of an illustrative process for change management software package installation and baseline processing in the global framework in accordance with some embodiments of the present invention;
  • FIG. 13 is a schematic diagram of an illustrative process for promotion of changed components within the custom layer of the global framework for testing in accordance with some embodiments of the present invention;
  • FIG. 14 is a schematic diagram of an illustrative concatenation process for each testing level of the global framework in accordance with some embodiments of the present invention;
  • FIG. 15 is a schematic diagram illustrating the change management software mnemonics for each layer of the global framework and additional versions of the global framework for new releases in accordance with some embodiments of the present invention;
  • FIG. 16 is a schematic diagram of an illustrative process for development and testing of the next release to be implemented at the SBU level using the shadow global framework in accordance with some embodiments of the present invention;
  • FIG. 17 is an illustrative flow diagram that demonstrates the configuration and release management of software globally to the account management system in accordance with some embodiments of the present invention; and
  • FIG. 18 is an illustrative flow diagram that demonstrates the configuration and release management of software locally to specific SBUs within the account management system in accordance with some embodiments of the present invention.
  • DETAILED DESCRIPTION OF THE INVENTION
  • The following description includes many specific details. The inclusion of such details is for the purpose of illustration only and should not be understood to limit the invention. Moreover, certain features which are well known in the art are not described in detail in order to avoid complication of the subject matter of the present invention. In addition, it will be understood that features in one embodiment may be combined with features in other embodiments of the invention.
  • In accordance with at least one embodiment of the present invention, a framework for configuration and release management of group application systems software is provided. In particular, the framework of the present invention may provide for the configuration and release management of group application systems software in, for example, an account management system, both globally to the account management system and locally to business units within the account management system.
  • The global framework of the present invention includes various features that result in an improved method for configuration and release management of group application systems software in an account management system, and in particular a credit card account management system. Such features may include, for example, a single set of libraries that contain common card processing system elements (e.g., the “global version” of the system); policies, processes, and procedures that allow for consistent use of and modifications to common card system elements; regional load module libraries to manage installation and distribute revised card system elements at a specific site or for a set of time zones; individual code libraries for SBUs that contain business unit specific modifications to meet local needs (e.g., local modifications that supplement or replace global business processing); individual execution environments (e.g., online and batch) to support data management and processing for each SBU; and naming standards to control and identify components, libraries, data sets, and execution environments.
  • The framework of the present invention has been built and enhanced on the premise that common functions can be provided through a single set of “base” source code, while allowing country- or SBU-specific processing through modifications, control parameters, and the integration of locally-developed solutions. The present invention provides a global framework to manage the source code and related components that provide executable production environments to support business software applications.
  • The global framework of the present invention is both a structure and a set of associated tools and processes that allow a single base of program code and related components to be managed and modified, thereby meeting the processing needs of business units through the use of a common account management system. The global framework provides flexibility to incorporate software changes as business needs evolve, while keeping code release versions consistent and current across all business units within the account management system. This flexibility results in an improved speed-to-market for changes to the account management system.
  • The global framework of the present invention includes various features and components for configuration and release management of group application systems software. The global framework includes source, copybook, load module, and related libraries used to contain components of the card processing system. Such components may include, for example, JCL, PROCs, control cards, etc. The global framework includes naming conventions to ensure segregation and control of both global and SBU-specific components, libraries, and datasets for development, testing and production. The global framework includes a comprehensive change management structure that controls the use of software version promotion levels as described herein. The framework supports the concurrent development of components within the framework. In one example, the component change management tool used in conjunction with the framework and processes described herein is ChangeMan®, sold by SERENA Software, Inc. of San Mateo, Calif.
  • The global framework of the present invention in combination with its associated tools, processes, and procedures effectively deliver group application systems software within an account management system. The global framework provides standardized tools and techniques for concurrent development of software for multiple SBUs from a single source platform. In doing so, the global framework significantly reduces the number of system components for which changes need to be managed for users of a particular group system.
  • The framework of the present invention may be used in connection with any entity (e.g., vendor, governmental agency, in-house developer, etc.) that provides updates or changes to an application-based software system such as an account management system, a credit card account management system, or other financial services system. Possible software updates may include, for example, compliance updates, enhancement releases, and fixes.
  • Compliance updates address any changes to operating regulations, for example, by a credit card provider (e.g., Visa, MasterCard) or by a governmental agency (e.g., Sarbanes-Oxley, etc.). For example, Visa and/or MasterCard operating regulations change on a regular basis to meet the needs of all credit card issuing and acquiring members. As a result, payment card association members, banks, and processors must comply with these amendments on a set schedule. These mandates are usually effective on the first of April and the first of October of each year. A software vendor or in-house developer develops compliance updates for all components within a credit card account management system. These compliance updates are delivered by the vendor or in-house developers typically in late February and August. The credit card member then accepts these updates for integration into the specific version of the credit card account management system.
  • Enhancement releases address any new features and functionality that are added to, for example, the credit card account management system. These releases may be created by a vendor, or may be created in-house. Typically, vendor enhancements are delivered every twelve to eighteen months, and are packaged as a new release of the business system. The vendor's enhancement releases are integrated with a credit card member's version of the credit card account management system for delivery in an internal enhancement release.
  • Fixes may be released by a vendor or by in-house developers to correct any specific software problems or to update system processing based upon the business needs of a specific SBU.
  • For efficient release management of group application systems software within the account management system, the framework of the present invention controls the libraries and environments used in production and release testing. The framework supports the current version of the account management system in production, and release versions of the framework which allows for the development and testing of a software release to be implemented at the SBU level. More than one version of the global framework can be created to support multiple SBUs each operating on a different release version of the account management system. The previous software version of the account management system continues to be used by SBUs that were already using it in production, until such time as they are ready for conversion to a later release version of the account management system.
  • In some embodiments of the present invention, promotion features are provided in connection with the promotion of a software fix, enhancement, or release within the global framework. The lifecycle of a fix, enhancement, or release starts with development of source code changes and ends with installation and implementation. The developer of the software, using change management software such as ChangeMan®, initiates a process that incorporates all software components affected by a change. Upon successful completion of development and unit testing, the developer initiates the promotion process. The promotion process leads to the migration of the appropriate components from the current level of development or testing to the next higher level of testing (e.g., within the global framework). This process continues until the package is determined to be “production ready,” at which time the package is installed.
  • The installation process of the present invention is initiated after extensive testing to ensure that the load modules and related components are production-ready. This testing results in a certification by the system that the modules and components are ready for installation. Load modules are installed via the change management software package into load module libraries, based upon a predefined schedule for the package. The package of software changes is installed, for example, in the corresponding library or libraries for the global account management core system or in an SBU-specific library or libraries.
  • In change management software terminology, the final step after a change management software package has been installed in the correct libraries, according to the predefined schedule, is to “baseline” the amended components. This baseline process takes place in the account management system component libraries. At this point in the process, the status of source code, copybooks and associated components is defined as “baselined” and they become a permanent part of the corresponding base account mangement system libraries. Any development or test versions of source, copybooks or other components that were created by the package during its transition from development to production installation are eliminated through an automated process.
  • As described hereinabove, the global framework of the present invention is made up of component management structures, referred to herein as “layers,” configuration management and reporting tools, naming standards, and library types. Each of these features of the global framework is described in detail hereinbelow, in connection with FIGS. 6-16.
  • The global framework of the present invention includes a number of layers to support segregation of globally-applicable software solutions from those that apply to specific SBUs. These layers advantageously permit the use of a single base of global source code and components to be used as the foundation for all account management system users, while still supporting the specific needs of each SBU. The global framework may include any number of layers. As shown in FIG. 6, for example, the global framework is illustrated as including six layers. This example is merely illustrative, however, and the framework may include some, all, or additional layers to the six shown in FIG. 6.
  • FIG. 6 illustrates the following six layers: global layer 102, base layer 104, regional layer 106, custom layer 108, environmental layer 110, and local layer 112.
  • Global layer 102 provides a development environment for software developers in, for example, a credit card processing system. Global layer 102 acts as the initial point at which vendor source code/copybook enhancements are integrated with the custom enhancements created by in-house developers on behalf of all SBUs. Global layer 102 supports the process of merging the two compatible sets of source code and copybook libraries into a full set of merged programs (source code and copybooks) that forms the foundation of the global account management system, so that the merged programs can be compiled and preliminarily tested.
  • In addition, homegrown applications which are an integral part of the overall account management system , are developed, compiled and tested as part of the global layer 102, prior to staging into base layer 104 (staging described in more detail hereinbelow).
  • Upon successful testing of enhancement releases and fixes at global layer 102, changed components are staged to the appropriate libraries at the base layer 104 for integration, testing, and subsequent installation in the production environment.
  • Base layer 104 provides support for the development and installation of all sub-systems. Vendor and homegrown solutions are integrated into the global card system at base layer 104. In addition, in-house developers may apply further fixes and modifications to the system at base layer 104, as needed.
  • The process at base layer 104 involves the merging of homegrown changes with vendor-supplied source code and copybooks to create a merged base set of libraries for source code and copybooks. Upon completion of integration and testing of these changes in the appropriate base layer environments, system global load modules are installed at regional layer 106.
  • Regional layer 106 provides a point at which production load libraries are distributed to support execution in batch or online. Regional layer 106 contains an exact copy of the execution libraries for base layer 104 load modules, so that individual SBUs can easily access the appropriate components in a local operational environment (e.g., environment layer 110). This is accomplished through concatenations of load module libraries.
  • Regional layer 106 load module libraries eliminate reliance on a single physical set of base layer 104 libraries for load modules. These load libraries are protected such that developers cannot change their contents, except through the authorized promotion/installation processes defined within the change management software at base layer 104 (described hereinbelow).
  • Custom layer 108 provides a number of advantages to the SBUs in the system. For example, custom layer 108 minimizes the time to market for minor releases and fixes within the global framework. Custom layer 108 provides the ability to maintain the integrity of the global system solution through code management tools and infrastructure. Custom layer 108 provides support for the evolution of solutions that have already been proven at the SBU level to be deployed globally as part of a major release.
  • Custom layer 108 provides the ability for each SBU to identify and implement processing rules and data that are specific to local market needs. A custom layer 108 exists for each SBU and includes of a set of component libraries that are used for development of SBU-specific source code/copybook changes and additions to the system.
  • Changes that are made at custom layer 108 by in-house developers are merged with corresponding source code and copybooks that have been created at base layer 104, similarly to the changes made at global layer 102. This merge is accomplished through change management software tools and promotion levels. Changes are developed, tested, and promoted through necessary environment levels, until they are ready for installation. At that point, in-house developers request an install of the package through the change management software. As a result of the installation via the change management software, the changes are baselined within custom layer 108.
  • New or modified components that exist in custom layer 108 may be accessed during execution by use of concatenations of the load module libraries within JCL that will point to the custom libraries first. If any given component is not found at custom layer 108, regional layer 106 load module libraries will be used.
  • Environment layer 110 is the operational processing environment in which all card system applications execute and where data files and databases are controlled and updated. It includes batch and online processing environments that support testing and production requirements. Environment layer 110 contains a complete set of databases, files and execution environments for each SBU. A distinct environment (batch and online) is created for each testing level required to support the SBU, as well as for production. The data files and databases are updated in at least one embodiment, for example, only by system applications.
  • Data and information that are required for processing outside the scope of the system for applications developed and maintained by SBUs are supported through interfaces (e.g., typically files) created for the express purpose of providing operational data to these systems. Development required to create these interfaces may be done at custom layer 108 by in-house developers. This process ensures full operational control by the primary production systems while still permitting each SBU to access information required for additional processing functions to meet local requirements.
  • Local layer 112 is a complete environment created for each SBU that contains non-card system application load modules that are used by an SBU and are dependent on system data. These applications may receive interface data from environment layer 110 during or after execution of system applications, as well as from other systems sources. The definition, development, and maintenance of these local applications may be managed and controlled by staff at the SBU.
  • As described hereinabove, the framework of the present invention may include some, all, or additional layers to those layers illustrated in FIG. 6, namely, global layer 102, base layer 104, regional layer 106, custom layer 108, environment layer 110, and local layer 112. In some embodiments of the present invention, for example, the framework may include only base layer 104 and custom layer 108. The use of base layer 104 and custom layer 108 allows global changes to be staged into base layer 104, and local changes specific to only a portion of the SBUs to be staged into custom layer 108.
  • Change management software, e.g., ChangeMan®, is the primary tool used to support the development and installation of various types of source code, copybooks, load modules, and other components in the mainframe environment. The change management software tool automates the full lifecycle of movement of system development components from development/testing through quality assurance (“QA”) and installation into production.
  • Change management software provides a wide range of features. For example, the software guarantees coordination of all components of a defined package for simultaneous promotion. The software supports concurrent development and maintenance of components by multiple developers. The software prevents version discrepancy and out-of-synch relationships through the use of auditing tools. The software provides notifications of activities and online access via reporting tools. The software maintains historical records of changes to components. The software supports the ability to rollback changes to specific versions.
  • Change management software uses the concept of a package of components created by developers to identify changed components. These packages are used for analysis and promotion to the correct testing environment or for installation into production. Change management software also provides automated back-out procedures for packages to support recovery of previous versions of components.
  • The change management software manages the correct creation of packages and their contents through the use of partitioned datasets (“PDS”) that store required components (e.g., source, copybooks, Job JCL, PROCs, etc.). A promotion level supports an environment occurrence (online and batch) to be used for a specific purpose, such as development/unit test, conversion, training, QA, etc. Each promotion level includes a set of libraries that support the development/testing functions being performed. The set of libraries that exist at the promotion level includes support for the online (CICS) region, batch processing procedures (JCL and PROCs), datasets, and the PDS libraries for load modules, source code, copybooks, and associated other components necessary to describe the overall execution environment.
  • The major library types that require the most frequent manipulation and promotion are copybooks, source code, and load libraries (batch and online).
  • Copybooks (e.g., COBOL copybooks) are managed through the use of partitioned datasets controlled by the change management software. A copybook PDS contains a distinct member for each copybook. Naming conventions for each copybook library are used to identify the origination point (e.g., vendor, card system, etc.) of the code created for each copybook and the type of code that it is.
  • Copybooks may be, for example, data division statements or procedure division statements. Copybooks may be used, for example, for one of two reasons: the code is a candidate for use in multiple programs (e.g., COBOL programs) or it is a modification/enhancement to an existing vendor module/program that exceeds five lines of code.
  • Each global framework layer described hereinabove and shown, for example, in FIG. 6, may have a set of copybook libraries to support the testing, installation, and distribution of global system application software. Depending on the layer and the number of environments required, there may be multiple sets of copybook libraries created to support development and testing needs. The process is illustrated, for example, in FIG. 7.
  • Source code is managed through the use of a PDS controlled by the change management software. Source code may be, for example, COBOL, Assembler, or any other suitable procedural language. Each global framework layer has a corresponding set of source code libraries to support the testing, installation, and distribution of the account management system application software. Depending on the layer and the number of environments required, there may be multiple sets of source code libraries created to support development and testing needs. These are illustrated in FIGS. 8 and 9.
  • Within the change management software, the proper identification of each component type requires the selection of the correct compile or assembly process to be executed to create load modules. In particular, system modules based upon the vendor-supplied system and the in-house version of this are subject to a merge process to combine the respective source or copybooks. Members of these merged libraries are then compiled/assembled. Other modules can be compiled/assembled without the need for merge. The change management software uses this component-type identification to determine which procedure needs to be invoked to create the corresponding load module.
  • The component, procedure types, and description of each is described in the table below:
  • PROCEDURE
    COMPONENT TYPE DESCRIPTION
    ASM CMNASM Assembler for in-house developed
    programs and BMS Maps that are not
    subject to the in-house version of
    the credit card system merge process
    ASM CMNMERGE Assembler code that is subject to the
    in-house version of the credit card
    system merge process
    COBOL3 COBOL370 COBOL source code that is not subject
    to the in-house version of the credit
    card system merge process
    COBOL3 CMNMERGE COBOL source code that is subject
    to the in-house version of the credit
    card system merge process
    COPYBOOK CMNMERGE COBOL copybooks that are subject
    to the in-house version of the credit
    card system merge process
    JOB JOB JCLCHECK for jobs
    MAPGNMRG CMNMERGE BMS Maps that are subject to the in-
    house version of the credit card
    system merge process
    PROC PROC JCLCHECK for PROCs
  • Load libraries (.PGM for CICS Online and .LNK for batch) are partitioned datasets (PDS) created to contain the programs that will be used for development, testing, installation, and execution in a production environment. An individual module in a load library is created as a result of a compile/assemble requested by, for example, the developer of a program. The contents of these libraries are managed through the change management software promotion process, which controls migration through the use of promotion levels and change management software packages.
  • Each global framework layer has a corresponding set of load libraries to support the testing, installation, and distribution of the system application software. Note, however, that the global layer 102 set of load libraries is used for the migration process of merging vendor and in-house changes to form the system, and is used for development testing only. These load modules are not subject to promotion, migration or distribution to any other layer within the framework. System source code, etc. is staged into the base layer 104 change management software mnemonic before any compilation occurs at base layer 104.
  • In order to implement any type of change into the system production environment, a number of decisions need to be made. First is the criticality of the change. It is also important to determine whether the change is global in nature or applies to a single SBU. Finally, it is important to determine at what point in the development life cycle of the software the change can be introduced.
  • There are various categories of changes that may be made to the system. For example, compliance changes may be made to the system. These compliance changes may be mandated by a payment card association on a semi-annual basis, or by a governmental agency.
  • An enhancement may be made to the system. Enhancements include major and minor modifications to the system that address business requirements not present or adequately provided at present. These enhancements are usually made on an annual basis as a major release.
  • A fix may be made to the system. Fixes include minor and concise changes to functionality that improve the capabilities of the system but do not prevent day-to-day operations. Fixes are usually made on an annual basis and may be included in the enhancement release. Fixes may also be implemented on an ad hoc basis, at either base layer 104 or custom layer 108, as business needs demand.
  • Emergency fixes may be made to the system. Emergency fixes are changes required to system modules in the short-term to permit correct operations. These emergency fixes are infrequent but critical fixes.
  • Promotion levels are defined to accommodate the smooth transition of copybooks, source code, and other related components from the development environment through testing environments and for eventual installation in production. There may be, for example, six environments defined as standard for any SBU implementation (see, e.g., FIG. 13). This number of environments is merely illustrative, however, and any suitable number of environments may be used for SBU implementation.
  • The following table, “Promotion Levels—Base Layer 104,” provides the corresponding standard promotion levels for both base layer 104 and custom layer 108. The following table also depicts how naming standards and conventions supports the various environments. A template for derivation of names for promotion levels for all SBUs is also provided hereinbelow as “Custom Layer 108 Template.”
  • The change management software promotion levels are used by the developer in conjunction with a change management software package to collect components to be grouped together as part of a unit of change. It can include any component type. The developer is responsible for defining a package and then adding components to the package. These may be COBOL source code and copybooks, although the package may also include items such as JCL, Assembler programs, or BMS Maps (CICS screen definition macros).
  • Once the package has been defined and any assemblies or compiles completed, the package is eligible for promotion. Note that load modules are automatically added to packages. The developer will request promotion of the package to the next testing level as prescribed by the testing requirements of the overall project. Packages progress through testing levels via promotion to the point of certification that the contents are production worthy and are then subject to install.
  • Promotion Levels - Base Layer 104
    Library Type Dataset Name(DSN)
    CICS Promotion First Second ChangeMan ®
    Level Region Purpose Level Node Node Environments Mnemonic
    1 N/A Development/Unit Test L1AMDEV D000. CP000000. D0B1 W0B1
    2 N/A Systems/Integration Test L2EUSIT D000. CP000000. R0B1 W0B1
    10 N/A Quality Assurance/User Q10APUAT Q000. CP000000. Q0B1 W0B1
    Acceptance Test
    N/A N/A Production N/A P000. CP000000. P0B1 W0B1
  • Custom Layer 108 Template
    Library Type Dataset Name(DSN)
    CICS Promotion First Second ChangeMan ®
    Level Region Purpose Level Node Node Environments Mnemonic
    1 H@B0 Development/Unit L1DEV D++0. CP000000. D&&& W&&&
    Testing
    2 H@B1 Systems/Integration Test L2SIT D++0. CP000000. R&&& W&&&
    7 C@B0 Conversion L7CONV C++0. CP000000. C&&& W&&&
    9 T@B0 Training L9TRN T++0. CP000000. T&&& W&&&
    10 J@B0 Dress Rehearsal Q10UAT Q++0. CP000000. Q&&& W&&&
    (QA/UAT)
    N/A P@B0 Production (Install only; N/A P++0. CP000000. P&&& W&&&
    not promotion)
    &&&= ChangeMan ® Mnemonic, last 3 characters
    ++= Owner ID & Country/Framework ID
    @= Country ID
    For Promotion purposes these are the only CICS Regions used.
    Software is moved to Production as a result of a ChangeMan ® Install only.
    CICS Programs are found in Library Type DSNs: .PGM e.g. D2B0.CP000000.D2B1.PGM Development
    Batch Programs are found in Library Type DSNs: .LNK e.g. T2B0.CP000000.T2B1.LNK Training
  • The installation process includes multiple steps primarily controlled by the change management software package. While similar to a promotion, an installation is a prelude to the baseline process, which changes the status of the change management software package components and production execution libraries. Baselining a package and its contents permits components to be checked out by developer for further modification.
  • For packages that are part of base layer 104, the change management software install process copies load library modules that have been created as part of the package to the regional layer 106 load libraries, thereby making the load library modules available for execution in the corresponding production environment or environments.
  • When a package is installed at base layer 104, a duplicate copy of the load modules are created at regional layer 106. Changes are then available for execution by all environments to which regional layer 106 load libraries are concatenated.
  • This install process takes place according to the schedule defined in the change management software.
  • Load modules in the package are installed to all occurrences at regional layer 106 (e.g., the Americas, Europe, etc.). Upon completion of the last installation step in the schedule at regional layer 106, the load module is copied to the base layer 104 load module libraries and the baseline process of the package components occurs.
  • FIG. 10 illustrates the scheduling of packages for installation at base layer 104. Note that when scheduling the install, it is necessary for all steps to complete before the package contents are baselined at base layer 104.
  • FIG. 11 illustrates the geographic distribution that takes place when the install is performed. Load modules are copied from, for example, the central development Sysplex to the remote production Sysplexes at which the regional layer 106 load module libraries are maintained.
  • The change management software completes the baseline process when it has certified that all regional layer 106 installation steps have been completed successfully. Note that a copy of the regional layer 106 load module libraries is also maintained at, for example, the development Sysplex for redundancy purposes.
  • As shown in FIG. 11, for example, the installation of a change management software package to production initiates an automatic process. The installation results in load modules (batch and/or on-line) being copied, according to a pre-determined schedule, from the source load module libraries in the development LPAR to the destination load libraries - either regional layer 106 (using base layer 104 as source) or custom layer 108 (using custom layer 108 as source) LPAR(s). Upon completion of all scheduled installations for the change management software package, the package components are baselined at the corresponding source layer.
  • At the custom layer 108 for a specific SBU, the change management software install process copies load modules that have been created as part of the package to the custom layer production load libraries. These load modules are then available for execution in the corresponding SBU custom layer 108 production environment.
  • The install process takes place according to the schedule defined in the change management software. Upon completion of the custom layer 108 installation, the baseline process of the package components occurs.
  • The load modules in the package are installed to the production level set of load module libraries at custom layer 108, based upon the schedule defined in the change management software by the developer.
  • As noted hereinabove, the load modules are copied from, for example, the central development Sysplex to the remote production Sysplexes at which custom layer 108 load module libraries are maintained. Upon completion of the installation step, the baseline process of the package components occurs at custom layer 108.
  • The change management software package installation and baseline process are illustrated in FIG. 12.
  • Testing environments for certain layers of the global framework are created around, for example, the CICS region required for each level of testing and production for each SBU. Each environment incorporates both online (e.g., CICS) components as well as the corresponding batch components to support online processing.
  • The testing levels that are required for acceptable levels of quality in the production environment are described hereinbelow. Note that support for a primary development, systems test, QAJUAT, and production environment exists at both base layer 104 and custom layer 108. There is a one to one correspondence of libraries and testing levels to allow for a timely and consistent progression of changes through each development/testing level. Promotion levels are defined within the change management software for each of the testing levels to support progression of modifications.
  • As described hereinabove, changes to source code/copybooks are assigned to a change management software package within the change management software. These changed components can then be compiled into load modules that are added to the package for use in the testing and promotion process. The contents of the package then advance to the next higher level of testing via package promotion using the change management software. This process of promotion continues until all testing is completed and the package is installed. This installation occurs either at base layer 104 or custom layer 108, depending on the global or local applicability of the software. In particular, if the change is global in nature, and applies to all SBUs, it is installed in the regional layer 106 load module libraries. If the change is SBU-specific, it is installed in the custom layer 108 load module libraries. The installation process is illustrated in FIG. 13.
  • Naming conventions provide a convenient way for a systems development project to organize all of the components required during the process of creating solutions for a complex business problem. Naming conventions have many advantages. For example, naming conventions eliminate the likelihood of incorrectly naming an element. Naming conventions provide easy identification of what an object is used for. Naming conventions provide an improved ability to identify the SBU- or application-owner of the object.
  • Specific rules are defined for use in the generation of the appropriate dataset or library name for a given global framework layer. These standards support not only the management of software releases, they are also provided to permit differentiation of programs, libraries, and datasets at the SBU level.
  • Dataset names (DSNs) provide a way to identify files and databases that are used by batch and online programs. In an environment where many SBUs operate a single base set of an application, it is important to be able to segregate the files and databases by business owner. This is accomplished through the use of dataset naming standards in accordance with the present invention.
  • Libraries are used to store key components including program load modules, specific tables and codes, and control cards (CTCs) that manage the allocation of resources and determine processing needed at a specific processing point. Within a processing model where many SBUs operate from a single base set of an application, it is important to be able to segregate the base layer 104 libraries and SBU-customized libraries at the custom layer 108 by business owner. This is accomplished through the use of library naming standards in accordance with the present invention.
  • Job names are used to identify the batch execution job streams. To segregate and control each environment for individual SBUs, it is important to have unique job names that identify execution units for the local business unit. The job name is used in conjunction with job control language (JCL) to build specific batch execution streams. Each job name must be unique for scheduling purposes. This is accomplished through the use of the job naming standards in accordance with the present invention.
  • Procedure (PROC) names are used to identify “blocks” of JCL statements executed as part of a batch job stream that has a unique job name. To segregate and control each environment for individual SBUs, unique PROC names are used to identify execution units for the local business unit. This is accomplished through the use of the PROC naming standards in accordance with the present invention.
  • An account code is a five character code required to establish allocation of charges for use of physical resources in a mainframe environment. The account code identifies the environment, owner, country, and application to which the job belongs. This is accomplished through the use of the account codes naming standards in accordance with the present invention.
  • Individual change management software control libraries are uniquely identified through the creation of a mnemonic within the change management software. This mnemonic is used to differentiate projects, or occurrences of components within a project, to support control of those components. The change management software mnemonic for a specific layer, or occurrence within a layer, is derived using the change management software naming standards in accordance with the present invention.
  • Load modules, whether used for CICS online execution or batch program jobs, are stored in libraries. The load modules that form part of the card system reside in the base layer 104 load libraries. However, to permit graceful implementation and installation of changed application code, regional layer 106 contains a copy of the card system load modules maintained at base layer 104. This copy of the load modules eliminates reliance by all SYSPLEXES (which are geographically dispersed) on a single set of load libraries at a central location. A “SYSPLEX” is a collection of mainframe processors that share resources and provide a processing platform for many batch and online environments. It is used as a management point for all resources required to meet the needs of many general purpose business systems. A SYSPLEX may include, for example, CPU, memory, network connections, direct access storage devices (DASD), magnetic tape drives and other input and output media types.
  • Each SBU environment may have customized versions of modules that are to be executed in lieu of the load module that resides in regional layer 106. To properly facilitate this feature, libraries are concatenated in order from custom layer 108 to regional layer 106. “Concatenation” means that, when the module is to be invoked, the system searches first in the custom layer 108 load libraries for the module. If the load module is not found in the custom layer 108 load libraries, then the regional layer 106 load libraries are used to provide the load module.
  • Examples of the concatenation sequence for the production environments, to include regional layer 106 as well as custom layer 108 libraries, is shown in the table below:
  • Type Layer Library Name
    Batch Custom P2M0.CP000000.P2M1.LNK
    Regional P200.CP000000.P2R1.LNK
    Online Custom P2M0.CP000000.P2M1.PGM
    Regional P200.CP000000.P2R1.PGM
  • The concatenation sequence is also dependent upon the test level for the environment. FIG. 14 illustrates a concatenation sequence for each testing level, as well as production environments. Examples of the concatenation sequence for the various test environments, to include regional layer 106 as well as custom layer 108 libraries, are shown in the table below:
  • Layer Library Name (Batch & Online)
    Development/Unit Test
    Custom D2M0.CP000000.D2M1.PGM & .LNK
    Regional D200.CP000000.D2R1.PGM & .LNK
    Custom P2M0.CP000000.P2M1.PGM & .LNK
    Regional P200.CP000000.P2R1.PGM & .LNK
    Systems/Integration Test
    Custom D2M0.CP000000.B2M1.PGM & .LNK
    Regional D200.CP000000.B2R1.PGM & .LNK
    Custom P2M0.CP000000.P2M1.PGM & .LNK
    Regional P200.CP000000.P2R1.PGM & .LNK
    QA (User Acceptance Test)
    Custom Q2M0.CP000000.Q2M1.PGM & .LNK
    Regional Q200.CP000000.Q2R1.PGM & .LNK
    Custom P2M0.CP000000.P2M1.PGM & .LNK
    Regional P200.CP000000.P2R1.PGM & .LNK
  • As each SBU implementation team initiates the development and testing project, the creation of the appropriate global framework environment and card system infrastructure components will be requested. The global framework requires the definition and creation of a change management software mnemonic, library types, and libraries. Infrastructure components are composed of all technical aspects of the batch and online environment.
  • Upon establishment of the SBU global framework environment, in-house development teams can commence the modifications necessary to meet the business requirements for a specific SBU.
  • Changes made to card system source and/or copybooks using the global framework of the present invention can be at either base layer 104 or the custom layer 108. Changes at base layer 104 are considered to be “global” in nature, and therefore affect all SBUs. The base layer 104 load modules are executed unless overridden by changes applied at custom layer 108 to meet SBU needs.
  • Changes made at custom layer 108 are specific to the needs of a single SBU. When changes are made at custom layer 108, the load modules created as a result are executed in preference to those that exist at base layer 104. This is accomplished through the use of load module library concatenation, as described hereinabove.
  • A feature of the global framework of the present invention is a “shadow” framework for use in connection with enhancement releases. An enhancement release of a system requires the ability to manage and maintain the existing production environment and the supporting testing environments, while at the same time permitting development and testing of the next major release of the system. The nature and complexity of the system dictates that a separate and distinct framework, libraries and environments be created to provide a method to fully and successfully test global functions, as well as any SBU custom changes that have been made to the current version of the card system.
  • The shadow framework of the global framework is a “shadow” of all aspects of the existing global framework. This shadow global framework provides environments for the acceptance of a new release of vendor source code and copybooks that constitute the next release of the system (e.g., at base layer 104). This is supplemented by any in-house changes to the system, at base layer 104, for example, and additional functionality created for specific SBUs, at custom layer 108, for example.
  • The shadow framework of the present invention provides various advantages. For example, the shadow framework permits the acceptance of new releases of the system into a set of environments separate and distinct from production baselined system libraries and change management software mnemonics. The shadow framework supports end-to-end testing of new releases at both base layer 104 and custom layer 108 prior to installation/implementation in a production environment. The shadow framework provides the ability to allow SBUs to begin using the new release of the account management system based upon their ability to manage the conversion to the new release.
  • The shadow global framework includes a complete set of change management software mnemonics, source/copybook libraries (using standard lib types), other source components, and load module libraries that support base layer 104 and custom layer 108. In addition, libraries also are provided at regional layer 106 to support geographic distribution of load modules.
  • As can be seen in FIG. 15, for example, a change management software mnemonic exists for each layer of the framework that contains components that can be created and maintained within the system (e.g., source code, copybooks, etc).
  • For smooth migration of SBUs from one major enhancement release of the system to the next, it is important to control the libraries and environments used in production and release testing. The global framework of the present invention is used to support the current version of the system in production. The shadow global framework of the present invention provides the mechanism for the development and testing of the next release to be implemented at the SBU level. More than one shadow global framework can be employed depending on the speed at which SBUs are able to migrate from one release to another. This aspect of the present invention is illustrated in FIG. 16. (It should be noted that the release notations, e.g., Release 8.15, Release 8.16, etc., provided in FIG. 16 are merely for illustration.)
  • Upon delivery of an enhancement release from a vendor and/or from an in-house developer, it is staged into the shadow global framework base layer 114 for that release. In addition, the contents of the existing custom layer 108 change management software mnemonics are migrated to the new release shadow global framework (e.g., to shadow custom layer 118). This duplicate copy is used as the foundation for integrating release modifications and testing the new release.
  • Any customizations to the card system created by an in-house developer are reviewed in light of the contents of a vendor release. A determination is made as to what extent any fixes applied at custom layer 108 have become redundant due to enhancements at base layer 104. Changes that are no longer needed at the custom layer 108 are removed and components are scratched or recompiled as required.
  • As changes can be introduced at custom layer 108 for an SBU-specific business requirement, it may be necessary to modify SBU-specific enhancements that will continue to be supported at custom layer 108. For example, this could be due to changes to files, copybooks, or source code used from base layer 104 as the basis for custom layer 108 enhancements.
  • All application sub-systems may use the shadow global framework for development of the next release of the card system. In particular, the release of any major enhancements to the system may be integrated and tested in the corresponding shadow global framework environments before installation into production.
  • Upon successful integration of source code/copybooks at base layer 104 and custom layer 108, full testing of the new release of the system is conducted prior to implementation in production.
  • Once the latest release of the system is certified as production ready and has been installed, the shadow global framework becomes available for use by SBUs, either as a conversion from a previous version or as a new SBU added to production.
  • The global framework may be implemented with, for example, an IBM mainframe environment using standard operating systems and tools, such as z/OS1.6, TSO, CICS, ChangeMan®, etc.
  • Various features of the present invention will be described hereinbelow in connection with the flow diagrams illustrated in FIGS. 17 and 18.
  • FIG. 17 is an illustrative flow diagram that demonstrates the configuration and release management of software globally to the account management system. At step 300, one or more changed components of the group application systems software are received at the global layer (e.g., global layer 102 of FIG. 6). At step 302, the one or more changed components are integrated into a single set of merged programs at the global layer. An example of this integration is shown in FIG. 6, with “Vendor” and “Card System” changes integrated into a single set of “Global Merged” programs at global layer 102. At step 304, the set of merged programs are tested at the global layer. By testing at the global layer, developers are free to test and further develop the software components without disrupting the processing of the remaining portions of the global framework, especially of software components used in production by SBUs.
  • At step 306, the one or more changed components are staged to the appropriate libraries at the base layer. As shown in FIG. 6, for example, the “Card System” and “Vendor” changes are staged to base layer 104. At step 308, the one or more changed components are merged into a base set of libraries for source code and copybooks. FIG. 6, for example, illustrates “Base Merged” as the merger of the “Gold Library Changes,” the “Vendor” changes, and any other changes integrated into base layer 104. The one or more changed components are tested at the base layer at step 310. An example of testing support at base layer 104 is shown, for example, in FIG. 13, which illustrates the promotion of a component up to the installation step. At step 312, following the testing of the changed components and, for example, certification that the components are “production ready,” the merged components are installed at the regional layer using base layer load modules. As shown in FIG. 6, for example, the “Base Load Modules” are used to install the “Base Merged” components from base layer 104 into the regional layer 106 libraries, for use by the SBUs.
  • It should be noted that the development and testing of the components in global layer 102 is merely illustrative, and the changed components may be staged directly into base layer 104 without first being integrated and merged within global layer 102.
  • FIG. 18 is an illustrative flow diagram that demonstrates the configuration and release management of software locally to specific SBUs within the account management system. At step 400, one or more changed components of the group application systems software are received at the custom layer (e.g., custom layer 108 of FIG. 6). The one or more components may be applicable to only a subset of all SBUs (i.e., the components are “local,” rather than “global”). At step 402, the one or more changed components are merged at the custom layer with a base set of libraries for source code and copybooks from the base layer. As shown in FIG. 6, for example,.“Custom” changes are merged with “Base Merged” to form “Custom Merged” at custom layer 108. At step 404, the merged programs are tested at the custom layer. An example of testing at custom layer 108 is shown, for example, in FIG. 13, which illustrates the promotion of a component up to the installation step and the creation of testing environments to meet the requirements of the custom layer. At step 406, the merged components are installed at the custom layer using custom load modules (e.g., “Custom Load Modules” of custom layer 108 of FIG. 6).
  • On an annual basis changes made at each custom layer 108 are reviewed centrally to determine to what extent these changes have wider applicability. Any specific system changes or enhancements that may have been created for an SBU are candidates for inclusion in the globalized version of the group application system. Such enhancements are evaluated by a central committee that determines priority, funding and finalizes all aspects of the documentation for these changes. Changes then progress to the global layer 102 for integration and subsequent release to the base layer 104, as described hereinabove.
  • It is to be understood that the invention is not limited in its application to the details of construction and to the arrangements of the components set forth in the following description or illustrated in the drawings. The invention is capable of other embodiments and of being practiced and carried out in various ways. Also, it is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting.
  • As such, those skilled in the art will appreciate that the conception, upon which this disclosure is based, may readily be utilized as a basis for the designing of other structures, methods and systems for carrying out the several purposes of the present invention. It is important, therefore, that the claims be regarded as including such equivalent constructions insofar as they do not depart from the spirit and scope of the present invention.
  • Although the present invention has been described and illustrated in the foregoing exemplary embodiments, it is understood that the present disclosure has been made only by way of example, and that numerous changes in the details of implementation of the invention may be made without departing from the spirit and scope of the invention, which is limited only by the claims which follow.

Claims (14)

1. A global framework multi-layer computer based architecture including at least one source code management system that provides executable production environments to support component applications, said architecture comprising:
multiple layers configured to segregate, into different layers, globally applicable software for installation into and execution by all of multiple business processing systems from software that is only installed into and executed by specific ones of said business processing systems; said multiple layers including:
a base layer containing the globally applicable software, and
a custom layer containing the software specific to specific business processing systems, such that the globally applicable software and the software specific to specific business processing systems are segregated into the respective layers;
said base layer providing globally applicable development and installation functionality for said multiple business processing systems within the source code management system, wherein source code commonly utilized by said multiple business processing systems is staged to said base layer for integration with existing source code for said multiple business processing systems to create a merged base set of load module libraries, said merged base set of load module libraries containing all common source code management system elements utilized in common by said multiple business processing systems; and wherein software modifications that are global in nature and apply to all business processing systems are installed in the base set of load module libraries at the base layer; and
said custom layer, in operative interaction with said base layer, providing specific development and installation functionality for utilization by a business processing system of said plurality of business processing systems within the source code management system, wherein source code specific to said business processing system is staged to said custom layer for integration with existing source code specific to said business processing system to create a merged custom set of load module libraries, said merged custom set of load module libraries containing all modifications to be utilized specifically by said business processing system to meet local needs of said business processing system; and wherein software modifications that are specific to a business processing system are installed in the custom set of libraries at the custom layer.
2. The global framework computer based architecture of claim 1, further comprising individual online and/or batch execution environments to support data management and processing for each of said business processing systems.
3. The global framework computer based architecture of claim 1, further comprising at least one set of associated tools and processes, in operative interaction with said source code management system, to enable consistent use of and modification to source code management system elements common to said multiple business processing systems.
4. The global framework computer based architecture of claim 1, further comprising a plurality of naming standards to control and identify components, libraries, data sets, and/or execution environments within said source code management system.
5. The global framework multi-layer computer based architecture of claim 1, further comprising:
a global layer, in operative interaction with said base layer, providing development functionality for said multiple business processing systems within the source code management system, wherein source code for said multiple business processing systems is developed within said global layer.
6. The global framework multi-layer computer based architecture of claim 1, further comprising:
a regional layer, in operative interaction with said base and custom layers, providing installation functionality for said merged base set of libraries, wherein said installed base set of libraries support execution by said multiple business processing systems in batch and/or online by allowing said multiple business processing systems to implement said base set of libraries, if necessary, by concatenating said custom set of libraries and said base set of libraries installed in said regional layer.
7. The global framework multi-layer computer based architecture of claim 6, wherein said base set of libraries in said regional layer are protected such that contents of said base set of libraries cannot be changed at said regional layer.
8. The global framework multi-layer computer based architecture of claim 1, further comprising:
an environment layer, in operative interaction with said custom layer, providing processing functionality for a business processing system of said plurality of business processing systems, wherein said installed base set of libraries support execution by said multiple business processing systems in batch and/or online by allowing said multiple business processing systems to implement said base set of libraries, if necessary, by concatenating said custom set of libraries and said base set of libraries.
9. The global framework multi-layer computer based architecture of claim 8, wherein said environment layer comprises a complete set of databases and data files for each business processing system of said multiple business processing systems.
10. The global framework multi-layer computer based architecture of claim 1, further comprising:
a local layer, in operative interaction with said custom layer, providing application load modules for each business processing system of said multiple business processing systems, wherein said local layer load modules are dependent upon source code management system data.
11. The global framework multi-layer computer based architecture of claim 1, wherein on execution of software at a specific business processing system load modules from the custom set of load module libraries are executed in preference to those that exist at the base layer and the load modules to be executed are selected by concatenation.
12. A method for configuration and release management of group application systems software within a source code management system using a global framework multilayer computer based architecture as defined in any preceding claim, said method comprising:
receiving one or more changed components of group application systems software at the base layer of the source code management system;
merging said one or more changed components into said base set of load module libraries for source code and copybooks at the base layer of the source code management system;
testing said one or more changed components at said base layer; and
installing said merged components at a regional layer using base load modules;
and further comprising:
receiving one or more changed components of group application systems software at said custom layer of the source code management system, wherein said one or more components are applicable to only a portion of multiple business processing systems within the source code management system;
merging said one or more changed components at said custom layer with a base set of libraries for source code and copybooks to create said custom set of load module libraries;
testing said custom set of libraries at said custom layer; and
installing said custom set of libraries at said custom layer using custom load modules.
13. The method for configuration and release management of group application systems software of claim 12, further comprising:
providing said multiple business processing systems with the ability to implement said base set of libraries in batch and/or online by allowing said multiple business processing systems to concatenate a custom set of libraries at a custom layer and said base set of libraries.
14. A global framework multi-layer computer based architecture including at least one source code management system that provides executable production environments to support component applications, comprising:
a base layer providing development and installation functionality for multiple business processing systems within the source code management system including base source code for said multiple business processing systems that provides common functionality for the multiple business processing systems and to be merged and compiled with custom source code for at least one of said multiple business processing systems to create merged source code and merged executable software code, said base source code including common source code management system elements comprising the common functionality that is common to and required by said multiple business processing systems, and wherein the merged source code is tested in said base layer prior to distribution of the merged executable software code; and
a custom layer, in operative interaction with said base layer, providing development and installation functionality for a business processing system of said plurality of business processing systems within the source code management system, wherein custom source code for said business processing system is staged to said custom layer for integration with the base source code for said business processing system to create merged source code, said merged source code including modifications to the base source code specific to said business processing system to meet local needs of said business processing system, and wherein said merged custom set of libraries are tested in said custom layer prior to installation of said merged executable software code.
US13/098,710 2005-01-13 2011-05-02 Computer software implemented framework for configuration and release management of group systems software, and method for same Abandoned US20110209115A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/098,710 US20110209115A1 (en) 2005-01-13 2011-05-02 Computer software implemented framework for configuration and release management of group systems software, and method for same

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US64375805P 2005-01-13 2005-01-13
US11/330,065 US7937685B2 (en) 2005-01-13 2006-01-12 Computer software implemented framework for configuration and release management of group systems software, and method for same
US13/098,710 US20110209115A1 (en) 2005-01-13 2011-05-02 Computer software implemented framework for configuration and release management of group systems software, and method for same

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/330,065 Continuation US7937685B2 (en) 2005-01-13 2006-01-12 Computer software implemented framework for configuration and release management of group systems software, and method for same

Publications (1)

Publication Number Publication Date
US20110209115A1 true US20110209115A1 (en) 2011-08-25

Family

ID=36678147

Family Applications (2)

Application Number Title Priority Date Filing Date
US11/330,065 Active 2029-12-04 US7937685B2 (en) 2005-01-13 2006-01-12 Computer software implemented framework for configuration and release management of group systems software, and method for same
US13/098,710 Abandoned US20110209115A1 (en) 2005-01-13 2011-05-02 Computer software implemented framework for configuration and release management of group systems software, and method for same

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US11/330,065 Active 2029-12-04 US7937685B2 (en) 2005-01-13 2006-01-12 Computer software implemented framework for configuration and release management of group systems software, and method for same

Country Status (6)

Country Link
US (2) US7937685B2 (en)
EP (2) EP1854024A4 (en)
CN (1) CN101164062A (en)
AU (1) AU2006205055A1 (en)
CA (1) CA2594754A1 (en)
WO (1) WO2006076396A2 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103473627A (en) * 2013-08-20 2013-12-25 国家电网公司 Data processing method for requirement change management of operation and maintenance system
US20180024818A1 (en) * 2016-07-25 2018-01-25 Sap Se Framework for on demand functionality

Families Citing this family (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7395527B2 (en) 2003-09-30 2008-07-01 International Business Machines Corporation Method and apparatus for counting instruction execution and data accesses
US8381037B2 (en) 2003-10-09 2013-02-19 International Business Machines Corporation Method and system for autonomic execution path selection in an application
US7895382B2 (en) 2004-01-14 2011-02-22 International Business Machines Corporation Method and apparatus for qualifying collection of performance monitoring events by types of interrupt when interrupt occurs
US7415705B2 (en) 2004-01-14 2008-08-19 International Business Machines Corporation Autonomic method and apparatus for hardware assist for patching code
US7937685B2 (en) * 2005-01-13 2011-05-03 Hsbc Technology & Services (Usa) Inc. Computer software implemented framework for configuration and release management of group systems software, and method for same
WO2007030796A2 (en) * 2005-09-09 2007-03-15 Salesforce.Com, Inc. Systems and methods for exporting, publishing, browsing and installing on-demand applications in a multi-tenant database environment
CA2667168A1 (en) * 2006-10-18 2008-04-24 Iscopia Software Inc. Online qualification management system
US7958188B2 (en) * 2007-05-04 2011-06-07 International Business Machines Corporation Transaction-initiated batch processing
US20090037870A1 (en) * 2007-07-31 2009-02-05 Lucinio Santos-Gomez Capturing realflows and practiced processes in an IT governance system
US8484615B2 (en) * 2007-12-20 2013-07-09 Ncr Corporation Software framework to build an executable scheme in a GUI environment
EP2248013A4 (en) * 2007-12-20 2012-09-26 Hsbc Technologies Inc Automated methods and systems for developing and deploying projects in parallel
US20090228862A1 (en) * 2008-03-04 2009-09-10 Anders Bertelrud Modularized integrated software development environments
US8352919B2 (en) * 2009-09-30 2013-01-08 Sap Ag Operation support in versioning systems
US9639347B2 (en) * 2009-12-21 2017-05-02 International Business Machines Corporation Updating a firmware package
US8607187B2 (en) * 2010-12-23 2013-12-10 Sap Ag System and method for mini-EHP development and delivery
US8667477B2 (en) * 2010-12-30 2014-03-04 Sap Ag Modifying software code
JP6084618B2 (en) 2011-09-16 2017-02-22 パーシモン テクノロジーズ コーポレイションPersimmon Technologies, Corp. Low fluctuation robot
US20130117749A1 (en) * 2011-11-03 2013-05-09 Microsoft Corporation Provisioning and Managing an Application Platform
US8910115B2 (en) * 2012-04-02 2014-12-09 Kony Solutions, Inc. Systems and methods for application development
WO2013184707A1 (en) 2012-06-04 2013-12-12 Goldman, Sachs & Co. Product driven approach to technology provisioning, operations, and billing
CN103577217A (en) * 2012-08-10 2014-02-12 腾讯科技(深圳)有限公司 Method and device for displaying software
US9158536B2 (en) * 2012-12-06 2015-10-13 International Business Machines Corporation Program code library consolidation in an integrated development environment
EP2932374B1 (en) * 2012-12-14 2023-11-15 Telefonaktiebolaget LM Ericsson (publ) Systems, methods, and computer program products for a software build and load process using a compilation and deployment service
US9563519B2 (en) * 2013-03-15 2017-02-07 Sap Se Reversing changes executed by change management
KR20220116079A (en) 2014-01-21 2022-08-19 퍼시몬 테크놀로지스 코포레이션 Substrate transport vacuum platform
US9225776B1 (en) * 2014-08-11 2015-12-29 International Business Machines Corporation Distributing UI control events from a single event producer across multiple systems event consumers
US9860145B2 (en) 2015-07-02 2018-01-02 Microsoft Technology Licensing, Llc Recording of inter-application data flow
US9658836B2 (en) 2015-07-02 2017-05-23 Microsoft Technology Licensing, Llc Automated generation of transformation chain compatible class
US9733915B2 (en) 2015-07-02 2017-08-15 Microsoft Technology Licensing, Llc Building of compound application chain applications
US9733993B2 (en) 2015-07-02 2017-08-15 Microsoft Technology Licensing, Llc Application sharing using endpoint interface entities
US10198252B2 (en) 2015-07-02 2019-02-05 Microsoft Technology Licensing, Llc Transformation chain application splitting
US9785484B2 (en) 2015-07-02 2017-10-10 Microsoft Technology Licensing, Llc Distributed application interfacing across different hardware
US9712472B2 (en) 2015-07-02 2017-07-18 Microsoft Technology Licensing, Llc Application spawning responsive to communication
US10261985B2 (en) 2015-07-02 2019-04-16 Microsoft Technology Licensing, Llc Output rendering in dynamic redefining application
US10031724B2 (en) 2015-07-08 2018-07-24 Microsoft Technology Licensing, Llc Application operation responsive to object spatial status
US10198405B2 (en) 2015-07-08 2019-02-05 Microsoft Technology Licensing, Llc Rule-based layout of changing information
US9672139B2 (en) * 2015-07-21 2017-06-06 Successfactors, Inc. Debugging in a production environment
US10277582B2 (en) 2015-08-27 2019-04-30 Microsoft Technology Licensing, Llc Application service architecture
CN105739980A (en) * 2016-01-28 2016-07-06 滴滴(中国)科技有限公司 Unified business development method and equipment
JP6559600B2 (en) * 2016-03-17 2019-08-14 株式会社東芝 Information processing apparatus, information processing program, and inspection system
US10372572B1 (en) * 2016-11-30 2019-08-06 Amazon Technologies, Inc. Prediction model testing framework
US10574544B2 (en) * 2017-01-04 2020-02-25 International Business Machines Corporation Method of certifying resiliency and recoverability level of services based on gaming mode chaosing
CN107945006A (en) * 2017-11-15 2018-04-20 深圳市买买提乐购金融服务有限公司 A kind of business management system and method
US10732948B2 (en) * 2017-12-01 2020-08-04 Jpmorgan Chase Bank, N.A. System and method for implementing automated deployment
CN108305161A (en) * 2018-02-02 2018-07-20 方欣科技有限公司 A kind of paying taxes service interface carding method and device
CN110297639B (en) * 2019-07-01 2023-03-21 北京百度网讯科技有限公司 Method and apparatus for detecting code
CN112596788A (en) * 2020-12-31 2021-04-02 扬州万方电子技术有限责任公司 Information system localization support service environment
US11550925B2 (en) 2021-03-24 2023-01-10 Bank Of America Corporation Information security system for identifying potential security threats in software package deployment
WO2023122480A1 (en) * 2021-12-21 2023-06-29 HSBC Technology and Services (USA) Inc. Automated developer governance system

Citations (61)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5204960A (en) * 1990-01-08 1993-04-20 Microsoft Corporation Incremental compiler
US5428788A (en) * 1991-05-10 1995-06-27 Siemens Corporate Research, Inc. Feature ratio method for computing software similarity
US5613114A (en) * 1994-04-15 1997-03-18 Apple Computer, Inc System and method for custom context switching
US5675802A (en) * 1995-03-31 1997-10-07 Pure Atria Corporation Version control system for geographically distributed software development
US5692158A (en) * 1992-08-28 1997-11-25 Abb Power T&D Company Inc. Methods for generating models of non-linear systems and components and for evaluating parameters in relation to such non-linear models
US5835896A (en) * 1996-03-29 1998-11-10 Onsale, Inc. Method and system for processing and transmitting electronic auction information
US5873071A (en) * 1997-05-15 1999-02-16 Itg Inc. Computer method and system for intermediated exchange of commodities
US5905974A (en) * 1996-12-13 1999-05-18 Cantor Fitzgerald Securities Automated auction protocol processor
US5905975A (en) * 1996-01-04 1999-05-18 Ausubel; Lawrence M. Computer implemented methods and apparatus for auctions
US5920723A (en) * 1997-02-05 1999-07-06 Hewlett-Packard Company Compiler with inter-modular procedure optimization
US5960200A (en) * 1996-05-03 1999-09-28 I-Cube System to transition an enterprise to a distributed infrastructure
US6016483A (en) * 1996-09-20 2000-01-18 Optimark Technologies, Inc. Method and apparatus for automated opening of options exchange
US6112189A (en) * 1997-03-19 2000-08-29 Optimark Technologies, Inc. Method and apparatus for automating negotiations between parties
US6178549B1 (en) * 1998-03-12 2001-01-23 Winbond Electronics Corporation Memory writer with deflective memory-cell handling capability
US6243691B1 (en) * 1996-03-29 2001-06-05 Onsale, Inc. Method and system for processing and transmitting electronic auction information
US6279100B1 (en) * 1998-12-03 2001-08-21 Sun Microsystems, Inc. Local stall control method and structure in a microprocessor
US20010044767A1 (en) * 1999-03-19 2001-11-22 Primex Holdings Llc Auction market with price improvement mechanism
US20020035534A1 (en) * 2000-05-04 2002-03-21 Buist Walter D. Method and apparatus for auctioning securities
US6377940B2 (en) * 1998-11-05 2002-04-23 International Securities Exchange, Llc Method and apparatus for setting a price for a security on an automated exchange based on a comparison of prices on other exchanges
US20020049603A1 (en) * 2000-01-14 2002-04-25 Gaurav Mehra Method and apparatus for a business applications server
US6405364B1 (en) * 1999-08-31 2002-06-11 Accenture Llp Building techniques in a development architecture framework
US20020087456A1 (en) * 2000-12-29 2002-07-04 Daniel Abeshouse Method, apparatus, and system for synchronizing timing of an auction throug a computer network
US20020091606A1 (en) * 2001-01-11 2002-07-11 Alan Shapiro Predictive automated routing system (PARS) for securities trading
US20020095369A1 (en) * 2001-01-12 2002-07-18 Kaplan Harry A. Anonymous auctioning of structured financial products over a computer network
US20020107684A1 (en) * 2001-02-07 2002-08-08 Kejia Gao Methods and apparatus for globalising software
US20020124245A1 (en) * 2000-08-14 2002-09-05 Alvin Maddux Method and apparatus for advanced software deployment
US20020129356A1 (en) * 2001-01-05 2002-09-12 International Business Machines Corporation Systems and methods for service and role-based software distribution
US20020156716A1 (en) * 2001-04-24 2002-10-24 Asif Adatia Automated securities trade execution system and method
US20020157076A1 (en) * 2001-04-23 2002-10-24 Kazuhiko Asakawa Fabrication method for a semiconductor device with dummy patterns
US6473794B1 (en) * 1999-05-27 2002-10-29 Accenture Llp System for establishing plan to test components of web based framework by displaying pictorial representation and conveying indicia coded components of existing network framework
US20020161687A1 (en) * 1999-09-23 2002-10-31 Stuart Serkin Match-off of order flow in electronic market system
US20020194105A1 (en) * 2001-05-18 2002-12-19 Andrew Klein Process of and system for trading securities and options and markets related thereto
US20020198734A1 (en) * 2000-05-22 2002-12-26 Greene William S. Method and system for implementing a global ecosystem of interrelated services
US20030004858A1 (en) * 2001-06-29 2003-01-02 Schmitz David J. Automated execution system having participation
US20030037315A1 (en) * 2001-08-13 2003-02-20 International Business Machines Corporation Automated audit methodology for design
US20030061148A1 (en) * 2001-07-16 2003-03-27 Shahram Alavian Financial derivative and derivative exchange with guaranteed settlement
US6553563B2 (en) * 1998-11-30 2003-04-22 Siebel Systems, Inc. Development tool, method, and system for client server applications
US20030088501A1 (en) * 2001-06-13 2003-05-08 Gilbert Andrew C Systems and methods for trading in an exclusive market
US20030120593A1 (en) * 2001-08-15 2003-06-26 Visa U.S.A. Method and system for delivering multiple services electronically to customers via a centralized portal architecture
US6601233B1 (en) * 1999-07-30 2003-07-29 Accenture Llp Business components framework
US20030167356A1 (en) * 2001-07-10 2003-09-04 Smith Adam W. Application program interface for network software platform
US6618707B1 (en) * 1998-11-03 2003-09-09 International Securities Exchange, Inc. Automated exchange for trading derivative securities
US20030177085A1 (en) * 2002-03-15 2003-09-18 Buckwalter Alan Mark Method and apparatus for monitoring and evaluating trade activity
US20030182652A1 (en) * 2001-12-21 2003-09-25 Custodio Gabriel T. Software building and deployment system and method
US6662357B1 (en) * 1999-08-31 2003-12-09 Accenture Llp Managing information in an integrated development architecture framework
US6671867B2 (en) * 2002-04-11 2003-12-30 International Business Machines Corporation Analytical constraint generation for cut-based global placement
US20040006537A1 (en) * 2002-03-04 2004-01-08 First Data Corporation Method and system for processing credit card related transactions
US20040015833A1 (en) * 1996-03-19 2004-01-22 Dellarocas Chrysanthos Nicholas Computer system and computer implemented process for representing software system descriptions and for generating executable computer programs and computer system configurations from software system descriptions
US20040024689A1 (en) * 2002-07-17 2004-02-05 Yuli Zhou System and method for automated trading
US20040030630A1 (en) * 2000-02-07 2004-02-12 Om Technology Ab Trading system
US20040031015A1 (en) * 2001-05-24 2004-02-12 Conexant Systems, Inc. System and method for manipulation of software
US20040046785A1 (en) * 2002-09-11 2004-03-11 International Business Machines Corporation Methods and apparatus for topology discovery and representation of distributed applications and services
US20040054984A1 (en) * 2002-04-08 2004-03-18 Chong James C. Method and system for problem determination in distributed enterprise applications
US20040098703A1 (en) * 2002-11-15 2004-05-20 Kondur Sankar Narayana Integration of multiple software tools under a single site
US20040098713A1 (en) * 2002-07-03 2004-05-20 Hajime Ogawa Compiler apparatus with flexible optimization
US6757689B2 (en) * 2001-02-02 2004-06-29 Hewlett-Packard Development Company, L.P. Enabling a zero latency enterprise
US20040133445A1 (en) * 2002-10-29 2004-07-08 Marathon Ashland Petroleum L.L.C. Generic framework for applying object-oriented models to multi-tiered enterprise applications
US20040158488A1 (en) * 2003-02-07 2004-08-12 Johnson Kurt D. Internet based automated real estate post card mailout system
US6779028B1 (en) * 1999-03-08 2004-08-17 Kabushiki Kaisha Toshiba System application management method and system, and storage medium which stores program for executing system application management
US20060155768A1 (en) * 2005-01-13 2006-07-13 Hsbc North America Holdings Inc. Computer software implemented framework for configuration and release management of group systems software, and method for same
US20080127045A1 (en) * 2006-09-27 2008-05-29 David Pratt Multiple-developer architecture for facilitating the localization of software applications

Family Cites Families (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE2862227D1 (en) 1978-12-13 1983-05-11 Control Tele Systems Limited Position sensing apparatus
FR2574236B1 (en) 1984-11-30 1987-07-17 Bull Sems METHOD OF ADDRESSING BETWEEN A TRANSMITTING STATION OF A MESSAGE AND AT LEAST ONE RECEIVING STATION IN A COMMUNICATION NETWORK AND DEVICE FOR IMPLEMENTING THE METHOD
US4835704A (en) 1986-12-29 1989-05-30 General Electric Company Adaptive lithography system to provide high density interconnect
US4908772A (en) 1987-03-30 1990-03-13 Bell Telephone Laboratories Integrated circuits with component placement by rectilinear partitioning
FR2644262B1 (en) 1989-03-07 1995-08-04 Univ Rennes METHOD FOR ANALYZING A SIGNAL, PARTICULARLY IN DIGESTIVE MANOMETRY
ZA907106B (en) 1989-10-06 1991-09-25 Net 1 Products Pty Ltd Funds transfer system
GB2251098B (en) 1990-12-17 1994-10-05 Allied Irish Banks P L C Apparatus for processing data
TW225595B (en) 1991-09-03 1994-06-21 Gen Electric
FR2684779B1 (en) 1991-12-06 1996-12-13 Bull Sa METHOD AND TOOL FOR CONCEPTUAL MODELING OF EXPERTISE ON A COMPUTER SYSTEM.
JP2740705B2 (en) 1992-04-08 1998-04-15 本田技研工業株式会社 Fluid torque converter characteristic simulation method and apparatus
US5418953A (en) 1993-04-12 1995-05-23 Loral/Rohm Mil-Spec Corp. Method for automated deployment of a software program onto a multi-processor architecture
DE4314768A1 (en) 1993-05-05 1994-11-10 Philips Patentverwaltung Method for the quantitative determination of the distortions of x-rays and arrangement for carrying out the method
EP0661647A1 (en) 1993-12-31 1995-07-05 Institut Pasteur A method and system for modelizing partition functions of sequences
EP1422670A3 (en) 1998-04-07 2004-09-01 Gerald R. Black Identification confirmation system
GB2337139A (en) 1998-05-09 1999-11-10 Ibm A bi-directional transaction intercepting filter and log
GB2377071B (en) 1998-06-22 2003-02-12 First Usa Bank Debit purchasing of stored value card for use by and/or delivery to others
US6615189B1 (en) 1998-06-22 2003-09-02 Bank One, Delaware, National Association Debit purchasing of stored value card for use by and/or delivery to others
US6523059B1 (en) 1998-12-07 2003-02-18 Sun Microsystems, Inc. System and method for facilitating safepoint synchronization in a multithreaded computer system
US6662232B1 (en) 1998-12-29 2003-12-09 Pitney Bowes Ltd. Dynamic E-mail re-transmitting system having time parameters
US6363414B1 (en) 1998-12-29 2002-03-26 Pitney Bowes Ltd. Method for converting an email message to a different format and retransmitting to a location other than recipient address information in the email message
GB2351366A (en) 1999-02-23 2000-12-27 Angus Duncan Mccallum Facilitating the accumulation of money for donation
FR2790173A1 (en) 1999-02-24 2000-08-25 Canon Kk DIGITAL SIGNAL TRANSFORMATION DEVICE AND METHOD
EP1032216A1 (en) 1999-02-24 2000-08-30 Canon Kabushiki Kaisha Device and method for transforming a digital signal.
WO2001016819A1 (en) 1999-08-27 2001-03-08 Kabushiki Kaisha Toshiba System for evaluating price risk of financial product or its financial derivative, dealing system, and recorded medium
US7006959B1 (en) 1999-10-12 2006-02-28 Exxonmobil Upstream Research Company Method and system for simulating a hydrocarbon-bearing formation
JP2001142944A (en) 1999-11-05 2001-05-25 Kizna.Com Inc Electronic commerce method, client computer for electronic commerce and medium with recorded program
US7082417B1 (en) 1999-12-28 2006-07-25 Pitney Bowes Inc. Method of calculating mailroom chargeback cost for incoming mails
CN1307301A (en) 2000-02-03 2001-08-08 李冠林 Electronic financial business system and program
DE10014089A1 (en) 2000-03-22 2001-09-27 Siemens Ag Automatic assignment of network planning process to computer - assigning sub-processes manually and/or automatically to entities, based on detection of parameters evaluating available power and usage of entities, and on determination and/or structuring of sub-processes
GB2360866A (en) 2000-03-28 2001-10-03 Cashthrough Com Internat Ltd Online payment method
DE10045521A1 (en) 2000-03-31 2001-10-04 Roche Diagnostics Gmbh Determining amplification efficiency of a target nucleic acid comprises measuring real-time amplification of diluted series, setting signal threshold value, and determining cycle number at which threshold is exceeded
ATE360862T1 (en) 2000-06-21 2007-05-15 Chikka Pte Ltd TRADING AND AUCTIONING SYSTEM AND METHOD FOR AUTHENTICATING BUYERS AND SELLERS AND TRANSMITTING TRADING INSTRUCTIONS IN A TRADING AND AUCTIONING SYSTEM
JP2002042000A (en) 2000-07-28 2002-02-08 Matsushita Electric Ind Co Ltd Accounting method
GB2368177A (en) 2000-10-17 2002-04-24 Ncr Int Inc A financial transaction system
US7058685B1 (en) 2000-10-23 2006-06-06 Hewlett-Packard Development Company, L.P. Validation and audit of e-media delivery
US7379916B1 (en) 2000-11-03 2008-05-27 Authernative, Inc. System and method for private secure financial transactions
RU2174708C1 (en) 2000-11-15 2001-10-10 Закрытое акционерное общество "Дженерал Текнолоджис" Method for carrying on trade operations using clearing transactions through communication network
GB2370904A (en) 2001-01-08 2002-07-10 Ace Card Ltd Transaction apparatus using a system for mobile communication
GB2389441B (en) 2001-01-22 2005-02-09 Igt Uk Ltd Management system for entertainment machines
EP1241601A1 (en) 2001-03-13 2002-09-18 EJay AG Method for purchasing and payment of audio and/or video data
DE10133370A1 (en) 2001-07-10 2003-01-30 Bayer Ag Computer system and method for automatically determining a customer price
FR2830354A1 (en) 2001-09-28 2003-04-04 Gravindus METHOD AND SYSTEM FOR ANALYZING AT LEAST ONE ELEMENT CONSTITUTING A CUSTOMIZED WORK, OF ENGRAVING OR CUTTING CUSTOMIZED
JP4244550B2 (en) 2001-11-15 2009-03-25 ソニー株式会社 Server apparatus, content providing method, and content providing system
CN1188779C (en) 2001-11-16 2005-02-09 威盛电子股份有限公司 Loan job method in accountment system
US20030174356A1 (en) 2002-03-15 2003-09-18 Darrel Cherry Tracking printing in a network
GB2387259A (en) 2002-04-02 2003-10-08 Sendo Int Ltd Method for obtaining a postage verification code
EP1357472A1 (en) 2002-04-23 2003-10-29 Hewlett-Packard Company, A Delaware Corporation Resilient protocol for control of composite services
JP2004070445A (en) 2002-08-01 2004-03-04 Ktfreetel Co Ltd Batch type billing method and system using distributed processing
EP1418501A1 (en) 2002-11-08 2004-05-12 Dunes Technologies S.A. Method of administration of applications on virtual machines

Patent Citations (64)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5204960A (en) * 1990-01-08 1993-04-20 Microsoft Corporation Incremental compiler
US5428788A (en) * 1991-05-10 1995-06-27 Siemens Corporate Research, Inc. Feature ratio method for computing software similarity
US5692158A (en) * 1992-08-28 1997-11-25 Abb Power T&D Company Inc. Methods for generating models of non-linear systems and components and for evaluating parameters in relation to such non-linear models
US5613114A (en) * 1994-04-15 1997-03-18 Apple Computer, Inc System and method for custom context switching
US5675802A (en) * 1995-03-31 1997-10-07 Pure Atria Corporation Version control system for geographically distributed software development
US5905975A (en) * 1996-01-04 1999-05-18 Ausubel; Lawrence M. Computer implemented methods and apparatus for auctions
US6021398A (en) * 1996-01-04 2000-02-01 Ausubel; Lawrence M. Computer implemented methods and apparatus for auctions
US20040015833A1 (en) * 1996-03-19 2004-01-22 Dellarocas Chrysanthos Nicholas Computer system and computer implemented process for representing software system descriptions and for generating executable computer programs and computer system configurations from software system descriptions
US5835896A (en) * 1996-03-29 1998-11-10 Onsale, Inc. Method and system for processing and transmitting electronic auction information
US6243691B1 (en) * 1996-03-29 2001-06-05 Onsale, Inc. Method and system for processing and transmitting electronic auction information
US5960200A (en) * 1996-05-03 1999-09-28 I-Cube System to transition an enterprise to a distributed infrastructure
US6016483A (en) * 1996-09-20 2000-01-18 Optimark Technologies, Inc. Method and apparatus for automated opening of options exchange
US5905974A (en) * 1996-12-13 1999-05-18 Cantor Fitzgerald Securities Automated auction protocol processor
US5920723A (en) * 1997-02-05 1999-07-06 Hewlett-Packard Company Compiler with inter-modular procedure optimization
US6112189A (en) * 1997-03-19 2000-08-29 Optimark Technologies, Inc. Method and apparatus for automating negotiations between parties
US5873071A (en) * 1997-05-15 1999-02-16 Itg Inc. Computer method and system for intermediated exchange of commodities
US6178549B1 (en) * 1998-03-12 2001-01-23 Winbond Electronics Corporation Memory writer with deflective memory-cell handling capability
US6618707B1 (en) * 1998-11-03 2003-09-09 International Securities Exchange, Inc. Automated exchange for trading derivative securities
US6377940B2 (en) * 1998-11-05 2002-04-23 International Securities Exchange, Llc Method and apparatus for setting a price for a security on an automated exchange based on a comparison of prices on other exchanges
US6553563B2 (en) * 1998-11-30 2003-04-22 Siebel Systems, Inc. Development tool, method, and system for client server applications
US6279100B1 (en) * 1998-12-03 2001-08-21 Sun Microsystems, Inc. Local stall control method and structure in a microprocessor
US6779028B1 (en) * 1999-03-08 2004-08-17 Kabushiki Kaisha Toshiba System application management method and system, and storage medium which stores program for executing system application management
US20030014354A1 (en) * 1999-03-19 2003-01-16 Primex Holdings Llc, A New York Corporation Auction market with price improvement mechanism
US20010044767A1 (en) * 1999-03-19 2001-11-22 Primex Holdings Llc Auction market with price improvement mechanism
US6473794B1 (en) * 1999-05-27 2002-10-29 Accenture Llp System for establishing plan to test components of web based framework by displaying pictorial representation and conveying indicia coded components of existing network framework
US6601233B1 (en) * 1999-07-30 2003-07-29 Accenture Llp Business components framework
US6662357B1 (en) * 1999-08-31 2003-12-09 Accenture Llp Managing information in an integrated development architecture framework
US6405364B1 (en) * 1999-08-31 2002-06-11 Accenture Llp Building techniques in a development architecture framework
US20020161687A1 (en) * 1999-09-23 2002-10-31 Stuart Serkin Match-off of order flow in electronic market system
US20020049603A1 (en) * 2000-01-14 2002-04-25 Gaurav Mehra Method and apparatus for a business applications server
US20040030630A1 (en) * 2000-02-07 2004-02-12 Om Technology Ab Trading system
US20020035534A1 (en) * 2000-05-04 2002-03-21 Buist Walter D. Method and apparatus for auctioning securities
US20020198734A1 (en) * 2000-05-22 2002-12-26 Greene William S. Method and system for implementing a global ecosystem of interrelated services
US20020124245A1 (en) * 2000-08-14 2002-09-05 Alvin Maddux Method and apparatus for advanced software deployment
US20020087456A1 (en) * 2000-12-29 2002-07-04 Daniel Abeshouse Method, apparatus, and system for synchronizing timing of an auction throug a computer network
US20020129356A1 (en) * 2001-01-05 2002-09-12 International Business Machines Corporation Systems and methods for service and role-based software distribution
US20020091606A1 (en) * 2001-01-11 2002-07-11 Alan Shapiro Predictive automated routing system (PARS) for securities trading
US20020095369A1 (en) * 2001-01-12 2002-07-18 Kaplan Harry A. Anonymous auctioning of structured financial products over a computer network
US6757689B2 (en) * 2001-02-02 2004-06-29 Hewlett-Packard Development Company, L.P. Enabling a zero latency enterprise
US20020107684A1 (en) * 2001-02-07 2002-08-08 Kejia Gao Methods and apparatus for globalising software
US20020157076A1 (en) * 2001-04-23 2002-10-24 Kazuhiko Asakawa Fabrication method for a semiconductor device with dummy patterns
US20020156716A1 (en) * 2001-04-24 2002-10-24 Asif Adatia Automated securities trade execution system and method
US20020194105A1 (en) * 2001-05-18 2002-12-19 Andrew Klein Process of and system for trading securities and options and markets related thereto
US20040031015A1 (en) * 2001-05-24 2004-02-12 Conexant Systems, Inc. System and method for manipulation of software
US20030088501A1 (en) * 2001-06-13 2003-05-08 Gilbert Andrew C Systems and methods for trading in an exclusive market
US20030004858A1 (en) * 2001-06-29 2003-01-02 Schmitz David J. Automated execution system having participation
US20030167356A1 (en) * 2001-07-10 2003-09-04 Smith Adam W. Application program interface for network software platform
US20030061148A1 (en) * 2001-07-16 2003-03-27 Shahram Alavian Financial derivative and derivative exchange with guaranteed settlement
US20030037315A1 (en) * 2001-08-13 2003-02-20 International Business Machines Corporation Automated audit methodology for design
US20030120593A1 (en) * 2001-08-15 2003-06-26 Visa U.S.A. Method and system for delivering multiple services electronically to customers via a centralized portal architecture
US20030182652A1 (en) * 2001-12-21 2003-09-25 Custodio Gabriel T. Software building and deployment system and method
US20040006537A1 (en) * 2002-03-04 2004-01-08 First Data Corporation Method and system for processing credit card related transactions
US20030177085A1 (en) * 2002-03-15 2003-09-18 Buckwalter Alan Mark Method and apparatus for monitoring and evaluating trade activity
US20030177082A1 (en) * 2002-03-15 2003-09-18 Buckwalter Alan M. Method and apparatus for processing and routing transactions
US20040054984A1 (en) * 2002-04-08 2004-03-18 Chong James C. Method and system for problem determination in distributed enterprise applications
US6671867B2 (en) * 2002-04-11 2003-12-30 International Business Machines Corporation Analytical constraint generation for cut-based global placement
US20040098713A1 (en) * 2002-07-03 2004-05-20 Hajime Ogawa Compiler apparatus with flexible optimization
US20040024689A1 (en) * 2002-07-17 2004-02-05 Yuli Zhou System and method for automated trading
US20040046785A1 (en) * 2002-09-11 2004-03-11 International Business Machines Corporation Methods and apparatus for topology discovery and representation of distributed applications and services
US20040133445A1 (en) * 2002-10-29 2004-07-08 Marathon Ashland Petroleum L.L.C. Generic framework for applying object-oriented models to multi-tiered enterprise applications
US20040098703A1 (en) * 2002-11-15 2004-05-20 Kondur Sankar Narayana Integration of multiple software tools under a single site
US20040158488A1 (en) * 2003-02-07 2004-08-12 Johnson Kurt D. Internet based automated real estate post card mailout system
US20060155768A1 (en) * 2005-01-13 2006-07-13 Hsbc North America Holdings Inc. Computer software implemented framework for configuration and release management of group systems software, and method for same
US20080127045A1 (en) * 2006-09-27 2008-05-29 David Pratt Multiple-developer architecture for facilitating the localization of software applications

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103473627A (en) * 2013-08-20 2013-12-25 国家电网公司 Data processing method for requirement change management of operation and maintenance system
US20180024818A1 (en) * 2016-07-25 2018-01-25 Sap Se Framework for on demand functionality
US9959099B2 (en) * 2016-07-25 2018-05-01 Sap Se Framework for on demand functionality

Also Published As

Publication number Publication date
EP2402865A2 (en) 2012-01-04
EP1854024A2 (en) 2007-11-14
AU2006205055A1 (en) 2006-07-20
CN101164062A (en) 2008-04-16
EP2402865A3 (en) 2012-08-15
US7937685B2 (en) 2011-05-03
CA2594754A1 (en) 2006-07-20
WO2006076396A2 (en) 2006-07-20
WO2006076396A3 (en) 2007-11-22
US20060155768A1 (en) 2006-07-13
EP1854024A4 (en) 2008-11-05

Similar Documents

Publication Publication Date Title
US7937685B2 (en) Computer software implemented framework for configuration and release management of group systems software, and method for same
US20200183896A1 (en) Upgrade of heterogeneous multi-instance database clusters
US8645326B2 (en) System to plan, execute, store and query automation tests
US8312414B2 (en) Method and system for executing a data integration application using executable units that operate independently of each other
CN102656557B (en) Automate enterprise-software-development
US20030018963A1 (en) Installation of a data processing solution
US20040098154A1 (en) Method and apparatus for computer system engineering
US20120066670A1 (en) Systems and Methods for Private Cloud Computing
US20200234213A1 (en) Method and system for implementing an adaptive data governance system
CN102007756A (en) Method and apparatus for dynamic provisioning in data processing environment
JP5965264B2 (en) Integrated program development management system
Annett Working with Legacy Systems: A practical guide to looking after and maintaining the systems we inherit
Lim et al. TAOS-CI: lightweight & modular continuous integration system for edge computing
CN102841842A (en) Automation controller for next generation testing system
Mourão et al. Dynamics AX
Makita et al. Description of Restricted Object Reservation System Using Specification and Description Language VDM++
Franck et al. ModernStats standards supporting the implementation and sharing of statistical services
Nivoit Issues in strategic management of large-scale software product line development
Arumilli SQL the One: Microsoft SQL Server Interview Guide
Blair Managing Ada using Rational's configuration management/version control and IBM's Software Configuration Library Manager
AU2013203291A1 (en) Systems and methods for private cloud computing
Collins et al. Mainframe Alternative Reference Implementation Redmond MTC
DOWGIELEWICZ et al. THE CONCEPT OF AN ENVIRONMENT FOR SERVICE MODEL APPLICATION TESTING
Yang et al. Software Evolution for Evolving China Software Evolution for Evolving China
Dobos et al. Multiplatform Environment

Legal Events

Date Code Title Description
AS Assignment

Owner name: HSBC NORTH AMERICA HOLDINGS INC., ILLINOIS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:WEIL, MICHAEL S.;NAU, STEVEN N.;WEBB, WAYNE P.;SIGNING DATES FROM 20051026 TO 20051207;REEL/FRAME:027462/0015

Owner name: HSBC TECHNOLOGY & SERVICES (USA) INC., ILLINOIS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HSBC NORTH AMERICA HOLDINGS INC.;REEL/FRAME:027462/0003

Effective date: 20110328

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION