Patent Application
20090030706
1. Technical Field
The present invention relates generally to cross-team change request management in a multi-component system, and in particular, to an architecture for cross-team change request management that uses a trunk system to connect multiple consumer and provider components.
2. Description of the Related Art
Today's software development includes a significant interdependency of software components and products. Exemplary of current multi-component systems having many critical interdependencies is the IBM® WebSphere® Application Server which provides scalable and resilient multi-component application infrastructure. The component interdependencies inevitably leads to a “consumer” of a component or product placing cross-team change requests, such as requests for defect fixes or enhancements (also referred to as requirements), on the “provider” of the component or product. As utilized herein a change request is generally a request for any kind of change in a product or service issued by a provider such as in response to a defect. As an example, consider IBM WebSphere Portal Server (WPS), which has dependencies on numerous other products such as IBM WebSphere Application Server (WAS) and IBM Database2 (DB2). Responsive to a WPS customer reporting a problem with WPS, a defect request is initiated in a WPS defect request handling entity. The WPS defect request handling entity may determine that there are defects in WAS and DB2 that must be addressed as part of addressing the reported WPS defect. Individually or in cooperation with WAS and DB2 defect request servicing entities, the WPS defect request handling entity opens two distinct defect requests—one in the WAS defect request service system and one in the DB2 defect request service system. In this scenario, the WPS service request resources or team, is a consumer of WAS and DB2, which are “providers” as utilized herein.
In most cases, the consumer uses the change request tracking system of the provider to open change requests. The provider's change request tracking system usually differs from that of the consumer, thus requiring the management of cross-team change requests in both consumers' and providers' tracking systems. Furthermore, the tracking system software used by a provider may differ from that used by a consumer, thus requiring the consumer to install and learn the provider's tracking system software. This becomes quite onerous when a consumer has dependencies on multiple providers. To complicate matters even further, in many cases consumers and providers use different systems to track their defects and enhancement requests.
Referring again to the above example of a change request originating from WPS service, the service and planning engineers of a product must be familiar with the change request (defect and/or enhancement) processes of many if not all of the products on which their own product(s) depend. This can be onerous when a product depends on a large number of other products, and in the WPS example, results in the WPS consumers having to be familiar with the change request processes for both WAS and DB2 and leaves unresolved how the WPS consumer tracks dependencies between the WPS defect and the WAS and DB2 defects.
It can therefore be appreciated that a need exists for a method, system, and computer program product for enhanced cross-team request management. The present invention addresses this and other needs unresolved by the prior art.
In a data processing system having multiple logically coupled branch systems that share interdependent products and services, a system for providing enhanced cross-team change request management is disclosed herein. In one embodiment, the system includes a consumer branch system that generates a consumer change request. A trunk system manages cross-team change requests between the branch systems in a shared database and stores a first cross-team change request that associates the consumer change request with a first provider branch system. In response to the first provider branch system determining that a supplemental consumer change request is required to address the first consumer change request, the first provider branch system generates a second cross-team change request within the trunk system. The second cross-team change request associates the supplemental consumer change request with a second provider branch system.
The above as well as additional objects, features, and advantages of the present invention will become apparent in the following detailed written description.
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself however, as well as a preferred mode of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
In various embodiments, the invention is directed to an improved method, system, and computer program for cross-team change request management that uses a trunk system architecture to logically couple individual consumer and provider branch systems. Cross-team change requests in the trunk system are linked with change requests in consumer and provider branch systems. A communication subsystem provides an interface for transferring cross-team change request data between the trunk system and branch systems.
In a preferred embodiment of the cross-team change request architecture, the trunk system manages the cross-team change requests in a shared database. This provides an aggregation of cross-team change requests that allows for simple report generation and capturing of metrics. In addition, it greatly reduces the number of systems that a consumer or provider is required to work with in processing cross-team change requests and significantly reduces the number of required mappings between system components. Another benefit is that of common cross-team change processes among the consumers and providers.
In another aspect, the cross-team change request in the trunk system can be used to implement and manage a cross-team change negotiation. Some items that could be “negotiated” between the consumer and provider could be the design and scope of the change and the target design and delivery dates for the change.
As the provider team updates change request information in their respective branch system, the updated information can automatically be shadowed to a consumer team's change request in their branch system via the cross-team change request in the trunk system. In this way, members of the consumer team would automatically see provider information updates in their own branch system without the need to access the provider's branch system or to request information from a member of the provider team.
The system of the invention can define and enforce a cross-team change request process. For example, the system may require that all associated provider change requests be closed in the provider's branch system before allowing a consumer change request to be closed in the consumer's branch system.
Another aspect of a preferred embodiment is that the logical connective relationships between consumer and provider change requests are many-to-many. That is, a consumer may open many cross-team change requests to different providers for a single consumer branch request and a provider may link a single provider branch request to many cross-team change requests from different consumers as depicted and explained in further detail with reference to the following embodiments.
Referring now to the figures, wherein like reference numerals refer to like and corresponding parts throughout, and in particular with reference to
In the simplest embodiment shown in
Responsive to detecting cross-team change request 110, a provider team member/processing unit opens or generates change request 114 within provider branch system 112 and associates the change request 114 with cross-team change request 110. It should be noted that the consumer change request 104 within consumer branch system 102 is now logically linked to provider change request 114 within provider branch system 112 via the cross-team change request 110 within trunk system 105.
Consumer branch system 102 is automatically informed of provider progress in processing the cross-team change request 110 as follows. As provider branch system 112 updates status in change request 114, the updated status is automatically shadowed/written to the associated cross-team change request 110. Trunk system 105 then copies the updated status by updating the associated consumer-side change request 104 using updated cross-team change request 110.
Expanding on the embodiment shown in
Similarly, a provider such as provider branch system 218 may link multiple provider branch system change requests such as change requests 220 and 222 to a single cross-team change request such as cross-team change request 235 using a corresponding set of provider-side branch links 238 and 242. Furthermore, a provider such as provider branch system 218 may utilize alternate mappings between provider-side branch links and cross-team change requests to link a single provider branch system change request such as change request 222 to multiple cross-team change requests such as cross-team change requests 235 and 240.
In accordance with the depicted embodiment, a team member or processing entity within consumer branch system 302 generates consumer change request 304 and also generates a cross-team change request 310 directed to provider branch system 312. To provide the requested change (i.e. satisfy the subject request contained in change request 310), provider branch system 312 opens or generates a cross-team change request 314. Provider branch system 312 may determine that an additional, supplemental consumer request should be generated and sent to provider branch 322. In response to determining that such a supplemental request should be directed to provider branch 322, provider branch system 312 simulates a consumer branch system and a team member or processing entity within provider branch system 312 generates and sends a supplemental cross-team change request 313 to provider branch system 322. The first cross-team change request 310 is thus “cascaded” with the second cross-team change request 313. In this manner, the cascaded cross-team change request architecture 300 enables the originally requested provider (i.e., provider branch system 312) to generate consumer requests associated with handling the original cross-team change request 310 that will be handled by additional providers (i.e., provider branch system 322).
While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention. These alternate implementations all fall within the scope of the invention.
