Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DevOps and the IT Consumer

When you jump off the hype curve, DevOps is neither "about" engineering nor "about" operations. At least not the way you think. And it doesn't fight with ITIL, either. What it's really about is...

  • Login to see the comments

DevOps and the IT Consumer

  1. 1. DevOps and the I.T. Consumer An Archestra Notebook
  2. 2. The rush to DevOps Glory would not be nearly as interesting if 9 out of 10 companies were not already intent on doing it. There are even entire vendor organizations that have repositioned in the market to be DevOps vendors. This is further interesting, however, because not more than 3 out of 10 companies agree on what DevOps is. To be fair, there is a lot of overlap of their ideas, which should be expected because everyone is looking for a practical consensus on how to recognize it when they see it. This effort is neither more nor less easy than similar previous efforts to deal with such things as “innovation”, “agile”, and “configuration items”. There will be lingering concerns about what is, at minimum, necessary to “actually have it” or to “do it right”... The agreement may resolve itself, mainly by avoiding brute-force insistence on specific tools, procedures, or metrics – all of which are simply “means”.
  3. 3. While we’re waiting for the calm to set in, the surprising and useful realization should be that DevOps is neither “about” generic Development nor generic “Ops”. Instead, it is about objectives to be addressed by both where neither can address them successfully alone. The single most important objective has to do with solving the problem of things not working correctly under high stress of demand, diversity, or change. In other words, the objective is Supportability, and the problem is how to maximize it.
  4. 4. Problem Type Definition DESIGN PRODUCTION PROVISION USAGE DEFECTS Includes damaged or incorrect parts Resources Building Configuring Packaging OMISSIONS Excludes necessary parts Requirements Modeling Versioning Access ERRORS Performs incorrect function for circumstance Logic Method Process Operation If defects, omissions and errors were not possible or not present, there would be no need for Support. Meanwhile, the gap between “properly designed for the use” and “properly used as designed” is predictably why most support issues originate. Support requires recognizing how and where the gap materializes, so that it can be eliminated at least in the heat of the moment -- but more importantly in advance, by preventing it. Prevention techniques range widely, including knowledge, detection, user interfaces, policies and more, as employed by responsible parties. PROBLEM CONSEQUENCES Detrimental effects and outcomes Insufficient fit to the demand for the purpose Low-to-No effectiveness Inherent probability of the risk of failure Costly need for abandonment Systemic probability of the risk of failure Cost of recovery or replacement Unanticipated inadequacy Lost opportunity and/or danger ©2015MalcolmRyder/ArchestraResearch
  5. 5. PREFERRED EXPECTED ACTUAL Priorities Competency Rules Responsibilities versus Choice: Across the full lifecycle of a service, each and every stage can experience tensions and variability between what is preferred, expected, and actual. The selection, generation, acquisition, provision and utilization of a service are all now evolving; technology allows consumerization, BYOD, and alternative IT portfolios to concentrate a far greater percentage of operational focus on the user’s management of the service lifecycle. Managing the users’ management becomes a key issue to business stakeholders in organizational performance. In the overall organization, functional responsibilities and instruments for implementing rules, competency and priorities may be organizationally distributed but not allowed to be logically misplaced. These measures create the effective supportability of the service. Selection Generation Acquisition Provision Utilization Social Xaas Consumerized BYOD Self-service ©2015 Malcolm Ryder / Archestra Research
  6. 6. Responsibilities: End User (service utilization) Provider (service level) Supplier (service class) Rules Compliance Monitoring Warranty Competency Skill Continuity Functionality Priorities Security Availability Capacity Supportability method: Consumerized Self-enablement Catalog management DevOps “Service” is itself a type of product, which has managed support. Users, providers and suppliers have different responsibilities, and have different methods, for addressing and achieving supportability of the service. Supportability of a service involves assuring the persistence of three things: the intended effectiveness at the initial usage, the resilience of the service’s utility within changing conditions, and the orderliness of its own status transitions or evolution. The primary value created by this is not “innovation” or “agility”; rather, it is “robustness” for ongoing consumption. ©2015MalcolmRyder/ArchestraResearch
  7. 7. SERVICE DESIGN MODEL ACCESS TERMS AVAILABILITY REQUIREMENTS OPERATIONS PLAN CONFIGURATION SPECS ARCHITECTURE ENVIRONMENT CONSTRAINTS PLATFORM & OPERABILITY CHANNEL & DELIVERABILITY release approve procure ordercontrol deploy offerinstall resourcebuild USE CASE SOURCING DEVELOPMENT The variables in the design of a service identify types of specifications that define an implementation, logically enabling recognition and support of the service. The design model is vertically hierarchical (top-down) and laterally directional (left-right). The platform and the channel are independent of each other but related. A knowledge base of the service design model (SDMK) associates CMDBs and capabilities with asset repositories and Catalogs. The selection and acquisition of service by individuals or organizations is flexible according to the specifications that can be supported. Standards may exist for a service type’s specifications, within narrow or broad tolerances. The providers of support allow the flexibility to be feasible. DevOps presumes the availability of a Service Design Model to guide collaborative and automated supportability. ©2015MalcolmRyder/ArchestraResearch
  8. 8. The most undesirable condition that DevOps is asked to address is the case where rigidity displaces robustness and frustrates the ability to adapt proficiently to changing business conditions. Rigidity can occur in the mechanism that supplies service, in the functional tolerances of the service, and in the scope of effectiveness of the service. DevOps is expected to manage through and away from rigidity. The service design model is both a guide and a diagnostic for determining the level and location of alternatives that can offer timely adaptation with low risk. That then amplifies the difference between two kinds of assurance to users: the value of relying on services for productivity, versus the value that a reliable service can offer to users. It becomes clear that the primary user perspective on support is assurance.
  9. 9. Users have increasingly shown that they prioritize the ability to rely on services more highly than they do the reliability of a given service. This is reflected in their quick migration to other services based on capability instead of on quality. Subsequently it is reflected in the pressure on a provider to quickly extend quality into new capabilities. As a result, the business development of a portfolio of services becomes the true nature of “Dev” in DevOps while continual alignment of service availability to current needs is the true nature of “Ops”, most visible in a catalog of services.
  10. 10. ©2015 Malcolm Ryder / Archestra Research