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 ID: 339576
Download Presentation The PPT/PDF document "ALM Maturity" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1Slide2
ALM Maturity
Tina Erwee
Senior consultant
Microsoft Consulting Services
Session Code: ARC203Slide3
Key take-awaysWhat is ALM and why is it importantThe different maturity levelsWhat discipline areas are coveredWhat maturity levels to strive for
How mature are YOUR ALM processes? Slide4
What is ALM and why is it importantALM stands for Application Lifecycle ManagementA mature Application Lifecycle Management approach is key to IT being a strategic asset to the businessALM 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 solutionSlide5
ALM as a Business StrategySlide6
Business Strategy and ITThe importance of being differentA primary goal of business strategy is to create competitive advantageThe 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 differentSlide7
Relative Benefit of an InnovationFrom competitive advantage to cost of doing businessTime
Competitive
Advantage
to Firm
First firm in an industry implements innovation
Third firm in an industry implements innovation
Second firm in an industry implements innovationSlide8
CompetitiveAdvantage to FirmCategorizing IT Spending
Strategic vs. utility
Utility IT
Window of differentiation
Strategic ITSlide9
Making the ConnectionBusiness 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 ProcessesSlide10
What is Application Lifecycle ManagementSlide11
Application Lifecycle Management IS?Defining ALM isn’t EasyOften Equated with SDLCALM 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”Slide12
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
Deployment
Idea
End
of LifeSlide13
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
GovernanceSlide14
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, v1Slide15
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
MonitorSlide16
The different maturity levelsSlide17
ALM Maturity LegendSlide18
ALM Maturity LevelsBasicProcesses are typically homegrownProcesses 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.Slide19
ALM Maturity LevelsStandardisedProcesses 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.Slide20
ALM Maturity LevelsAdvancedThe right process across the organization The processes are clearly documented Processes are maintainedProcesses are following industry best practices This level is where most companies strive to be.Slide21
ALM Maturity LevelsDynamicThe Dynamic maturity level is rarely foundIt 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 practicesSlide22
ALM Practice AreasMicrosoft identified the following practice areas:Architecture and DesignUser ExperienceRequirements Management
Software Coding Quality
Software Configuration Management
Data Management
Project Management
Deployment and Operations
Quality Assurance and Test
Application DeliverySlide23
Typical ALM ChallengesSlide24
Typical ALM challengesSlide25
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”Slide26
What goes wrong at immature levels?Architecture and designFunctionality is repeated in several different applicationsThere is very little or no overall architecture and architectural standardsA 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! Slide27
What goes wrong at immature levels?User ExperiencePoor UX in internal facing applications cost moneyProductivity is negatively impactedSwitching between screens to complete a single taskCopy 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 sitesSlide28
What goes wrong at immature levels?Requirements ManagementPoor requirements are expensiveDevelopment time is lengthenedDevelopers spend time clarifying requirements rather than developing softwareRequirements 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 resourcesSlide29
What goes wrong at immature levels?Software coding qualityPoor code quality is expensiveHigher defect rateExpensive to make changesDifficult to find the right placeLearning curve for new developers
Security weaknesses
Performance issues
Frustrated and unhappy developers!! Which can lead to your company loosing highly skilled and valuable resourcesSlide30
Aside
I don’t care if it works
on your machine.
We are not
shipping
your machine!Slide31
What goes wrong at immature levels?Software configuration managementPoor software configuration management is expensiveEmbarrassing – reintroduction of previously fixed bugsLost 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 environmentSlide32
What goes wrong at immature levels?Data managementLost data – poor back-up proceduresUnable 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 representSlide33
What goes wrong at immature levels?Project management – PMs with no clear and up to date of project statusBroken promises!Projects are lateProjects run over budget90% syndromeOverworked developers
Overtime, stress
Us vs. Them syndromeSlide34
What goes wrong at immature levels?Deployment and operationsWrong versions are deployedDeployment takes too longBugs aren’t fixed quickly enoughSource of a bug is not identified soon enoughBugs 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 errorSlide35
What goes wrong at immature levels?Quality Assurance and TestTesting should start with requirements or else:Requirements might be misunderstood and therefore incorrectly programmedNot 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 applicationSlide36
What goes wrong at immature levels?Application DeliveryIf your application delivery methodology is too cumbersome you will lag too far behind BusinessThis will cause the Business to loose the competitive edgeShort 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 qualitySlide37
My mottoI would rather fail three months into a two-year project than three years into a two-year project.Slide38
What level to strive for?Slide39
Advanced is good enough!AdvancedThe right process across the organization The processes are clearly documented Processes are maintainedProcesses 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 OperationsSlide40
Flexible
Scalable
Interoperable
Secure
Manageable
An
Effective
ALM Platform Involves:
Process
Technology
People
Skilled and Highly Productive Teams
Adaptive to change
Clear visibility and accountability (
KPI’s
)
Compliance and risk managementSlide41
Why Slow Adoption of Team Tools?To Adopt Team Tools requires more then individual developers changing, The process had to changeThe change was meet with resistanceFocus was on optimizing individual practice and not process as a whole.
Vendors did not get it!
Team Tools enable transparency developers where not comfortable withSlide42
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 ToolSlide43
What are your next steps?Do an online assessmentWork out a heat map based on the resultsAsk Microsoft to assist with a full ALM assessmentSlide44
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 ManagementSlide45
Find out where you areAn online ALM assessment can be completed by an individual or a teamUnderstanding of exactly where IT processes are strong and where they can be improvedPeer 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 partnersSlide46
Online AssessmentThe online assessment can be used for:A quick overview of current conditions An initial baseline measurement of their development processesTo track progress over time with periodic surveys
A conversation starter for deeper dialogue about ALM
www.microsoft.com/assessSlide47
question & answerSlide48
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. Slide49
Track Resourceswww.microsoft.com/assess
msdn.microsoft.com/en-
za
/architecture
www.codeplex.comSlide50
Related ContentDTL203 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 SessionSlide51
Complete a session evaluation and enter to win!
10 pairs of MP3
sunglasses
to be
wonSlide52
©
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.