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!

The Four Ps of Service Design - It’s not all about Technology

People ask me why I think that many designs and projects often fail. The most common answer is from a lack of preparation and management. Many IT organizations just think about the technology (product) implementation and fail to understand the risks of not planning for the effective and efficient use of the four Ps: People, Process, Products (services, technology and tools) and Partners (suppliers, manufacturers and vendors). A holistic approach should be adopted for all Service Design aspects and areas to ensure consistency and integration within all activities and processes across the entire IT environment, providing end to end business-related functionality and quality. (SD 2.4.2) People: Have to have proper skills and possess the necessary competencies in order to get involved in the provision of IT services. The right skills, the right knowledge, the right level of experience must be kept current and aligned to the business needs. Products: These are the technology managem

What Is A Service Offering?

The ITIL4 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 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. Note: Goods may not always be provided for every Service Offe

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

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you. Roles and Responsibilities: Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance. Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the

Search