After two external benchmarks, the Software Application Support division decided that the only way to quantitatively manage application support was by establishing a sufficient estimate of the size of the application portfolio. Based on criteria from Gartner’s Application Benchmark a selection was made regarding which applications made up the application portfolio. Five different methods were used to size approximately three hundred applications, each with its own precision and cost efficiency: Gartner Fast FPA estimation, Backfiring from LoC for some older PL/1 and Assembler applications, detailed counts with NESMA FPA and COSMIC for newly developed systems and backtracking from budget for less important smaller applications. The size estimations were made by regular support personnel with little training in functional size measurement. A sample selection was reviewed by an experienced consultant, in order to detect possible pitfalls and ambiguities. The results from the review led to a re-evaluation of most of the FPA-estimations, with a higher precision and greater consistency. The results of these size estimates can now be used to compare parts of the portfolio and to quantitatively manage the (support of the) portfolio.
"I see eyes in my soup": How Delivery Hero implemented the safety system for ...
Application Portfolio Management, the Basics - How much Software do I have
1. Application Portfolio
Management, the basics
How much software do I have
Marcel Rispens, Rabobank
Frank Vogelezang, Sogeti
May 11, 2007
Group ICT - B&E - Application Support
2. Content
Part 1: Application Portfolio Management Marcel Rispens
– Why did we start with APM
– The first management indicators
– APM parameters
Part 2: Application Portfolio Measurement Frank Vogelezang
– The base metric: size
– Current functional size measurements
– Improving by review
– Special sizing challenges: packages
– Size estimation technique
2
2 Group ICT - B&E - Application Support
3. Application Portfolio
Management
Marcel Rispens
3
3 Group ICT - B&E - Application Support
4. Why did we start with APM
• For comparison of departments and a baseline for improvement we
needed information on:
– performance on cost
– performance on productivity
– performance on quality
• Benchmarks by Maturity and Gartner
• Application Portfolio Management is the best way to manage on
performance in a support environment and to start with building up
influence in IT investment decisions
4
4 Group ICT - B&E - Application Support
5. The first management indicators
• Cost per function point
– detailed view on cost-related performance
– build-up of this cost gives directions for improvement
• Function points serviced per full-time equivalent
– detailed view on productivity
– trigger to improve/remove service intensive applications
• Defects per 1,000 function points
– detailed view on quality
– trigger to improve/remove defect sensitive applications
5
5 Group ICT - B&E - Application Support
6. APM, overall goals
• Providing the basis for a consistent set of application related
discussions
• Communicating the status of the exisiting application set
• Highlighting and aligning which applications support the business
strategy and vision and which applications are likely to constrain the
business in the future
• Uncovering major issues associated with applications
Taken from: IT Portfolio Management step-by-step, B. Maizlish and R. Handler
6
6 Group ICT - B&E - Application Support
7. benchmarklijn
€ 84
laag gemiddeld hoog
Bedrijfsbelang
7
7 Group ICT - B&E - Application Support
8. APM indicators
• Size
• Cost per function point
• Service level
– Gold
– Silver
– Bronze
• Architectural fit
• Complexity
• Business importance
8
8 Group ICT - B&E - Application Support
9. Application Portfolio Management, the basics:
Establish a way to quantify the amount of software you have
to support with a precision that suits your management
targets
Build a limited number of indicators which you can use to
guide management decisions
9
9 Group ICT - B&E - Application Support
10. Functional size per department x 1,000 FP
150
133
125
100
75 69
75
53 54
50
15
25
0
DK LB Siebel SAP KRN KGICT
Application Portfolio
Measurement
Frank Vogelezang
10
10 Group ICT - B&E - Application Support
11. The base metric: size
• Application size is the base metric to make different aspects of the
software portfolio comparable
• Currently used functional size measurement methods:
– Fast FPA estimation
– Function Point Analysis
– COSMIC
– Backfiring
– Backtracking from budget
11
11 Group ICT - B&E - Application Support
12. Improving by review
Size measurement method Review results
• Fast FPA estimation • Corrections on the size between
-60% and +130%
On average: -30%
• Function Point Analysis • Only corrections for scope creep
• COSMIC • Only corrections for scope creep
• Backfiring • Not reviewed: the method is as
good as the tool that is used
• Backtracking from budget • Not reviewed
12
12 Group ICT - B&E - Application Support
13. Special sizing challenges: packages
• Six categories can be distinguished:
– as-is, implemented without modifications
– as integrated part of a larger application
– new functionality in addition to existing package functionality
– new functionality to enable interfacing with the packaged software
– unused functionality of the package
– customized for this installation, within the package
• Two special challenges:
13
13 Group ICT - B&E - Application Support
14. Special sizing challenge: Siebel
• Over 1,000 tables
• Over 1,000 applets
• Start from the Responsibilities table
– Determine the number of business entities in use as logical files
– Determine the number of list applets as 1 External Output
– Determine the number of form applets as 3 External Inputs
1 External Output
14
14 Group ICT - B&E - Application Support
15. Special sizing challenge: SAP
• Over 40,000 tables
• Over 70,000 transactions
• Some rules of thumb:
– logical files make up about 25% of the total size in a SAP application
– reports make up about 25% of the total size in a SAP application
– expect between ½ and 2 logical files per 3 external inputs
• Determine the SAP transactions that are active
– consider the active transactions that are reports to be External Outputs
– consider the other active transactions to be External Inputs
– derive the number of logical files from the number of External Inputs
– check if the rules of thumb apply
15
15 Group ICT - B&E - Application Support
16. Size estimation technique
• Questionnaire for functional owners or support staff
• Based on Function Point Analysis categories:
– Internal Logical Files
– External Interface Files
– External Inputs, divided into:
– maintenance screens and functions
– inbound interfaces
– background processes initiated by the user
– External Outputs, divided into:
– inquiries
– reports
– outbound interfaces
– unique controls to select field values
– External Inquiries
– inquiries with a unique identifying key
– help functionality
16
16 Group ICT - B&E - Application Support
17. Application Portfolio Measurement:
Size estimation, combined with expert review, can give size
measurement results that are precise enough for Application
Portfolio Management purposes, but require only a limited
amount of resources
17
17 Group ICT - B&E - Application Support
18. More information:
• Marcel Rispens
m.a.rispens@rn.rabobank.nl
http://metrieken.sogeti.nl
• Frank Vogelezang
frank.vogelezang@sogeti.nl
18
18 Group ICT - B&E - Application Support
This is what we mean with APM as a part of IT PM as a whole. Thanks to Gartner for this picture, it shows what we are doing know. We are building an application inventory with data and indicators which can be used in life cycle management and support IT investments decisions. Of course we have a Configuration management database and other inventories but they are primarily used to support ITIL processes. (best practice for IT support; incident management, change management) Essentially we are trying to play a more pro-active role in IT life cycle management. Traditionally IT support departments in the Netherlands are rather reactive and introvert. Business and development departments often are the players. We are becoming more self confident.
It didn’t start with APM. In the article we explain that different application support departments merged to one and we needed a kind of base line. How are we doing? In addition we used models like ITIL and ASL (Application Support Library) to design the new department. In ASL, Portfolio- and Life cycle management are introduced but at the beginning we didn’t get any further than theoretical discussions. For baselining we did a benchmark by Maturity in 2005. They introduced function points, a rather new phenomenon for us. What that meant, Frank will explain in detail. We got a first view on our performance based on three indicators: euro/fp, fp/fte and defects per 1000fp. We repeated the benchmark in 2006 by Gartner. We became familiar with this type of indicators and to the new way to look at our performance. Till then management information was rather “traditional” and not focused on output in a comparable way. You do need a factor which makes things comparable > function points. At that point, autumn 2006, APM finally clicked. If we use the new indicators and combine these with a few other parameters with a beginning of an application inventory with meaningful data for investment-decision making. If for instance we can show that a lot of small applications in a segment of the portfolio has a cost/fp of xx, That SAP can cover the functionality of these applications and we can show that we support SAP for a much lower cost/fp, Then you have arguments to execute a more detailed discovery to the possibilities of an IT-investment in that direction. I will emphasize that we chose for a very pragmatic approach. We realize all the time that some data or indicators are nor reliable enough yet. We know from a lot of applications we dot have reviewed FP-counts, we are improving contract management to get a complete and reliable view on our software licenses. It’s getting better but all kind of departments took software costs without a proper centralized view.
These are the indicators we now use to manage our department financially. We quartely make reports with these indicators: - on Application services department level - on sub departmental level - with or without large applications like SAP and Siebel - at a detailed application level. Not to manage one application to the benchmark but to zoom in on the circumstances and to analyse
Other ICT portfoliomanagement initiatives has been undertaken the last year (not always knowing about the existence of others!) within Rabobank, in some business departments, within Program management and with us, Application Support. Next week we will try to join those initiatives within Group ICT. Goal is to investigate possibilities to develop overall IT Portfolio management. That means that IT discoveries, IT programs and projects and IT Assets are managed consistently to improve decision making on IT investments.
Vertalen
Something about the chosen parameters, or indicators. At this moment we’re working with this set. Why these? More or less common sense and to start with something! We relate cost per functionpoint to Service level, Architecture, Complexity and Business importance. We use graphics, I show you one in a moment. We will problably standardize this set and comply to “standards” or best practices. Gartner e.g publiced a healthcheck for applications (Use a healthcheck to determine you’re applications “fitness for duty”) It covers 14 indicators
10 Application Portfolio Measurement As Marcel has shown it is necessary to measure the portfolio to be able to do APManagement. I will share with you some of the problems we encountered and the solutions we came up with. Een beeld schetsen van de portfolio op basis van de grafiek.
11 The base metric: size Four different functional size measurement methods used: Fast FPA estimation for the largest part of the portfolio FPA where it was available COSMIC for recent custom-built applications Backfiring for older PL1 and Assembler Backtracking when FPA was not worth the time investment
12 Improving by review Necessary for Fast FPA estimation and on average a size estimate reduction of 30%. FPA and COSMIC only corrections fro scope creep For backfiring and backtracking reviews won’t improve the quality.
13 Special sizing challenges: packages Six categories As-is (support cost not determined by size, but by other factors) Integrated part, considered as separate package New functionality, considered as a separate application Interfacing with the package, considered as a separate application Unused functionality, ignored at this moment (will perhaps be used later for architectural decisions) Customisation within the package, only count the part of the package that is actually in use Two special cases: Siebel and SAP Tellen we toch omdat ze voor beheersinspanning vergelijkbaar zijn met gebouwde applicaties
14 Siebel From the Responsibilities table it is possible to determine which business entities and which applets are actually used.
15 SAP Based on a number of rules from our own and IFPUG member experience we worked out a model to make a size estimate for a SAP implementation.
16 Size estimation technique To allow functional owners or support staff to make a functional size estimate we developed a questionnaire with which they could easily make a first estimate. Based on FPA. Together with a review by a size measurement expert it gives a good indication of size to serve as input to the APM process.
17 Application Portfolio Measurement With a limited amount of resource it is possible to create size estimates that are precise enough to serve APM purposes.
18 More information If you want more information you can reach us at these adresses or download the paper.