2. Tina Erwee Senior consultant Microsoft Consulting Services Session Code: ARC203

3. 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?

4. 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

5. ALM as a Business Strategy

6. 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

7. Relative Benefit of an Innovation From competitive advantage to cost of doing business Time Competitive Advantage to Firm First firm in an industry implements innovation Third firm in an industry implements innovation Second firm in an industry implements innovation

8. Competitive Advantage to Firm Categorizing IT Spending Strategic vs. utility Utility IT Window of differentiation Strategic IT

9. 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

10. What is Application Lifecycle Management

11. 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”

12. 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 Development Operations Governance DeploymentIdeaEnd of Life

13. 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 Project Portfolio Management Application Portfolio Management Business Case Development Operations Development Governance

14. 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 Operations Development Governance Maintenance SDLC, v2 SDLC, v1

15. Aspects of ALM Operations Deployment Intimately Connected with Development And a fundamental part of Operations Continuous Monitoring and Updates Operations Development Governance Deploy Updates Deploy Monitor

16. The different maturity levels

17. ALM Maturity Legend Homegrown software development processes in use, potentially due to technology / tool limitations Basic Software development best practices performed more uniformly Tools not fully integrated into the development environment Standard Best practices adopted, documented, and maintained Tools are fully integrated into the development environment Advanced Development practices are highly innovative and demonstrate industry leadership Dynamic

18. 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.

19. 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.

20. 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.

21. 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

22. 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

23. Typical ALM Challenges

24. Typical ALM challenges

25. “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”

26. 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!

27. 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

28. 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

29. 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

30. Aside

31. 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

32. 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

33. 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

34. 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

35. 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

36. 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

37. My motto I would rather fail three months into a two-year project than three years into a two-year project.

38. What level to strive for?

39. 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

40.  Flexible  Scalable  Interoperable  Secure  Manageable  Flexible  Scalable  Interoperable  Secure  Manageable An Effective ALM Platform Involves: Process Technology People  Skilled and Highly Productive Teams  Adaptive to change  Skilled and Highly Productive Teams  Adaptive to change  Clear visibility and accountability (KPI’s)  Compliance and risk management  Clear visibility and accountability (KPI’s)  Compliance and risk management

41. Why Slow Adoption of Team Tools?

42. Modern ALM Tools Test Tool Project Management Tool Requirements Tool Shared Server Requirements Source Code Versions Test Cases Design Documents Project Stats Development Tool Architecture Tool

43. 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

44. 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

45. 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

46. 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

48. www.microsoft.com/teched Sessions On-Demand & Community http://microsoft.com/technet Resources for IT Professionals http://microsoft.com/msdn Resources for Developers www.microsoft.com/learning Microsoft Certification & Training Resources Resources Required Slide Speakers, TechEd 2009 is not producing a DVD. Please announce that attendees can access session recordings at TechEd Online. Required Slide Speakers, TechEd 2009 is not producing a DVD. Please announce that attendees can access session recordings at TechEd Online.

49. Track Resources www.microsoft.com/assess msdn.microsoft.com/en-za/architecture www.codeplex.com

50. 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

51. Complete a session evaluation and enter to win! 10 pairs of MP3 sunglasses to be won

52. © 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.