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

Competitive Advantage to Firm Categorizing IT Spending Strategic vs. utility Utility IT Window of differentiation Strategic 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 Development Operations Governance DeploymentIdeaEnd 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 Project Portfolio Management Application Portfolio Management Business Case Development Operations Development Governance

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

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

The different maturity levels

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

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

“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

 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

Why Slow Adoption of Team Tools?

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

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

Sessions On-Demand & Community Resources for IT Professionals Resources for Developers 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.

Track Resources msdn.microsoft.com/en-za/architecture

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

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

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