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]<mailto:[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]<mailto:[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]<mailto:[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/

Reply via email to