application portfolio models in practice - Semantic Scholar

APPLICATION PORTFOLIO MODELS IN PRACTICE – A COMPARATIVE STUDY WITH PUBLIC SECTOR AND BUSINESS ORGANISATIONS Ari P. Hirvonen TietoEnator Oyj P.O.Box 203, FIN-40101 Jyväskylä, Finland Email: [email protected]

Abstract Application portfolio models are proposed as tools for enterprise level strategic ICT management to maximise benefits from information systems investments. In this case study, three different organisations are investigated in order to analyse application portfolio models’ suitability to manage an organisation’s application assets. Not all enterprises benefit from application portfolio models in the same way. The organisation’s domain, strategic intent and EA management maturity need to be considered when choosing tools for the management of information systems. Public organisations with their lower strategic flexibility, clear goals set by an external authority and well known systems can be managed adequately well with simpler tools. Based on these findings, a framework of organisational maturity for information systems investment planning tools selection is presented. Key Words: Application Portfolio, Organisational Maturity, Enterprise Architecture, Public Sector

Organisation, Strategy.

1

INTRODUCTION

Information and communication technology (ICT) management in organisations has changed its scope from being focused on a single system and its effectiveness optimisation, to being considered at enterprise and strategic levels (Somogyi and Galliers 1987, Earl 1989, Ward and Peppard 2002). In the past decade, this has become reality in business organisations as they start to interface directly with customers through web and mobile technology based solutions. ICT quality has a direct impact on the value of the business. Public organisations are also increasingly offering ICT based services (Johansen 1988). It is claimed that e-business is having an even more profound effect on the public sector than it is on private sector. In addition to cost savings and round-the-clock customer oriented services, it enables the integration of traditional vertical government services to one point of contact. A new kind of democratic and political participation is possible and even economic growth is facilitated (Holmes 2001). ICT is enabling new business and service opportunities and is influencing organisations' strategies directly (Henderson and Venkatraman 1999, Seltsikas 2000, Ward and Peppard 2002). Business information is shared in an intra-, extra- and interorganisational context, thus increasing the need for information management (Quinn et al. 1996, Hackney et al. 2000). Because of these changes, the management and development of ICT has become a part of an organisation’s management agenda, and consultants are used in order to benefit from their experiences in previous similar cases (Hirvonen and Pulkkinen 2003). In EA consulting and development projects, organisations evaluate and improve the use of their ICT assets (Hirvonen et al. 2003). Enterprise Architecture (EA) Management (Zachman

1987, FEA 2003) and business managerial tools, like portfolios, have been adopted to support decision-making. This study contributes answers to the following questions: • Are application portfolio models always the most suitable and best way to manage an organisation’s ICT application assets? • When should these models be used? • What are the preconditions of their use? The result of the study is a proposed maturity level model to guide application asset management tool selection. Portfolios are a good approach for mature, strategically flexible enterprises. Yet alternatives should be considered if the general information system investment management maturity level is not high enough, or if the organisation’s domain restricts strategic flexibility. The study consists of the following sections: Section 1 introduces the study; Section 2 describes the main concepts relevant to the research scope; Section 3 outlines the research setting and presents the collected data; In Section 4 the data is analysed and the framework of organisational maturity for information systems investment planning tools selection based on the case study findings is presented; and Section 5 concludes the study and presents areas for further examination.

2 2.1

MATURITY FRAMEWORKS AND APPLICATION PORTFOLIOS Maturity frameworks

Klimko (2001) defines maturity modelling as “a generic approach, which describes the development of an entity over time progressing through levels towards a usually idealistic ultimate state”. The entity’s development is described in a simplified way using a limited number of maturity levels. Each level is described by a set of criteria that characterise an entity that has reached the level. Levels are in sequential order and the entity progresses from one level to the next one above without skipping any in between. Maturity models have been created for various aspects of ICT development and use. Klimko (2001) has proposed a maturity model for knowledge management; and Venkatraman (1994) has developed a model for the application of information technology. The Capability Maturity Model (CMM) developed in the early 1990s is a well established model in the software industry (Mark 1993). In CMM, software process maturity is defined as “the extent to which a specific process is explicitly defined, managed, measured, controlled, and effective. Maturity implies a potential for growth in capability and indicates both the richness of an organisation’s software process and consistency with which it is applied in projects throughout the organisation” (Mark 1993). There are organisations at different maturity levels starting from the first even chaotic initial level to optimised continuously improved level (CMM). The highest levels are challenging to reach (SEI 2003). Similarly, there are organisations at different maturity levels with their enterprise architecture (EA) management. The potential for growth in capability is possible and guidance can be found in general enterprise architecture maturity analysis models (META 2002, Schekkerman 2003) or domain specific adaptations like USA Department of Commerce’s model (DoC 2003). These give criteria for maturities in different enterprise architecture areas, like communication, procurement or management commitment. Maturity analysis can also be applied to other enterprise architecture areas like systems investment management, which is discussed in this article.

2.2

Application portfolios

As a tool for enterprise level strategic ICT management, application portfolios are suggested (Ward 2002, Weill 1998). An application portfolio is the sum total of an organisation’s ICT investments including the work force dedicated to ICT services, all of which must be managed like a financial portfolio, balancing risks and return-on-investment to meet management goals and strategies for customer and shareholder value (Weill 1998). Application portfolio models provide the means for balancing the portfolio and the life cycle of information systems. They also provide the management approaches to meet the goals of the enterprise and to create the maximum benefit. Application portfolio models provide similar concepts to those found in financial portfolios whose function is to find the best strategic combination of managed portfolio items and optimise their use. Weill and Broadbent’s and Ward and Peppard’s portfolio models are based on a real world cases. Weill and Broadbent’s (1998) model is based on 27 enterprises and their ICT systems. Their portfolio model is also referred to by commercial service providers (Gartner 2002). Ward and Peppard’s (2002) portfolio model is a widely used model, since it was first time introduced in mid 90’s. The main principles of these models are presented next. 2.2.1

Ward and Peppard’s Application Portfolio

The foundation of Ward and Peppard’s application portfolio is the large variability in different organisation’s IT Systems. There are systems from different eras, initially built for different purposes with varying technologies. There are also plans to build new applications. An application portfolio is needed to evaluate an IT systems’ relation to business success and answer questions such as how much should be invested in new systems or technologies. Applications are classified into four categories depending on their current or expected contribution to business success. Strategic information systems are crucial for the enterprise to sustain its success and to support future business strategy. In other words, an organisation’s business success is directly related to these systems. They create or support the organisation’s business change to achieve competitive advantage. The time to market of these systems is essential for the organisation. Key operational systems are those which the organisation currently depends on for success. These systems support current business processes and operations. Any malfunction in these systems will directly affect the business, thus the quality of these systems is crucial. Applications that are valuable to business, but not critical, are classified as support systems. Payroll systems and others not directly related to organisation’s core processes, or systems not providing competitive advantage, are in this class. Here cost is the most important quality attribute of the systems: how to run as many important, but not critical, transactions as possible, at the lowest possible cost. High potential systems are those, which may be important to achieve future success. The organisation’s R&D functions typically produce these systems. There could be even more failures than successes, but a few potentially strategic innovations are enough to ensure the organisations future success.

Figure 1. Application Portfolio Models. 2.2.2

Weill and Broadbent’s Application Portfolio

The Information Technology Portfolio by Weill and Broadbent starts with four different management objectives in information technology investment assessment. These four objectives yield up four different types of systems: informational, transactional, infrastructure and strategic. Technologies, not just applications, are included in the portfolio, which is missing in Ward and Peppard’s model. Infrastructure technology is the foundation for an enterprise’s applications. The technological infrastructure is a shared facility across the company to run multiple applications. Therefore, a high reliability is needed. Sufficient infrastructure decreases development time for new applications, which will increase a company’s agility. Transactional systems process the basic repetitive processes of the company aiming at cost reduction.

These include systems like payroll or order processing. Transactional systems are built on reliable infrastructure. Technologies in the informational system category collect and refine information for enterprise management. Planning, communication, decision-making, accounting and knowledge management are typical areas of these systems. Information is typically collected from several transactional systems. Both transactional technology and infrastructure technology are preconditions for the informational systems’ development. Key operational and support systems are the equivalents to this and to the transactional systems categories in Ward and Peppard’s model. Systems in the strategic information systems category, which is equivalent to the strategic category in Ward and Peppard’s portfolio model, aim to gain competitive advantage or position the company

better in the marketplace. The strategic potential of the technology is limited in time and typically systems or technologies move from this category to another during their life cycle. Both these portfolio models are comprehensive and give instructions for managerial use. Actual enterprise cases have proven their correspondence with real world enterprises. If these models fit the real world on a conceptual level, should they always be used? What are the preconditions for beneficial usage? Next, I will present three enterprise architecture planning cases, in which application portfolio models could have been used.

3

RESEARCH SETTING AND COLLECTED DATA

Our experience in EA consulting and with development cases suggests that application portfolio models are not always the first tools to be used. I conducted a case study to validate this assumption. Three enterprise architecture consulting cases (Projects A, B and C) carried out by TietoEnator during 2000-2003 were selected in order to investigate the application portfolio models’ suitability for managing an organisation’s application assets, to find out when the models should be used, and what the preconditions for their use were. Cases were selected based on their main targets: systems architecture planning including multiple systems to guide investments and project activities for coming years. As a tool for data collection, semi-structured interviews were selected (Fontana and Frey 2000). All cases were with clients that have long partnerships with TietoEnator, and were thus well known by the interviewees. The client related data is presented in Table 1. Question What is the client’s domain? What is the client’s strategic planning flexibility?

Client A Public sector

Client B Telecom

Client C Public sector

They have a rather restricted, static and formal way of doing things. There are no R&D activities. Systems development is dependent on legislation. Targets are given; The main challenge is to plan how to reach those targets. The organisation is net budgeted and is not allowed to take on loans.

Very dynamic, there are R&D projects.

Does the client have a defined EA management process?

There is ICT management, but not the entire EA is covered. Top management decides on big projects’ initiation and accepts the results. Organisational subunits are quite independent in their ICT management and have their own budget for small projects. ICT is highly connected to operative processes and operative management is highly involved.

There is ICT management, but not the entire EA is covered.

They don’t have such flexibility in their strategic planning. Their operations are based on laws, but this client has a different attitude: they try and can influence coming new laws. Legal change needs are included in the plans when new operations or systems are planned. There are no R&D projects. There will possibly be EA management after the whole architecture development is finished.

What is the client’s maturity in EA

Not very high. The client’s maturity has improved during

Not very high, same as in the organisation A.

They are not at a high maturity level.

management? Does the c lient have long term application development investment planning?

the consulting project. Not before the project discussed here. Now the planning horizon is 7-8 years. The reason for this long period is a) modular modernisation of the system, b) yearly budget limits. Systems are known and their value to the organisation is known but not described explicitly. This planning approach meets the needs very well.

They do plan; they have client roadmaps that describe which system changes have to be undertaken.

It seems not, it has been reactive.

Table 1: The clients The interviews took place in August 2003, when two of the projects were finished and utilization of the results had started. Project B continued, but the consultancy parts were over. Two consultants who participated (Person 2: Projects A and B, Person 3: Projects A and C) and one client representative from project A were interviewed. The interviews were recorded on tape, and the interviewee checked and commented on my written case reports, which thus can be seen as negotiated text (Fontana and Frey 2000). To supplement this material, all preliminary and final result material from project A were studied to get a more balanced picture (Hodder 2000). Table 3 in Appendix A presents the most central parts of the interview answers, related to the interviewee data (Table 3a), and to the consultancy projects (Table3b). All the interviewees had over 10 years of experience in the field in many roles. Additionally, the consultants had experience with multiple EA cases. They knew portfolio models. All interviewees had participated in at least one multiple systems’ architecture planning project. One of the cases was in a business organisation which is very dynamic in its strategic planning. R&D projects were used to attain competitive advantage. The two public sector organisations in the other two cases seemed much more restricted in this respect. Their systems development is dependent on laws. Targets are given from outside and funding is restricted to yearly budgets. Alternative funding models like loans, which are the standard means of financing larger investments in business organisations, are not possible. Organisation C is different from organisation A; it influences the legislation process and takes this into account in its plans also. That makes its strategic planning more dynamic, as the organisation can also affect its environment and the preconditions for its operations. None of the clients had a defined process for EA planning, some EA management areas (The Open Group 2002) were covered and were also under development, but parts were also missing. Organisation A had started a 7-year planning span, organisation B had some planning, but organisation C seemed to be more reactive. From that point of view the interviewees considered the clients’ EA management maturity to be quite low. According to the interviews, mature organisations manage their systems one way or another, maybe not using any named application portfolio model, but they consider the same issues that the models contain. Application portfolio models were not used in the case organisations. In project A, a small number of systems were well known and the problems were found in the systems’ scoping and responsibility setting between systems. An application portfolio seemed not to be the best fit for this kind of problem. The consultants were not aware of the models at the time when projects B and C made decisions about tools to be used. Application portfolio models could have been helpful in both cases. Also in case A, it was considered that these models could have given some new perspectives.

4

ANALYSIS

The results of the study indicate that not all organisations seem to benefit in the same way from using application portfolio models. The reasons for this are the organisation’s strategic intent, business domain and EA management maturity. Weill and Broadbent (Weill and Broadbent 1998) propose that organisations should have a different amount of infrastructure and related services according to their strategic intent. If, for example, a multinational enterprise’s goal is cost efficiency of autonomous country level business units in a non-information intensive business domain, little common infrastructure is needed and there are only a few strategic applications, as most of the applications are serving the cost effectiveness. Positioning the systems in Ward and Peppard’s application portfolio model, we could say that most of this kind of an organisation’s systems are in the key operational or support classes. A simple system map, describing the systems, applications, processes supported and system owners, could be enough to manage these systems. An application portfolio model will be of only a little additional value to this. Public sector organisations’ flexibility in their strategic planning is much more restricted than in business organisations. In project A, the number of the systems was limited, their roles were quite clear as was the needed functionality and services. Only simple structural architecture planning was needed. Even though the organisation’s EA management maturity, compared to literature standards, was quite low and application portfolio models were not used, the business requirements were fulfilled. It seems that public sector organisations would get only minor benefit from application portfolio models. The previously presented application portfolio models are based on data collected from business organisations. The two public organisation cases presented in this study indicate that public organisations have similarities and differences compared to business organisations. Some public organisations miss some areas of the application portfolio models, like R&D in Ward and Peppard’s model. There were no R&D projects in either one of the public sector cases, though I assume that R&D related activities are also part of some public organisations, for example military or police institutions. According to the interviews, there are also cases where the clients do not exactly know the business meaning and the value of their systems, or do not know who owns them, or which processes they support. If the client has problems at this level, then application portfolio is probably too hard a concept to apply. It was stated in an interview: “a direct leap to application portfolio usage is too big” and “starting points, like information on your systems and their responsibilities, should be clear first”. It is nearly impossible to position systems strategically, as should be done using an application portfolio model, if the system's business context is unknown. 4.1

A framework of organisational maturity for information systems investment planning tools selection

Organisations are at varying maturity levels in information systems investment management. Some organisations need very simple tools to get on from a chaotic situation; others have a long tradition and practice proven procedures to optimize their information systems investments. Based on the findings in this study, a framework of organisational maturity for selection of information systems investment planning tools is presented in Table 1. It sets the criteria for organisations to identify the maturity level and proposes proper tools accordingly. Level Initial

Criteria No awareness of what systems there are What processes they support Who owns them

Tools - Systems map: systems, applications, processes, and owners. Lists and matrixes.

Aware

Managed

Optimized

Table 2:

Management is not interested in these issues Organisations’ systems are known Management is aware of information systems management Actual management actions are missing Organisations’ systems are known Systems development investments are planned, not reactively started Business requirements are an important part of investment decision making Management wants to get information about information systems management and contributes to decision making There are continuous activities for planning and management in this area Application portfolio is continuously optimized based on organisation’s strategic intent and information systems strategic value to organisation The information systems management process is optimized Information systems investment management is equally a business management and an ICT management issue – management commitment is high There is a well established enterprise architecture management process

- Overlapping/obsolete systems list - Systems map: systems, applications, processes, owners - Possibly overlapping/obsolete systems list - Systems map: systems, applications, processes, system owners - Application portfolio models can be used to get new ideas and perspectives

Application portfolio models can be used for strategic business optimisation

A framework of organisational maturity for information systems investment planning tools selection

At the initial level, the organisations are in a chaotic situation. There could be many totally or partially overlapping systems, or systems that have become obsolete and are not in use. The organisation’s management is not interested in ICT issues. At this level a systems map, which is a simple list of information, could be used. If there are many system overlaps, separate lists of overlapping and obsolete systems are needed. This so-called conflict list is the starting point for planning. At the next level, the organisation is aware of their systems. Management might pay a little more attention to their systems than at the initial level, but there are no managerial actions in this area. Tools are the same as at the initial level, but the need for conflict resolution is smaller and systems map based planning can be started from the beginning. Client C in the studied cases belongs to this category, but it seems to be reaching the next level criteria. At the managed level, the organisation’s systems, their ownership and other related issues are known. Systems development investments are planned for a longer period, and business requirements are an important part of investment decision-making. Management wants to get information about information systems investment management and contributes to decision-making. There are also continuous activities for planning and management in this area. A systems map can be used as a planning tool and application portfolio models can be used for new idea and perspective creation. Clients A and B in the studied cases could be classified into this category. At the highest or optimized level, an application portfolio is continuously optimized based on the organisation’s strategic intent and the information systems’ strategic value to an organisation. Mature enterprise architecture management processes qualities (META 2002, Schekkerman 2003) are fulfilled. Application portfolio management supports the achievement of the organisation’s strategic goals.

5

CONCLUSION

Application portfolio models are proposed as tools for enterprise level strategic ICT management in order to maximise benefit from information systems investments. In this study of three consultancy cases, all the interviewees agreed that application portfolios could at least give new perspectives to planning, although application portfolios were not used in any of the cases. For this purpose application portfolios could be useful for most organisations. In the present study, the ICT management in both public and business organisations was examined. Organisation domain and strategic flexibility seems to be related to application portfolio models’ usability. Some of the public organisations have lower strategic flexibility than business organisations. The organisational goals are very clearly set by an external authority, and a limited number of well known systems are to be managed. These organisations get adequate results with simple systems architecture planning tools. The interviews conducted in the study indicated that there are organisations whose systems investment management is in a chaotic state and organisations where the situation is more developed. In addition to an organisation’s domain and strategic flexibility, its EA management maturity is the second most important factor in estimating the applicability of an application portfolio model. As a result of the study, a framework of organisational maturity for information systems investment planning tools selection was presented to guide the selection of consulting, and also management, tools. Even if application portfolios were useful from an organisations’ strategic and domain perspectives, application portfolio models would not be the first tools to be used in chaotic organisations. Instead, simple systems maps and obsolete/conflicting systems lists can be used in the preliminary phase to clarify basic issues. Only those organisations that have reached the third level of the maturity model will be able to fully benefit from application portfolio models in their strategic information systems investment management. In this study, only three cases were analysed, supplemented with experiences from some other consultancy cases provided by the consultants. It is likely though, that there are also other organisations that would benefit from simpler information systems investment management concepts. In fact, only a few organisations have reached the top levels of CMM maturity model and possibly only a few organisations are at the highest level of information systems investment management maturity. Therefore further research topics raised in this study are: • Confirmation of the results of this case study from other public sector organisations, and also cases from other countries • Analysis of the number of organisations at the highest level in the framework of organisational maturity for information systems investment planning tools selection • Development of simpler long-term information systems planning and management tools and experimentation with them

References FEA (2003). Federal Enterprise Architecture. URL http://www.feapmo.gov/fea.htm, Accessed: 30.9.2003. Fontana A. and J. H. Frey (2000). The Interview: From Structured Questions to Negotiated Text. In: Denziu, N K and Lincoln Y S (Editors): Handbook of Qualitative Research, 2nd Edition. Sage. DoC (2003). Department of Commerce Architecture Maturity Model. URL: https://secure.cio.noaa.gov/hpcc/docita/, Accessed: 30.9.2003. Earl, M. J. (1989). Management Strategies for Information Technology. Prentice Hall.

Hackney, R., Burn, J. and Dhillon, G. (2000). Challenging Assumptions for Strategic Information Systems Planning: Theoretical Perspectives. Communications of the Association for Information Systems. Volume 3, Article 9. AIS. Henderson, J. C. and Venkatraman, N. (1999). Strategic alignment: Leveraging information technology for transforming organisations. In: IBM Systems Journal, Vol 38 No 2-3, 472-484. International Business Machines. Hirvonen, A. and Pulkkinen, M. (2003). Evaluation of Enterprise IT Architecture Solutions – How can an ICT consultant tell what is best for you? In Berghout, E and Remenyi D (Eds): Proceedings of the 10th European Conference on Information Technology Evaluation (ECITE). Management Centre Limited, UK. Hirvonen, A., Pulkkinen M., Ahonen J. J. and Halttunen V. (2003). The Gap between Strategies and Implementation – Methodic Support for EA Projects as a Bridge. To appear in: Proceedings of The 2003 International Business Information Management Conference. IBIMA. Hodder, I. (2000). The Interpretation of Documents and Material Culture. In: Denziu, N K and Lincoln Y S (Editors): Handbook of Qualitative Research, 2nd Edition. Sage. Holmes, D. (2001). eGov e-business Strategies for Government. Nicholas Brealey Publishing. Johansen, R. (1988). Computer Support for Business Teams. The Free Press, MacMillan, Inc. Klimko, G. (2001). Knowledge Management and Maturity Models: Building common Understanding. Proceedings of the 2nd European Conference on Knowledge Management ECKM 2001. Mark, P., Curtis, B., Chrissis, M. and Weber, C. (1993). Capability Maturity Model, Version 1.1. IEEE Software, Vol. 10, No. 4. Quinn, J. B., Anderson, P. and Finkelstein, S. (1996). Leveraging Intellect. In: Academy of Management Executive Vol. 10 No. 3. 7-27. Schekkerman, J. (2003). Architecture Score Card. URL: http://www.enterprisearchitecture.info/Images/Architecture%20Score%20Card/Architecture%20Score%20Card%20UK. htm#_Toc22713206 , Accessed: 22.8.2003. SEI (2003). List of High Maturity Organisations. URL: http://www.sei.cmu.edu/cmm/highmaturity/HighMatOrgs.pdf, Accessed: 19.8.2003. Seltsikas, P. (2000). Managing Global Information Strategy: Xerox. In: ICIS 2000. Proceedings of the Twenty-First International Conference on Information Systems 791-806. Association for Information Systems. Somogyi, E. K. and Galliers, R. D. (1987). Strategic Information Systems Management: Towards Strategic Information Systems. Gordon & Breach Science Publishers. The Open Group (2002). The Open Group Architecture Framework (TOGAF) Version 8 “Enterprise Edition”. Document Nr 1911 December 2002. The Open Group 2002. Accessed on the 13th of January, 2003 at http://www.opengroup.org/togaf/

Venkatraman, N. (1994). IT-enabled Business Transformation: from Automation to Business Scope Redefinition. Sloan Management Review, 73-87. Ward, J. and Peppard, J. (2002). Strategic Planning for Information systems, third edition. John Willey & Sons Ltd. Weill, P. and Broadbent, M. (1998). Leveraging The New Infrastructure: How Market Leaders Capitalize on Information Technology. Harward Business School Press. Zachman, J. A. (1987). A framework for information systems architecture. IBM Systems Journal, Vol. 26, No. 3, 276-292. IBM.

Appendix A Table 3a: Interviewees and interviewee’s experiences Question Person 1 Person 2

Person 3

What is your experience with EA planning? Are you familiar with application portfolios? Have you used application portfolios? Have you seen such clients, where EA management is in chaotic state?

This one case discussed here.

5 EA cases, 3 multi-systems planning cases.

No

Yes

4-5 EA cases, 1 multisystems planning case. Yes

No

No

No

NA *)

Systems ownerships are typically unknown. Systems purpose and connection to business is also unknown in many cases.

Should application portfolios be used? In what kind of cases?

We could test them to have new perspectives and ideas. Can’t exactly tell what would be the benefits. NA *)

There are organisations which don’t exactly know what the business purposes of their systems are, or what the systems are responsible for. There are overlapping systems and for example customer information may be in many systems. I will pilot them soon. Application portfolios would be the best tool when there are new business plans, acquisitions or mergers.

Does the clients EA management processes maturity affect usability of application portfolio models?

Table 3b: Projects Question Why was the project needed?

What were the project’s targets?

The mature clients have application portfolio issues handled in one way or another. Maybe not using any formal model though. For immature organisations application portfolios are not the first thing to use; starting points, like knowledge of your systems and their responsibilities, should be clear first.

If the situation is chaotic, there are a lot of overlaps etc. then those must be clarified first. Client’s overall ability to make structural work is important. For low maturity organisation the direct leap to application portfolio usage is too big.

Project A

Project B

Project C

The support for old technology was ending, Systems were hard to maintain (architecture was corrupted during past years), Processes were re-engineered (new requirements for ICT). The client did not have technical competence which is why the consultancy project was needed. System renewal and modernisation.

There was organisational change and process owners were also changing. There were pressures to cut the expenses and rationalise overlapping systems.

The operations will change; there is demand for a higher level of automation. Their old system’s technology is becoming obsolete.

To investigate which systems were overlapping, how many overlapping systems there were and where they were.

New systems based on a new strategy, which takes ICT into account, should be implemented. End-to-end follow-up and measurement should be possible in the new automated operations. Systems architecture, application architecture; how the applications should be implemented uniformly in the future.

What were the project’s results?

Requirements specifications, A proposal/ recommendation how to continue. Systems and sub-systems architecture, High level technology alignment and platform selection, Roadmap and enterprise plans for the systems entirety development, transformation plans, Investment calculations. No Were application portfolios No Was not aware of application portfolio models. used? In these public cases you know Application portfolios contain the same things Why/Why not? exactly what systems you have. that were made in the projects, except they are The problem is elsewhere; which are the responsibilities presented in a different way. Application between the applications and portfolio could have been useful. application portfolio cannot tell these kinds of things. *) Person 1 was a client representative and the questions marked with an asterisk were not asked.

Table 3: Interviewees and Projects

No. These were not known. Application portfolios could have been useful in this because the number of applications is so big. Portfolios would have helped to view new perspectives.