DevOps for Enterprise Systems - Rosalind Radcliffe
•Download as PPT, PDF•
4 likes•4,197 views
DevOps for Enterprise Systems - Rosalind Radcliffe, Distinguished Engineer Chief Architect for CLM & DevOps
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (19)
Similar to DevOps for Enterprise Systems - Rosalind Radcliffe
Similar to DevOps for Enterprise Systems - Rosalind Radcliffe (20)
More from DevOps for Enterprise Systems
More from DevOps for Enterprise Systems (20)
Recently uploaded
Recently uploaded (20)
DevOps for Enterprise Systems - Rosalind Radcliffe
- 1. DevOps for Enterprise Systems Session 6289 Rosalind Radcliffe Distinguished Engineer Chief Architect for CLM and DevOps rradclif@us.ibm.com @RosalindRad
- 2. High-growth companies are re-composing their businesses through digital transformation New apps are consolidating data and capabilities to engage new audiences Business processes are being infused with insight from nontraditional data sources to create new business moments New business are composed leveraging digital services from a broad ecosystem New channels and business models Digital innovationReal time insight driven processes
- 3. Digital Disruption enables smaller competitors to be successful with disruptive business models ……TO FROM……..
- 4. 1 . IDC (2015). Innovation, Agility and Customer Experience: How Business Value Messaging Influences the Line-of-Business Buyer, Randy M. Perry. The Reality: Change or get marginalized IT Spending is increasingly influenced by LOB In 2015, ~65% of IT funds are influenced by LOB, going to 80% in late 20161 . Speed of innovation is a primary driver for LOBs. Infrastructure Outdated developer and team tools Aging developer population Disconnected teams, silos FUD: “manual processes exist for a reason”, “SoR dev can’t be as nimble as distributed dev” Processes Manual testing Availability of entire system is required to test Difficulty in creating and managing test data Cross-platform coordination required Manual project prioritization, status tracking What barriers are holding you back from change?
- 5. 5IBM Innovate. Disrupt. Transform. Fast. @Enterprise Scale. DevOps patterns Increased Delivery Cadence: from slow to fast Architecture: from monolithic to more, smaller, decoupled, pieces Organization: from silos to app teams aligned to business Where: from physical on-prem to cloud Enterprises need to move forward toward Innovation Less Cloud Bigger Teams More Coupling More cloud Smaller teams Less Coupling Slower Faster Innovators Optimizers Maintainers 1 Business alignment2 Enabling DevOps Transformation Co-existence of the 3 patterns in a same organization3
- 6. DevOps is not one of these things… It’s all of them! …across the entire lifecycle …for all technologies and platforms – Distributed People Process Tools Develop/ Test Operate Deploy Plan Cloud SoR
- 7. © IBM Corporation ‘Lean’ DevOps The Process
- 8. Lean & Agile are at the heart of IBM’s DevOps approach Balance efficiency and effectiveness to deliver the right things right! Fast response times Small batch sizes Continuous feedback AGILE Reduce work Remove bottlenecks Eliminate waste
- 9. 1. Minimum Viable Product 2. Dedicated Teams 3. Loosely Coupled Architecture 4. Minimizing Hand- offs, Maximizing Flow 5. Deliver in Small Batches 6. Transparency 7. Eliminate Overhead 8. Automate Testing using APIs Base: 600 IT professionals with application development responsibilities from US, Canada, UK, France, and Germany Source: A commissioned study conducted by Forrester Consulting on behalf of IBM, May 2014 34% of companies have “crossed the chasm” to critical 3- week delivery increments Positive correlation between speed and business satisfaction The New Software Imperative: Fast Delivery With Quality Eight DevOps Practices Are The Key To Success 1. Minimum Viable Product 2. Dedicated Teams 3. Loosely Coupled Architecture 4. Minimizing Hand- offs, Maximizing Flow 5. Deliver in Small Batches 6. Transparency 7. Eliminate Overhead 8. Automate Testing using APIs
- 10. © IBM Corporation ‘Lean’ DevOps The Culture
- 11. It’s all about the people Building a DevOps Culture grounded in lean and agile principles: • Everyone is responsible for Delivery • Common measures of Success • Empower your teams • Don’t under-estimate the value of training and skills enablement! Product Owner Senior Executives Users Domain ExpertsAuditors App Owner Support Staff External System Team Operations Staff Team MemberTeam Lead Team MemberTeam Member
- 12. Legacy Core Banking A Bank is connecting “Systems of Record” in a Private Cloud with “Systems of Engagement” on a Public Cloud … to deliver easy, secure mobile banking to clients Benefits to the Bank Optimize client experience Rapid development Rapid deployment Mobile analytics Secure the bank Systems of Record on Private Cloud Mobile Banking / Mobile Analytics Benefits for the Consumer Easy access Convenience Mobile banking Mobile payments Secure transactions Systems of Engagement on Public Cloud
- 13. Develop Build Test Production API Catalog Develop Build Test Slower iterations Production Systems of Interaction Systems of Record Digital Applications Enterprise Applications By the end of 2015, 75% of large organizations are expected to have adopted agile DevOps practices, (IDC) and 25% of cloud developers indicated development of cloud apps from within a hybrid environment. Applications and teams move at variable speed
- 14. Application Deployment to Multi-Platform Environments Mobile Device Cloud Distributed Develop IDE CI Tool SCM Build Deploy Built Artifacts Deliver Request Build System of Engagement System of Record z System Power
- 15. 15IBM Culture Foundational values and principles Think Conceptualization, refinement, and prioritization of capabilities Code Generation, enhancement, optimization and testing of features Deliver Automated production and delivery of offerings Run Services, options, and capabilities required to run in the Cloud Manage Ongoing monitoring, support, and recovery of offerings Learn Continuously learn based on outcomes from experiments IBM Bluemix Garage Method Combining industry best practices for Design Thinking, Lean Startup, Agile Development, DevOps, and Cloud to build and deliver innovative solutions. To learn more visit: https://www.ibm.com/devops/method
- 16. Bluemix is an open cloud platform designed for digital transformations Deliver your services to developers and access IBM’s middleware and SaaS portfolios, 3rd party and open services to build your apps • Stitch an application from APIs and services • Manage your APIs in private and public catalogs • Integrate across hybrid environments, on and off premises • Choose the appropriate deployment option 90+ Services and growing 1/4 from channel partners bluemix.net
- 17. APIs power the modern, digital supply chain Developers can share, re-use, (re)combine and deliver new capabilities quicker Composing new capabilities using internally shared APIs and external APIs Enterprise IT team Systems of Record (Processes, services and data) Reuses Shares Combines Shares Composes Enhances External APIs Consumes
- 18. The Critical Measure of DevOps Success The Hidden Factory Opportunity 80% 20% 50% 50% Waste Productive Hidden Factory= additional value you could create if you eliminated waste and redirected those resources to innovation DevOps Transformation
- 19. Building out new digital capability with speed Agile infrastructures Lean delivery methods & tools, across the lifecycle Bridging on premises assets to on cloud services Cloud DevOpsIntegration Operate Develop/ Test Deploy Plan Key enablers
- 20. DevOps for Enterprise Systems – Key Takeaways 1.DevOps is about transforming application development and delivery in order to accelerate digital innovation. So DevOps is a topic for both business and IT roles in the organization. 2.You don’t buy DevOps, you do DevOps. DevOps is an approach, a mindset – a combination of culture, process and technology (including infrastructure, tools and services). 3.DevOps is not only about the hand-off between Development and Operations. DevOps is about applying lean and agile principles across the application delivery lifecycle (biz-dev-test-deploy-operate) to achieve continuous delivery of digital innovation. Key concepts: automation, feedback loops.
- 21. • For Dummies books: • https://ibm.biz/mmdevops • http://ibm.co/devopsfordummies • http://ibm.co/agilefordummies • http://ibm.co/ServiceVirtualizationForDummies http://ibm.co/ARDfordummies • IBM DevOps Page: http://ibm.com/DevOps • IBM DevOps for Enterprise Systems: http://bit.ly/1PB02KS • DevOps Lean Assessment (Beta): http://bit.ly/IBMLeanAssess Resources Continuing your ‘Understanding DevOps’ journey
- 22. Thank You Your Feedback is Important! Access the InterConnect 2016 Conference Attendee Portal to complete your session surveys from your smartphone, laptop or conference kiosk.
- 23. Please Note: 23 • IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion. • Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. • The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. • The development, release, and timing of any future features or functionality described for our products remains at our sole discretion. • Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user’s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here.
- 24. Notices and Disclaimers 24 Copyright © 2016 by International Business Machines Corporation (IBM). No part of this document may be reproduced or transmitted in any form without written permission from IBM. U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM. Information in these presentations (including information relating to products that have not yet been announced by IBM) has been reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM shall have no responsibility to update this information. THIS DOCUMENT IS DISTRIBUTED "AS IS" WITHOUT ANY WARRANTY, EITHER EXPRESS OR IMPLIED. IN NO EVENT SHALL IBM BE LIABLE FOR ANY DAMAGE ARISING FROM THE USE OF THIS INFORMATION, INCLUDING BUT NOT LIMITED TO, LOSS OF DATA, BUSINESS INTERRUPTION, LOSS OF PROFIT OR LOSS OF OPPORTUNITY. IBM products and services are warranted according to the terms and conditions of the agreements under which they are provided. Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without notice. Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual performance, cost, savings or other results in other operating environments may vary. References in this document to IBM products, programs, or services does not imply that IBM intends to make such products, programs or services available in all countries in which IBM operates or does business. Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation. It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or products will ensure that the customer is in compliance with any law
- 25. Notices and Disclaimers Con’t. 25 Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products in connection with this publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to interoperate with IBM’s products. IBM EXPRESSLY DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. The provision of the information contained h erein is not intended to, and does not, grant any right or license under any IBM patents, copyrights, trademarks or other intellectual property right. IBM, the IBM logo, ibm.com, Aspera®, Bluemix, Blueworks Live, CICS, Clearcase, Cognos®, DOORS®, Emptoris®, Enterprise Document Management System™, FASP®, FileNet®, Global Business Services ®, Global Technology Services ®, IBM ExperienceOne™, IBM SmartCloud®, IBM Social Business®, Information on Demand, ILOG, Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™, PureApplication®, pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®, pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, Smarter Commerce®, SoDA, SPSS, Sterling Commerce®, StoredIQ, Tealeaf®, Tivoli®, Trusteer®, Unica®, urban{code}®, Watson, WebSphere®, Worklight®, X-Force® and System z® Z/OS, are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at: www.ibm.com/legal/copytrade.shtml.
Editor's Notes
- Main point: High-growth companies are re-composing their businesses through digital transformation Speaking Points: New apps are bringing data and decision making to the fingertips of people at the front lines of your organization who need to act Airbus is bringing insight directly to their maintenance engineers Insight from non-traditional data – social data feeds such as twitter, internet of things, wearable devices, m2m is being used in real-time business critical processes DelHaize is using weather data to predict real-time inventory needs Digital Innovation from an ecosystem Citi is sourcing new innovation from mobile developer communities Segue: The only question is how you will personally respond to the new digital era? Narrative Script: We envision a future helping customers continue their digital business transformation - with a focus on speed - with “just-in-time” or real-time analytics becoming a business cornerstone. We are seeing disruptors leveraging some key digital transformations to reinvent business processes: New apps are bringing data and decision making to the fingertips of the people at the front lines of your organization who need to act. Airbus (who spoke on stage at InterConnect this year) is changing the aviation industry by bringing insight directly to their maintenance engineers and changing their business models to extend greater value to their customers and to their industry Insight from non traditional data – social data feeds such as twitter, internet of things, wearable devices, and m2m are being used in real-time business critical processes. Businesses like DelHaize, parent company of Food Lion, are using non-traditional, weather data in their inventory business process to predict buying behaviors based on weather. DelHaize is taking just in time inventory to an entirely new future. Just-in-time inventory based on answering open-ended business questions like weather that causes them to adjust their optimal goals continuously. Other companies – like Citi - are effectively becoming digital innovators. They are focusing on creating their unique differentiation and sourcing from developer communities to help complete complex products and solutions. We heard from Citi at InterConnect about how they are creating a community of developers.
- 1. z Systems development shops are risk averse and frequently stuck in old and slow practices Without speed, LOBs will steer funds to platforms providing speed of development DevOps provides the how to for delivering at required speed 2. Access to workloads needs to be provided through services Services is how mobile and cloud workloads are delivered DevOps provides the how to for service enablement and API management 3. Younger developers needs to be attracted to the z platform or it will die DevOps processes, tools and associated cultural transformation attracts young developer
- There may be critical systems within the business (Systems of Record) where there is no value in trying to move them forward. These are the maintainers which you want to keep at minimal cost. But many SoRs need to move forward, engage with agile teams to increase the delivery cadence or tie in to SoEs – these are the Optimizers. Innovators are needed across the business. This is a sliding scale where we want to make everyone an innovator.
- Like any transformational exercise, a transformation to a continuous delivery model support by DevOps involves three key things: People: Organizational culture, behaviors Process Tools Tools simply enable the transformation and help reinforce the process. Process provides a framework, a set of guidelines and best practices to help you adopt lean and agile principles in a continuous delivery model. Now, people – that’s the tough part! Change is hard and transformational change is even harder. Don’t underestimate the need to focus on the people, which includes organizational structure, roles, ownership, behaviors and cultural differences that exist in your environment. (Optional, if you want to mention this) In VersionOne’s state of agile survey, 3 of the top 4 barriers to adoption were related to the people aspect: 1. Inability to change organizational culture (53%) and 2. General resistance to change (42%) 4. Availability of personnel with the right skills
- Like any transformational exercise, a transformation to a continuous delivery model support by DevOps involves three key things: People: Organizational culture, behaviors Process Tools Tools simply enable the transformation and help reinforce the process. Process provides a framework, a set of guidelines and best practices to help you adopt lean and agile principles in a continuous delivery model. Now, people – that’s the tough part! Change is hard and transformational change is even harder. Don’t underestimate the need to focus on the people, which includes organizational structure, roles, ownership, behaviors and cultural differences that exist in your environment. (Optional, if you want to mention this) In VersionOne’s state of agile survey, 3 of the top 4 barriers to adoption were related to the people aspect: 1. Inability to change organizational culture (53%) and 2. General resistance to change (42%) 4. Availability of personnel with the right skills Lean and agile at foundational in IBM’s DevOps approach. Lean is about reducing waste – which occurs everywhere along the software delivery lifecycle. You need to identify bottlenecks and then resolve them, using technology where it can help and taking advantage of lean principles, such as Kanban, where technology falls short. Agile provides guidance and best practices to help teams respond more quickly to feedback by reducing batch sizes that help reduce churn, delivering functionality in smaller chunks and getting feedback earlier in the lifecycle. The key is to apply both lean and agile principles to balance the efficiency of your teams with their effectiveness: It’s not enough to deliver right, you must deliver the right things right. What does that mean? Deliver value – software that customers want and will buy and will enjoy using. It’s not about delivering function anymore (Optional, from the Scaled Agile Framework web site: http://scaledagileframework.com) The effectiveness of applying lean and agile principles to the enterprise: 20–50% increase in productivity 30–75% faster time to market 50%+ defect reduction Increase in employee engagement
- Main point: 8 DevOps practices are key and are most highly correlated with accelerated delivery and increased business satisfaction: Myth exposed: releasing fast requires you to sacrifice quality. Exactly the opposite is true: small incremental releases are more thoroughly tested, more stable and lower risk. Speaking points: In May 2014, IBM commissioned Forrester Research to conduct a survey of 600 app dev professional. The study identifies the 8 DevOps practices that are most highly correlated with accelerated delivery And it refutes the myth that releasing fast requires you to sacrifice quality and accept higher risk: adopting these eight DevOps practices, especially automated testing and delivering in small batches, does exactly the opposite: small incremental releases are more thoroughly tested, more stable and lower risk. The best part about DevOps adoption is the flexibility to choose which practices to adopt first, based on each organization’s priorities, and then to incrementally adopt the rest of the practices as needed to optimize the software delivery lifecycle and accelerate innovation. Segue: MORE INFO / KEY FINDINGS Forrester’s study yielded five key findings: › Development teams that consistently deliver at the fastest cycle times enjoy the highest business satisfaction. We found a high correlation between fast cycle times and business satisfaction in our survey results. In this study, high business satisfaction is an indicator of software quality. The reverse is also true — teams delivering at the slowest cycle times self-reported the lowest business satisfaction with their projects. › Incremental improvements to waterfall methods run out of steam at one- to two-month delivery cycles. Our findings strongly suggest that sustained cycle times of two months or less are impossible to achieve with incremental improvements to waterfall methods. The overhead of those regimes — even when supplemented by Agile methods — eats up too much of a multiweek delivery window to succeed. To consistently deliver quality software at the fastest cycle times, teams adopt new methods and software designs and leave waterfall behind. › Eight DevOps/continuous delivery practices are the key. DevOps/continuous delivery relies on eight practices: 1) deliver small increments of functionality; 2) use dedicated, cross-functional teams; 3) use loose architectural coupling; 4) automate environment provisioning; 5) continuously integrate code; 6) continuously test; 7) continuously fund; and 8) provide real-time transparency. › DevOps practices address the top reasons for project disappointment. DevOps practices directly address the reported causes of business dissatisfaction with software projects. We found the practices used by the fastest teams to achieve high business satisfaction were a mirror image of the practices the slowest teams reported caused low business satisfaction. › DevOps practices reduce cycle time and the risk of failure at the same time. Conventional wisdom and intuition say that faster releases must come at the expense of higher risk of project failure. DevOps techniques turn this logic on its head. DevOps practices enable faster and safer releases because they are smaller, less complex, and more thoroughly tested. Automating provisioning and deployment further reduces configuration errors and speeds up delivery.
- There is no technology that will solve the issues related to culture in your DevOps transformation. Sorry! But don’t forget that this is the most critical part and you must focus on building a DevOps culture that is grounded in lean and agile principles: -- Everyone is responsible for software development and delivery. Agile helps you define roles in your organization, the activities they must perform, and the ownership each role has for specific activities and deliverables. You want to build a culture that has control and ownership and a sense of responsibility for successful value delivery. -- Teams and teams-of-teams should be using common measures of success. Again, agile can help define that process. -- Finally, please do NOT underestimate the need to train!
- At a bank in Australia, the management team has been developing their strategy for the future. The solution they retained is to buy a core banking application that functions almost solely as a system of record, and build the systems of engagement and systems of insight in a public cloud. This is a very common pattern we see over and over as few companies ever wanted to buy monolithic systems. If you step back and think about the teams building these different systems, you quickly realize that they are vastly different: Teams building SoR are typically larger, more structured, focused on attributes like security, reliability, compliance. On the other hand, teams focused on SoE are much smaller, integrated and agile, with a focus on getting a solution to market as quickly as possible and gathering customer feedback. In short, SoR teams’ focus is on time to certainty, while SoE teams focus’ is on time to experiment. These culture differences have significant impact in the ability of an organization to quickly deliver hybrid cloud solutions, and require optimized DevOps approaches and solutions.
- But even with optimized DevOps solutions to cater for these differences, the reality of a two speed IT makes the delivery of these integrated systems complicated multi-team projects. Why do we talk about two speed? - SoR teams typically release software in cycles measured in months, commonly 3-6 months with very distinct phases, dedicated teams (e.g. testing). - SoE teams typically deliver new versions of their software in days or weeks. These differences in speed, culture, and priorities create lots of challenges to manage dependencies. Typical issues include: Lack of clarity on Services requirements Mis-alignment of schedules and priorities Different tools and infrastructures render rollout of entire stack complex How do we solve this?
- Deploy complex applications: multi-platform, multi-technology Applications in different layers develop and deploy at different velocities Hybrid environments: Public and Private Cloud, Distributed physical or virtualized servers, Mainframe, Mobile Devices, and also Smart devices
- From Hayden: What I had imagined starting with is the top level BM Method graphic...where Culture is in the middle. I had imagined clicking on each to then show the portion of our portfolio that is relevant. Sue’s thinking: he clicks on the “Code” tile which takes him to the “Code” slide and from there he launches a product demo if applicable. Or, he does all the product intros from this circle and does the demos completely separate from this circle. IBM’s practical method combines the best of open communities, Design Thinking, Lean Startup, with an Agile DevOps methodology to build and deliver innovative solutions. It reflects how we design, build applications, and incorporate feedback on a regular basis. It’s called IBM Bluemix Garage Method. It’s an open and repeatable method with best practices, tool chains and a thriving ecosystem. Provides: Hardened method-ware, delivered as digital experience and practice library of work-product assets. Accelerators to speed adoption, combining tool chains and methods. Shared learning (videos, case studies, blogs) of IBM transformation; extends to clients, phase 2. Open community forum to engage, comment, progress and extend methodology.
- Main point – APIs, open communities and governance are key to innovation and efficiency POV – In an API centric, hybrid world, heterogeneity is a fact of life. Using Open Technologies helps improve cloud and application interoperability, leads to better device support and often increases innovation.
- Speaking Points: We’re not speaking to the words on the slide….This is a digital experience example: Imagine a scenario where a driver gets in an accident. Many of us have been there and we know this is a process the involves many companies working in harmony. My insurance firm, the adjuster, the body shop, the tow truck driver. Yet, we assume the insurance firm owns the experience. Our first call is to the insurance company who has us gather some information. A tow truck is dispatched, but doesn’t arrive within an hour. Who do I call? Not the tow truck company. I call my insurance company to ask where is the tow truck? So, by building out an ecosystem of partners built on secure APIs, I build a new digital experience that increases value to my consumer AND to my partners. Imagine the digital experience where all of these are integrated. A maps app that shows me where the tow truck driver is en route. Let’s me accept or negotiate the adjuster’s claim. I can see images of the repair as it happens. All powered by the new, digital supply chain.
- Let’s focus for a few minutes on waste and what causes it because, unless you can identify waste across the software development lifecycle, it’s going to be difficult to eliminate it right? You want to find your organizations “hidden factory”, which is essentially the amount of waste you can eliminate to transform your organization’s ability to innovate and be productive as opposed to just “keeping the lights on”. Financially the issue is simple. Demands on software delivery resources are increasing and funding is decreasing. DevOps targets this dilemma: that both speed and efficiency must improve as we discussed on the last slide. This is why lean, agile, automation, and collaboration are key elements of any solution. At least 40% of your resources are probably wasted on non-value added effort. What if you could redirect this wasted resource to a Hidden Factory that dramatically improves your competitive differentiation? Hidden Factory is a Lean Six Sigma term. It is the additional output that would be possible if the resources you are currently directing at creating waste were released and redirected instead at creating value and innovation. Think about what cutting that waste by 50% or more would mean. This is the value of lean adoption and executing the core value proposition of DevOps. Reducing waste, duplication and process friction means we can spend less time on drudgery, duplication and rework, and more time on efficient innovation and smarter systems, products and services. There are three *typical* causes of waste: Unnecessary Overhead Caused by lack of collaboration, wasted time in meetings, problems articulate feedback (aka requirements, ideas). Communication, in general , or lack of good communication is a primary source of waste. Technology can help here in many ways. Collaborative tooling that enables teams to work together online, using a consistent source of truth to represent status and health of projects, to communicate feedback, and to report on all of that information in a consistent, simple way. Tooling that can do that goes a long way toward easing the communication overhead, especially for distributed organizations. Unnecessary Re-work This is actually caused, in large part, from poor communication, in all respects. Feedback (aka requirements, ideas) are not communicated properly. Objectives are not communicated properly. Other causes include lack of testing, validation against feedback and integrated deployments early in the lifecycle. As software changes move further to the left in the delivery pipeline, re-work becomes more and more costly. Over-production It is critical to understand what is “good enough” in terms of solution development. A wise IBMer once told me that IBM is very good at delivering a Cuisinart when the customer just needs a wooden spoon or a hand mixer. Over-engineering, delivering really cool functionality, causes huge waste if the customer does not want the solution and therefore will not buy it. Understand the feedback, the requirements, the ideas and then craft a solution that delivers the “minimum viable product” so that you can get feedback before adding more capabilities.
- Main point: 3 key enablers to help you speed up digital transformation Speaking points: In the digital era, responsiveness to the market is paramount. Which means your current digital transformation will soon be followed by your next transformation (and so on). To transform, adapt and respond quickly requires three things An agile infrastructure to help you build, deploy, run and manage apps Flexible and open APIs so you can integrate on-premises assets and on-cloud services Agile and lean processes & tools so you can accelerate software delivery: beginning with planning - through development, delivery - and finally, monitoring and analyzing the feedback and incorporating it back into the planning. Segue: Let’s look at each of this individually.