| CA Uses SOA to Close Software Change Management Loop | | Print | |
| Monday, 17 December 2007 | |
|
With the latest release of its CCM change management offering, CA is applying SOA to help integrate its Software Change Management tooling, not only to external application lifecycle tools such as software QA/Testing, but also to ITIL/IT operations-related processes and tooling such as Service Desk.
Specifically, the new release of CA’s Change and Configuration Management (CCM) bundle adds a new integration link generically branded SOA Bridge. It’s intended to tie CA’s existing main frame and distributed software change management (SCM) repositories to external offerings such as HP Quality Center (the testing products that came from Mercury), and to CA’s Service Desk products. Along with the new release, several parallel processing and multithreading performance and patch management enhancements have been added to the mainframe version of the CCM tooling. There are several pieces of rationale for these new links: first, a properly managed software development lifecycle (SDLC) mandates that all software changes should be tested, and that test results be added to the test history or genealogy of the software artifact. But the link to IT Service Desk prompts another key point: even when software changes pass QA tests, they could break IT infrastructure if servers or databases are not configured to accept the newest version of the software. In other words, the surgery could be successful but you know what could happen to the patient. Just ask anybody who has implemented an update of any off-the-shelf software – it’s critical to validate new software versions or patches before you commit to installing them. ITIL v3, the latest version of the framework, adds further backing to the idea by applying a lifecycle approach to IT Services that starts with defining strategy to designing the service, making the transition to production, operating the service, and then continually improving or optimizing it. For the CMDB (Configuration Management Database), it means not only storing the current configuration record of the asset (in this case, software), but storing those records throughout the lifecycle, knitting a history of how the item changed. And that's where CA makes the case that artifacts from CCM, which are under the aegis of the application development group, be exposed also to the CMDB, which is under IT operations. In actuality, data does not have to literally move from the SCM system to the CMDB; instead, the SCM repository is federated with the CMDB, exposing a face of its metadata. CA is proposing to accomplish this with its new SOA Bridge technology. |
| < Prev | Next > |
|---|

















