Tina Erwee Senior consultant Microsoft Consulting Services Session Code: ARC203 Key take-aways What is ALM and why is it important The different maturity levels What discipline areas are covered What maturity levels to strive for How mature are YOUR ALM processes? What is ALM and why is it important ALM stands for Application Lifecycle Management A mature Application Lifecycle Management approach is key to IT being a strategic asset to the business ALM is more than just the SDLC since it covers the entire lifespan of a software solution – from the original idea when a business need is identified right through to decommissioning of the solution ALM as a Business Strategy Business Strategy and IT The importance of being different A primary goal of business strategy is to create competitive advantage The essence of that advantage is being different Virtually all business strategies today have an IT component But most of IT isn’t focused on being different Relative Benefit of an Innovation From competitive advantage to cost of doing business First firm in an industry implements innovation Competitive Advantage to Firm Second firm in an industry implements innovation Third firm in an industry implements innovation Time Categorizing IT Spending Strategic vs. utility Window of differentiation Competitive Advantage to Firm Strategic IT Utility IT Making the Connection Business strategy and application platforms Business strategy means being different from the competition Being different relies on differentiated IT Differentiated IT commonly means custom applications Custom application development depend on you ALM Platform and Processes What is Application Lifecycle Management Application Lifecycle Management IS? Defining ALM isn’t Easy Often Equated with SDLC ALM is much more than SDLC “An application’s lifecycle includes the entire time during which an organization is spending money on this asset, from the initial idea to the end of the application’s life” The Three Aspects of ALM Turning Business Ideas into Software Governance All decision making and project management Development Happens first between idea and deployment Continually Reappears throughout an Applications Life Operations Run and Manage the Application Governance Development Operations Idea Deployment End of Life Aspects of ALM Governance Key to Maximizing Return Start by Developing a Business Case Manage Development with PPM Manage the Application like any other business asset with APM until End Of Life Business Case Development Project Portfolio Management Governance Development Operations Application Portfolio Management Aspects of ALM Development A fundamental part of every Application’s Lifecycle Define Requirements based on the Business Case and Design, Develop and Test the Application Manage Maintenance of the Deployed Application Perform another develop cycle to build new version SDLC is not ALM, but a part of the ALM story SDLC, v1 SDLC, v2 Maintenance Governance Development Operations Aspects of ALM Operations Deployment Intimately Connected with Development And a fundamental part of Operations Continuous Monitoring and Updates Deploy Monitor Deploy Updates Governance Development Operations The different maturity levels ALM Maturity Legend Basic • Homegrown software development processes in use, potentially due to technology / tool limitations Standard • Software development best practices performed more uniformly • Tools not fully integrated into the development environment Advanced • Best practices adopted, documented, and maintained • Tools are fully integrated into the development environment Dynamic • Development practices are highly innovative and demonstrate industry leadership ALM Maturity Levels Basic Processes are typically homegrown Processes are typically not documented There are little to no cross-functional communications; Processes are performed in an ad-hoc, informal manner. These companies are not professional development organizations They usually do not know the next steps for developing software. ALM Maturity Levels Standardised Processes are performed in a more uniform way but not 100 percent consistently A few departments follow the process but you see that some of the other areas do not. The company may follow best practices, but it is not receiving the value because of implementation or commitment. ALM Maturity Levels Advanced The right process across the organization The processes are clearly documented Processes are maintained Processes are following industry best practices This level is where most companies strive to be. ALM Maturity Levels Dynamic The Dynamic maturity level is rarely found It is not feasible for most companies to be performing at this level. Therefore, do not be alarmed or try to move into this maturity level since it may not make economic or business sense The companies that qualify for this level generally perform at the top of their industry and include the lower maturity levels in their practices ALM Practice Areas Microsoft identified the following practice areas: Architecture and Design User Experience Requirements Management Software Coding Quality Software Configuration Management Data Management Project Management Deployment and Operations Quality Assurance and Test Application Delivery Typical ALM Challenges Typical ALM challenges Application Delivery Management Architecture and Design User Experience Quality Assurance and Test Requirement s Management Deployment and Operations Software Coding Quality Project Management Data Management Software Configuration Management Typical ALM challenges “We don’t have good visibility into project status” “Our teams are not communicating effectively” “Requirements are not sufficiently defined or tracked” “We need lightweight, agile development processes” “Software is not adequately tested” “Cost of maintaining and operating the solution exceeds the business benefit” What goes wrong at immature levels? Architecture and design Functionality is repeated in several different applications There is very little or no overall architecture and architectural standards A minor change can cause massive headaches: Time consuming to implement Costly A change in one area breaks functionality in another area There is very little direction for the future of the application It becomes a GREAT BALL OF MUD! What goes wrong at immature levels? User Experience Poor UX in internal facing applications cost money Productivity is negatively impacted Switching between screens to complete a single task Copy and paste between screens Data capture errors impact on the quality of data External facing web sites with a poor user experience will loose your company business Think of the difficulties to find a good movie and book a seat on some of our local movie theatre sites Or find the cheapest air fare and book your ticket on some of our airline sites What goes wrong at immature levels? Requirements Management Poor requirements are expensive Development time is lengthened Developers spend time clarifying requirements rather than developing software Requirements are incorrectly implemented leading to project failure Redevelopment has to occur which increases the cost of the application overall Frustrated and unhappy developers!! Which can lead to your company loosing highly skilled and valuable resources What goes wrong at immature levels? Software coding quality Poor code quality is expensive Higher defect rate Expensive to make changes Difficult to find the right place Learning curve for new developers Security weaknesses Performance issues Frustrated and unhappy developers!! Which can lead to your company loosing highly skilled and valuable resources Aside What goes wrong at immature levels? Software configuration management Poor software configuration management is expensive Embarrassing – reintroduction of previously fixed bugs Lost source code Confusion as to which is the current version Development has to halt when a Production bug has to be fixed The incorrect version of the application is released into the Production environment What goes wrong at immature levels? Data management Lost data – poor back-up procedures Unable to roll back to previous version of the database Poor application performance due to poor DB design “Unmaintainable” stored procedures Data structures become convoluted Column names no longer describes the data it represent What goes wrong at immature levels? Project management – PMs with no clear and up to date of project status Broken promises! Projects are late Projects run over budget 90% syndrome Overworked developers Overtime, stress Us vs. Them syndrome What goes wrong at immature levels? Deployment and operations Wrong versions are deployed Deployment takes too long Bugs aren’t fixed quickly enough Source of a bug is not identified soon enough Bugs are not reported to the correct team Is it a network issue? Not enough capacity on a server? A software configuration error? A real bug in the code? An ID 10 T user error What goes wrong at immature levels? Quality Assurance and Test Testing should start with requirements or else: Requirements might be misunderstood and therefore incorrectly programmed Not all areas are tested Poor performance in Production – Stress and Performance testing Users will only test the paths they expect to use – edge cases might not be tested Some functionality gets tested over and over while other bits and pieces don’t get tested at all and then break in Production on the first day! Poor impression is created and Business looses confidence in the application What goes wrong at immature levels? Application Delivery If your application delivery methodology is too cumbersome you will lag too far behind Business This will cause the Business to loose the competitive edge Short term Insurance – the advent of the No claim bonus! Banking – new exciting products Cellular companies – SMS banking Big bang approaches Requirements are out of date even before you implement Applications seem more expensive and Business cannot percieve the value - canned development projects Controlled agility is the answer – short iteration of the full SDLC providing the Business with core functionality quickly and of high quality My motto I would rather fail three months into a two-year project than three years into a two-year project. What level to strive for? Advanced is good enough! Advanced The right process across the organization The processes are clearly documented Processes are maintained Processes are following industry best practices This level is where most companies strive to be Timely delivery of high quality software that is maintainable and can be monitored by Operations An Effective ALM Platform Involves: Skilled and Highly People Process Clear visibility and accountability (KPI’s) Compliance and risk management Productive Teams Adaptive to change Technology Flexible Scalable Interoperable Secure Manageable Why Slow Adoption of Team Tools? To Adopt Team Tools requires more then individual developers changing, The process had to change The change was meet with resistance Focus was on optimizing individual practice and not process as a whole. Team Tools enable transparency developers where not comfortable with Modern ALM Tools Development Tool Architecture Tool Test Tool Design Documents Requirements Source Code Versions Test Cases Project Stats Project Management Tool Requirements Tool Shared Server What are your next steps? Do an online assessment Work out a heat map based on the results Ask Microsoft to assist with a full ALM assessment What is an ALM Assessment? Measures organization’s capabilities against industry and Microsoft best practices in disciplines across the lifecycle – Demand and Portfolio Management – Requirements Management – Project Management – Quality Assurance – Build and Release Management – Change Management – Architecture & Design – Data Management Find out where you are An online ALM assessment can be completed by an individual or a team Understanding of exactly where IT processes are strong and where they can be improved Peer comparisons, so you can see how your processes set up against others in your industry and organization size An important discussion document for your team, management, and partners Online Assessment The online assessment can be used for: A quick overview of current conditions An initial baseline measurement of their development processes To track progress over time with periodic surveys A conversation starter for deeper dialogue about ALM www.microsoft.com/assess Resources www.microsoft.com/teched www.microsoft.com/learning Sessions On-Demand & Community Microsoft Certification & Training Resources http://microsoft.com/technet http://microsoft.com/msdn Resources for IT Professionals Resources for Developers Track Resources www.microsoft.com/assess msdn.microsoft.com/en-za/architecture www.codeplex.com Related Content DTL203 What’s New in Team Foundation Server 2010? DTL305 Managing Releases Between Your Development and QA with Team System 2008 DPR201 The Daily Scrum DTL301 Power Tools on Team Foundation Server 2008 DTL205 A Lap Around Team System 2010 Architecture Edition DTL202 Team System 2010 Development Essentials WTB212 How Microsoft and Others Use Team Foundation Server WTB201 Architecture Whiteboard Session 10 pairs of MP3 sunglasses to be won Complete a session evaluation and enter to win! © 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.