WARNING! The Titanic is Sinking! Service Providers… Stay CALM & Share!

(DevOps VALUES revisited)

We used to talk about the rate of demand for change and how that was forcing service providers to change course. Service Providers are the current Titanic. Many believe that they are invincible. The iceberg today is multifaceted. It is not only speed and quality but the challenge of dynamic business requirements, complexity of new services and rigid silo’s. These all add to the depth and potential threat of this new iceberg. To avoid sinking, Service Providers must consider the DevOps values and stay C A L M and Share! There are five DevOps values that will help us avoid the iceberg. These values include:

C - Culture

A rigid, “We have always done it this way” culture will break your capability to steer the ship in the direction that you must go to avoid the iceberg. A Cultural shift will steer your ship in the right direction. Those shifts include

Shift Left Culture– Getting representation for change, compliance, security and operations engaged early in the requirements gathering. The challenge here is how we integrate these into our Agile/Scrum teams or traditional project management activities. Service providers will need to integrate and engage these stakeholders throughout the design, delivery and support from idea to end of life for the service. Life preservers and Lifeboats must be fit for purpose.

Proactive vs. Reactive - Continuous Integration should not be confined to code and developers. Integrated Security and Integrated Testing for true Continuous Integration will be required to get the type of results we hear about from Continuous Delivery. This cultural shift will require that we shift our entire thought process out of the silo and collaborate across all functional teams. These teams include: Business Partners, Customers, Architects, Developers, Operations, Engineers, Security, Legal, Change Managers, Partners and more. Being truly proactive keeps us on the right course and away from the iceberg.

A - Automation

Automation alone will not keep us from hitting the iceberg. You can not automate chaos. Just enough process, (not a 40-page document with hundreds of checklists and useless KPI’s) and just enough governance will be required. Communication and Collaboration will allow for an understanding of toolchains and the ecosystems involved. Easy to say but what tools are you using to allow for collaboration? What teams are using Kanban, Chatbots and others? Do you have policies in place? Do you know what your “Eco-Systems" are? Transparency is required here. Be very careful. Remember that open source is not always the most efficient and there is no one vendor solution to provision. Continuous Delivery is not the goal but is merely one of the tools utilized to meet the business goals. Be careful and don’t automate your ship directly into the iceberg.

L – Lean

Consider the flow of work from idea to the delivery of a service into an antifragile, secure production environment. Service providers will need to consistently search out where there are constraints, roadblocks and waste. Visualizing the flow of work using lean tools like Value Stream Mapping will prove to be a good first step. Plot the correct course at the right speed and avoid the iceberg.

M – Metrics and Measurements

If metrics and measurements are looked at subjectively from your individual functional teams or departments (silo’s) then they are likely to look good. As a matter of fact, individual teams are out celebrating their numbers and customer satisfaction could very likely be taking a dive in the wrong direction. WARNING! New metrics and measurements such as lead time (not just cycle time) will need to be considered. Also, what is your velocity? Does it meet the rhythm of demand or cadence required from your business customers? Are developers using Agile, Scrum and other techniques to speed up only to hit a brick wall when it comes to change, security or other risk mitigating activities in the delivery cycle? If so then Danger, Danger, you may be headed towards the iceberg. Measure to business goals and results.

S - Sharing

Share what? People, Process, and Technology. Experimentation and learning is key. Across the board collaboration, communication and education will be an ongoing endeavor.

Learn more, Inspire and Educate so that we don’t hit the iceberg!

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