ALM MaturityTina ErweeSenior consultantMicrosoft Consulting ServicesSession Code: ARC203

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

ALM as a Business Strategy

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

What is Application Lifecycle Management

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

The different maturity levels

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 Challenges

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

Aside

I don’t care if it works on your machine.

We are not shipping

your machine!

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.

What level to strive for?

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

question & answer

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

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.