Skip to main content

Posts

Showing posts with the label DevOps Foundation

How ITIL 4 and SRE align with DevOps

In the early days of DevOps, there was a lot of debate about the ongoing relevancy of ITIL and IT service management (ITSM) in a faster-paced agile and DevOps world. Thankfully, that debate is coming to an end. ITSM processes are still essential, but, like all aspects of IT, they too must transform. Recent updates to ITIL  (ITIL 4), as well as increased interest in site reliability engineering (SRE), are providing new insights into how to manage services in a digital world. Here's a look at ITIL 4 and SRE and how each underpins the "Three Ways of DevOps," as defined in The Phoenix Project, by Gene Kim, Kevin Behr, and George Spafford.‎ What is ITIL 4?  ITIL 4 is the next evolution of the well-known service management framework from Axelos. It introduces a new Service Value System (SVS) that's supported by the guiding principles from the ITIL Practitioner Guidance publication. The framework eases into its alignment with DevOps and agile through a bi-mo

DevSecOps - Identity and Access Management

Testing starts with the first line of code!   It is NOT a downstream activity. DevOps testing has a critical role to play in a Continuous Delivery Pipeline. Without integrated testing DevOps simply will not work!   With the advent of DevOps and the movement to breakdown silos between developers, QA, security, and operations, it becomes critically important that all members of an IT team - regardless of what tools they use, or role they play - understand the essentials of testing. Every member of your development team should also integrate to ensure Compliance and Audit outcomes!   It is a new world.   In this new world we can leverage from existing but must be open to walking through new doors of opportunity. Understanding traditional test strategies is helpful but when and where, and most importantly how we proceed with our test strategy must shift.   Knowing how to code is not enough, Quality Assurance in and of itself is not enough.   We cannot afford to have our product

DevOps and ITSM… Are They Compatible?

Many are surprised to learn that ITSM practices ARE compatible with their DevOps pipelines and even more important that they are a critical element in order to ensure the effectiveness, efficiency and the value that is expected. Those that are struggling with silos us vs. them blame games, or roadblocks and impediments for change and test, are shocked to learn how accelerated, modernized ITSM practices can enable their outcomes!  Topics and discussion from a recent ITSM for DevOps class were exciting as practitioners, managers, and leaders discovered together how It is possible to streamline and even automate their ITSM processes and practices so that people don’t even realize that they are executing ITSM processes. We don’t need to change “what” needs to be accomplished. Policy, Governance, and Compliance are a reality. In order to achieve true value and business outcomes service providers must change the way that they think. A change in thinking provokes a change in h

10 Types of People Who Need to Understand DevOps

If your organization hasn’t adopted DevOps approaches yet, it probably will soon. In the InteropITX 2018 State of DevOps Report , only 9 percent of the business technology decision-makers surveyed said that their organizations had no DevOps plans. A third said their organizations had already adopted DevOps principles and another 46 percent had plans to do so within the next two years. As DevOps spreads, many IT leaders have questions about which types of employees should get basic training on the fundamentals of the approach. We recommend that at least the following ten types of people get a foundational education about DevOps: 1. Developers In many organizations, DevOps begins with the application development team adopting Agile methodologies. DevOps begins to spread as those in the operations team start to follow some of the same principles. 2. IT operations professionals DevOps is all about closer integration between development and operations, so it stands to r

DevOps and the North Pole

T’was a month before Christmas on the pipeline, not a heart was beating not even mine. For the product owner there is work to be “DONE”, so into the “Sprint Log” the work has begun! ­­­­ On Dasher! On Prancer (Development Deer) - QA and Security, they are all here. Red hats worn by all and only one “White”; The teams almost ready, so don’t you fright. When what to my wondering eyes should appear, a massive build from the Ops Engineer! This today, that tomorrow, “Fail Fast” and learn there is no sorrow! Ho Ho Ho! A jolly Scrum Master appears; impediments removed we all give a cheer! Ops leads the way with their nose shining bright; we are agile and fast and we’re out of site! Off with a flash, then “deer-to-deer” review”; here comes the surprise, it's coming to YOU. We stand all amazed, and straight is our gaze.  The Christmas tree stands all tall and bright; its branches are massive and covered with lights!  On top is a star that streams long bright bar

DevOps Stakeholders – Who Are They?

IT professionals attending the DevOps FND Certification class offered by the DevOps Campus at ITSM Academy are sometimes surprised to discover that DevOps in not just about Dev and Ops . The DevOps pipeline and value stream for the continuous delivery of products and services mandates that an integration of requirements and controls be orchestrated in such a way that speed and value are achieved. DevOps extends far beyond software developers and IT operations. One way to consider the stakeholders for DevOps: Dev Includes all people involved in developing software products and services including but not exclusive to: Architects, business representatives, customers, product owners, project managers, quality assurance (QA), testers and analysts, suppliers … Ops Includes all people involved in delivering and managing software products and services including but not exclusive to: ·Information security professionals, systems engineers, system administrators, IT operations engin

You too can Take Action! – Key Takeaways from DevOps Foundation Certified Professionals

Taking action is one of the most necessary steps in effectuating life changes. However, as most of us know, sometimes it is very difficult to take that first step and commit to a desired achievement. When delivering DevOps/Agile/ITSM certification classes, I like to stress that as leaders we must inspire. And this is true because Inspiration leads to motivation and motivation triggers ACTION! Although this is true, a recent Forbes article opened my mind to another way of looking at this. In this article Svetlana Whitener states that: “You don’t need to wait to feel inspired before you implement a new behavior. You can immediately begin by gathering your willpower (a strong self-control determination that allows you to do something difficult) and stop procrastinating.” So whether you dig deep into your inner self and use will power or you are inspired by others, take action! Both motivation and will power are necessary. The bottom line is this: Digital Transformation is real and IT

Golden Keys to Unlock Agile Success

Communication and Education before Collaboration  An engineer attending a recent DevOps FND class for certification said “OMGosh! I have been trying to do DevOps and I really did not understand what it really was!” He knew that a self-organizing team was defined as a group of motivated individuals who work together toward a goal, have the authority to take decisions and readily adapt to changing demands. Solutions are derived from inter team collaboration. Innovation is the name of the game for digital transformations. All true but … “authority” without ability is dangerous.  Let’s not forget that before these teams are able to recommend innovative ideas for improvement that we must communicate the strategy and outcomes that deliver value. Also true is the fact that we must educate teams to continuously enhance their skills.  Challenge: During your next virtual or face to face meeting with staff, ask a few questions to validate that all are on the same page. You could as

I KAN KANBAN

LEAN Principles LEAN principles originated in Japan with the “Toyota Production System” and have evolved from manufacturing. Tools and techniques for LEAN are rocking the world of Information Technology (LEAN IT). LEAN does not stand alone! There is a DevOps Foundation certification class available that explains how LEAN, AGILE and ITSM dove tail together to optimize a DevOps integrated delivery pipeline. The core idea is to deliver customer value while eliminating waste ( Muda ). The goal is to provide value to the customer through a perfect value creation process that has zero waste. What About KANBAN? KANBAN is one of many techniques utilized for LEAN practices and results in an increase in productivity and value for individuals and teams. In Japanese the word KAN means visual and the word BAN means board. KANBAN is a visual board that helps teams to visualize work and get more done. If you’re reading this because you are interested in using KANBAN for yourself or your tea

What is a Microservice?

Business requirements are not static.  The rate of dynamic change for new evolving business needs is increasing as you are reading this blog.  The traditional software development practice for building one big honking monolithic program to provision services is not applicable to the explosion of need. This old way of thinking and deploying is not conducive to Agile.   To understand a microservice let’s first start with our traditional view point.  For this purpose, let’s say that you want to build a “Self Service Catalog”.   To make this seemingly complex service less complex let’s break it up into many microservices.   For example; one microservice might be for “Creation of Online Account” another for making a selection from the “Service Catalog”.  One might be to “Select Payment Method” and yet another microservice for “Invoicing” and so on.  These are many microservices or sub-services that will eventually be connected via Application Programming Interfaces. These microservices

Agile / DevOps: Value Stream Mapping for IT Services – Some Thoughts

Value stream mapping  originated a s a   lean -management method.  Today this method along with Agile, ITSM and other LEAN practices is utilized to understand and improve the delivery of products or services for all industries.  Being able to analyze the current state for the series of events that take a product or service from concept all the way through to value realization by the customer is a powerful tool. A tool necessary for designing an efficient future state and for strategizing continual service improvement.  Below are some thoughts on how the approach to value stream mapping can be applied to service management. Getting Started: Beginning with the formal proposal or request from the customer and then documenting what takes place throughout the lifecycle is always a good starting point.  Value Stream Mapping requires a gradient approach including the following elements: ·          Define physical flow of events – If you are just starting out, it might prove helpfu

ITIL – Back to Basics for Agile and DevOps

ITIL advocates that IT services are aligned to the needs of the business and support its core processes. It provides guidance to organizations and individuals on how to use IT Service Management (ITSM) ­­­as a tool to facilitate business change, transformation and growth. Some are believing that ITIL has run its course.  In truth I believe the opposite is true.   In the past, and still today, many organizations believe that Best Practice and ITSM processes are focused on the Service Operation Lifecycle.   Implementation, process design, and ITSM tools have had a very heavy focus on processes like Incident, Problem, Change and Configuration Management. Few have yet to recognize or have not seen the value in the guidance for Service Strategy and Service Design processes and roles.   How did these get overlooked? In the last three or so years I have seen a bit more buzz about “Business Relationship Management”.   Less so for “Demand” and “Strategy Management” for IT Services. Few are

Measuring Goals for DevOps Test Succcess

Each organization will have to define what their quality goals are for integrated testing based on the business and customer requirements for speed and outcomes.  The fact is that these goals must be quantified or in other words measurable. If you are not measuring your testing activities in alignment with the strategic goals then success becomes subjective and it will be very difficult to show value for your effort. Some examples of measurements might be in the form of Run-To-Plan and Pass-To-Plan. Run-To-Plan (RTP) is the number of the total planned tests that have completed and typical goals are to have 95% RTP Pass-TopPlan is the number of tests that have passed and a typical goal for this metric is to have a 90% PTP The criteria for determining when testing is complete is agreed by all stakeholders.   It will be impossible to have all stakeholders on the sprint team, but certainly input and validation from key stakeholders will have to be included before acceptanc

Site Reliability Engineering

Site Reliability Engineering (SRE) is a discipline that incorporates aspects of software engineering and applies that to operations with the goal of creating ultra-scalable and highly reliable software systems.  Google’s mastermind behind SRE, Ben Treynor, describes site reliability as “what happens when a software engineer is tasked with what used to be called operations.” Historically, Dev teams want to release new features in a continuous manner (Change). Ops teams want to make sure that those features don’t break their stuff (Reliability). Of course the business wants both, so these groups have been incentivized very differently leading to what Lee Thompson ( (formerly of E*TRADE) coined the “wall of confusion”.  This inherent conflict creates a downward spiral that creates slower feature time to market, longer deployment cycles, increasing numbers of outages, and an ever increasing amount of technical debt. The discipline of SRE can begin to reduce this dilemma by

Pace-Layered Application Strategy

Historically, many companies have had a single strategy for selecting, deploying and managing applications. They have had a defined structure for classifying applications by value or functionality, but failed to recognize that applications are fundamentally different based on how and when they are engaged by individuals and the organization as a whole and the pace at which these tools need to be changed and updated.   Many organizations are finding themselves with an enterprise application strategy that fails to satisfy the needs of the business community, which has often led to underutilized applications throughout their portfolio. Gartner’s Pace Layered Application Strategy is a methodology for categorizing applications based on how they are used and how fast they change.   This strategy helps IT organizations rationalize the use of DevOps practices that ensure a faster response and a better ROI, without sacrificing integration, integrity or governance requirements.   The

Big Bang - DevOps

I learned about ‘The Diffusion of Innovation Theory’ in a DevOps Foundation training course.  I wanted to get my DevOps certification but more than that to learn about what makes a DevOps initiative successful.   When I mentioned the Diffusion of Innovation Theory to a coworker he said “It sounds like Sheldon talking to Raj on “The Big Bang Theory” TV series.  Although the name sounds Big Bangish the usage of this theory could be the real difference for success in any transformational change including DevOps. To start let’s begin with the definition of DevOps. DevOps is a professional and cultural movement that that stresses communication, collaboration, integration and automation in order to improve the flow of work between software developers and IT operations professionals. Improved workflows will result in an improved ability to design, develop, deploy and operate software and services faster. That’s where this “Big Bang” or Diffusion of Innovation Theory comes in.   De

Every Business Has Become a Technology Business

Every business has become a technology business.  Let that one sink in for a moment.  With the internet of things ever increasing it has become ever more imperative for us to make wise decisions about how to move forward on which IT services we should be delivering into the future (pipeline), how long we should continue to deliver our current (catalog) and when should we retire them (retire).  We literally could be an app away from becoming irrelevant. It is no longer enough to satisfy our customers, we must now delight and excite them.  They have to be able to enjoy the experience of how they receive these services along with the knowledge and comfort that the service provider of choice can continue without interruption to deliver this level of performance and functionality and even deliver new capabilities swiftly and often. By engaging in DevOps principles & practices (Scrum and Agile) at the strategic level we can begin to prioritize new and changing customer require