DevOps Integrating the Enterprise
•Transferir como PPTX, PDF•
0 gostou•156 visualizações
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Semelhante a DevOps Integrating the Enterprise
Semelhante a DevOps Integrating the Enterprise (20)
DevOps Integrating the Enterprise
- 1. Integrating the Enterprise Aligning at all levels
- 2. What we will discuss… What is DevOps? Why DevOps? The Enterprise Challenge The Vision The Possible Solutions
- 3. What is DevOps? “DevOps is a culture built on collaboration and communication across all IT professional units and key stakeholders while automating the process of software delivery and infrastructure change”
- 4. 5 key words CULTURE “Ideas, customs, and social behaviour of a particular people or society” Changing a philosophy and mentality. Cultural Change is often the most challenging aspect of DevOps, and the greatest reason for failure COLLABORATION “The action of working with someone to produce something” Teamwork towards an end-goal. So teams must be clearly defined, as must an end goal COMMUNICATION “means of sending or receiving information” Inputs AND outputs Clarity is key ALL (or Enterprise) “Used to refer to the whole quantity” Enterprise wide, business AND IT No silos, no walls, all encompassing responsibility WHILE (or Continuous) “At the same time/During the time that” A parallel operation to any other transformation Ongoing and iterative, learning and developing
- 5. Why are they key? Communication EnterpriseCollaboration Continuous Culture – Culture is at the foundation/centre – Without Communication – Collaboration across the Enterprise breaks down – Without Collaboration – Communication of Continuous work becomes confused – Without the Continuous – Effective Collaboration across the Enterprise fails – Without the Enterprise – Communication of the Continuous work stops
- 6. Analogy: Building an Apartment Block Culture Collaboration Communication Enterprise Continuous Sand (Ad hoc) No No No Yes Gravel (Silo’d) No Yes No Yes Rock (Waterfall/Agile) Yes Yes No Yes Earthquake Resistant (DevOps) Yes Yes Yes Yes
- 7. What do the Foundations support? Culture Enterprise Collaboration Communication Continuous “The ideas and social behaviour of our organisation” “The whole of our organisation” “The connectivity of our organisation to one goal” “The sending and receiving of information in our organisation” “The ongoing learning and development of our organisation”
- 8. Slow time to market Long application release cycles Poor user experience Low application quality Poor predictability Lack of end-to-end visibility Why do we want DevOps? High costs Poor resource utilization, rework cycles Gartner, “Survey Analysis: DevOps Adoption Survey Results.” (September 2015) c05195879 July 2106
- 9. The Enterprise Challenge Agile implementations require projects to self-organise Enterprise constructs are often fragmented, with alignment at the top level Differing approaches to process, governance and reporting cause conflict and confusion Top down alignment dictates, clash with bottom up self-organisation Results; Communications break down between teams Continuous work stops Enterprise remains fragmented and DevOps culture fails
- 10. The Legacy of Silos CxO IT Management Enterprise Architecture ITSM Incident Management Infrastructure Support Event Management Application Development Project 1 (Finance) Project 2 (Finance) Project 3 (Manufacturing) Project 4 (HR) Project 5 (Marketing) Business Units Finance Manufacturing HR Sales & Marketing Enterprise Enterprise Agile Transformation
- 11. Our Enterprise DevOps Vision Enterprise DevOps CxO Business Units Enterprise Architecture Application Development ITSM “An agreed single, social behaviour that drives all teams towards a single goal for the continuous improvement of the business”
- 12. The Possible Solutions Use the Agile Manifesto and its 12 principles at an enterprise level “Work together” “Self-organise” “Simplicity” “Tune and adjust behavior” Use Enterprise Architecture and TOGAF® methods Define technology based around business need Rules & Guidelines
- 13. The Agile Manifesto and 12 Principles Collaborate enterprise teams & agile project teams Invite Incident Managers to daily stand-ups Invite Enterprise Architects to retrospectives Perform retrospectives at enterprise level Simplify communications Use a Kanban at each level Only report what is actually needed Face-to-Coal Face Continuous learning Identify silo walls and break them down Accept failure and learn from it Share and share alike https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/
- 14. Enterprise Architecture and TOGAF® Define the principles Identify stakeholders Confirm goals and drivers Evaluate capabilities Assess readiness and define scope Develop the vision around value Identify risks and activities Establish rules & guidelines Build the DevOps architectural culture http://www.opengroup.org/
- 15. DevOps - Integrate the Enterprise Communication EnterpriseCollaboration Continuous Culture Thank you
Notas do Editor
- Welcome to this presentation, hopefully leading to a lively discussion, on integrating the Enterprise into DevOps. In this next 30 minutes we will demonstrate how integrating the Enterprise into DevOps is not just something we think should be done, but is absolutely essential in ensuring that any DevOps implementation is successful. We will look at the challenges presented by not aligning all levels of an organisation to a DevOps culture and how we can ensure a smooth transition and integration
- Firstly, I feel we need to re-evaluate exactly what DevOps is, as well as what it is not. This has been something of a grey area, with many different definitions, often tainted as a result of the perspective of the one giving the definition. For example, Development may view this as a development, or IT only framework to speed up development. Operations may view this as a framework for the faster turnaround of incidents. Business heads may wonder why this has anything to do with them. I am sure I will probably be no different, but I hope to provide a more holistic perspective. We will also quickly review why we need DevOps. What are the drivers? We will then look at a typical example of the kind of challenge organisations face. Many times this challenge will not be realised until it is too late, so it is good for us to consider it in advance. Finally, we will reiterate our vision of what we want to achieve, which will help us to look at potential solutions.
- We’ll start by thinking carefully about what DevOps is. It is from this definition that we can derive the key aspects we need to ensure are implemented. I have highlighted 5 key words in this statement – Culture, collaboration, communication, all (IT professional units and key stakeholders) & while (automating the process)
- Let us look carefully at what each of those key words mean. CULTURE The forcing of one culture - one groups ideas, customs and social behaviour – onto another has throughout human history been a cause of friction. We all have our own culture and forcing someone to change that is always going to be a cause of resistance. It is human nature. In implementing DevOps we are removing an old culture and replacing with a new and so is subject to that same potential resistance and we must be mindful of that, It is the principal reason most business transformations fail COLLABORATION “The action of working with someone to produce something” The last 3 words are key. We all know about working together, but it is about achieving a common goal at the end that is important COMMUNICATION It is about listening, as well as talking. Communicating requirements is not just about telling a development team about what you want done, it is also about the feedback on that requirement request Clarity is key – too much information can be as bad as none at all. Too much wood for the trees can mean vital information is lost. Communications must be clear and targetted ALL (or Enterprise) “Used to refer to the whole quantity” Enterprise wide, which means business AND IT – the whole thing. The “Enterprise” could be a subfunction of your whole business, but you would only realise benefit for that function and not the whole. Start small by all means, but ensure that you eventually rollout to the entire enterprise to ensure maximum value It means no silos, no walls, all encompassing responsibility WHILE (or Continuous) “At the same time/During the time that” A parallel operation to any other transformation. As we expand and grow, so must our culture, our technology and our automation. Ongoing and iterative, learning and developing
- At this point we need to bring those 5 aspects together to fully understand the philosophy behind a DevOps culture. And that is the first aspect. DevOps IS a culture. The culture is at the very core of everything we do. It is about our ideas, it is about our custom, but above all, it is about our behavior. Without the correct culture, all other aspects will fail. Our communications will fail. Our collaboration will fail. Our continuous efforts will fail. Ultimately, the enterprise will fail. But these elements do not just rely upon the culture, the culture is actually created from these elements. If any one of these elements is missing, our culture suffers and fails. It is ultimately a feedback loop. Each part feeding off the culture, whilst also supplying and nourishing it. So without communication we cannot have effective collaboration across the enterprise Without collaboration, we cannot provide continuous communication and continuous work and improvement. Without the continuous improvement and parallel work, the enterprise cannot effectively collaborate Finally, and to the point of this discussion, without the enterprise as part of our DevOps culture, how are we supposed to communicate and make use of our continuous work and improvement. HERE is the point at hand. Without the Enterprise, a DevOps culture is seriously impaired and may completely fail
- Let’s take a basic analogy. Our DevOps is an apartment block we are trying to build. I realise this sounds a bit like a parable, but it works for us. If our culture is ad hoc, it is a bit like building on sand. Little or no collaboration, communication or inclusion of the Enterprise. Our culture is weak and is bound to fail, depending upon the heroic efforts of a few firefighters and their continuous efforts. We have single projects operating in isolation. If we operate a Silo’d culture, one that many of us will be aware of and have come from, we may well see plenty of effort towards continuous improvement and work, and we may be better at communicating our efforts, but without the collaboration and the Enterprise, we are building on gravel. We will over-communicate, telling everybody everything. We think this provides the information needed, yet most will see it as spam. Communications deleted, including maybe that one sentence that was actually needed to be understood. Efforts from individual projects are likely to clash. Service Introduction from Application Development into IT Service/Operations Management will be a case of throwing information over the silo wall. As we move to more traditional waterfall, and even Agile methods, such as ScrumXP, we are working on a more solid foundation. We are introducing the collaborative element, more successfully with Agile than waterfall as many of us will be aware. However, just how good are our foundations? Can they cope with Change? For Agile, generally it copes better than waterfall, but there are still instances where, without the Enterprise, our culture can still be shaken to its roots by substantial and considerable change at the Enterprise level. To make our culture Earthquake proof, we need to integrate the Enterprise into our culture – into DevOps
- Allow me to drive that message home. Our culture provides our foundations. They are core to our behaviour in the organisation Our enterprise is all IT teams, stakeholders, projects and processes, as shown here by the rooms. It directly rests on our culture Collaboration connects all of the parts of our enterprise together. It ensures teams, processes, stakeholders and projects can work together Communication is about using that collaboration in a directed and two way manner. Ensuring information flows through our Enterprise correctly – not just spamming everyone. We then continuously work to improve our Enterprise. Learning and developing as an organisation, both in the systems we deliver to support the business and in the development of our culture. This must be ongoing to allow us and the business to grow
- Key points: DevOps Optimization is the comprehensive approach across people, process and technology to resolve the pain points around these areas: Slow TTM: Long application release cycles and slow response to business needs. Poor predictability of application project schedules, due to lack of visibility across siloed processes – Dev, Test, QA, production, etc. High costs, due to rework, bug fixes, silos waiting on each other (e.g., developer waiting for infrastructure, etc.). Poor user experience, due to bugs in the applications or not having the right features as it takes too long to add them in quickly based on customer feedback.
- We are going to assume a best case scenario for this challenge. We have already built our culture on Rock. In fact, it is Agile Rock. Our projects have been self-organised and have transformed well. Each is doing well independently. However, we still have a legacy construct in our Enterprise. Teams fragmented, in particular around Service Introduction and the handover of our Agile developed Applications to our Support operations. This can result in delayed go-live. The differing ways in which teams interact with the business, report up to senior management, the key measures and SLA’s by which they define success from their individual teams can lead to conflict and confusion. This can lead to project implementations not being correctly integrated, and so to bugs. In order to get a grip on what the enterprise is doing, the higher levels of management will start to dictate ways of working, approaches and information expected to be captured. They will seek consistency across the Enterprise At this point, every man and his dog across the enterprise will now start to want to push their agenda. Everyone wanting the way their individual culture operated, to dominate or at least still be included. In an attempt to please everyone, everyone is allowed to the table. Conflict ensues, communications breakdown, continuous improvement comes to a halt as no-one can agree a way forward. The things that make up our culture, now begin to breakdown and our foundations start to turn to sand. In order to gain control, individual teams assert their own way of working. The Enterprise fragments and the DevOps culture fails.
- Here we see the legacy of silos in action on this organisation/enterprise. Here is a typical example of a fragment of the enterprise organisation. Multiple business units being supported by respective application development teams and by a separate IT Operations Management. Our Application development teams have successfully transformed to an Agile structure As part of the reporting and governance, project teams will report into the Application Development programme and portfolio management groups. In turn, Incident Management, for example, will report into IT Service Management as a whole. Each of these leadership groups will in turn report up to a senior/executive IT management layer and it is at this point that information and governance can start to become confused. This management layer, maybe through a CTO, or CIO, must report up to the executive level of the organisation, but the message can be incomplete or confused. As I once heard one CTO say to his IT group, “Why can I ask the simple question of how many servers we have, or how many applications we support, and nobody can provide me with a quick and simple answer?” In this organisation, only 2 groups are representative of the Enterprise. The executive level, but it is not their role to determine what individual projects do. And the Enterprise Architects. We will come back to them later
- This is the vision we want for our Enterprise. Each and all of these elements working together centered around a single culture. A DevOps culture. So each of them works to the same set of ideas being developed out of this culture and there is “an agreed, single social behaviour that drives all teams towards a single goal for the continuous improvement of the business.” “Agreed” means it was communicated “Single, social behaviour” is culture “all teams” is the enterprise “drives…towards a single goal” is collaboration “continuous improvement” is self explanatory
- Given the challenge we face, how do we resolve to achieve that vision. Well the answers are already there for us within our organisation, it is just that we often do not think of bringing these principles together. There are 2 things, that we as an Agile Enterprise are likely to have implemented. One is a bottom up approach, the other is top down. Using the basics of the culture we want to achieve, we must ensure that these 2 principles collaborate, communicate, provide continuous improvement and across the enterprise. Our bottom up approach is the Agile Manifesto and the 12 principles that support it. I’m not going to go into each of the 12 principles and how they should work at an Enterprise level, that is for you and your organisation to dictate, but some things are basic and clear – working together, self-organisation, simplicity and tuning and adjusting behaviour. All of these must be applied at the higher levels of the Enterprise. It is not enough that our bottom up approach to Agile Transformation should stop at the Project Teams. It needs to continue to cascade right up to the top. Our top down approach must work with this mantra, and this can be found in our Enterprise Architecture, and of particular use is TOGAF. This team and these set of disciplines help us to provide the way to develop a culture. Defining around business need using a defining set of Rule and Guidelines established for the Enterprise as a whole
- We will now look at each in a little more detail. The manifesto and its principles are clear about collaboration. Here are just a few steps that can help to extend those principles to the Enterprise. (Explain each if there is time) If ever there is something which needs to be simplified in an Enterprise, it is communications. Who else has had a mail box bursting at the seams with corporate communications which someone believes to be important, however, if you tried to read them all, you would never get your actual job done. Only communicate what is important – do just enough and make it clear. The principles are also clear about continuous development and learning. Fail and fail fast, but learn and develop from it. Identify the silo walls and break them down. Share what has been learned. Take a look at the principles from the Agile Alliance web page and think big. Think how these can work across the enterprise.
- It is at this point we can start to see where TOGAF can be useful. Those who are aware of TOGAF will know this as the ADM, the Architecture Development Method. At its core is setting out an architecture based around business requirements, business need. If those requirements are a DevOps Enterprise level culture based upon the principles of the Agile Manifesto, then we already have a core set of rules and guidelines ready to develop upon. What makes the culture then unique, is the individual business requirements for the Enterprise. At the outset of defining our culture, we define our vision, and TOGAF is clear on this. Define the principles – Agile 12 principles + business drivers Identify stakeholders – the enterprise Confirm goals and drivers – collaboration to achieving DevOps Evaluate capabilities – This is for your own organisation Assess readiness and define scope – as an outcome of the capability evaluation Develop the vision around value – The Enterprise DevOps Vision statement we saw earlier, but must be related to a metric value defined from the business needs and drivers Identify risks and activities – be prepared, there will always be resistance Establish rules & guidelines – generate requirements from the principles and visions Build the DevOps architectural culture – break down into sizeable chunks, implement a piece at a time, extend and share learnings to develop and expand out to the rest of the enterprise By plugging an Enterprise Architectural Culture, based around the Agile principles, we can plug the Enterprise into our transformation
- We can integrate the Enterprise into a single DevOps culture Thank you