Today technology has been integrated into almost every aspect of business and continues to grow in importance with every new innovation. It is impacting organizational structures, business processes, how and what products and services we offer to our customers.  This tidal wave of change is increasing in complexity and velocity.  These dynamics are shaping the strategies we must employ to manage our IT environments. Given the changes that are happening in the digital world today, support organizations have had to look at how to enhance and speed up the traditional waterfall approach to management of our IT infrastructures.  ITIL and Agile are not contradictory of each other.   Agile development provides opportunities to assess the direction of a project throughout its development lifecycle.  It is a methodology on how to deliver projects , that is iterative, adaptive and an incremental approach to project management which can be used for almost any type of project. ITIL   is

Underlying and supporting the  Agile Manifesto  are the twelve principles that help to bring the Agile philosophy to life. The DevOps movement encourages us to adopt and adapt these principles into the ITIL lifecycle not to reinvent it, but to allow us to make it spin faster.  Let’s take a look at them individually and interpret them from an ITIL, operational and support perspective. Our highest priority is to satisfy the customer.   We do this through early and continuous delivery of the proper utility & warranty. Welcome changes, even late in development, by using well defined and nimble change, release and deployment management, teams and models, allowing our customers to remain competitive in their given market spaces. Deliver updated working services frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. OK that one I modified a bit. We’ll   be Agile about it. Business people and IT must work together daily and collaborate

Service Asset & Configuration Management (SACM) is the one process that touches all of the other ITIL processes. SACM’s purpose is to deliver accurate and up-to-date data and information to every other process across the lifecycle.  The fascinating fact about SACM is that in many cases it depends on those other processes through their defined, documented and agreed to activities, to insure that the data and information about those assets is up to date, accurate and properly recorded through the Configuration Management System (CMS),  No organization can be truly efficient and effective without having a configuration management process to insure we understand how and where that infrastructure, application, tools, documentation and sometimes even people are being utilized in delivering business outcomes and creating value. SACM ensures that CIs (configuration items) are properly identified; baselined and that changes made to them are properly controlled and recorded.  This

DevOps is a cultural and professional movement that stresses communication, collaboration, and integration between software developers and IT operations professionals. DevOps responds to the demands of application and business unit stakeholders for an increased rate of production software releases. Driven by the adoption of agile development processes by IT development organizations, DevOps aims to help organizations rapidly produce quality software products and services. Although the “Ops” in DevOps is often viewed as the technical and application management professionals that deploy and manage applications and their associated infrastructure (e.g., application servers, web servers, and database servers), the service desk supports the goals of DevOps in a number of ways. A goal of DevOps is to produce more frequent software releases. This means the service desk must be prepared to handle a faster rate of change. One way to ensure the service desk is prepared is to engage the serv

As most of us are already aware, the business of IT has become even more critical in ensuring the overall success of an organization.  In today’s fast pace and fluid environments the statement that “every business decision triggers and IT event” is becoming increasingly true for those of us who operate in the world of ITSM. One of the most valuable tools that we can employ is our service catalog.  In a mature ITIL organization we can have two views of this catalog. The first being the Business/Customer catalog where we connect our customers/users to the standard IT services that we offer, deliver and support.  The second view is the Technical/Supporting service catalog, which when appropriately maintained is a very powerful tool that allows us to relate IT services to our supporting services and the underlying supporting infrastructure.  It is this second view that we will review here. Our service catalog provides us with a central source of information on all of the IT servi

Originally published on DevOps.com , written by Jayne Groll , CEO of DevOps Institute For over a decade, ITIL has been the leading ITSM framework adopted by enterprises across the globe. So, what is driving a rapidly increasing interest in Site Reliability Engineering (SRE) as a service management alternative? In its own words, Google refers to SRE as its approach to service management: “The SRE team is responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response and capacity planning.” In traditional ITSM terms, the role of the SRE is responsible for service level, change, availability, event, incident, problem, capacity, performance, infrastructure and platform management. While the operational practice areas may be similar, there are significant differences in how the practices are approached. ITIL4 Framework Compared to SRE Released in 2019, the newest update to ITIL4 remains a complex governance model with four dimensi

The Professor has kindly lent me his blog to share the latest ITIL Library update - Jayne It was recently announced that the 2011 Edition of the ITIL Core Library will publish on July 29, 2011. Notice that I did not refer to the new release with a new version number - and with good reason. All future revisions to the ITIL publications will be referenced by the year that it was published. ITIL will finally just be ITIL. If you regard the 2011 ITIL update as the equivalent to the revision of a college textbook, you'll understand why this is not a big deal. Academic textbooks are revised on a regular schedule without much fanfare or impact on prior or future students. Past attendees do not retake their final exams or replace their textbook. Just a normal course of continual improvement. Do you base your decision on whether to take a college course on the edition of the textbook being used?  Not really.  What's important is the relevancy of the topic.    The 2011 ITIL Edit

Assigning clearly defined roles and responsibilities are critical to the success of every process. These roles need to be defined early and reviewed periodically to ensure proper training, communication and education.  A process without clearly defined roles will fail at some level.   There is a very clear distinction in the activities or the roles that are played out by individuals in your organization.  You should determine and communicate who is accountable and who is responsible for the process activities.  A role is like a hat.  One individual could wear two or more hats.  Watch out for titles.  You might have a title such as Service Transition Manager.  What role(s) would this individual fulfill? It all depends on WHO is best suited for the role or task that needs to be performed when it comes to assigning roles. The Service Transition Manager could be accountable or OWN the “Release and Deployment” process but might also be a practitioner and be responsible to perform task

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

Stronger alignment between IT and the business: Historically IT has not been a participant in helping to create business strategies, it was normally in the role of supporting them. Recently, with the speed of innovation impacting businesses position in the marketplace, IT has been playing a greater role in helping to develop that business strategy. The ITIL framework enables IT to act as a service provider and become a core and more strategic part of the business. Pre-defined processes and best practices from the ITIL framework enable businesses to react quickly to today's rapidly changing technology landscape, focus on innovation and ultimately keep customers satisfied. Improved service delivery and customer satisfaction: Event, incident and problem management processes included within the ITIL framework enable businesses to review performance, perform root cause analysis, resolve issues and through problem management, prevent future incidents from occurring and allows us an

Most of us are aware that Agile can be used to improve the effectiveness and efficiency needed for software development.  Agile core values and principles are defined in the Agile Manifesto . But wait!  There is more! While there are many techniques, methods and frameworks that can be utilized to ensure agility within your organization, what is important to note is that they can and should be expanded beyond software development.   Agile Values are realized via many different techniques and methods including: Continuous integration - A software development practice where: Members of a team code separately but integrate their work at least daily Each integration goes through an automated build and test to detect errors and defects The team collectively builds the software faster with less risk Continuous delivery - Continuous delivery does not infer that you are deploying every day or every hour. It means that you COULD release when needed.  It is a softwar

Stronger alignment between IT and the business: Historically IT has not been a participant in helping to create business strategies, it was normally in the role of supporting them. Recently, with the speed of innovation impacting businesses position in the marketplace, IT has been playing a greater role in helping to develop that business strategy. The ITIL framework enables IT to act as a service provider and become a core and more strategic part of the business. Pre-defined processes and best practices from the ITIL framework enable businesses to react quickly to today's rapidly changing technology landscape, focus on innovation and ultimately keep customers satisfied. Improved service delivery and customer satisfaction: Event, incident and problem management processes included within the ITIL framework enable businesses to review performance, perform root cause analysis, resolve issues and through problem management, prevent future incidents from occurring and allows us

A Continuous Delivery Architect (CDA) is a tool-agnostic individual engaged in the design, implementation and management of DevOps deployment pipelines and tool chains that support Continuous Integration, Continuous Delivery, Continuous Testing and, potentially, Continuous Deployment. A continuous delivery architect is also involved in defining or integrating underpinning processes, metrics, APIs and cultural considerations. Getting CDA certified prepares any IT professional engaged in the Continuous Delivery value stream . Not only will they know what to expect but could save a lot of time, money and effort to expedite the systems required to deliver. While earning a CDA Certification is a great compliment to the DevOps Foundation Certification , you might also find that it can help boost your career or prepare you for very needed positions coming up. The information and perspectives that one gains from shared experiences and class discussions is invaluable. Sometimes it is just a

The question about how to manage virtualization and configuration items pertaining to the Cloud continues to challenge service management practitioners and managers who are trying to strategize and architect a working solution to provision business services.  Some would say the idea of the CMDB (Configuration Management Database) is dead because we use the infamous “Cloud”. Let’s start with a refresher about the structure and purpose of a CMDB and system and then move into how that relates to the management of virtual Configuration Items or Cloud services. Configuration Management System The key to a CMDB, or the sets of data that comprise your broader Configuration Management System (CMS), is “Relationships”.  When provisioning a service, the service provider must be able to manage and control all of the items necessary to produce “Value” to the consumer.  All elements in the end to end service that need to be managed and controlled are referred to as a Configuration Item

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 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 engineer

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 products

The Age  of Architecture   Architecture is one of those universal roles that no matter the job, it's critical you have a good understanding of the architecture to be successful in both development and operations. As with any architectural role, there are so many moving parts that if you can’t see the machine for the cog you’ll never be able to master your craft. The problem seems that because of the siloed nature of the business, no one but those in architecture gets the lay of the land, it is in this challenge that continuous Delivery Architecture was created to help ALL practitioners understand not only the big picture but the why and how every component is vital to success. What’s In The Toolbox To help you get an idea of the sheer quantity of tools that will be at your disposal I’ll give you the highlights reel. It starts with what we call a collective body of knowledge. This is a collection of materials (books, blogs, websites, etc.) to help you on your journey to lear

We continue our "Best of " blog series by moving into Service Operation.   Cost per Incident Originally Published on August 17, 2010 A reader, upon downloading our ITIL ROI calculator , recently asked the following great question, “how do you determine cost per incident?” Cost per incident is a variation of cost per call or cost per contact, all of which are excellent ways to understand the impact of incidents, calls, or contacts on the business. The calculation is fairly straightforward. Cost per incident is the total cost of operating your support organization divided by the total number of incidents for a given period (typically a month). Cost per incident = total costs/total incidents To accurately calculate cost per incident you must: Log all incidents. You may also find it beneficial to distinguish between incidents (unplanned events) and service requests (planned events). Such a distinction will enable you to more accurately reflect business impact

To survive in today’s competitive business climate organization’s must respond quickly  to their customers’ evolving needs and desires.   How many times have you heard that? We know from experience that an agile culture where agility is gained through people, process and tools can enable organizations to gain market share and competitive advantage.   And still, more organizations than not silo agile principles to software and product development. Ever wonder why, as an industry, we are not getting the types of returns that are expected from our efforts? Agile software development alone will not get us there!  Other factors include: Ability to quickly respond to customer feedback and needs – Customer engagement. An understanding that the customer and business requirements are dynamic and that we must have agile processes in place to respond to them. (Not only agile development) Sustained innovation and speed from idea to end of life for the service and processes. Incre