Devops and ITIL/COBIT all seek to bring about a change in the way IT does business. By their own admission (in their own literature) these are culture changes, not just checklists, or certifications. ITIL and COBIT are both geared towards large organizations with organizational responsibilities, devops works best in smaller groups, and works best in groups with personal (rather than organizational) responsibility.
The framework in devops is laissez faire, "Listen, we need to work together for our mutual benefit, how are we going to solve this problem?" The framework in ITIL/COBIT is structured, "Our Service document, claim that we have a 5 minute SLA for these products." Have you been in a small organization that tried to impose strict structure? They don't work. Have you been in a large organization that had laissez faire agreements for service management? They don't work. Ultimately all three have the same goals: 1. Delivering better Services that are aligned to the business needs of the organization. 2. Delivering those services in the most efficient manner possible for the organization and for customers. 3. Change the culture of IT and Service Management to create a stable, yet flexible operational environment. They approach the same goals from different view points and different means. The rhetoric from both sides only confuses the issue. They do the same things in different ways. No matter where we work or who we work for, we all have the same problems, we all need better services, better delivery, and a better culture. But we all need them at a different scale and in a different style. You need to find the right mix and the right structure for your organisation. Make no mistake, devops is IT Governance, and that's not a bad thing. On Thu, Sep 1, 2011 at 2:40 PM, Christopher R Webber < [email protected]> wrote: > This book may be an interesting place to start: > > http://www.amazon.com/Visible-Ops-Handbook-Implementing-Practical/dp/0975568612 > > -- cwebber > > Christopher Webber > Computing Infrastructure and Security > University of California, Riverside > > > On Sep 1, 2011, at 11:18 AM, Will Dennis wrote: > > @cwebber, I thought the same thing – my understanding of DevOps is > that’s it’s a way of working, not a framework. I have worked on the Ops side > of a Dev/Ops split (think “us/them”) and DevOps does sound like a very > good idea… However, my current $job has almost no “dev” component (at least > in the traditional sense).**** > ** ** > Anyways, I think that ITIL/COBIT are too complex for our environment, so > am wondering if there’s a “cut down” version that someone’s come up with. If > not, well, we’ll have to come up with our own.**** > ** ** > Thanks,**** > Will**** > ** ** > *From:* Christopher R Webber [mailto:[email protected]] > *Sent:* Thursday, September 01, 2011 1:58 PM > *To:* Joseph Kern > *Cc:* Will Dennis; <[email protected]> > *Subject:* Re: [lopsa-discuss] IT services add/change decision > processframework**** > ** ** > I would be hard pressed to call DEVOPS a framework. In fact, I would > argue that ITIL can very much be done in a DevOps manner. DevOps is less > about framework and instead about finding what works best. Stop the > in-fighting between devs and ops, use tools to automate the process and make > sure that their is real teamwork.**** > ** ** > There are a few things that people that are involved in devops tend to > do such as continuous integration and test driven development. Those are > tools in the toolkit not and enable your governance structure, not define > it.**** > ** ** > Just my two cents.**** > ** ** > -- cwebber > > Christopher Webber > Computing Infrastructure and Security > University of California, Riverside > > > **** > ** ** > On Sep 1, 2011, at 10:48 AM, Joseph Kern wrote:**** > > > **** > ITIL, COBIT, or DEVOPS.**** > ** ** > DEVOPS is bottom-up, COBIT and ITIL are top-down.**** > ** ** > DEVOPS requires small groups (think startup).**** > ** ** > COBIT and ITIL require larger groups (think Large or Medium sized > businesses).**** > ** ** > COBIT is free, ITIL is not.**** > ITIL has more "respect" than COBIT.**** > ** ** > COBIT: http://www.isaca.org/Knowledge-Center/COBIT/Pages/Overview.aspx** > ** > ITIL: http://www.itil-officialsite.com/**** > DEVOPS: http://en.wikipedia.org/wiki/DevOps**** > ** ** > These are frameworks for "IT Governance", "Change Management", and "IT > Service Management", but be aware: it's not enough to do the checklists or > hold daily scrums. You must initiate change in your organization on a > personal level for this to work, you need a champion, and you need people to > want this change. DEVOPS works in smaller groups, of concerned participants. > ITIL and COBIT work better in larger groups, with participants of various > levels of buy-in. **** > ** ** > Pick the parts from each that best fit the time, attention, and talent > of your organisation, dump the rest, and ship better services.**** > ** ** > On Thu, Sep 1, 2011 at 12:06 PM, Will Dennis <[email protected]> > wrote:**** > Hi all, > > We are working on becoming more rigorous in following processes in > building/delivering IT services here. As a part of this effort, we are > trying to come up with a lightweight process (i.e, not full-on ITIL, > etc.) to intake / analyze / decide on new requests for (or modifications > to existing) IT services. Here's what we've come up with so far: > > ========== > Proposed Framework > > 1. Identify issue/new service > 2. Business case - risks in doing and risks if not done/done well > 3. How best to solve issue/deliver new service (regardless of current > setup or constraints) > 4. What are the impediments to delivery > 5. How can the impediments be overcome > 6. Resources needed (both direct $ + manpower) > 7. How would the solutions be delivered (in house, outsource, > consultant) > 8. How would the decision be made (by whom, standard material to review) > > 9. Once decision is reached to proceed, how to prioritize with existing > workload > > > The following thoughts are based upon the proposed framework. They are > intended as a straw man for discussion. > > - Initiators of Change > > Change can be initiated from a number of sources, but the most likely > will be one of three sources: > > * An existing Community of Users who see the need to Migrate into an > expansion and/or upgrade of an existing Service Catalog offering. > * A new Emerging Community of Users who wish to adopt new services and > work methods not currently available in the Service Catalog. > * A Visionary who proposes Early Adoption of new services and work > methods not currently available in the Service Catalog. > > - Formulation of Requirements > > * Change requires direction. > * Direction is best provided by the Initiator providing a proposal > including a base set of Requirements. > * Requirements are in effect a set of Goals (or initial goals) > necessary to obtain the desired Service Catalog offerings. > > - Business Case - Risk/Benefit Analysis > > * A Business Decider will review the Requirements and Goals to > determine if the proposed change has Business Value > > - Technical Analysis - Potential Solutions > > * What is required from a purely technical viewpoint to satisfy the > Requirements and meet the Goals? > > - Technical Analysis - Costs and Resources > > * What is required to implement each Proposed Solution? > > * There may need to be multiple Proposed Solutions and/or multiple > passes through the Technical Analysis phases to obtain the most > desirable but achievable solution. > > - Business Case - Cost/Benefit Analysis > > * A Business Finance Decider will review the Proposed Solutions to > determine if they are cost effective in achieving the Requirements and > Goals > > - Scheduling and Acceptance Criteria Phase > > - Implementation Phase > > - Testing and Acceptance Phase > > - Roll-Out Phase > > - Feedback and Iterative Improvement Phase > > ========== > > I'm thinking this sort of process may have already been invented, and is > available "out there" already... We don't want a very complex process > (we are a SME) but we do want to be able to have a good framework to be > able to get good enough data to make a decision. Anyone have any > resources or thoughts about this? > > Thanks! > Will > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss > This list provided by the League of Professional System Administrators > http://lopsa.org/**** > ** ** > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss > This list provided by the League of Professional System Administrators > http://lopsa.org/**** > ** ** > > >
_______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
