tina erwee senior consultant microsoft consulting services session code: arc203
TRANSCRIPT
Key take-aways
What is ALM and why is it importantThe different maturity levelsWhat discipline areas are coveredWhat maturity levels to strive forHow mature are YOUR ALM processes?
What is ALM and why is it important
ALM 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 solution
Business Strategy and ITThe importance of being different
A primary goal of business strategy is to create competitive advantage
The essence of that advantage is being differentVirtually all business strategies today have an IT component
But most of IT isn’t focused on being different
Relative Benefit of an InnovationFrom competitive advantage to cost of doing business
Time
CompetitiveAdvantage to Firm
First firm in an industry implements innovation
Third firm in an industry implements innovation
Second firm in an industry implements innovation
CompetitiveAdvantage to Firm
Categorizing IT SpendingStrategic vs. utility
Utility IT
Window of differentiation
Strategic IT
Making the ConnectionBusiness strategy and application platforms
Business strategy means being different from the competitionBeing different relies on differentiated ITDifferentiated IT commonly means custom applicationsCustom application development depend on you ALM Platform and Processes
Application Lifecycle Management IS?
Defining ALM isn’t EasyOften 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 ALMTurning Business Ideas into Software
GovernanceAll decision making and project management
DevelopmentHappens first between idea and deploymentContinually Reappears throughout an Applications Life
OperationsRun and Manage the Application
Development
Operations
Governance
DeploymentIdea End of Life
Aspects of ALMGovernance
Key to Maximizing ReturnStart by Developing a Business CaseManage Development with PPMManage 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 ALMDevelopment
A fundamental part of every Application’s LifecycleDefine Requirements based on the Business Case and Design, Develop and Test the ApplicationManage Maintenance of the Deployed ApplicationPerform another develop cycle to build new version
SDLC is not ALM, but a part of the ALM story
OperationsDevelopment
GovernanceMaintenance
SDLC, v2SDLC, v1
Aspects of ALMOperations
Deployment Intimately Connected with Development
And a fundamental part of OperationsContinuous Monitoring and Updates
OperationsDevelopmentGovernance
Deploy Updates
Deploy Monitor
ALM Maturity Legend• Homegrown software development processes in use,
potentially due to technology / tool limitationsBasic• Software development best practices performed more
uniformly• Tools not fully integrated into the development
environmentStandard
• Best practices adopted, documented, and maintained• Tools are fully integrated into the development
environmentAdvanced
• Development practices are highly innovative and demonstrate industry leadershipDynamic
ALM Maturity Levels
BasicProcesses 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 organizationsThey usually do not know the next steps for developing software.
ALM Maturity Levels
StandardisedProcesses 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
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.
ALM Maturity Levels
DynamicThe 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 practices
ALM Practice Areas
Microsoft identified the following practice areas:Architecture and DesignUser ExperienceRequirements ManagementSoftware Coding QualitySoftware Configuration ManagementData ManagementProject ManagementDeployment and OperationsQuality Assurance and TestApplication Delivery
Typical ALM challengesArchitecture and Design User
Experience
Requirements
Management
Software
Coding Quality
Software
Configuration
Management
Data Manage
ment
Project Manage
ment
Deployment and
Operations
Quality Assurance and
Test
Application
Delivery Manage
mentLack of visibility into
project status
Ineffective
team communicatio
n Balancing
business
demands with project
risk
Unpredictable delivery times
and quality
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 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 implementCostlyA change in one area breaks functionality in another area
There is very little direction for the future of the applicationIt becomes a GREAT BALL OF MUD!
What goes wrong at immature levels?
User ExperiencePoor UX in internal facing applications cost money
Productivity is negatively impactedSwitching between screens to complete a single taskCopy and paste between screens
Data capture errors impact on the quality of dataExternal 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 sitesOr find the cheapest air fare and book your ticket on some of our airline sites
What goes wrong at immature levels?
Requirements ManagementPoor requirements are expensive
Development time is lengthenedDevelopers spend time clarifying requirements rather than developing softwareRequirements are incorrectly implemented leading to project failureRedevelopment 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 qualityPoor code quality is expensive
Higher defect rateExpensive to make changes
Difficult to find the right placeLearning curve for new developers
Security weaknessesPerformance issues
Frustrated and unhappy developers!! Which can lead to your company loosing highly skilled and valuable resources
What goes wrong at immature levels?
Software configuration managementPoor software configuration management is expensive
Embarrassing – reintroduction of previously fixed bugsLost source code Confusion as to which is the current versionDevelopment has to halt when a Production bug has to be fixedThe incorrect version of the application is released into the Production environment
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 proceduresData structures become convolutedColumn 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 lateProjects run over budget90% syndromeOverworked developersOvertime, stressUs vs. Them syndrome
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 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 testedPoor performance in Production – Stress and Performance testingUsers will only test the paths they expect to use – edge cases might not be testedSome 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 BusinessThis will cause the Business to loose the competitive edge
Short term Insurance – the advent of the No claim bonus!Banking – new exciting productsCellular companies – SMS banking
Big bang approachesRequirements are out of date even before you implementApplications 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.
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 beTimely delivery of high quality software that is maintainable and can be monitored by Operations
FlexibleScalable Interoperable
SecureManageable
An Effective ALM Platform Involves:
Process
Technology
PeopleSkilled and Highly Productive Teams
Adaptive to change
Clear visibility and accountability (KPI’s)
Compliance and risk management
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 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 with
Modern ALM Tools
Test Tool
Project Management
ToolRequirements
Tool
Shared Server
Requirements
Source Code
Versions
Test Cases
Design Documents
Project Stats
Development ToolArchitecture
Tool
What are your next steps?
Do an online assessmentWork out a heat map based on the resultsAsk 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 improvedPeer comparisons, so you can see how your processes set up against others in your industry and organization sizeAn 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 processesTo track progress over time with periodic surveysA conversation starter for deeper dialogue about ALM
www.microsoft.com/assess
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
Track Resources
www.microsoft.com/assessmsdn.microsoft.com/en-za/architecturewww.codeplex.com
Related Content
DTL203 What’s New in Team Foundation Server 2010?DTL305 Managing Releases Between Your Development and QA with Team System 2008DPR201 The Daily ScrumDTL301 Power Tools on Team Foundation Server 2008DTL205 A Lap Around Team System 2010 Architecture Edition DTL202 Team System 2010 Development Essentials
WTB212 How Microsoft and Others Use Team Foundation ServerWTB201 Architecture Whiteboard Session
© 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.