ALM Practices - Modern Applications Development and its impact on ALM
4 likes1,121 views
The document discusses modern approaches to application lifecycle management (ALM). It notes that the way software is developed is changing, with modern applications focusing on rapid feedback, continuous delivery, and deployment on elastic infrastructure. It advocates dividing ALM tasks between those requiring algorithmic emphasis like continuous integration and those requiring heuristic emphasis like design. The goal is to support high-performance teams, revitalize architectures, and make the development process social, fun and rewarding.
ALM Practices - Modern Applications Development and its impact on ALM
- 1. Making Leaders Successful Every Day
- 2. Modern Applications – Modern ALM Jeffrey S. Hammond, Vice President & Principal Analyst @jhammond August 21, 2014
- 3. The best way to have a good idea… Source: Flickr (http://profiles.nlm.nih.gov/ps/retrieve/Narrative/MM/p-nid/55/p-visuals/true)
- 4. Software innovation used to be expensive… “When I built my first company in 1999 it cost $2.5 million in infrastructure just to get started and another $2.5 million in team costs to code, launch, manage, market and sell our software. So it’s not surprising that typical “A rounds” of venture capital were $5 to $10 million.” Mark Suster, GRP Partners …but what if innovation with software now cost 90% less than it used to?
- 5. The way we develop is changing… 7 Traits of Modern Applications 1. Omni-channel clients 2. Deployed on elastic infrastructure 3. Aggregate discrete services 4. Use managed APIs 5. Integrate open source software 6. Employ dev-ops techniques 7. Focus on measurable feedback Source: Flickr http://upload.wikimedia.org/wikipedia/commons/6/65/HP_garage_front.JPG)
- 6. Modern applications are complex © 2013 Forrester Research, Inc. Reproduction Prohibited 6
- 7. Context Is The Key To Modern Application © 2014 Forrester Research, Inc. Reproduction Prohibited
- 8. We need to prioritize and modernize the architectures we build
- 9. Building Modern Applications is hard! Are you Agile enough? Do you collect (and incorporate) rapid feedback? Can you design useful, usable, desirable experiences? Does your infrastructure evolve? Can you build high quality, multichannel, 5 star apps? Source: Flickr (http://www.flickr.com/photos/kaz25/2444344463/sizes/o/in/photostream//)
- 10. Modern Applications shift ALM focus Systems of Engagement Time to Feedback Time to Certainty Time to Safety Systems of Automation Systems of Record Lifecycle Focus
- 11. Adapting Agile principles › Use personas to drive insight › Create journey maps › Wireframes and prototypes build backlog › Feedback not requirements documents › Kanban boards to manage atomic demand › Analytics built into applications
- 12. A Multi-channel journey map Wow Enjoyable Functional Neutral Missed It Frustrating Awareness Consideration Research Purchase Engagement 1 2 3 4 5 6 7 8 9 10 Describe each step in the journey, the customer’s needs and perceptions 11 Identify customer and stages of journey Indicate Indicate significant primary (and secondary ) devices for each step steps Persona: James
- 13. Modern applications are complex systems Complex Unknowable Probe, sense, respond Complicated Knowable Sense, analyze, respond Chaos Turbulent and unconnected Act, sense, respond Simple Known Sense, categorize, respond Disorder Feedback Established Practices Using the Cynefin framework Hat Tip: Simon Bennett
- 14. We don’t how to make Modern Applications Complex Unknowable Complicated Knowable Chaos Turbulent and unconnected Simple Known Disorder Feedback Established Practices Systems of Engagement Systems of Operation Systems of Record
- 15. Modern applications evolve Amazon deployment stats (May -2012) › Mean time between deployments – 11.6 seconds › Max # deployment/hour – 1079 › Mean # of hosts simultaneously receiving a deployment – 10K › Max # of hosts simultaneously receiving a deployment – 30K Source: O’Reilly (http://assets.en.oreilly.com/1/event/60/Velocity%20Culture%20Presentation.pdf) Pictures: http://www.flickr.com/photos/blueridgekitties/4423381216/sizes/l/
- 16. A typical mobile app release schedule Features + Defect fixes V 1.0 (MVP) V 2.1 V 2.0 V 1.2.2 V 1.2.1 V 1.2 Regression + Emergency Patch New OS version released Regular Internal Sprint Cycle + Beta Testing (2 weeks) Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
- 17. A move toward different ALM processes › Fewer branches in SCM – evolve toward DVCS › Developers test › CI becomes decentralized, more atomic, and critical › You must run and consume beta › Mocks and mocking tools help manage multi layer complexity
- 18. Running “experiments” › Requirements are testable hypotheses › Multivariate testing with traffic routing › Services are architected for continuous deployment (e.g. feature flags, hot patching) › Releases become more “organic” › Development moves from an engineering process model to a scientific process model © 2013 Forrester Research, Inc. Reproduction Prohibited 18
- 19. How do you test? In production! › Test like you deploy – the last mile is beyond your control › Issues are hard to replicate in isolation › Big data requires storage › You need to harden your services › Delivered via a new generation of testing tools Pictures: http://www.flickr.com/photos/dyanna/3202542828/sizes/l/ Not Quite A Simian Army
- 20. Continuous Delivery Capability Is Key Level Focus Characteristics Results 5 Hypothesis-driven delivery Requirements include testable metrics Frequent use of A/B testing Services designed for CD DBMS changed decoupled from system changes Delivery enables business innovation 4 Release on demand Teams organized around services Deployment pipeline rejects bad changes Work delivered in small batches Comprehensive test + release automation Service always in a releasable state Capability >= Need 3 Regular releases w/ milestones CI and trunk-based development Automating provisioning and testing “Done” = tested and deployed Regular release cadence Capability < Need 2 Time-boxed releases Clear product ownership Change management controls <1 mo. cycles Some testing, release automation Planned releases Capability < Need 1 Heroic individuals Manual testing Integration explosion Manual provisioning Ad-hoc releases http://bit.ly/10hUmK3
- 21. 21 Shorter time-to-feedback = faster time-to-value Feedback drives improved customer experience and business results › The faster the feedback, the less waste. › The less waste, the lower the cost. › Faster feedback means better results to customers, faster. › Happier customers = more customers, increased revenue. › Increased revenue and lower cost = better business results. Source: November 18, 2013, “Measuring Mobile Apps” Forrester report
- 22. What if everything you’ve been told about managing developers was wrong? 22 Entire contents © 2010 Forrester Research, Inc. All rights reserved.
- 23. Software supply chains become social › Use of OSS and participation in OSS communities › Growth of “The Forge” as a developer’s home base › Service composition and the death of NIH › From Draftsmen -> Craftsmen › Crowdsourcing for software innovation › ALM data will become increasingly federated Picture: http://www.flickr.com/photos/mulad/200072198/sizes/l/
- 24. The public forge: hub of social development • GitHub • JazzHub • Bitbucket • CodePlex • Cloudforge • Sourceforge Github Growth Repositories Users 12,000,000 10,000,000 8,000,000 6,000,000 4,000,000 2,000,000 0 Feb-09 Jul-09 Jul-10 Apr-11 Sep-11 Sep-12 Dec-12 Apr-13 Dec-13
- 26. NYC Resistor
- 29. Intrinsic motivation dominates development Source: 2013 Developer Forrsights © 2012 Forrester Research, Inc. Reproduction Prohibited I contribute to open source projects Yes, 27% No , 73% N=1744 On average, how many hours a week do you spend programming personal or side projects not related to your day job? N=2042 23% 35% 24% 12% 7% I do not program or develop on my own time outside my day job <5 hours a week 5-10 hours a week 11-20 hours a week > 20 hours a week
- 30. What are the potential long term implications of social development? › Formation of developer collectives (Drupal) › Disruption of VC/capital markets (Kickstarter) › Disruption of sourcing industry – rise of freelancing › Different BT org models (Holacracy, devops) › Developer-led social movements (Mozilla vs. OK Cupid) › Ethical hacking (Angelhack, code for America) › Rise of alternative learning models - apprenticeship © 2013 Forrester Research, Inc. Reproduction Prohibited 30
- 31. Divide ALM development tasks by intent Algorithmic Emphasis › Build/Continuous Integration › Configuration management › Regression testing › Static analysis › Provisioning & Deployment › Gathering dev analytics › Defect remediation › Performance testing Heuristic Emphasis › Design › Development › Exploratory testing › Scheduling demand › Gathering requirements › Backlog prioritization › Refactoring › Performance tuning ALM Automation ALM Collaboration
- 32. Manage innovation and cost avoidance differently Attack Risk Heuristic Emphasis $100+/HR Dev Pro Feedback Recovery Innovation Predictability Cost avoidance High variance with limited data Under-estimated Medium variance with better data Low Variance w. high confidence data Over-estimated Attack Cost Algorithmic Emphasis $20/HR Dev Pro Process Guardrails Prevention Uncertainty Chaotic/Complex/Unknown Complicated/Known Simple Application Lifecycle Hat Tip: David Lubanko
- 33. You need to rethink your approach 1. ALM that’s fit to purpose 2. Revitalize architecture 3. Horizontal, not vertical 4. Support hi-perf teams 5. “Done” is DONE 6. Federate and collaborate 7. Make it social, fun and rewarding!
- 34. Thank you Jeffrey Hammond +1 978.226.8886 jhammond@forrester.com
Editor's Notes
- #27: http://en.wikipedia.org/wiki/NYC_Resistor
- #29: http://svenpet.com/2011/12/19/motivation-fedex-days/
- #32: Mike
- #33: Jeffrey IT Governance Consists of Three Types of Behavior: Type 1 - Development based decisions- High variance with limited data- Decisions on activities designed to gather data and reduce risk. Decisions are made at known checkpoints and are examinations of the value and effort assumptions underlying the project. Venture capitalists and strategic planning occupy this space. This is typically at the start of a project, before it ships before revenue is known. Type 2 - High level process based decisions- Systems engineering type of decisions, Lower variance with better data, processes in place, examples include Supply Chain management, Customer Relationship Management- These are discrete processes with dynamic flexibility required Type 3 - Transactional behavior- typical example is an assembly line. Discrete activities that can be estimated to high degree of accuracy, Examples include IC Manufacturing