Operation and DevOps

DevOps is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably. It’s about improving, communicating and collaboration. From a Service Operation perspective we are already part of the way there, so maybe it won’t take as long or require as much organizational change as we think.

Application management is responsible for managing applications throughout their lifecycle. Application management covers the entire ongoing lifecycle of an application, including requirements, design, build, deploy, operate and optimize. The application management function is performed by any department, group or team involved in managing and supporting operational applications. Application management also plays an important role in the design, testing and improvement of applications that form part of IT services. As such, it may be involved in development projects.

They are the custodians of technical knowledge and expertise relating to the management of applications. Working together with technical management (Cross Functional Teams) they together guarantee that the knowledge required to design, build, test, manage and improve IT services gets defined, developed and continually improved. They provide the actual resource that supports application in the service lifecycle. By undertaking this role they are ensuring that the resources being utilized are appropriately trained to take part in continuous integration, continuous delivery and continuous deployment, which means they must be included in any value stream map we create.

It is therefore imperative that they are part of the team who contributes to the development of the set of centralized platforms and tool services that will ensure the appropriate levels of collaboration and integration with the development teams by encouraging the breakdown of the wall of confusion.

For more information on Service Operations and DevOps please see http://www.itsmacademy.com/itil-so/ and http://www.itsmacademy.com/dofnd/

Comments

Four Service Characteristics

Recently I came across several articles by researchers and experts that laid out definitions and characteristics of services. ITIL provides us with a definition that can help drive the creation of value-laden services: A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. An area that ITIL is not so clear is in terms of service characteristics. Several researchers and experts put forth that services have four basic characteristics (IHIP): Intangibility—Services are the results of actions not things. They have no physical presence and represent a logical set of elements. One way to think of service is “work done for others.” Heterogeneity—Also known as “variability”; services are unique items because of the mechanisms used to deliver services, which is people. Because the people element adds variability, the service is variable. This holds true, especially for the value proposition—not eve...

What Is A Service Offering?

The ITIL 4 Best Practice Guidance defines a “Service Offering” as a description of one or more services designed to address the needs of a target customer or group. As a service provider, we can’t stop there! We must know what the contracts of our service offering are and be able to put them into context as required by the customer. Let’s explore the three elements that comprise a Service Offering. A “Service Offering” may include: Goods, Access to Resources, and Service Actions 1. Goods – When we think of “Goods” within a service offering these are the items where ownership is transferred to the consumer and the consumer takes responsibility for the future use of these goods. Example of goods that are being provided in the offering – If this is a hotel service then toiletries or chocolates are yours to take with you. You the consumer own these and they are yours to take with you. ...

What is the difference between Process Owner, Process Manager and Process Practitioner?

This article was originally published in 2015. With the Introduction of ITIL 4, some of this best practice has changed. See ITIL 4 and the Evolving Role of Roles . Updated Definitions in ITIL 4: Process Owner: In ITIL 4, the concept of 'processes' has expanded into broader 'practices.' Consequently, the Process Owner is now often referred to as the 'Practice Owner.' This individual is accountable for the overall design, performance, integration, and improvement of a specific practice within the organization. They ensure that the practice achieves its intended outcomes and aligns with the organization's objectives. Process Manager: Now commonly known as the 'Practice Manager' in ITIL 4, this role is responsible for the day-to-day management of the practice. The Practice Manager ensures that activities are carried out as intended, manages resources assigned to the practice, and oversees the practitioners performing the work. Process Practit...

Search