Downloaded 157 times
Uploaded byFrank Vogelezang
Application Portfolio Management, the Basics - How much Software do I have
The document discusses the fundamentals of application portfolio management (APM), focusing on performance metrics such as cost per function point and productivity. It emphasizes the need for a consistent set of indicators to guide management decisions regarding software applications and their alignment with business strategy. Special challenges in sizing applications, particularly for complex systems like Siebel and SAP, are also outlined along with methods for effective size estimation.
More Related Content
Similar to Application Portfolio Management, the Basics - How much Software do I have
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: ApplicationPortfolio 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 westart 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 managementindicators • 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 perdepartment 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
- 19. 19 19 Group ICT - B&E - Application Support
- 20. 20 20 Group ICT - B&E - Application Support
Editor's Notes
- #4 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.
- #5 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.
- #6 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
- #7 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.
- #8 Vertalen
- #9 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
- #11 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.
- #12 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
- #13 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.
- #14 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
- #15 14 Siebel From the Responsibilities table it is possible to determine which business entities and which applets are actually used.
- #16 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.
- #17 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.
- #18 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.
- #19 18 More information If you want more information you can reach us at these adresses or download the paper.