ALM Maturity - Microsoft Center

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.