DevOps is a culture, movement or practice that emphasizes the collaboration and communication of both   software developers   and other   information-technology   (IT) professionals while automating the process of software delivery and infrastructure changes.   It aims at establishing a culture and environment where building,   testing , and releasing software can happen rapidly, frequently, and more reliably. It’s about improving, communicating and collaboration.  From a Service Operation perspective we are already part of the way there, so maybe it won’t take as long or require as much organizational change as we think. Application management is responsible for managing applications throughout their lifecycle.  Application management covers the entire ongoing lifecycle of an application, including requirements, design, build, deploy, operate and optimize.   The application management function is performed by any department, group or team involved in managing and supporting opera

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

In a recent DevOps Foundation Certification class one IT executive said “You can not automate Chaos”! Another learner spoke up and said “Yes you can… that is what we are doing”!   Although that was meant as a LOL moment, it is true that when it comes to velocity and improving cadence all too often service providers jump the gun and look at automation as the silver bullet.  While recognizing that tools, technology and automation are key elements, process and governance must also be considered. Automating before we get management control of these is likely to lead to bigger and faster CHAOS! Executive buy in and support is rewarded when the business and IT are integrated to the point that IT alignment with the business is a given.  Properly designed and well governed process will enable any automation initiative.  Remember we are talking about “Just enough process” and “Just enough governance”.  If your process is the roadblock then you might have created exactly what you are t

In his recent blog ‘ Devops Areas - Codifying devops practices ’ Patrick Debois explains that DevOps activities typically fall into four patterns or areas.   DevOps activities typically fall into four patterns or areas. In each of these areas best practice dictates that there will be a bi-directional interaction between Dev and Ops, which will result in a fluid knowledge exchange and feedback from each of the major stakeholders, including Development, Test, Product Management and IT Operations.   In the 1st area we extend delivery to production. This is where Dev and Ops will collaborate to improve anything on delivering a project to production by creating or extending the continuous integration, deployment and release processes from Dev into Ops. Activities here include making sure environments are available to Dev as early as possible. That Dev & Ops build the code and environments at the same time. Create a common Dev and production environment process while ensuri

Infrastructure as Code – is a common term among developers, architects, and operational staff and the practice has evolved in response to demand for quality and efficiency in the industry.  Over the last decade many organizations have come to realize that the essence of Infrastructure as Code is to treat the configuration of systems the same way that software source code is treated.  Frequent code integration, automated builds, and integrated testing have resulted in stronger IT performance and therefore business value. Security as Code – An increase in security breaches across all industries has brought forward a similar concept, and that is to look at “Security as Code”.  This concept would include the usage of repeatable algorithms to integrate security checks with each code check.  This expands the scope of traditional “Continuous Integration” and automation.  Organizations realize that security is no longer a second thought and must be addressed at the front of the value s

User stories are one of the primary development artifacts for Scrum teams.  They are a short description of the feature as told from the perspective of the person (stakeholder) who desired some new capability from a current service, system or application.  Many Scrum teams have adopted the user story template developed by Mike Cohn, which identified who the end user is, what the end user wants and why in a single sentence.  This template is most often written like this:  "As a (type of user), I want (some goal) so that (some reason)."  Example: As an Incident Process Owner, I want to see a release of known errors in order to do appropriate service desk staff training. In this way team members are encouraged to think of their work from the perspective of who will use it, ensuring requirements get met and value is delivered.  User stories are narrative texts that describe an interaction of the user and the service.  It focuses on the value that a user gains from utilizin