@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/
