Agile Cloud Service Strategy using DevOps

Editor's Notes

• #2: Welcome to our session on cloud services strategy My name is Jason Stevenson and I am an Transformation Consultant In this session we will be outlining an approach to help your organization remain both relevant and competitive in a changing market
• #3: Before we begin lets take a look at the topics we will be discussing in this session: DevOps: An approach to iterative adoption IT as a Service: An approach organizing IT as commodity to deliver services on demand to meet business needs using scalable and measurable resources pools and processes Wagile: An approach to combining SCRUM project management with ITIL service management Transformation: An personal trainer versus plastic surgeon approach to changing culture
• #4: First up is our approach to adopting DevOps
• #5: The first thing we need to discuss is that DevOps is a concept rather than a best practice, standard, or framework It really is a discussion within the IT industry from multiple perspectives: Some people looking at DevOps from the perspective of consolidating both development and operational responsibilities into a single role Some looking at it from the perspective of using an agile or SCRUM Yet others looking at it from the perspective of delivering and supporting cloud services such as SaaS
• #6: Unless your organization is new or very small, DevOps is a major cultural shift that must be made incrementally over time We suggest a three-step approach to adopting DevOps: One, fully understanding the current state Two, leveraging iterations of an interim state Three, not just achieving but sustaining the desired future state
• #7: Current state culture can vary widely from one organization to the next However many organization share some common characteristics: One being an alignment with functional management which creates “siloed” or “stovepiped” departments Another being partially-defined operational processes that are buried deep within the organization Either authorized or unauthorized exploration and shift to DevOps which often involves isolation Informal communication with business at varying levels It is common for many IT departments to perform annual budgeting or planning however fiscal stewardship often ends there or dwindles
• #8: The next step in our journey is to move through multiple iterations of an interim-state We do this by abstracting some of our critical functions into technical-facing services such as network, compute, and storage We may also abstract some critical applications from our application portfolio into services Simultaneous we will define missing processes and mature existing processes This will involve consistent documentation and communication of policies, process flows, procedures, and roles and responsibilities One important part of roles and responsibilities is identifying service and process owners and managers throughout the organization We also want to bring DevOps into the fold by making them accountable to management policies but not affecting their autonomy and ability to execute agile processes At the same time we want to cross-pollinate traditional operations with the lifecycle-spanning culture we have in DevOps In addition, we want to begin to manage existing business relationships informal through consistent communication And finally we want to move beyond annual budgeting to some type of regular accounting of technical service cost
• #9: To achieve the desired future state we must mature our organization in business-facing service culture This goes well beyond the technical-facing services identified in the interim state This involves shifting our focus to providing services on demand to meet business needs through scalable and measurable resources using shallow integrated processes When I say shallow processes, I'm referring to moving the processes once buried deep in the organization as discussed in the current state to a higher level We also need to look at structuring processes around a service lifecycle As well as automating processes to increase agility Service and process owners and managers we identified in the interim state will also move higher and consistently in the organization These owners and managers will leverage DevOps to deliver and support a service throughout its lifecycle DevOps may at first be focused heavily on operations but as the organization matures their focus will shift to earlier stages of the lifecycle including transition, design, and strategy We also want to update our process with DevOps techniques discovered as part of this journey to remove bureaucracy We also want to target communications paths and business points of contact at the right level using a formal business relationship management process that delivers value to the customer Finally we want to evolve budgeting and accounting into a financial management process for service cost recovery including showback/chargeback or better yet realizing profitability beyond cost recovery and using revenue to enable research and development and service improvement
• #10: In summary, its important integrate service management, traditional operations, and DevOps closer together at a rate the organization can absorb
• #11: Now we will take a look at our approach to adopting to transforming your organization to an ITaaS provider
• #12: Now that we’ve talked about DevOps Lets go deeper and discuss building an ITaaS Provider leveraging DevOps culture we’ve been discussing as well as Cloud computing standards Service management best practices An agile project management framework And leading cloud and virtualization technologies
• #13: Up to this point we’ve using the term service management in the general sense As our conversation shifts to building an ITaaS Provider we want to speak specifically to service owners and service managers and where they fit in the organization Many government and commercial organizations are broken into sub-units by geography, line of business, etc. You may find that your IT organization must reflect these lines as well. If so, its important to a have single service owner with accountability and fiscal responsibility that solid-line reports into the CIO. With a single service owner its okay to have multiple service managers with their solid line into each sub-unit and also having a dotted line relationship to the service owner Within the roles and responsibilities clear lines of delineation are made between service owners and managers with the owners focusing on strategy and improvement and managers focusing on design, transition, and operation You can see that service owners are at the very top of the organization directly reporting to the CIO along with a financial manager and a business relationship manager As we discussed in our DevOps discussion this level of service ownership is often a shift for many organizations and therefore requires both incremental transformation and finesse to be successful
• #14: After the concept of service ownership sinks and the organization realizes that service owners have fiscal responsibility the question becomes “What happens to all the function directors we already have within our organization?” Well some of the will become service owners and others will be come service lifecycle directors for each phase of the service lifecycle: Strategy, design, transition, operation, and improvement These service lifecycle directors are solid-line into the CIO but dotted line into the service owners as service lifecycle directors’ funding is allocated by service owners
• #15: In an ITaaS provider organization, process managers and owners play an important role in addition to service managers and owners As mentioned before, these processes are no longer deep within the organization and positioned below the service lifecycle directors A process owner/manager needs to be identified for each service management process In larger organizations this may be one individual for each role and in smaller organizations it may be one individual fulfilling multiple roles Within ITaaS, it is preferable to consolidate the ownership and management responsibilities into a single role However, similar to service owners and managers, processes can be segregated into owners and managers as well for siloed organizations
• #16: Earlier in this session we discussed functional management Within ITaaS, functional management does not go away it just moves further down into the organization under service owners and service lifecycle directors Functional owners can include infrastructure, applications, data, service desk, operations center, etc. The role of functional owners and process owner can be fulfilled by one person For example, the role of service desk function owner and incident process owner/manager Another example is the role of operation center function owner and event process owner/manager Earlier in the session we also discussed technical-facing services like network, compute, and storage The service owners for these technical-facing services will report into functional owners
• #17: Under the service, process, and functional owners and managers is DevOps With a strong service focus, lifecycle structure, and process management at the right level, DevOps can flourish along side traditional configuring item owners and managers as assignment groups for issues across the entire lifecycle DevOps is matrix managed by the service lifecycle directors and process owners/managers As the organization matures, DevOps focus will shift to earlier phases of the lifecycle from operations to transition and then design
• #18: Another way to look at an ITaaS Provider is to flip the organizational chart upside down By inverting the organizational chart we can see our users and customers are at the top of the organization and they interface with first line support First line support is anyone logging and incident or request on behalf of the user If first line is unable to resolve the incident of fulfill the request it is escalated or routed to second line support Traditionally, second line support will escalate to third line support including developers, engineers, third-party supplier as needed Within ITaaS, the service desk is a virtual function including traditional service desk agents and also automated options Incidents and request are escalated to DevOps who fulfills the role of second line support Third line support is no longer developers and engineers because DevOps is supporting that role as well as operations subsequently third line support is distilled down to third party suppliers All lines of support are supported by service, process, and functional management and directed by ITaaS provider organization It is important that the ITaaS provider’s tools be service rather than technology focused and configured to support this escalation structure and governance
• #19: Now we will take a look at our approach to leveraging “Wagile”
• #20: Now that we’ve had a chance to discuss DevOps within the context of an ITaaS provider It becomes much easier to have a conversation around consolidating waterfall and agile into a single Wagile approach Service management or ITIL can be considered slow and fat where agile or SCRUM can be considered fast and loose By consolidating these two approaches into a single Wagile approach we mitigate the concerns associated with both approaches and we gain the greatest efficiency Efficiency is gained by using service management to deliver value to customers through services throughout a service lifecycle And using agile for project management to deliver valuable products through an adaptive approach in support of service design and transition
• #21: Finally, we will take a look at an approach to changing your organizational culture
• #22: As we reach the end of this workshop, you can now see that adopting DevOps within and ITaaS Provider using a Wagile approach can be a major shift in culture that comes with many challenges such as: Putting other people first; specifically customers paying for the service and users receiving the service Placing ourselves in a service role from the very top of the IT organization to the very bottom and allow ourselves to be subservient to others Giving up the notion of self-importance and recognize each and every person plays an equal role in the chain when delivering an end-to-end service and accept a fair amount of autoMATION of what we do on a regular basis Redistributing control from individuals to processes that leverage group intelligence and center authority within service ownership and lifecycle Becoming truly accountable for our role in service delivery and support where all involved can clearly see what we have done or not done And approaching problems and continual service improvement in a blameless environment that shines light on issues rather than covering or avoiding them
• #23: Let’s talk about a real-world approach to large-scale transformation Many organizations will leverage an outside consultant to support transformation activity They do this because: External consultants are not as susceptible to internal politics as internal resources External consultants have skills and experience specific transformation where internal resources are more focused on design and operation activities When using a consultant be sure to choose a “personal trainer” rather than a “plastic surgeon” What I mean by this is a consultant that works on a regular basis with your resources rather than produces paper mill deliverables I found that three day workshops every two weeks work really well These workshops can be in the middle of the week on a Tuesday, Wednesday, and Thursday with two hour morning session, an opportunity for professional networking over lunch, and a two hour afternoon session This turns the workshops into events that people want to attend and is conducive to their schedules Though 100% of the organization must be involved in transformation at sometime these workshops equate to approximately 10% of the time of 10% of the organization
• #24: I hope you enjoyed this session and found it useful If you have any questions, please feel free to contact me at jasonastevenson@hotmail.com Thank you