Body
Statement of Purpose
Provide guidance, specific instruction, and tools to configuration item owners of Enterprise Applications within Solution Delivery to perform this role
Contact
Bob Black, Service Asset and Configuration Management Process Owner
David Schaefer, Enterprise Application Configuration Item Process Manager
[Undefined], End User Device Application Configuration Item Process Manager
Definitions
- Configuration Item: A service asset that needs to be managed in order to deliver an IT service. All CIs are service assets and come under the control of Change Management. Configuration items may vary widely in complexity, size and type, ranging from an entire service or system including all hardware, software, documentation to a single software module or a minor hardware component.
- Enterprise Application: A subset of configuration items regarding the applications that are created, managed, or maintained by enterprise IT. Examples: Banner General, Banner Finance, TeamDynamix, OBIEE, Tableau, Gmail
For Solution Delivery these are applications that are specifically identified in TeamDynamix as owned by a member of a Solution Delivery team AND use the Enterprise Application form. https://miamioh.teamdynamix.com/TDNext/Apps/741/Reporting/ReportViewer?ReportID=B4AguRxYKKw_&RunNow=1
- End User Device Application: A subset of configuration items regarding applications that reside on individual user devices. Examples: SPSS, MS Excel, Chrome, MS Windows
- System: Collection of CIs working together for use by other CIs
- Service Offering: Collection of CIs specifically assembled for use by end users
- Server: Virtual or Physical computer and storage
- Network Device: Technology that provide conveyance of data across Miami's network infrastructure
- Database: Platform for providing databases to applications
- End User Device: Equipment that resides with end users or deployed as an end-point.
- Facility: Specific locations containing technology managed by IT
Responsibilities
Understand and represent the application throughout the organization
This responsibility involves a reasonable understanding of the architecture, underlying technologies, underpinning agreements, and technical capabilities of the application. Some questions to consider:
- What IT Service does this application support? (eg, Banner and PageUp support the delivery of the Enterprise Resource Management service; WebEx and Google Meet support the delivery of Video Conferencing service; Canvas supports the delivery of Learning Management service)
- What business offices are the primary business owners that benefit from the service or capabilities of this application?
- Who are the individual stakeholders who care most about the utility and warranty provided by this application?
Ensure the entry in the Configuration Management Database (CMDB) is accurate and is maintained
Recommend reviewing the enterprise applications at least annually. As you review consider the level of detail you would want if taking on application ownership as someone new.
- Run this report for a list of enterprise applications you own with review dates older than 12 months
- Refer to the Support Guide: SACM / Service Asset & Configuration (Application/Software) for a complete list but highlighting a few of the most important items:
- Name: The name of the asset
- External ID: Unique identifier of the asset for connecting to third party systems via API. For Applications: Typically use the Name
- Status: Status of the asset
- Supplier: Vendor from whom the asset was acquired. Specify Miami University if home-grown
- Escalation Instructions: Instructions for ticket logger on where to escalate if unable to solve. Most commonly a link to an escalation procedure article in the Knowledge Base
- Owner (Local Change Authority/Manager): Authorized local change authority/manager of asset.
- Owning Acct/Dept: Solver Team that contains deepest level of technical expertise
- Diagram Link: Physical and Logical Diagram Links
- Prod URL: URL to the production application
- Description: Purpose of the application or any pertinent information
- Application Location: ie. On Premise, Cloud - Miami or Cloud - Vendor
- Product Model: The product model of the asset. (MU - Application/Software) - This will be filled in by using the form Application/Software
- Server Environment: This is the ITSM Lifecycle phase. (Production is automatically filled in, but you can use the drop down to change the environment
- Audited By: UniqueID of the Configuration Item Owner who last audited this Configuration Item record for completeness and accuracy
- Audited Date: This is the date that this configuration item record was last audited for completeness and accuracy by the configuration item owner
- Requestor: Individual in business office who serves as the business owner
- Requesting Account / Department: Primary business unit beneficiary of asset.
- Ticket Routing Details: Link to KB Article that describes how and in which situations tickets should be escalated by IT Help
- Application Language: For open-source or custom-built, in what language was the application developed?
- Application Platforms / Frameworks: The development platform for premise or hybrid applications
- Git Repository: URL to the git repo for the application
- Prod URL: URL to the production application
- Test URL: URL to the test application
- Internal Escalation Notes: For solver teams to include notes needed for support. Links or location of operational documented
- Blackout Window: Time periods when changes should not be made with reason why
- Relationships: Other configuration items upon which this application depends; Other configuration items that depend on this application; service(s) enabled by this application
- Attachments: Run Books; Architecture Diagrams; Contracts; Memorandum of Understandings; Operational Documentation
Review the Memorandum of Understanding in coordination with the business / service owner and IT Procurement
Key elements we recommend including in a Memorandum of Understanding
- Stakeholders. Who cares most about the utility and warranty provided by this application?
- What IT Service(s) does this application help provide. List individual owners of those services.
- What business offices are the primary business owners that benefit from the service or capabilities of this application? List individual contacts in those offices
- Licensing.
- How are licenses allocated. For example: by person, concurrent use, by a certain function or activity within the application
- How are licenses funded. Include specific Index codes and formulas for shared funding when possible.
- Plan for monitoring use relative to contracted allowance
- Upgrade Plan.
Monitor utilization relative to contracted allowances
For some applications, the owner should establish a cadence for reviewing utilization relative to the contracted allowances. Some applications provide metering tools that will send notifications if limits are approaching or breached. Where such tools do not exist, we recommend setting up a scheduled ticket in TeamDynamix to review utilization at an interval that makes sense for the specific application circumstances.
Provide input for performance, availability, etc.
This responsibility involves a deeper understanding of the utility and warranty provided by the application.
Questions to consider:
- Is the application performing within target specifications?
- Is the application responsive?
- Is the user interface intuitive and easy to use?
- Is demand growing or shrinking?
- How frequently do people experience incidents with this application?
- What major incidents have recently involved this application?
Serve as a point of escalation for major incidents
If this application were to be at the source of a major incident, the application configuration items owner will often be called upon to serve as the Major Incident Leader. While full details are fully documented in the Major Incident Handbook, the role of leader centers around
- assembling resources to restore service
- ensuring communications to stakeholders take place in timely manner
- conduct after-action report to summarize root cause
Represent the application during Change Advisory Board (CAB) meetings
Risk Level 1 and Risk Level 2 Changes are reviewed by weekly Change Advisory Board. The Local Change Manager may optionally request CAB review of lower risk changes.
- Explain the positive risk of the change, such as new features or added warranty
- Explain the negative risk of the change, such as impact from downtime
- Explain how risks are being mitigated through means such as redundancy, timing, back-out plans, etc
- Explain potential impact on other applications or services that share resources with this application
Review knowledge articles for accuracy and completeness
KB Article ownership is synchronized with the configuration item about which the article most closely aligns. The owner receives reports of articles that will expire in the next month to conduct a currency review.
When a support ticket is escalated to you or your team, consider authoring an article to address that situation in the future or improving an article if one already exists. Consider these questions:
- What information did the lower tier support team lack that would have prevented the escalation?
- What is the likelihood this situation will reoccur?
Additionally, the application configuration item owner should make a holistic review of articles related to that configuration item annually.
- Do these articles address the preponderance of issues and questions a user experiences?
- Is it possible to remove duplication and consolidate multiple articles into a single article?
- Which articles are most commonly linked to incident and service request tickets?
- Review data from google analytics to help determine which articles are being viewed
Provide expert-level support for unsolved incidents and service requests escalated by lower support tiers
Each enterprise application identifies a technical team with the highest level of technical expertise related to that application. If lower tier support teams are unable to resolve an incident or service request, it may be escalated to that expert team.
In some cases, a supplier / vendor may be needed to address the issue. Typically, the configuration item owner maintains the relationship with that vendor and designates the pathways by which members of their team may gain access.
Capturing the final resolution in a knowledge article for lower tier to use in the future will mitigate escalations on the same issue.
Participate in service review meetings within IT and with the business
Ideally, each IT Service in the service catalog undergoes a service review on an annual basis. The details of these reviews are covered by the service level management process. The application configuration item owner is typically involved to represent that application in the context of the broader service.
Provide input for and prioritization of Continual Service Improvement (CSI) efforts
No uniform process for continual improvement within IT has been defined and agreed. Nonetheless, the application configuration item owner may identify opportunities through the administration of their duties to improve the utility or warranty of the application and therefore improve business outcomes. Consider advancing such improvements through informal means in addition to these known improvement registries:
- Problem / Continual Improvement Attribute of Major Incident Summaries: Improvements identified in the post mortem analysis of the major incident
- Pebbles: Improvements for development teams to optionally work into a sprint
- SolDel Product Backlogs: Tracking defects discovered in testing by development teams
- ITSM Improvement Backlog: Improvements to ITSM processes, including the Service Desk function, or tools
- ITSM Roadmap FY20-22: Stategic view of ITSM process state of operation and planned improvements on rolling two year horizon
- Service Improvement Plan: Outcome of service review to identify potential improvements to service artifacts, performance, or perceived value
Application Specific Duties
These responsibilities apply the the class of configuration items known as enterprise applications, largely identified in TDX by the form "Software/Application"
Conduct a service confidence assessment
The specifics for conducting this assessment are still under development. Instructions are being drafted as we gain experience and iterate from what we learn.
The Service Confidence Framework describes three factors for a service:
- Context - the impact of the application on the University
- Confidence - our trust in the service reliability and our ability to restore the service in the event of an outage
- Potential impact - combines the context and confidence to represent likely "blast radius" of a disruption
When considered together, these factors provide a useful summary which allows comparison of multiple services, identifies critical services with low confidence and informs efforts to improve service stability.
Selection Criteria for a Configuration Item Owner
When determining the best person to select to serve as the application configuration item, consider these characteristics:
- Job role is an IT role
- Access to expert technical resources, typically as a manager of that tier 3 team
- General Understanding of the Application Asset and related technologies that are used together to support it
- Effective at engaging with the IT units that support those component technologies
- Understanding of how the application supports the business
- Possesses existing relationship(s) with business partners
- Evidence of excellent written and verbal communication skills
- Effective negotiator
Related Documents, Forms, and Tools