The major issue when implementing any Governance framework is measurement. You're going to put a lot of work into this (if you do it right), please find a way to measure your impact.
If you want a decent (and lightweight) primer to ITIL, try Owning ITIL[1]. Besides ITIL and COBIT (which have their own lightweight implementations), review the wikipedia article on the Capability Maturity Model[2]. Which is software-centric, but may provide you with several good ideas. And if you'd like to read a counterpoint to my previous email[2]. :-) [1]: http://www.amazon.com/gp/product/0958296901<http://www.amazon.com/gp/product/0958296901?ie=UTF8&tag=thitsk-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0958296901> [2]: http://en.wikipedia.org/wiki/Capability_Maturity_Model [3]: http://www.itskeptic.org/devops-and-traditional-itsm-why-devops-wont-change On Thu, Sep 1, 2011 at 8:16 PM, Joseph Kern <[email protected]> wrote: > 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/
