One of the most frequently stated key takeaways from DevOps Foundation Certification Candidates is the big AAH-HAA moment when they realize the difference between Continuous Delivery and Continuous Deployment. Terms matter and the context in which we use them can make or break the success of any DevOps pipeline for digital transformation . Which one of these you select for your organization will have a significant impact on the way you orchestrate ­­­­your DevOps Pipeline and your Continuous Delivery Architecture. It will most definitely help to define the appropriate tool pipeline, determine how you will utilize and program those tools for automation and will have an impact on the context of your communication plans to your stakeholders. How will you approach integrated testing? There is not one element of development and delivery that Continuous Delivery or Continuous Deployment will NOT impact. Therefore; It is critical to understand what they are, how they are the same, how they

(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

Recently, I am hearing things like  “We are the World Leader for Value Stream Mapping”   from vendors and managed service providers alike.  Why? I thought. Value Stream Mapping (VSM) was originally introduced in 1996.  Why is this becoming such a hot item again now?   Other tag lines and mantras that you are likely to hear are things like:      Experience Management is an Evolution Speed to Value not Time to Market Without continuous flow, continuous integration               Continuous Delivery are just an aspire! From Milestones To a Continuous Quality Assurance Flow Shift Left, and    Green to Green Every IT executive, manager, or practitioner can surely add to this list. I thought about these and other new ways of thinking and realized we are moving beyond Digital Transformations and understood that true success for any delivery cycle will require Flow Engineering. Without continuous flow service providers are likely not going to be able to meet business and customer requirements

DevOps is here and it seems to be what everyone in ITSM is buzzing about. So what are the goals and how do we know it’s not just the next hot kitchen color for this year?  DevOps is a cultural and professional movement that stresses communication, collaboration and integration between software developers and IT operations professionals while leveraging agile, lean and traditional ITSM practices. Stakeholders on the development side will include, but not be limited to, all of the people involved in developing software products and services.  On the operations side it will include, but not be limited to, all of the people involved in delivering and managing those software products and services and the underlying IT infrastructure on which it is being delivered.  The goals are to better align IT responsiveness to business needs, smaller more frequent releases, reduce risk, increase flow, improve quality and reduce time to market. These can only be accomplished by underst

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

ALL CALL SREs REQUIRED!  Let’s take a walk down to the ocean and while you consider the opportunity, benefits, and $$$, think about dipping your toe in. Let’s explore Reliability, Site Reliability, and the Site Reliability Engineer .  No doubt the world is evolving. People are evolving and tech is evolving. Business and customer requirements are evolving. The evolution of systems requires the evolution of engineers. Nature and pandemics put undue stress on our resources! In comes the Certified Site Reliability Engineer .  "Urgent, Urgent, Urgent… All hands on deck!",  is a call that practitioners, managers, and organizations do not want to hear and recognize must stop! Reliability – At a minimum, we recognize that the delivery of service is not dependent solely on the quality of the product itself and the goal is not that the products or service merely be deployed. A service must be operated and sustained over a period. How long? For the life of the service.

We saw in a recent blog from “The Professor” how cybercriminals could create a network of controlled computers to propagate a “BotNet”.   One of the malicious reasons for these powerful networks of control is so that the hacker can perform “Distributed Network Attacks” (DDA’s). We all have experienced this at some level and the outcome is not good for enterprise, corporations, or businesses of any size.  DDA’s create disruption even to our own home operations.   A DDA is sometimes referred to as a Distributed Denial of Service or DDOS attack.  This virus or network of virus’s attacks behind the scenes to take over system resources.  A DDOS could attack switches, hubs, routers. It sometimes will flood the network backbone with nuisance transactions with the intention of sucking up all the bandwidth that might otherwise be necessary for day to day operations. DDOS can bring to a screeching halt the web sites for processing claims, or even shopping cart interfaces for the purchasing o

I always hear people say ‘Don’t like the weather, wait an hour it will change’.  The one constant in our lives is change. In business today, customers, users and stakeholders all have the expectation that as IT service providers we can and should be able to handle change requests at an ever-increasing pace.  Yet they still have the expectation that an appropriate response to all requests for change entails a considered approach to assessment of risk and business continuity, change impact, resource requirements, change authorization and especially to the realizable business benefit. For us to be able to do change management in an Agile environment, does that mean we must give up those requirements for speed and agility? The purpose of Change Management is to control the life cycle of all changes enabling beneficial changes to be made.  I was once told by a very wise thought leader ‘Being agile is a state of mind.  It’s more perspective than prescription.’  Why can’t we have a

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

The systems, the processes, and the culture that worked for IT service providers 20 years ago will not work in today’s environment.  No big news here!  Most IT support staff will agree. The truth is that the same could be said for systems or methods that service providers used five years ago or even last year.  The dynamic and rapid change of business requirements demands that a service provider be dynamic and continuously adapt to evolving business needs and outcomes. When you get into your car and turn the key or push the start button, most would expect that the car is going to start.  You might also expect that it has wheels, an engine, and all the elements necessary to drive this car, right?   This is the same expectation that a business operation expects.  When a service is provided the business expects that service is going to have all the working elements to ensure that it does what they need. The customer expects that the service is available and secure for day to day oper

The “Best of the Professor” blogs focus on one unique individual topic and will be followed by links to papers with more in depth information. DevOps initiatives are supported by three basic principles. In his book “ The Phoenix Project “, Gene Kim  leverages the Theory of Constraints and the knowledge learned in production environments to describe the underlying principles of the DevOps movement in three ways. These principals are referred to as The First Way, The Second Way and the Third Way.    In earlier papers from the “Best of the Professor” we discussed  the “First Way” and how this DevOps principle was all about the flow of work from Left to Right.  We then discussed the “Second Way which was all about the flow of work from right to left and how critical that is for measuring DevOps value.  In this iteration from “The Best of the Professor“, the focus will be on the last of these three DevOps Principles known as “The Third Way”. The Third Way – Continual Experimentati

Every organization that delivers products or services will need to shift their ideas for how they plan, build, test and deploy a service that is resilient and for one that truly delivers value for both customers and the internal business.  Continuous Integration, Continuous Delivery, and Continuous deployment are all supported by Continuous testing.    Continuous anything will not be assured of success without Continuous Testing.   Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate. Shifting left ensures that the test takes place early, up front in the pipeline of delivery, NOT after the development.  Testing after development is too late because then we do not have the time, money or resources available to re-engineer, re-design or to re-develop appropriately.   When we test after the development of an application the best we can do wit

Originally Published on the DevOps Institute Site One of the most interesting trends in DevOps adoption is the evolution of the IT silo into the cross-skilled squad. This is not just a semantical name change. Most IT teams today are comprised of like-skilled individuals such as a Scrum team of developers. The modern squad takes a slightly different approach, is more static than dynamic and is more product-focused than project based. Squads are built around T-shaped professionals –where each member has a specialty competency, but all members have a broad scope of skills across multiple disciplines. A high performing squad essentially has all of the skills needed for the product or feature to which it is assigned and is not generally constrained by the availability of an individual resource. There is enough breadth of knowledge inside and outside the squad to shift more activities to the left so as to allow them to move more quickly and with more agility. While the squad model ori