Tag: itil

  • DevOps: Achieving Process Without Too Much ‘Process’

    DevOps: Achieving Process Without Too Much ‘Process’

    While there’s no fundamental conflict between IT service management (ITSM) and DevOps, DevOps does bring new and different techniques for getting work done and interacting with the rest of the organization.

    ITSM people who are used to frameworks such as ITIL and COBIT tend to regard the IT department as a “service provider” and the rest of the organization as “the customer.” But DevOps has come from web-scale organizations “where IT is the business,” and that means the prevailing view is more like the Toyota Production System mentality, wherein the aim is to move things along a production line with maximum speed and maximum quality, says Matt Hooper, product evangelist at LANDESK.

    DevOps thus has already broken down some of the barriers between “IT” and “business”—practitioners realize they have to determine what the business needs, and then provide it. But Agile or Agile-like practices also are part of this approach, so there’s lots of experimentation, learning and redeployment in “lots of tiny little steps,” and, consequently, there’s not much risk of going very far wrong with any of them.

    An issue is that this conflicts with ITSM’s view of life cycles, partly because the whole idea is to merge development and operations—for instance, by automatically spinning up software-defined infrastructure as needed.

    What’s needed, Hooper suggests, is “service management with a digital mindset” rather than ITIL’s “human mindset.” It’s all about feedback, he says, but for ITSM and DevOps to sit comfortably together there must be a realization that feedback can come from humans or systems.

    And even though the command and control mindset tried to avoid failures, systems still failed. So a better approach is to accept that “stuff breaks” and make small changes at a time, respond to issues as they arise and keep learning. In the longer term, this will lead to more durable systems, he says.

    It’s a myth that you’ll be able to stop bad things happening, because people and systems aren’t perfect. DevOps, in contrast, accepts that things will go wrong but aims to respond quickly—for example, by keeping developers close to operations so they can see problems occurring, realize what mistakes they made, and put them right.

    “That’s challenging to a traditional ITSM person,” Hooper says. It is important to accept that failure is an option, even though massive failure isn’t.

    (Before you ask, he accepts that certain systems need to be extremely reliable. But others provide room for a somewhat experimental approach, in which case DevOps helps avoid overengineering.)

    While some ITIL practitioners see value in DevOps’ continuous deployment approach, their premise is still that IT is a “service provider” rather than a “partner,” but the business side of the organization wants the latter. You don’t get home from a business trip and tell your spouse you were 99.98 percent faithful while you were away, he observes, and that sort of SLA-based thinking works against becoming a learning organization, achieving good demand management and so on.

    ITIL v2 served a good purpose, but ITIL v3 arrived too late, Hooper suggests. The growing influence of the Lean movement means systems are going through rapid change cycles, and too much “process” leads to waste and lower performance. DevOps and software-defined technologies provide ways to better handle rapid change—infrastructure can be spun up and back down in seconds, providing opportunities for self-healing systems with better scalability and reliability.

    Where ITIL focuses on meetings and human processes, DevOps prefers to use analytics to determine the right time to release and then whether then release was successful. “The feedback loop is an essential part of DevOps strategy,” just as it is with ITIL, but ITIL has a more human-centric idea of feedback.

    “ITSMers tend to hide in the back closet” waiting for the business to tell them what to do, but DevOps takes a more active approach, he suggests.

  • REP SPOTLIGHT: Soft2Solve

    REP SPOTLIGHT: Soft2Solve

    DevOps Institute: Tell us a little about your organization,

    Soft2Solve: We work with our customers in order to help them to enhance IT performance, saving cost, and training on best methods, process and practices, selecting at the same time the best solutions for Spanish Speaker Customers.

    DevOps Institute: What other topics do you teach or consult on?

    Soft2Solve: Cost savings in some specific areas as printing, energy.

    DevOps Institute: What type of interest in DevOps are you seeing in your region?

    Soft2Solve: The interest is initial. Most of customer are aware of DevOps initiatives, but they are still learning and looking how movement evolves and how they can set up the practices on their companies. Some of them already started with agile methodologies in development.

    In the other side, most of them already have ITSM practices implemented, based mainly in ITIL.

    DevOps Institute: How do you think that DevOps contributes to the business’ value stream?

    Soft2Solve: First, aligning IT with the business requirements in terms of speed, flexibility and agility. Then it contributes to analyze the bad processes in place and getting high cost savings when implementing DevOps practices. It also enhances the internal relationships between IT departments, as usually there is a big fight between them. Also, that impact on quality and speed to answer the business.

    DevOps Institute: What topic area in DevOps excites you the most?

    Soft2Solve: It is an IT answer to the business requirements to follow the business needs; meanwhile, being more productive and less expensive. In other areas, the automatization is a base for DevOps.

    DevOps Institute: Why should enterprises and individuals consider formal DevOps Training?

    Soft2Solve: Although sometimes the organizations do not know, any new change—especially culture changes—need internal sponsors as much as possible in the organizations. These people have to be trained by third-party independent people outside their organizations that are aseptic and not influenced from the internal existing culture and way of doing. These people will be the people that will support the change and the IT alignment with the business organization and will answer quickly to business requirements.

  • REP SPOTLIGHT: getITright

    REP SPOTLIGHT: getITright

    DevOps Institute: Tell us a little about your organization.

    getITright: With offices in Australia, South Africa, The Netherlands, Nigeria and Malta and a network of partners operating in 31 countries, we offer a bouquet of services to help organizations to:

    • Manage better
    • Lower risk
    • Perform better
    • Make better business and IT decisions

    Our service offering includes:

    • Training courses – Learning best-practice through our Partner Academy courses or network of training providers
    • Accredited IT Best practice course material – License our training material
    • Consulting – We use an agile approach for projects and a lean approach for operations when consulting and coaching.

    DevOps Institute: What other topics do you teach or consult on?

    getITright:

    • Service Management: ITIL®, ISO/IEC20000, Lean IT, Service Desk Institute
    • Governance of Enterprise IT: COBIT® 5
    • Project Management: PRINCE2®, PRINCE2® Agile, DSDM AgilePM®, Scrum
    • Information & Cyber Security Management: ISO/IEC27001, NIST Cybersecurity using COBIT5
    • Quality Management & Business Improvement: ISO9001, LEAN SIX-SIGMA
    • Risk & Continuity Management: ISO31000, ISO/IEC27005, ISO22301
    • Cloud Computing

    DevOps Institute: What type of interest in DevOps are you seeing in your region?

    getITright: DevOps awareness in the region is still low, but we see a steady increase in the level of interest in the topic.

    DevOps Institute: How do you think that DevOps contributes to the business’ value stream?

    getITright: It makes projects and business as usual faster, more stable, with less risk.

    DevOps Institute: What topic area in DevOps excites you the most?

    getITright: DevOps enables organizations to improve productivity and respond to change with less risk. It’s easy to adopt by organizations with mature ITSM practices in place.

    DevOps Institute: Why should enterprises and individuals consider formal DevOps training?

    getITright: Training ensures that all resources in the organization are in sync when implementing new practices like DevOps in an organization and ensures a cohesive approach that facilitates proper organizational buy-in and adoption.

  • REP SPOTLIGHT: Omnikron

    REP SPOTLIGHT: Omnikron

    DevOps Institute: Tell us a little about your organization.

    Omnikron: With over 30 years of industry experience, we have honed IT and project management training techniques to ensure that course material caters to our clients’ needs. Our training is not just lectures from a book. We offer world-class courses, assessments and simulations in a variety of formats and at various paces. As the workplace has changed in the 21st century, so has the training approach here at Omnikron.

    DevOps Institute: What other topics do you teach or consult on?

    Omnikron: Omnikron’s most popular training includes ITIL, PMP, TOGAF9, Change Management, DevOps, Security & Security Awareness and Cloud.

    DevOps Institute: What type of interest in DevOps are you seeing in your region?

    Omnikron: There is a lot of talk about DevOps and our classes are slowly but surely increasing in size. Hopefully by the end of the year, we will have a packed house for our classes.

    DevOps Institute: How do you think that DevOps contributes to the business’ value stream?

    Omnikron: We have honed in on ITIL for years and DevOps is such an easy transition for most of our students. Not only are the students enjoying the class, but they are able to use their past experience to share stories in class as well as apply what they have learned outside the class.

    DevOps Institute: What topic area in DevOps excites you the most?

    Omnikron: Organization consideration and practices seems to be the favorite among our students. Plenty of dialogue has been given around this particular topic.

    DevOps Institute: Why should enterprises and individuals consider formal DevOps training?

    Omnikron: Because DevOps is designed to help our student continually improve their services to their internal and external customers. Can’t get any better than that!

  • Rep Spotlight: Global Lynx

    Rep Spotlight: Global Lynx

    DevOps Institute: Tell us a little about your organization:

    Global Lynx: Global Lynx is a leading and fast-growing IT consulting and training company that assists companies and government agencies improve the competence and skills of their IT organization, enhance the maturity of their IT governance and improve the quality and effectiveness of their IT operations, services and processes.

    Since 1996, Global Lynx experts have helped organizations in five different countries, improving—and often transforming—their IT operations through the implementation of effective frameworks for IT governance, ITSM (IT services management), PMO (project management office) and information security.

    As an Accredited Training Organization (ATO), Global Lynx also offers a wide variety of IT courseware covering different areas, standards, frameworks and methodologies, and at various levels of expertise.

    Global Lynx trainers are experienced consultants, certified in multiple IT disciplines. They have actual firsthand experience in their areas of IT expertise, as well as experience in delivering training programs.

    DOI: What other topics do you teach or consult on?

    Global Lynx: IT service management, IT corporate governance, IT audit, information security, cyber resilience, IT risk management, cloud computing, project management, SCRUM, business continuity, process design and implementation, and enterprise value creation.

    DOI: What type of interest in DevOps are you seeing in your region?

    Global Lynx: Companies are interested in obtaining a common understanding of DevOps concepts and best practices, and they are focusing on deploying these practices organization-wide.

    DOI: How do you think that DevOps contributes to the business’s value stream?

    Global Lynx: The digital disruption all industries are experiencing, has created the need for IT to be embedded in every single business unit. Solid DevOps practices will help IT organizations deliver higher value to their customers, as value is delivered through operations, but it is defined and enabled in the development stages. Value should be managed not only in operations, but rather from the early stages of the service life cycle. A mature IT organization cannot have a poor collaboration and communication culture; without this, value creation will be limited to technical value instead of real business value.

    DOI: What topic area in DevOps excites you the most?

    Global Lynx: How DevOps interfaces other frameworks and how all of them can work together toward creating value to the customer.

    DOI: Why should enterprises and individuals consider formal DevOps training?

    Global Lynx: DevOps is all about people, and it is enabled by people. If a person is not committed, that person will do little to support the DevOps initiative. People need to go through formal DevOps training to learn what DevOps is, and how their role impacts the initiative and how they contribute to value creation. Certification is a plus, as it gives people a personal benefit. People will naturally react positively to something they own, because they will believe in it.

  • What is a DevOps ‘Best Practice’?

    What is a DevOps ‘Best Practice’?

    In IT, we love our frameworks. Whether agile, ITIL, lean, cobit, six sigma or others, our thirst for “best practice” guidance seems to be unquenchable.

    The concept of a “best practice” is an enigma. Who decides if a practice is actually the best? And best for whom? While an “adopt and adapt” mentality is advocated in most frameworks, there is still a tendency to benchmark efforts against and conform to published best practices. Whether promoting “best in breed,” “world-class,” or “best practices,” many organizations swing these terms around as some form of competitive advantage.

    Is it really? Shouldn’t business outcomes be the real competitive advantage and measure whether IT’s practices are really the “best” to meet customer requirements?

    The DevOps Institute was founded in 2015 as a global learning community for emerging DevOps practices. Since our launch, we have intentionally avoided any reference to DevOps “best practices.”

    We believe that DevOps practices are constantly emerging and, in many cases, being proven in the wild.

    Through research, interviews, conferences and the experience of our Regents and partners, DOI’s goal is to identify, capture and share emerging DevOps practices through knowledge, education and certification models that best serve the learning community and enterprise IT. We feel it is premature to certify an individual as an “Expert” or “Master” when the expertise and mastery needed for successful DevOps is not clear and may not be appropriate in a single person.

    DevOps is fairly young. It does not have a single body of knowledge. There is disagreement on whether it is a philosophy, movement or framework. Despite that, DevOps is crossing the chasm from innovators to the early majority faster than any other IT framework. Why? Perhaps it is because DevOps speaks to many of the cultural and technical challenges that IT has been amassing for years.

    So instead of focusing on best practices, let’s agree on DevOps’ core principles:

    • Go faster
    • Shorten feedback loops
    • Experiment and learn
    • Cultural transformation
    • Deliver business and customer value constantly and consistently

    No doubt, some practices have clearly risen as being critical to the realization of DevOps’ core principles:

    • Agile software development
    • Continuous integration
    • Continuous delivery pipelines
    • Automated and continuous testing
    • Proactive monitoring
    • Improved communication and collaboration

    Still, over the past year, DOI has seen additional practices gain interest

    • DevSecOps/rugged DevOps
    • ChatOps
    • Agile service management
    • Lean
    • Immersion practices (Garage, Lofts, Dojos)
    • DevOps teams

    What will emerge next year? Who knows—but that’s the exciting part of DevOps. As time passes, there is less contradiction and more supplementation. Each emerging practice seems to complement and fine tune what came before.

    Even without a standard definition, DevOps is already encouraging organizations to examine their proprietary practices, identify gaps, assess their automation and, most importantly, engage in collaborative discussions. Transformations have taken seed without defined best practices. That’s awesome! Let’s not quell the momentum by attaching a static set of best practices.

    Will DevOps’ best practices eventually be agreed? Maybe. DevOps touches almost every aspect of IT management—people, practices and automation. That’s a tall order for a set best practices. Certainly some will try to publish their version of a “definitive” DevOps body of knowledge. Even “The DevOps Handbook,” an important book publishing later this year, was built as a collaborative effort between many of the early founders of the DevOps movement. Their perspective and insight will be awesome but not finite.

    I understand the frustration by the lack of a single body of knowledge and prescribed best practices. In past frameworks, the body of knowledge was both a enabling tool and constraining limitation. Bodies of knowledge are difficult to keep current. For DevOps, let’s embrace the concepts of spirit of sharing, collaboration and continuous innovation by promoting an inclusive and collective body of knowledge of emerging practices.

    If we settle on a set of DevOps best practices, are we actually inhibiting the very values that we are trying to instill? I hope not.

  • DevOps is ITSM Best Practice!

    DevOps is ITSM Best Practice!

    What boggles the mind is that opponents of DevOps use risk as an excuse why DevOps would not work in their environments and why using the “traditional ITSM” approach is better and safer.

    When I start asking them about their transition practices, specifically the alignment between transition, change, test and release models, I soon find that these models are either very skimpy or, most of the time, non-existent.

    So here are the facts: You don’t want to do DevOps because you don’t want to do what ITSM best practice dictates!

    ITSM best practice recommends building and aligning change, test, release, deployment and transition models that clearly define transition/change boundaries, practices, artifacts, acceptance criteria, roles, responsibilities and authorities, making transition practices repeatable, less risky and more reliable.

    Is this not exactly what you need to do in DevOps automation? If you have not built the models and made sure they are tried and tested, you can’t automate them—and if you have built these models and made sure they are tried and tested (repeatable), then why not automate them? It’s a no-brainer.

    The reality is that by using DevOps practices, organizations have far better control and manage risk far better than what opponents and detractors of DevOps have in their non-DevOps environments.

    This may not be best practice, but we have for years recommended that during a post-incident review the following questions should be added to the agenda:

    • Will we do this again? If so,
    • Will we do it in the same way?
    • Can we define an implementation approach based on the change just completed and the lessons learned, and can we reuse this approach safely in future (build change, release and test models)?
    • If we can,
      • Build the models
      • Define this type of change as a standard change

    Some say that this is not best practice, as “standard changes” are low risk. This, in fact, is not true!

    ITIL® defines a standard change as follows (ST 4.2.4.7): “A standard change is a change to a service or other CI for which the approach is pre-authorized by change management, and this approach follows an accepted and established procedure … Every standard change should have a change model that defines the steps to follow … Authorization for each occurrence will be granted by a delegated authority … The crucial elements of a standard change are defined triggers, tasks are well-known, documented and proven, authority is given in advance … The risk is usually low and always well-understood.”

    We have for years argued that standard changes are ideal candidates for automation. By extending the post implementation reviews, you identified safe candidates for DevOps automation!

    About the Author/ Johann Botha

    Johann ProfileJohann Botha is the CEO of getITright, a DevOps Institute Registered Education Provider that will run its first African DevOps course May 23 in Johannesburg. Visit www.get-it-right.com for more info.

  • Does the Future of DevOps Lie in NoOps?

    Does the Future of DevOps Lie in NoOps?

    Why DevOps is more a bi-directional rather than a simple top-down approach

    DevOps is one of those buzzwords that nearly everyone wants to discuss these days. However, it often is interpreted as an extension of Development’s influence to the detriment of Operations teams.

    So much has changed in the past few years that it is conceivable we will see another major shakeup: Could Operations teams disappear altogether? Or to put it another way, is “NoOps” the future of IT? While DevOps promotes faster delivery of new digital services and a blurring of the lines between Dev and Ops, in reality, is Dev consuming Ops entirely?

    Before DevOps was called DevOps, the two disciplines were growing further apart. Agility has been driven by Developers since the turn of the century, with the famous Manifesto for Agile Development. Meanwhile, Operations formalized repositories of good practices into frameworks such as ITIL or COBIT, which were implemented by most large companies in the mid-90s. Those two approaches seem to oppose, as DevOps advocates the acceleration and multiplication of changes and ITIL tends to monitor and control them.

    NoOps, or the End of Operations?

    If you believe everything you read, then Operations is a dying art. But in practice, Development does not want to be involved with infrastructure, while few organizations would trust developers to manage their data centers, whether physical, virtual or cloud. So breathe easy: DevOps does not mean the end of Operations teams.

    On the contrary, Operations remains essential throughout the DevOps approach. Production infrastructure is a complex and delicate stack of technologies, often with a discreet mix of modern architecture and historical applications. It often is impossible for Development to replicate these types of environments. And that is why an application successfully tested in a qualification environment often does not work properly in production. However, it is crucial to validate new developments in a representative replica of the production environment.

    So is DevOps doomed to constant failure because of lack of continuity between qualification platforms and production systems? Well, this is probably the case if we merely consider DevOps as a simple top-down approach from Development to Operations. Focusing on producing changes at a higher frequency only shifts and grows a bottleneck that sits in production, without producing the added value expected by the company. As a consequence, DevOps must also be seen as a bottom-up process. In other words, if we consider DevOps, we must also take very serious look at “OpsDev” (OK, it doesn’t flow off the tongue, but you see my point!).

    DevOps or OpsDev?

    For a successful DevOps approach in practice, Development must position itself as a consumer of turnkey infrastructure environments. Operations then adopts an OpsDev approach and provides infrastructure on demand for all steps of continuous integration, from compilation to qualification, through unit testing.

    If DevOps is a radical change in how Development works, OpsDev would also revolutionizing common Operations practices. It comes with more agile “declarative” infrastructures (described and built from source code), an even more sophisticated level of automation and the ability to provide self-service infrastructure for developers.

    The adoption of DevOps does not mean that Operations will disappear or will be replaced by Development, but rather the emergence of bi-directional agility that needs to be supported by more sophisticated automation. In fact, DevOps implies OpsDev rather than NoOps. Finally, whatever you consider your release process under the ITIL or DevOps angle, isn’t the end goal exactly the same: delivering zero-default service to customers?

  • How ITIL Can Co-Exist With DevOps

    How ITIL Can Co-Exist With DevOps

    The original ITIL framework definition was published in the 1980s, but contrary to many opinions, it has evolved since then, provided one takes a more flexible view.   Fast forward to ITILv3, and the framework has been shifted to the view that IT is a service that needs to support business initiatives and strategy.

    In parallel, the “DevOps Movement” has continued to gain momentum, and is now the “culture” at many forward-thinking organizations.   So, that begs the question, “Can I have my ITIL framework and still transform my IT Org to embrace DevOps?”

    First, as a refresher, let me quickly outline the key components of ITILv3.

    1. Service Strategy — The service lifecycle must stay focused on meeting the business goals and objectives.
    2. Service Design — Architectural blueprint for the service
    3. Service Transition — Outlines the change management and release cycle practices
    4. Service Operation — Focuses on the delivery and control processes for the service
    5. Service Improvement — Focuses on how to continually improve the processes for Service Delivery

    Now let’s lay out an engagement model for the transition of the culture to DevOps.

    1. DevOps Strategy — Establish metrics that outline Business Objectives and Value
    2. DevOps Design —  Establish Capacity, Availability, and Security Best Practices
    3. DevOps Transition — Establish Organizational Structure and Define SLAs
    4. DevOps Operation — Shift to Agile; Programmatic CMDB and Change
    5. DevOps Improvement — Automate Incident, Problem, and Event remediation; Feedback loop

    As you can see, there isn’t a huge gap between the two worlds, and I assert that the main changes are cultural, not technical, but one can use technology to start shifting the culture.

    This is where the concept of a Security Fabric plays an integral role.  Here is an example of how an Enterprise Reference Architecture can be organized to combine the best parts of ITIL and DevOps:

    1. Policy Definition — Allows you to define Users, Groups, Hosts, Layers, and Interdependencies
    2. Secrets Management — Allows you to store Secrets in a vault and access them programmatically in a secure manner with a complete Audit Log
    3. SSH Management — Allows you to securely manage SSH public-keys and session interaction with a complete Audit Log
    4. Host Factory — Allows you to instantiate and register new hosts or containers into your infrastructure
    5. Identity/Service-Defined Authorization– Allows you to control interaction between your hosts or containers via Policy and Gatekeeper

    IT now has a powerful platform to map Business Objectives to Identity, Hosts, and Processes.   Once that mapping is established, previously static and brittle activities such as managing Secrets and SSH public-keys, can be moved into the Continuous Delivery pipeline, which maps directly improving Service Transition, Operation, and Continual Improvement.

    Agility and Scale are programmatically added via various tools, which allows for frictionless and auditable Change requests, as well as rapid response to Incidents, Events, and Problems.

    The diagram below attempts to pictorially show the co-existence of ITIL and DevOps and how the features of a Security Fabric are common between the two.

    Screen Shot 2015-06-25 at 1.37.14 PM

    The shift to a DevOps culture should be approached as a continual evolution.   ITIL was a great starting framework, but over time added too much structure and rigidity.   You can leverage the Best Practices of DevOps to overcome that and transform into an extremely agile and productive environment.

    About the Author/Mike Kail

    mike_kailMike Kail was Yahoo’s CIO and SVP of Infrastructure, where he led the IT and Data Center functions for the company. He has more than 24 years of IT Operations experience with a focus on highly scalable architectures, prior to joining Yahoo. Most recently, Kail served as VP of IT Operations at Netflix. Prior to that, he was VP of IT Operations at Attensity, where he was responsible for the Americas data center operations team; including managing various big data systems with their Hadoop cluster, HBase, and MongoDB components. He has been recognized widely for his insightful industry commentary on Twitter, and was recently named by the Huffington Post as one of the “Top 100 Most Social CIOs on Twitter.” He holds a B.S. in Computer Science from Iowa State University. Reach out to him on Twitter or LinkedIn.

  • DevOps Perspectives from Pink15

    DevOps Perspectives from Pink15

    I recently had the privilege of covering the Pink15 conference on behalf of devopsy.kinsta.cloud. Pink Elephant is a renowned leader in ITIL and ITSM education, consulting and conferences. Now in its 19th year, the Pink conference brings together attendees from a wide range of vertical markets to learn and share about IT service management and related topics. My mission was to take the pulse of DevOps in the ITSM enterprise community, many of whom represent the operational side of IT.

    Let me start by saying that this was a well-organized and executed conference. The attendees that I spoke with unanimously agreed that the sessions were relevant and the peer networking invaluable. And while there was not a specific Devops or Agile track, the core concepts were directly or indirectly present in several of the sessions.

    One particularly interesting session was on “Enterprise Change Management in an Agile, Fast Moving World” from a large retail organization. The presenter did a good job of describing how they are adapting their categories of their changes to meet the growing requirements for a more agile change management process. At present, only 5% of changes are categorized as “fast track” – an even more expedited route than what is normally considered a standard change. This organization’s goal is to exponentially increase their ability to fast track more changes in response to increasing demand. This session was a good indicator of how enterprise IT is recognizing the need to adapt for continuous delivery and more automation.

    More than one attendee shared their appreciation at being able to interact with other IT organizations about specific ways to bridge the practices between Dev and Ops so as to make service management more agile. One person mentioned that while some of the sessions did not specifically call out DevOps or Agile, presenters often had to address these in depth during the question and answer period. There was particular interest among attendees in learning how to engage developers in processes such as Event, Demand, Capacity, Availability, Change and Release Management.

    Some attendees expressed concern about the perception that ITSM and ITIL have no place in a DevOps culture or that DevOps would somehow invalidate the investments that many organizations have already made in establishing better processes for managing services. Kaimar Karu, the ITSM Product owner for Axelos (who owns the IP for ITIL) strongly believes that ITIL is absolutely a key player in the realization of DevOps as a philosophy. ITIL processes are not specific to operations – they enable the entire lifecycle of a service or product from development to deployment and into operations. ITIL was meant to be adopted and adapted; nowhere does the guidance recommend that the processes be complex, bureaucratic, lengthy or manual.

    So what does all of this mean? While DevOps is not yet fully understood, organizations are taking tangible steps to make ITSM processes go faster, integrate with other practices and leverage automation in order to deliver more business value. Wouldn’t you call that DevOps?