|
What are the benefits of doing this training? |
|
The seventh book in ITIL V2 was on Application Management. While it was perhaps not the best construction in the suite, it did contain some very powerful suggestions and activities regarding managing applications.
The first was to take an orginisation-wide view of applications. Traditionally, Applications Development was project based, not looking outside of the objective of delivering the required business functionality. Application Management means looking at like applications, standardising on application frameworks, restricting the variety of application architectures to a supportable few, and reusing application design to fast-track development to market.
The second suggestion was in collecting requirements from all stakeholders, not just business but the various areas within IT as well.
. Operability requirements from the Operations areas,
. Platform requirements from Infrastructure,
. Management tool requirements,
. Data security requirements from Security Management,
. Diagnosis requirements for Incident Management,
. Release Unit definitions for Release Management,
. etc.
Cast a broad net rather than try to retrofit these requirements in later.
Thirdly, that Application Management extends well beyond Application Development. That delivery is not the end of an application. Operations and Optimisation are critical to the return on investment for the organisation. Have regular reviews of critical applications to determine if they are still delivering the value they were intended. Be proactive about application reviews.
. Are there simple changes that can be made to improve the effectiveness of the application, both for business and for IT?
. Is there a perceived end of life for this application and how far out is it?
. Must we start to plan the replacement before it becomes a matter of urgency?
Finally, the Application Management book stated that Application Management was a superset of both Application Development and Service Delivery. A point which is essential to having the overarching perspective.
From what I have read of ITIL V3 to date, ITIL has taken a backward step on this approach. Saying that Application Management is primarily involved on the Service Delivery side and much less on the Application Development side. This concerns me, however further reading and interpretation is required. |
|
To answer the question of what one might get out of the ITIL Application Management Essentials training course I would like to paste part of an email from a past student.
"The points I felt were of most value from the Application Management course I did last November.
In a nutshell, they are:
* As I am in the Production Support area, the key points that interested me the most were around Supports early involvement in the SDLC, particularly the early Requirements/Design stages, so that Support ensures the application is simpler and cheaper to run and more supportable.
* There needs to be an "Optimise" phase in the SDLC cycle. Also, SDLC is a cycle, not a start-End process and the Operations phase is not the end of the SDLC process where the dead cat is thrown over the fence.
Perform an Application Review periodically as part of the Optimise phase, with change recommendations for improvements being fed back into the SDLC. The aim being to make the application be cheaper to run and to operate better.
* People get hung up on the initial cost of Development/Purchase but the largest cost of IT is Operations. If you can optimise Operations, you'll save significantly more money than penny-pinching Development costs by a) putting in poor architectural designs, b) forgetting about how it will be supported and so incurring cost-wastage once the application is in Operations, etc.
* Consider long-term, architectural considerations early in the SDLC, which can save alot of money later by having an well-architectured application.
* Always look to Re-use during development and to set up Re-use capabilities in every change. Assume that a change you're putting in for one business unit will be wanted by another and enable it to be re-usable and save costs, time and improve business happiness.
* During Build, test back to the Requirements to ensure the original business needs have been met.
* Seek out to implement "Self healing" and automated handling of errors into an application so that it minimises Support effort in Operations.
* Implement good monitoring and alerting tools into Operations, and design these into the application as part of the Development. Not something that operations put in after the fact because they're running blind once the application is in production.
If you can make these Monitoring and Alerting tools to be automated, then better still. Eg. overnight batch job falls down with e error, the automated tool kicks in, allocates additional e, then job continues on.
* Perform proactive Operational Management. Early in the SDLC, work with technical and applications support teams to proactively consider how to make the application run more smoothly once it is in production.
Understand business drivers and needs solidly before starting changes, so that we ensure we deliver what the customer needed and not what we think they wanted. (The old Swing ogy)
* Set up a range of measurements to understand the application's true position better.
* Main reasons for Application failure are: rushed design/requirements, inadequate training, poor monitoring and alerting, poor doentation and operations instructions, insufficient online availability, and insufficient testing " |
|
Other feedback from the course have been,
"around the setting up of an Application Management Office (AMO) in line with the characteristics and functions of a PMO.
This is to view and manage the portfolio of applications organization wide, establish and doent Frameworks for future development, and track costs and benefits of applications across their entire lifecycle."
I see the AMO as the independent Application Management Office (AMO) may be valid for very large organizations. Alternatively, the activities of the PMO may be expanded to include AMO work.
The AMO must manage and maintain the Application Portfolio. This should provide information to other areas of IT that need to interrogate application related data.
The Portfolio must contain data relevant to the applications, links to relevant doentation, application status, application state and relationships to other applications.
The AMO will manage and maintain the Service Dependency Model (SDM) to reflect relationships.
The Portfolio and SDM may be part of the CMDB.
The AMO should control the doentation (including SLAs, Test Plans) relating to the applications in a Doent Library, and the source core in a Source Library.
The AMO should perform the administrative tasks of notifications, identify when Optimisation Reviews are required and initiate these (allocating the appropriate resources). They can be used to track application costs (implementation, maintenance, licencing) and report the benefits.
The AMO to report on applications and the progress / trend of applications across the organization. E.g number of apps, consolidation of apps, retirements, etc. |
| clee49564/09/2008 4:39:33 PM |
I have a question here.
What's the difference between application manager and application owner? |
| MikeD5/09/2008 9:54:44 AM |
My view is that an application owner should be the responsible business owner of an application who must approve any work requests for enhancements and will be a key business contact in critical situations.
An application manager is the IT person responsible for ensuring that work requests get processed by the service provider and for ensuring that the application is delivered to the quality standards agreed in SLAs.
|
| clee49565/09/2008 11:55:26 AM |
Does this module includes topics on vendor management?
|
| MikeD5/09/2008 2:00:07 PM |
There is little reference to vendor management in the Application Management book. There is some discussion of delivery/sourcing strategies but there is an implication that vendor management would be performed via an appropriate project management framework during the Requirements, Design, Build and Deploy phases.
Once an application has reached the Operate phase, the project would be expected to close down and ongoing vendor management should be the responsibility of Supplier Management (this is covered in Service Design in ITIL V3). Supplier Management continues to be active in the Optimise phase although major changes to an application may result in a further project and another iteration of the lifecycle. |
