Many IT organizations have implemented some form of Change Management but fewer have implemented a formal release management process successfully. Yet, most incidents are caused by poorly planned and/or tested releases. Why? Because several prerequisites to a sound release management program have not been addressed.
Here are a few:
- Develop a clear set of expectations with application development organization on timing, lead times, risk, end-user training and infrastructure readiness state, ensuring smooth, planned launches. It is quite impossible to have effective releases of applications without a cooperative effort between infrastructure and application development. Even with the onslaught (or rebirth) of Agile application development processes, this cooperation must be in place to ensure quality services.
Continue Reading…
1. ITIL is an instructional manual for improving IT operations.
Fact: ITIL is an industry approved set of best practices and leaves the ?how to? of implementation up to the practitioner.
2. ITIL and CobiT are pretty much the same things.
Fact: ITIL is best practices for IT process improvement. COBIT provides managers, auditors, and IT users with a set of generally accepted measures, indicators, processes and best practices to assist them in maximizing the benefits derived through the use of information technology and developing appropriate IT governance and control in a company.CobiT are controls to help ensure governance and compliance with regulations such as Sarbanes Oxley (SOX).
Continue Reading…
Hi Guys-
Here is a discussion that transpired recently with some of us at Evergreen related to advanced practices in Release Management. Note–this is not complete or polished--just some interesting musings.
David: Client A and Client B use Change Management to plan for the production ready releases of (applications). All other release activities from conception, design, test, QA, etc… are handled by individual groups outside of a singular control process. Based on my experience with both clients this is the case because the Operations team owns the change process and the Development team doesn’t believe Operations should be involved with the management of applications, other than installing, modifying, or removing production ready apps.
Continue Reading…
