How Italian Enterprises Are Reacting to Technological Emerging Trends

School of Industrial and Information Engineering Master of Science in Management Engineering

IT Governance: how Italian enterprises are reacting to technological emerging trends

Supervisor: Prof. Corso Mariano Co-supervisor: Eng. Piva Alessandro, Eng. Dozio Luca

Master graduation thesis by: Manzotti Nicolò [837370] Natalucci Marina [837028]

Academic year 2015-2016

III Abstract

English version The purpose of this document is to describe how companies and their IT functions should react to remain competitive in a market scenario that is continuously evolving due to exponential technological growth. This research is based on a literature review that aims at identifying the main impacting technological trends and at determining what can be consequently done in terms of IT management, under both an organizational and technical point of view. Moreover, an empirical research on the Italian market has been conducted, together with the Enterprise Application Governance Observatory of Politecnico di Milano School of Management, with the objective to understand how companies are coping with this situation, which trends they consider for their application portfolio evolution, and whether they are renovating working methodologies and technological architectures to address Digital Transformation. Main keywords: IT Governance; Information Systems; Information and Communication Technology; Enterprise Architecture; Application portfolio evolution; technological trends; agile development; adaptive enterprise.

Versione in italiano L’obiettivo di questo documento è descrivere come le aziende e le loro funzioni IT dovrebbero reagire al fine di mantenersi competitive in uno scenario di mercato in continua evoluzione a causa di una crescita tecnologica esponenziale. La ricerca è basata su un’analisi della letteratura volta ad identificare i trend tecnologici più significativi e a determinare cosa può essere messo in campo di conseguenza in termini di IT management, da un punto di vista sia tecnico sia organizzativo. Inoltre, è stata svolta una ricerca empirica, all’interno dell’Osservatorio Enterprise Application Governance della School of Management del Politecnico di Milano, per comprendere come le aziende Italiane stanno affrontando questa situazione, quali trend considerano nell’evoluzione del loro portafoglio applicativo, e se stanno rinnovando metodologie di lavoro e architetture tecnologiche per accogliere la Digital Transformation. Principali parole chiave: IT Governance; Sistemi Informativi; Tecnologie dell'informazione e della comunicazione; Enterprise Architecture; evoluzione del portafoglio applicativo; trend tecnologici; sviluppo agile; adaptive enterprise.

V Table of Contents Executive Summary ...... 1

Introduction, research objectives and methodology ...... 1

Literature review...... 2

Research findings, discussion ...... 7

Conclusions ...... 11

1. Introduction ...... 13

2. Research objectives and methodology ...... 15

2.2. Enterprise Application Governance Observatory ...... 15

2.3. Methodological flow ...... 16

2.4. Preliminary objectives ...... 16

2.5. Literature review ...... 16

2.6. Research objectives ...... 17

2.7. Data collection ...... 17

2.8. Results analysis ...... 19

2.9. Case studies ...... 20

3. IT trends and the Digital Transformation Journey ...... 21

3.1. Technological progress: IT-enabled business trends ...... 22

3.2. Digital transformation: from First to Fourth platform ...... 30

4. Managing enterprise evolution: the adaptive enterprise ...... 32

4.2. IT and business divergences: the shadow IT ...... 33

4.3. Enterprise Architecture management ...... 36

4.3.1. Organizational unit for Enterprise Architecture ...... 47

5. IT governance: how to evolve the IT function ...... 53

5.2. Bimodal IT: a new way to deliver IT services...... 56

5.2.1. Bimodal organization ...... 57

5.3. IT portfolio management ...... 59

VI 5.4. Managing modern IT projects ...... 65

5.4.1. Heavyweight lifecycle models ...... 69

5.4.2. Agile methods ...... 73

5.4.3. Why moving to agile? ...... 82

5.5. Information Systems Architecture ...... 85

5.5.1. Software development and architecture elements ...... 86

5.5.2. Software architecture evolution ...... 92

5.5.3. What’s best in 2016 ...... 95

5.6. The need for high level organizational changes ...... 100

6. Findings from the survey ...... 101

6.2. Sample description ...... 101

6.2.1. Introduction ...... 101

6.2.2. General description ...... 101

6.2.3. IT function description ...... 102

6.2.4. Clustering ...... 109

6.2.5. Clusters analysis ...... 110

6.3. Technological trends influencing application portfolio management ...... 112

6.4. Technological trends: current state evaluation ...... 116

6.5. Role and processes of IT function ...... 118

6.6. Evolution of Information Systems architecture ...... 121

6.7. Role of IT function and Enterprise Architecture: state-of-the-art evaluation ...... 124

7. Case studies ...... 131

7.2. Company 1 ...... 131

7.3. Company 2 ...... 133

7.4. Company 3 ...... 135

7.5. Company 4 ...... 137

7.6. Final remarks ...... 139

VII 8. Discussion on findings ...... 140

9. Conclusions ...... 149

List of references ...... 153

Appendix ...... 170

Annex A - Introduction to Information Systems...... 170

Annex B – Literature review glossary ...... 176

Annex C - Enterprise Application Governance Observatory – Research survey ...... 182

Annex D - Enterprise Application Governance Observatory - Interactive frameworks ...... 190

Acknowledgements - ringraziamenti ...... 196

VIII Table of figures

Figure 1 Your New Tech Overlords (BloombergGadfly, 2016) ...... 13 Figure 2 Methodological flow ...... 16 Figure 3 Cloud Computing Delivery models (Mainetti, 2015) ...... 26 Figure 4 Evolution from First to Fourth Platform (Hinchcliffe, 2015) ...... 30 Figure 5 Gartner Nexus of Forces ...... 31 Figure 6 Lines of Business dynamics and impacts on IT function (Mazzucco, 2015) ...... 34 Figure 7 CIOs' competences evolution towards collaboration (Mazzucco, 2015) ...... 35 Figure 8 Enterprise Architecture layers (Osservatorio Enterprise Application Governance, Politecnico di Milano, 2016) ...... 36 Figure 9 Role of Enterprise Architecture (Mainetti, 2015) ...... 37 Figure 10 The Zachman's framework (Zachman, 1987) ...... 39 Figure 11 Motivation model for a new CRM in a hypothetical insurance company (Castiglioni, 2012) ...... 44 Figure 12 The new application portfolio coming from the migration of CRM to the Cloud in an insurance company (Castiglioni, 2012) ...... 45 Figure 13 Diagram of the revised application model for a new CRM in an insurance company (Castiglioni, 2012) ...... 45 Figure 14 Architecture roles, breadth vs. depth of IT illustration (Walker, 2007) ...... 49 Figure 15 Architecture trade-offs (Walker, 2007) ...... 50 Figure 16 IT strategy lifecycle (Walker, 2007) ...... 50 Figure 17 Scrum & ITIL: A perfect fit on high level (Lichtenberger, 2014) ...... 55 Figure 18 Two modes of Bimodal IT (Gartner, 2016) ...... 56 Figure 19 Strategic and operational decisions made to introduce a Bimodal approach (Osservatorio Cloud & ICT as a Service, 2015)...... 57 Figure 20 Tree rings are like enterprise technology portfolios (Walker, 2007) ...... 61 Figure 21 Governance extends over the entire application lifecycle (Chappell, 2008)...... 63 Figure 22 - Waterfall model with Royce's iterative feedback (Ruparelia, 2010) ...... 70 Figure 23 Boehm's spiral life-cycle (Ruparelia, 2010) ...... 71 Figure 24 TOGAF's ADM as a wheel-and-spoke model ...... 72 Figure 25 Scrum visual introduction (Mountain Goat Software, 2016) ...... 78 Figure 26 Story Map Diagram (Patton, 2008) ...... 79 Figure 27 DevOps Infinite Loop (Tricentis, 2016) ...... 81

IX Figure 28 Analysis and Planning (Osservatorio Enterprise Application Governance, Politecnico di Milano, 2016) ...... 82 Figure 29 Spaghetti integration (Piraccini & Rossini, 2006) ...... 89 Figure 30 IS architecture, late '90 - early 2000 ...... 92 Figure 31 IS architecture, 2000-2005 ...... 92 Figure 32 IS architecture, 2005-2008 ...... 93 Figure 33 IS architecture, 2008-2011 ...... 93 Figure 34 IS architecture, 2011-2015 ...... 94 Figure 35 Bounded Contexts, adapted from Fowler (2014) ...... 97 Figure 36 Hybrid IT (Gartner, 2012) ...... 98 Figure 37 An integrated view of an information system (adapted from Alter's Work System Framework) ...... 171

Table of charts

Chart 1 Companies size in terms of employees ...... 18 Chart 2 Companies size in terms of employees ...... 18 Chart 3 Companies sectors ...... 19 Chart 4 Companies turnover per employee ...... 102 Chart 5 Companies IT staff and IT spending on turnover ...... 102 Chart 6 IT staff size by company size ...... 103 Chart 7 IT staff size by sector...... 103 Chart 8 IT spending on turnover by sector ...... 104 Chart 9 Companies investments in digitalization...... 104 Chart 10 Investments in digitalization by companies’ size ...... 105 Chart 11 Companies investments in digitalization by IT spending ...... 105 Chart 12 Who is responsible for IT projects ...... 106 Chart 13 Groups by responsibility for IT projects ...... 106 Chart 14 Companies usage of IT outsourcing ...... 107 Chart 15 Outsourcing by sector ...... 107 Chart 16 Clusters size ...... 110 Chart 17 Clusters companies size ...... 110 Chart 18 Clusters by sector ...... 111

X Chart 19 Clusters by IT staff size ...... 111 Chart 20 Most impacting technological trends ...... 112 Chart 21 Most impacting technological trends ...... 113 Chart 22 Most impacting technological trends ...... 113 Chart 23 Most impacting trend by sector ...... 114 Chart 24 Sponsorship for the trends ...... 115 Chart 25 Trends impact on different application scope in a portfolio ...... 115 Chart 26 Evaluation of trends impact on application portfolio ...... 117 Chart 27 Diffusion of Agile methodologies ...... 118 Chart 28 Organizational changes diffusion and type ...... 119 Chart 29 Limits to adoption of innovative methodologies ...... 120 Chart 30 Motivations to adoption of innovative methodologies ...... 120 Chart 31 Application portfolio mapping ...... 121 Chart 32 Investments in application architecture evolution and rationalization ...... 121 Chart 33 Organizational unit devoted to Enterprise Architecture ...... 122 Chart 34 Roles of Enterprise Architecture management ...... 122 Chart 35 Limits to EA adoption ...... 123 Chart 36 Benefits from EA correct management ...... 124 Chart 37 Evaluation of sample IT governance ...... 125 Chart 38 Evaluation of SMEs and LEs IT governance ...... 126 Chart 39 Evaluation of proposed clusters IT governance ...... 126 Chart 40 Groups of companies with similar profile score in IT governance: backward and advance ...... 127 Chart 41 Numerousness of groups of companies with similar score profile in IT governance... 128 Chart 42 Groups of companies with similar score profile in IT governance ...... 128 Chart 43 Groups of companies with similar score profile in IT governance ...... 129 Chart 44 Groups of companies with similar score profile in IT governance ...... 129 Chart 45 Advanced and Backward companies in IT governance by turnover per employee ...... 130

Table of tables

Table 1 Traditional vs. Agile methods for analysis and planning ...... 82 Table 2 Traditional vs. Agile methods for design and development ...... 83

XI Table 3 Traditional vs. Agile methods for deployment ...... 83 Table 4 Incentives and barriers to the adoption of agile methodologies ...... 84 Table 5 Limits of Monolithic and Service Oriented architectures ...... 95 Table 6 Limits of Spaghetti integration and Enterprise Service Bus ...... 96 Table 7 Limits of Data Silos and Master Data Management ...... 97 Table 8 Limits of In-House development and SaaS solutions ...... 98 Table 9 Limits of Elementary languages and General Purpose platforms ...... 99 Table 10 Clustering...... 109 Table 11 Value of parameters for trends impact evaluation ...... 116 Table 12 Value of parameters for IT governance evaluation ...... 125 Table 13 Case studies roundup ...... 139

XII Executive Summary

Executive Summary

Introduction, research objectives and methodology Megatrends like globalization and exponential technological evolution have changed both the business and consumer world, and technology plays a central role in this ongoing transformation. While competition in every market is increasingly fierce, the most valuable companies are tech giants and digital startups are bringing disruptions across many industries. In this equation, technology has also deeply transformed customers’ expectations and behavior, bringing further complexities inside companies. As a result, the nature of competitive advantage has changed and organizations need to evolve their strategies and business models becoming more agile and adaptive to the complex and challenging context in which they run. This can be successfully achieved only fully embracing what todays’ technology can offer, both to improve the internal efficiency and to deliver higher value to their “digital customers”. This Digital Transformation requires changes at every level of the organization, and our research addresses its impacts on enterprises IT function and the reaction the IT functions should have to fully embrace it.

The research, placed in the context of Enterprise Application Governance Observatory of Politecnico di Milano School of Management, involved 114 CIOs, IT executives and Enterprise Architects, operating in large and medium Italian enterprises. The research methodology consisted of sequential phases, the first of which has been defining the preliminary objectives of the study for what concerns the literature review. In fact, the matter was rather new and we had to include all the information gathered through different articles and scientific papers, which was never unified and correlated. The preliminary objectives are the following:  Which technological trends are influencing companies’ evolution enabling new IT-based business opportunities;  Which reactions companies can put in place in terms of IT management as critical factors to face the change.

Once identified the objectives, we started the literature review in order to understand all the possible analysis directions to deploy in the phases of data collection and results analysis. Therefore, we defined the following research objectives and started to collect data:  Understanding how Italian companies are coping with Digital Transformation in terms of processes digitalization;

1 Executive Summary

 Analyzing which emerging technological trends Italian companies are considering in decision-making about application portfolio evolution;  Understanding whether Italian companies are evolving IT function processes management, adapting to new working methodologies in an agile model;  Analyzing which changes Italian companies are deploying in terms of application portfolio and Information System architectures governance, assessing the diffusion of specific tools such as Application Portfolio Management and Enterprise Architecture.

During the research year, we participated to the organization of thematic workshops where, from the interactive discussion among companies, we identified the points of interest for each specific matter of analysis. Subsequently, we carried out a questionnaire to be diffused through an online survey in order to get standard information for quantitative analysis. Meanwhile, interesting companies have been identified in collaboration with the Enterprise Application Governance Observatory partners to deepen the analysis through case studies, which allowed us to investigate single companies’ peculiarities in terms of approach to Digital Transformation.

Quantitative results coming from survey responses analysis have been integrated with qualitative reflections emerged during thematic workshops and interviews for case studies drafting. Once the analysis was carried out and the research objectives were answered, we have derived some personal considerations about results.

Literature review The expansion of information technology capabilities enables new ways of connecting, sharing, collaborating and doing business: a brunch of new IT-enabled business trends are rising inside companies, changing the way they usually operated. Some of these trends are directly impacting the management choices of enterprise information systems: mobility (making enterprise applications available on every device), user experience (design applications considering user experience as a key element), collaboration (supporting structured and unstructured collaborative information flows, decreasing e-mail overhead), pervasive computing (using data collection and automation to exploit interactions with the material world), data intelligence (using artificial intelligence and machine learning to extract the maximum value from available data) and open application (integrate applications in standard ways, allowing the extension of application functionalities).

2 Executive Summary

To remain competitive in complex and fast changing environments, and to successfully face emerging IT trends, enterprises need to become adaptive, that is flexible organizations able to adjust almost in real time to changing environments. In adaptive enterprises, IT services provision and business needs are matched and aligned. Therefore, IT should not be managed with a tactical approach, as this leads to rigid and complex applications, continuous re-projects and high maintenance costs; on the contrary, using a strategic approach allows IT resource usage optimization: projects with similar objectives have a common orientation and can exploit their synergies, building a solid base for the future development of new solutions.

Today, although technology is becoming easier to use and simpler to manage, IT functions are facing an increasing complexity: business users often ask them high quality technological solutions, which must be delivered as fast as possible and at the lowest possible cost. Indeed, business people expect to use in their workplace the same good technology they use at home, and they are becoming ever more experts in domain which used to be exclusive of IT functions. For example, due to the pervasive growth of public clouds, many Lines of Business are accustomed in receiving IT as a Service: they see IT resources as a commodity that should be timely delivered for an agreed fee. However, as IT is often managed with a tactical approach, it is not able to answer business requirements, and IT departments are thus bypassed by Lines of Business, placing the company at greater risk (this is the concept of Shadow IT). IT functions need to become more agile to avoid this situation, changing their objectives, roles and working processes, and introducing a structured and effective approach that allows them to quickly and flexibly respond to ever-changing business needs. IT should shift from being a commodity to being a research laboratory focusing on innovation, proximity to business and creativity: business innovation and IT innovation should be integrated.

A first step to support enterprise transformation in response to ongoing context changes, pursuing the alignment between business and IT, could be managing the Enterprise Architecture (EA). EA is defined as a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA consists of the essential architecture components structure, relationships, principles and guidelines presiding over organizations’ design and evolution. EA delivers value presenting business and IT leaders with recommendations to achieve business outcomes: it can thus be described as the alignment between Enterprise Strategy and Executional activities, resulting in a graphical roadmap to evolve an enterprise from a present state to a future state. Many frameworks have been

3 Executive Summary developed to help companies implementing such a complex concept; we have detailed three of them (Zachman’s framework, TOGAF model and Mainetti’s model) and proposed a practical example of EA usage. A correct management of EA leads to different benefits, the main are: flexibility of information systems (which are ready to respond to business needs), reduced complexity of application portfolio, improved control and knowledge on application portfolio, decrease in IT management costs and process changing costs. Possible issues, instead, involve a low commitment of management, lack of competences in the IT function and resistance of project teams. While EA was born in the ‘80s as an IT-centric exercise in mapping, controlling, standardizing and consolidating, to be successful it should become an organizational unit aimed at giving centralized architectural guidelines, entrusted with creating a permanent process for business and IT alignment. Different kind of architects usually take care of EA inside companies: while Enterprise Architects are responsible for the overall architectural vision, Domain Architects, which focus on specific domains, and Solution Architects, which have a technical expertise in development, are needed to build complex, distributed and enterprise-wide Information Systems.

Information Technology Governance (ITG) is a concept strictly related to the concept of IT and business alignment, and thus to EA; ITG comprises leadership, organizational structures and processes to ensure that IT extends the organization’s strategies and objectives: it enables companies to reach their goals through an effective and efficient use of IT. Beside strategic alignment between business and IT, ITG focuses on IT value delivery, accountability, risk management and resource management. Different frameworks have been developed to support ITG implementation, which are constantly updated to match modern IT trends and requirements, such as the spread of agile development methodologies; the most popular frameworks are CoBIT and ITIL. Beside frameworks, different tools for ITG are available, from IT Balanced Scorecards for performance measurement, to IT portfolio management that helps in managing IT resources across an enterprise in terms of investments and financial viability, taking risk into account. Physical assets and infrastructures, projects and applications are the main resources and relative dependencies that are mapped and managed through IT portfolio management.

Project Portfolio Management (PPM) consists in cataloging all the IT projects and controlling them as one set of interrelated activities: it provides a centralized overview of investments and helps in quantifying and manage their risk and return, avoiding projects overlapping and redundancy, prioritizing and aligning them with business and allowing results management. Through PPM, IT functions can abandon projects which are too risky or redundant, shift resources from low value

4 Executive Summary investments to strategic ones, being sure that IT value is maximized; however, a strict collaboration between business and IT is key for a successful PPM, thus an organizational change is needed.

Application Portfolio Management (APM) instead provides IT managers with an “inventory” of company’s software applications with metrics to illustrate business benefits and risks of each application, determined using information about age and lifecycle, quality and usage, interrelationships with other applications and maintenance costs. APM is a pragmatic approach to manage the optimization and transformation of enterprise application assets, providing multiple criteria analysis compatible with the complexity of modern applications landscape: with APM it is possible to pursue an application overhaul, reworking the application portfolio which is usually made of a mix of complex and redundant legacy applications, and putting companies in a better position to meet the current and future needs of both business and IT. A topic strictly related to APM, which is gaining ground, is the one of Application lifecycle management (ALM), the continuous process of managing the life of an application, from initial planning throughout retirement.

For what concerns the relationship between EA and ITG, it is a two-sided relationship. On one side, ITG is a prerequisite for EA to become truly effective, as, for example, processes like PPM and APM are the only way to make architecture review a condition for investment approval. On the other side, EA enables a genuine and better IT Governance revealing deficiencies in the interactions of business processes, applications and infrastructures.

As application portfolio should be rationalized to become aligned with business, also the way in which software is developed should change from its traditional rigid approach. Enterprise information systems development is usually organized in the form of a project, the management of which is supported by Software Development Lifecycle Models (SDLM). SDLM born with the diffusion of the idea that there is a direct correlation between the process through which the software is developed and the quality of the developed software. A software lifecycle describes the different phases in the lifetime of a software product and defines the principles and guidelines that must be followed in carrying out each stage; usually, the lifecycle stages are grouped in three phases: analysis and planning, design and development, deployment. Modeling (i.e. describing in a textual or graphical form the system to be designed) is very important for the software development process, both for software and for the business processes it has to support. Requirements analysis is also a crucial stage of the software process, as a software is successful if it meets the purpose for which it was intended; the aim of requirements engineering (RE) is discovering that purpose. However,

5 Executive Summary

RE practices have received some criticism, as they often presume a stable context and loose the sight on real world goals; indeed, many of the “requirements” in software projects are just design decisions or preferences, not real requirements to meet stakeholder goals.

Software development methodologies can be divided into two widely recognized categories: heavyweight methodologies and lightweight or agile methodologies. Heavyweight are the traditional and oldest ones, focusing on detailed documentation, inclusive planning and expansive upfront design. Waterfall model is the most known and spread heavyweight model, and today it is still used by many companies; it consists of several non-overlapping development stages: each stage must be fully completed before moving on to the next, and once a stage is finished it is frozen in time. Agile methods instead focus on short iterative development cycles, relying on knowledge within a team and on working prototypes rather than documentation and detailed processes. These lightweight methodologies were born in the ‘90s, when Personal Computing started spreading in enterprises and they faced a crisis of application development: business needs were changing faster than development times, and when software projects were completed they were already outdated. However, agile methodologies have become popular only in recent years, as environments are becoming increasingly dynamic and business needs start to change much frequently. Indeed, compared to heavyweight methods, agile models are lighter, faster and more flexible, being ready to accept changes adapting to business needs. Agile methodologies emphasize teams against structured processes, teams which should be composed also by customers: they are domain experts and can thus bring real knowledge that is difficult to write on a paper; customers are also involved for frequently testing single pieces of working software, giving immediate feedbacks on it. Agile is against a big design upfront approach: as it’s very difficult to define what is needed before starting to build software, software should be produced and tested in the context of a working system as soon as possible, as it is the best way to understand requirements. The most popular Agile methodologies are: User Story Mapping for what concerns the analysis and planning phase, Extreme Programming, Scrum and Lean Software Development for what concerns the design and development phase, and DevOps for what concerns software deployment.

Like Enterprises, also Information Systems (IS) must have a clearly defined architecture, that is the formal definition of the business processes and rules, of systems structures, technical frameworks and product technologies for an enterprise IS. Indeed, having a flexible and reactive architecture is crucial to answer the ever-changing business needs. We thus identified and defined the main topics

6 Executive Summary related to technological support to software development and deployment, we shortly analyzed their history and identified the latest and advised solutions:  Architectural patterns: they are the fundamentals structures of software systems, concerning different aspects of the applications (e.g. design, deployment, communication, …). Today, software architectures should be composed of very small, decoupled and independent components, called microservices, which have a great agility, scalability and availability. The granularity of microservices allows higher loads scalability and easier reuse and functionality extension of services.  Integration methods: this involves the way through which different applications and functionalities are presented to end users. Integration should no longer be specific and point to point, nor left in the hands of a central and inflexible orchestrator: a flexible, distributed and scalable infrastructure should manage services exposition, both internally and outside the companies’ boundaries. This is allowed by API management tools, which enables new business models to increase profitability through APIs.  Data management: it is referred to how data and their relationships are managed. Data should not be limited into data silos, nor centrally managed, as the required data attributes change according to the context in which they should be used. A Bounded context mechanism, instead, divides a large data model into smaller contexts which can be differently modelled, and whose interrelationships are explicit.

 Development frameworks: they are the tools available to support developers. Today, different specialized platforms have been developed to make development easier and faster.  Application sourcing: it involves how application are sourced, and where they are hosted. From everything realized and hosted internally, to everything outsourced, the best way to manage sourcing seems to be a hybrid one: critical services should be managed internally, mainly for safety and availability reasons, while noncritical ones can be outsourced allowing IT functions to focus on providing competitive advantage to business.

Research findings, discussion Results analysis consists of four sections carried out as a response to our research objectives.

In the first part of the analysis, we segmented the market according to what we recognized as digital orientation: this means understanding how much Italian companies are investing in Digital Transformation. We derived three groups of companies:

7 Executive Summary

 “Strongly digital oriented” - companies that invest a high percentage of turnover in IT and are able to dedicate a significant part of this amount in digitalization and innovation;  “Weakly digital oriented” – companies that invest a low percentage of turnover in IT and, moreover, spend a small part of this amount in digitalization, therefore not giving a strong economic priority to Digital Transformation;

 “Medium digital oriented” group that is mediumly positioned compared to the other two, resulting neither particularly focused on Digital Transformation, nor particularly unfocused. Unfortunately, “Strongly digital oriented” companies represent a small percentage of the market, just the 18%, while the majority is “Weakly digital oriented” (42%). Going more in detail, Large Enterprises turned out to be significantly more digital oriented compared to Small & Medium Enterprises, while looking at companies’ sectors, the most advanced is Finance. Coping with digitalization projects, we found out a general tendency to share their responsibility between IT function and Lines of Business. This confirms the trend of diluting IT into business processes in order to overcome the traditional mindset of seeing it as a separated support process. Moreover, Outsourcing of IT services resulted to be rather spread in the market as an enabling factor for digital transformation, probably thanks to Cloud Computing services diffusion.

In the second section of the analysis, we have tried to evaluate which technological trends are mainly impacting on companies’ choices in terms of application portfolio evolution. We combined survey questions to assess this impact according to 4 parameters with a value between 1 and 4. We found out that User Experience and Collaboration, directly followed by Mobility, are the main impacting trends. User experience and Mobility trends are coming from the consumer world, indeed their main impact is on Customer Facing Applications and they are now entering companies’ boundaries influencing, for example, Office Automation systems. Having a strong impact on employees’ lifestyle and way of working, the sponsorship of these trends is significantly shared between IT function and Lines of Business. Collaboration, a trend fundamental to reduce the overhead deriving from abuse of emails and meetings, is impacting both on Supplier Facing Application and on Office Automation. The subsequent trends, ordered by importance, are Data Intelligence, Open Application, and Pervasive computing, since awareness about their potential is still low in the market. Anyway, they show some peaks of consideration depending on companies’ sector: for example, thanks to new omnichannel customers’ journeys involving the interaction between digital and physical touchpoints, data generated in Wholesale & Retail sector are voluminous and heterogeneous so that companies in

8 Executive Summary this sector are giving importance to Data Intelligence. Generally, Mobility, Collaboration, and Data Intelligence are significantly sponsored also by Top Management, probably due to their economic implications (improvements in processes efficiency and employees’ productivity).

Moving to the third part of results analysis, it is focused on the new role and working methodologies of IT departments. In particular, it is oriented to understand the diffusion of Agile methodologies for IT projects management, detailing motivations and limits for their adoption. Results are divided according to IT projects phases: Analysis & Planning, Development, and Deployment. The market turned out to be rather backward, especially in the Analysis & Planning phase, declaring that the main limits to methodologies adoption for this phase are lack of internal knowledge and technical competence. Just a small part of the market is in a state of maturity in terms of Agile frameworks usage, but there is a positive signal since just the 15% of companies is not using any methodology in any phase, while the 75% of the market is introducing organizational changes in the IT function. Companies having successfully adopted Agile methodologies recognized gradual experimentation through pilot initiatives and cultural change in a collaborative mindset at all organizational levels as critical success factors.

The fourth section of analysis is dedicated to the evolution of application architecture and its management tools. Particularly, it follows three directions of assessment: presence of Application Portfolio Management, investments in architecture evolution and rationalization, and presence of Enterprise Architecture. The majority of the market turned out to manage portfolio evolution, having an updated application mapping, and to invest continuously, or at least discontinuously, in architectures rationalization. Just a minority of companies has an organizational unit dedicated to EA, and the market identifies the main limits to its adoption in a lack of management commitment, budget, and competences. If correctly managed, EA brings benefits mainly identified in improved Information Systems flexibility, timeliness towards business requests, and uniformity of architectural choices. We found out that, to be successful, EA organizational unit should be more diluted in project activities rather than being a separated and theoretical entity, so that it could give guidelines taking into account trade-offs related to technical debt and specificities of each situation.

Finally, to give a comprehensive vision of the situation of Italian companies in terms of IT governance, we tried to evaluate the market situation through four parameters valued between 1 and 4, based on: usage of innovative methodologies for IT projects management, existence and update level of application portfolio mapping, investments in architectures evolution and rationalization, and existence and development level of an organizational unit dedicated to EA. The general market

9 Executive Summary situation reflects what emerged from the fourth section of analysis, but we found out a significant difference according to companies’ dimensions: Large Enterprises are more advanced compared to Small & Medium Enterprises. Looking at the proposed clusters in terms of digital orientation, “Strongly digital oriented” companies turned out to be more advanced compared to the other two groups, but not with a significant break. Therefore, investments in IT and innovation are not the only factor to be considered trying to understand why a company is better than others in terms of IT governance. In order to find a tendency in the market, we tried to segment companies looking at the occurrence of similar score profiles in each parameter of evaluation. We found an “advanced” group, with a score between 3 and 4 in all the assessment parameters, and a “backward” group with a score between 1 and 2, representing respectively the 12% and the 14% of the sample. In the middle, we found 6 similar groups with a numerousness between 5 and 15 companies (4%-13% of the sample), which can be considered mediumly positioned with some areas of success and some others of backwardness. Despite our effort in grouping sample companies according to their situation in terms of IT governance, a remaining 24% of them have too heterogeneous profiles in each evaluation parameter so that we could not identify a common tendency. Therefore, we can conclude that the Italian situation shows some positive signals in terms of interest towards the various areas of IT governance, but the way to exploit all its benefits is still long, especially in terms of awareness and competences about the previously described models. It is interesting to notice that there is a slight correlation between being advanced in IT governance and being economically successful: in fact, enterprises in the “advanced” group, according to our evaluation parameters, have also a higher turnover per employee if compared to “backward” ones. To be significant, this aspect should be deepened through a future research, but it is anyway a signal that being able to transform IT from a separated support to something diluted and aligned with business is a fundamental change for companies to remain competitive. Case studies analysis confirmed that Italian enterprises are aware of this conclusion. Indeed, we interviewed four companies that are evolving their application portfolio according to technological emerging trends: they have digitalized processes like sales, knowledge management and project management, introducing applications oriented to Collaboration, Data Intelligence, Mobility, User Experience, and Open Application. They soon benefitted from improved efficiency and effectiveness, transparency and quality of information, better monitoring of activities and decision-making, directly impacting on business results. However, generally, they are not following a systemic and structured approach to change and, moreover, they are facing challenges in terms of building internal competences and managing organizational resistances.

10 Executive Summary

Conclusions We can highlight the results of our research giving an answer to its objectives, starting from the preliminary questions on literature review. The first purpose was identifying the emerging IT- enabled business trends that are leading companies to rethink their approach towards IT management. From the literature analysis, it is possible to summarize these trends as following: Collaboration, Mobile, User Experience, Data Intelligence, Open Application and Pervasive Computing. Once recognized the main emerging IT trends, we analyzed their impact on companies’ Digital Transformation. Particularly, companies need to change their approach in managing IT resources in order to exploit opportunities coming from digitalization. The most important factor is becoming adaptive, aligning IT resources provisioning to real business needs. This is possible only through sound management of Enterprise Architecture, as a tool to support company’s transformation, and IT governance, as a mean to efficiently manage IT rationalizing its resources. These two elements have a two-way relationship, reinforcing each other and are enabling factors for IT-business alignment, which nowadays is fundamental to make a company innovative and, therefore, competitive. This alignment requires a change of organizational mindset towards a more collaborative approach between business and IT, and the introduction of new competences and organizational roles, such as Enterprise Architects. A top-down sponsorship of this organizational transformation could be a critical success factor. Companies, after years of unstructured and sequential approach to change, are now feeling the urgency of introducing these tools since their complex and fragile Information Systems are no longer able to provide value keeping the pace of technological progress, consumerization and business evolution.

Once identified the key elements to analyze, we defined the objectives of empirical analysis. Firstly, we wanted to understand how Italian companies are coping with Digital Transformation in terms of processes digitalization. Therefore, from survey results, we segmented companies according to their IT spending on turnover and the percentage of this amount invested in digitalization. We found out that the market has a weak orientation to Digital Transformation, not giving it an economic priority among other IT expenditures, which is probably related to a general mindset of considering IT as a support process.

11 Executive Summary implications (Mobility, Collaboration, Data Intelligence), while Lines of Business foster trends leading to an improvement of their tools and ways of working (Mobility, User Experience).

Finally, the last two objectives were related to understanding Italian companies state-of-the-art in terms of IT governance and Enterprise Architecture. According to our evaluation model, based on Application Portfolio management, architectures modernization, usage of Agile methodologies and presence of Enterprise Architecture, companies are generally mediumly positioned, nor being particularly successful or backward. Even if it is difficult to identify an overall tendency, a positive signal is that completely backward companies represent a low number (though it is the same for advanced ones), and the 75% of the sample is introducing organizational changes in IT function, confirming that the urgency of this transformation is perceived. From case studies and workshops, we found out that the main challenges to the change are the introduction of new competences and the effective management of organizational resistances, since a mindset evolution is required.

In conclusion, results have shown how IT-business alignment has become fundamental for companies’ competitiveness, so that IT cannot be seen any more as a mere support to business. This is also supported by a slight positive correlation we have found between companies’ situation in IT management and their economic results in terms of turnover per employee, even if this aspect should be deepened through a future research. Moreover, from case studies, we recorded strong positive effects of technological solutions related to new emerging technological trends on business processes.

12 Introduction, research objectives and methodology

1. Introduction In the last 20 years, the world has seen disruptive changes, with new innovations occurring faster than ever before, and new products being marketed with an ever-increasing frequency. Globalization and technological evolution have paved the way to this situation, allowing new players to come into virtually every market and creating a hyper-competitive scenario: competition is becoming increasingly fierce and companies need to become more agile, reshaping their strategies and business models (Triumph, 2014). This situation affects companies in every industry, which need to react becoming more adaptive to the complex and challenging context in which they run; otherwise, established companies’ survival is at risk. Indeed, as the nature of competitive advantage has changed, nowadays innovation is commonly equated with entrepreneurs, not with incumbent market leaders; big businesses need to become more entrepreneurial, leveraging their scale while embracing disruptive and innovative thinking typical of startups (CIO, 2015).

In this scenario, technology plays a central role: not only technological growth and its democratization have led to hyper-competition, they also deeply changed customers’ expectations and behavior bringing new complexities inside companies. Nowadays, tech companies are those with the highest market capitalization, with a trend of positive growth over the last years, replacing the companies who conventionally were on the top of rankings, like American industrial firms, European energy companies and Chinese banks (BloombergGadfly, 2016).

Figure 1 Your New Tech Overlords (BloombergGadfly, 2016)

According to Kurzweil (2001), when we think to a future period we intuitively assume that the current rate of progress will continue in a linear way. However, analyzing the history of technology, the pace of technological change advances at least exponentially; Intel co-founder, Gordon Moore, already noticed that in 1965, forecasting the exponential shrinking of transistor sizes on an

13 Introduction, research objectives and methodology integrated circuit (Moore, 1965), but according to Kurzweil exponential growth is “a feature of any evolutionary process, of which technology is a primary example” (Kurzweil, 2001). However, in 2001, many technology forecasts ignored such exponential aspects, underestimating what technology could achieve in the long term. Indeed, technology pervasiveness is increasing year by year, connecting an ever-growing number people and objects in an ever more digital world: just think at the evolution of the mobile phone market, the rapid diffusion of internet of things or the recent progresses in virtual reality or artificial intelligence.

To be successful, companies thus need to fully embrace what todays’ technology can offer, both to improve the internal efficiency and to deliver the “digital customers” what they expect in today’s world, as information is increasingly becoming a source of value for them. Digital transformation has also influenced the economic realignment of recent years, fostering investment in technology, as emerging markets increased their demand for technology to fuel growth and advanced markets looked for new ways to cut costs and drive innovation, and leading to increased economic growth, as digital technologies drive consumer income and demand, education and training, and efficient use of capital and resources (Oxford Economics, 2011). Nowadays, the idea that every company needs to become a software company is widespread, as it’s required to survive to the disruptions many digital startups like Uber and Airbnb has brought (Patel, 2016); however, it’s not a new idea: in 2011, Marc Andreessen, an American entrepreneur sitting on the board of directors of many digital companies, stated that “software is eating the world”, as he probably fully understood that technology had an exponential growth. This process of change goes under the name of “Digital Transformation”, and it is sweeping across all sectors in recent years. Digital transformation requires changes at every level of the organization: in the following pages, we will see how this transformation is impacting companies’ IT functions, and what IT functions can do to embrace this transformation.

14 Introduction, research objectives and methodology

2. Research objectives and methodology The purpose of this research is describing how companies and their IT functions should react to remain competitive in a market scenario which is continuously evolving due to exponential technological growth.

Before detailing the research methodologies and objectives of this report, we need to contextualize Enterprise Application Governance Observatory, where data have been collected and analyzed. After that, we will present the methodology and logical flow we used to deploy personal analysis and considerations.

2.2. Enterprise Application Governance Observatory Enterprise Application Governance 2016 research has been carried out with the aim of analyzing state-of-the-art and evolution trends of enterprise application in order to identify the main changes necessary to govern Information Systems. Italian Chief Information Officers (CIO) and Enterprise Architects of Large and Small & Medium Enterprises have been involved in the research. The specific research objectives have been:

 Identify trends that are changing decisions in terms of application portfolio;  Deepen how IT function role and processes are changing;  Identify how Information Systems architectures are evolving.

The Observatory used many tools to collect data and achieve these results: 1. Three cross-industry workshops where companies, using interactive frameworks, shared their experiences on three matters:  Role of IT function and management of internal processes;  How Information Systems architectures are evolving;  Trends that are changing application portfolio choices; 2. One vertical workshop dedicated to the Fashion Industry and focused on matters already analyzed in the other three meetings; 3. Interviews to Large and Medium Enterprises in order to deepen specific themes; 4. Online research survey to Large and Small & Medium Enterprises.

Even if it is at its first year of research, the Observatory already has four partners and a large community of IT Executives and Enterprise Architects. The research findings have been published in an annual report and presented in a final conference.

15 Introduction, research objectives and methodology

2.3. Methodological flow The stages followed during the research have been the following:

Preliminary Literature Research Data Results Case objectives review objectives collection analysis studies

Figure 2 Methodological flow

2.4. Preliminary objectives The first research aim has been understanding the peculiarities of the change companies must go through, and how companies can react successfully. In particular, the initial part of the present paper will analyze through a literature review:  Which technological trends are influencing companies’ evolution, enabling new IT-based business opportunities;

 Which reactions companies can put in place in terms of IT management as critical factors to face the change, both under an organizational and a technical point of view.

2.5. Literature review Firstly, we carried out a literature review analyzing the main reports and articles related to the subject of this thesis. We tried to understand which technological trends are impacting on business opportunities, the steps of digital transformation and the consequent concept of adaptive enterprise. Then, we described possible problems deriving from divergences between IT function and business, and the notion of Enterprise Architecture as a tool to manage company evolution keeping them aligned. We also presented a brief description of the role of an organizational unit for Enterprise Architecture within a company. Subsequently, we analyzed IT governance, its relationship with Enterprise Architecture, and how it requires an evolution of IT department organizational configuration. This part is followed by a description of IT portfolio governance in terms of project portfolio management, application portfolio management and application lifecycle management. Then, we focused on software development and IT project management describing the difference between new Agile working methodologies and the traditional ones, highlighting why agility is now necessary. Finally, we described the main architectural patterns for software development and their evolution in terms of software architectures, integration and data management, development frameworks, and application and infrastructure management.

16 Introduction, research objectives and methodology

The main sources have been: Gartner, Microsoft Developers Network, IBM, McKinsey, Observatories researches, MIP School of Management, TechTarget, EMC, IDG, Open Group and scientific articles on specific matters.

2.6. Research objectives The present document has four additional objectives, based on empirical research about Italian companies’ current state in terms of IT management:

 Understanding how Italian companies are coping with Digital Transformation in terms of processes digitalization;

 Analyzing which emerging technological trends Italian companies are considering in decision-making about application portfolio evolution;

 Understanding whether Italian companies are evolving IT function processes management adapting to new working methodologies in an agile model;

 Analyzing which changes Italian companies are deploying in terms of application portfolio and IS architectures governance, assessing the diffusion of specific tools such as Application Portfolio Management and Enterprise Architecture.

2.7. Data collection An online survey was submitted to a preselected sample of Italian Chief Information Officers, IT executives, and Enterprise Architects. The questionnaire represents a quantitative investigation: it is uniformed and structured in questions and answers options. Therefore, it allows to get standard information that is a significant base for more qualitative analysis based on workshops interactive frameworks and discussion.

The survey questionnaire has been structured in order to identify companies’ situation in terms of:

 IT management and investments: spending, investments in digitalization, outsourcing;  Emerging technological trends impact on decisions in terms of application evolution;  Role and processes of IT function focusing on usage of agile methodologies;  Investments in architectures rationalization and presence of Enterprise Architecture.

These objectives correspond to four specific sections of questions in the survey.

17 Introduction, research objectives and methodology

Companies responding to research survey have been 114 and represent the core of the analysis. In order to describe the sample, we can use parameters as sectors and organization dimensions in terms of number of employees and turnover.

Looking at dimensions, we identified:  Small & Medium Enterprises (SMEs) those with less than 249 employees;

 Large Enterprises (LEs) those with more than 249 employees.

25% LE

SME 75%

Chart 1 Companies size in terms of employees

In terms of terms of turnover, we identified three main groups:  Companies with a turnover lower than 50 million €;

 Companies with a turnover between 51 and 500 million €;  Companies with a turnover higher than 501 million €.

16% 0-50 million € of Turnover 45% 50-500 million € of Turnover more than 500 39% million of Turnover

Chart 2 Companies size in terms of employees

While concerning the sector, we used the following classification in order to gain better statistical significance.

18 Introduction, research objectives and methodology

Manufacturing 17% Wholesale & Retail 38% 10% Finance Service & Utilities 11% Public Sector & Healthcare 10% 14% Other

Chart 3 Companies sectors

During the research year, we participated to Observatory workshops where companies were given interactive frameworks to map their “as-is” situation and discuss their experiences in the research topics. Participating to each discussion, we have been able to identify interesting knowledge to integrate results from survey. Particularly, we have studied:

 advantages, disadvantages and critical success factors perceived by IT managers in using agile methodologies for project management;  impacts of new architectural trends, such as Hybrid Cloud, Microservices, and API Management, on IT architectures evolution governance;

 impacts of technological emerging trends, identified as Mobile, Collaboration, User Experience, Data Intelligence, Open Application and Pervasive Computing, on decisions about application portfolio evolution.

2.8. Results analysis We carried out results analysis firstly following a general description of market characteristics, according to survey responses. Then, we tried to correlate responses of different questions in order to get insights on results motivations.

Firstly, we analyzed the sample according to its economic effort towards IT, IT departments size and collaboration with LoBs, and usage of outsourcing. Then, we quantified technological trends influence on application portfolio evolution according to 4 parameters based on responses about trends importance and impact on different application scopes.

Finally, we derived a framework for evaluating companies’ current state in terms of IT management according to 4 parameters based on usage of agile methodologies, application portfolio management, investments in evolution and rationalization of architectures, and presence of

19 Introduction, research objectives and methodology

Enterprise Architecture. In order to get insights from this framework, we analyzed companies as is situation according to a segmentation based on:  Investments in IT and specifically in digitalization;

 Occurrence of similar score profiles on the framework allowing to identify advanced and backward companies.

In order to better contextualize the results, we integrated them with qualitative analysis coming from companies’ discussions during thematic workshops.

2.9. Case studies Case studies represent a more qualitative and flexible inquiry to deepen companies’ initiatives of application portfolio evolution. We have supported each interview with a standard sequence of semi-structured questions defined at the beginning of the analysis. The complementary usage of quantitative and qualitative investigation methods allowed us to benefit from positive aspects of each methodology and, at the same time, to compensate their disadvantages, such as sample numerousness and depth level.

Case studies have been suggested by Observatory research partners. Our analysis structure included:

 Strategy – examining needs for which the company decided to introduce the technological solution, the project extent, its benefits and criticalities;  Technology – investigating introduced platforms and applications;  Organization – studying organizational impacts in terms of working methods, competences, and internal relationships.

20 Literature review

3. IT trends and the Digital Transformation Journey Progress in Information Technology (IT) is deeply changing both business and consumer’s worlds. New ways of connecting, sharing, collaborating, and doing business are enabled by expanding IT capabilities. Understanding how these capabilities are evolving is critical for companies to provide new sources of value, such as new products, new ways of touching customers, and new tools for improving operating efficiency. As found out by Gartner, enterprise IT is living a “digitalization era”, which means “deep innovation beyond process optimization, exploitation of a broader universe of digital technology and information, more-integrated business and IT innovation, and a need for much faster and more agile capability” (Gartner, 2014).

Continuously growing processing speed, storage capacity, data sets, and software advances are leading to new IT-enabled business trends that are able to shift profit pools, disrupt markets and commercial relationships, undermine existing market leaders, and shift value to customers or among producers (McKinsey Global Institute, 2013). Some of these trends were just surfacing in 2007 or 2010, but are now gathering greater momentum: Hinchliffe (2015) defined SMACT trends, e.g. Social, Mobile, Analytics, Cloud, and Internet of Things, as the agenda of key digital improvements underway in the typical enterprise.

Indeed, digital business is demanding a strategic and transformational response to all organizations which need to be dynamic as new business models emerge, technology evolves and markets begin to establish winners and losers. These changes create chaos and uncertainty for those designing and operating the business and striving to balance business stability with imminent innovation (Gartner, 2016).

However, before detailing how the evolution of enterprises can be managed, it is important to specifically describe the mentioned IT-enabled business trends, which are related to the role of ICT in enabling companies to reach a new competitiveness (McKinsey Global Institute, 2013).

21 Literature review

3.1. Technological progress: IT-enabled business trends According to McKinsey (2013), it is possible to identify ten IT-enabled trends relevant in recent years:

1. Social matrix 6. Integrated digital/physical experience 2. Internet of All Things 7. Me + free + ease 3. Big Data and advanced analytics 8. The e-volution of commerce 4. Realizing anything as a service 9. The next three billion digital citizens 5. Automation of knowledge work 10. Transformation of government, health care and education

In the following pages, we will see in detail each of them, making connections with the trends impacting IT governance in terms of applications portfolio management1, as identified by the Politecnico di Milano Enterprise Application Governance Observatory. Indeed, application portfolio management is a key aspect to foster Digital Transformation, as we will see in the following chapters.

Social matrix This trend is related to the socially enabled applications that will become ubiquitous, allowing liking, commenting, and information sharing across a large array of activities at a professional level. This is linked to the growing importance of Collaboration and Communication within the company: indeed, reading and answering email, searching for information, and collaborating with colleagues consume a large percentage of knowledge workers’ time. The McKinsey study (2013) estimated that companies can see an improvement of 25% in productivity just introducing a social platform to communicate and share information, both by making communications more efficient and effective, and by uncovering hidden information and expertise otherwise lying unused in corporate emails, which are responsible for a quarter of office workers’ life. To accomplish this result, it is fundamental to evolve Information System architecture2, avoiding to just add a new technology, since the objective is integrating instruments more oriented to the user with the company transactional systems and data. In this sense, technology is the main enabling factor: using standard solutions, maybe available on Cloud, allows to have up-to-date systems, which speak the same language of users and do not become immediately obsolete compared to new solutions on the

1 Two terms that we will detail in the fifth chapter of the present paper. 2 Information System Architecture is described in the fifth chapter of this paper.

22 Literature review market (Osservatorio Social Business Collaboration, Politecnico di Milano, 2015). Keeping the right IS evolution strategy is the hardest part: in fact, looking at the Italian situation, on 102 initiatives analyzed by Observatory for Social Business Collaboration (2015), only 19 have a plan of extension from a pilot project to all the company. Indeed, generally, projects are focused only on specific processes that need more collaborative flows, such as Marketing and Internal Communication. This trend has been identified by Enterprise Application Governance as “Collaboration”.

Internet of All Things It is the extension of Internet of Things (IoT), renamed due to the proliferation of connected devices. There are more than 12 billion devices around the world, including computers and smartphones, that are connected to the Internet and this number is expected to dramatically grow in the next decade. This will mean transforming activities such as manufacturing, buildings infrastructure management, healthcare provision, and supply chain management by monitoring and optimizing processes and assets at a very granular level. Any activity that “touches” multiple things or people across the value chain would be potentially reimagined with the help of networked sensors and actuators. According to a Zebra Technologies study (2012), at least 15% of companies have implemented some kind of IoT solution and 67% had plans to do so within five years. The rapid adoption of IoT is driven by the rapid decrease in the cost of sensors and actuators, the increasing ability of connecting to these sensors, often wirelessly, as well as the ability to analyze the huge amount of data generated. The main implications are remote monitoring and systems optimization, for which companies are becoming able to monitor how equipment are used or under what conditions a product makes its way along the supply chain. Moreover, they are becoming able to track the health of physical systems and make maintenance continuous and effective. In complex systems, IoT enables decisions automation based on sensing input. Enterprise Application Governance identifies this trend with the term “Pervasive Computing”.

Big Data and advanced analytics This trend refers to the phenomenon for which, as our world becomes more networked and our activities more digital, data is more abundant, more diverse, and more available in real time. Organizations are harnessing Big Data to develop insights to fine-tuning systems, inform decision making, and develop products that were previously impossible. However, many companies still struggle to adopt Big Data and fully capture its potential: in Italy, only the 13% of companies has

23 Literature review an advanced technology for Big Data analytics with advanced data warehouse (for example, NoSQL database3), the 24% has at least technologies aimed at predictive analysis, while the 53% has traditional data warehouse for just structured data and the 10% is stable at silos architectures and heterogeneous systems. However, the main problems are the organizational ones: only the 24% of companies has developed a plan and a budget for Big Data management, while the 33% does not have a plan and even is not aware of the opportunities coming from Big Data. Finally, just the 9% of companies has a plan to create and enhance competences regarding Big Data management (Osservatorio Big Data Analytics & Business Intelligence, Politecnico di Milano, 2015). In general, data-driven companies, being early adopters, have gained an advantage of 4% more productivity and 6% more profitability (Brynjolfsson, et al., 2011). Need for Big Data capabilities continues to grow as the amount of data in the world doubles every two years. Communications, trade and commerce, media consumption and work are some of those activities providing extensive digital data. The proliferation of networked sensors through IoT and smartphones is leading to more activities having a digital footprint and, consequently, more data. Moreover, as predicted by the aforementioned Moore’s law, computational capacity continues to double every 18 months. Combined with Cloud Computing and advances in User Interfaces and virtualization techniques, this progress is increasing the power to rapidly analyze data and deliver insight, while requiring new skills and raising new challenges. Big Data analytics will improve performance management through access to timely data, introducing real-time monitoring and transparency; it will foster experimentation and research, automate decision making and knowledge work, enable unprecedented customer micro-segmentation and create new business models through data monetization. Companies will try to use Machine Learning logics to gain maximum value from data. The organizational challenge will be the introduction of new competences and roles, such as Data Scientist and Data Steward, in order to manage Data Intelligence. From a technological viewpoint, an integrated management of structured and unstructured data will be needed in combination with the possibility to integrate data from external sources. Data storage will need to evolve to a NoSQL3 logic in order to store unstructured data in the so-called Data Lake (Osservatorio Enterprise Application Governance, Politecnico di Milano, 2016). This trend is identified as “Data Intelligence” from the Enterprise Application Governance Observatory.

3 A detailed definition of NoSql, along with that of other terms cited in the literature review, is available in the glossary (Appendix B)

24 Literature review

Realizing anything as a service This trend refers to the internet model for acquiring resources through pay-as-you-go models that is giving companies the opportunity of being more “asset-light”. Enterprises are finding out the advantages of tapping into this trend, replacing expensive infrastructure and assets with discrete service purchases, especially in software solutions and IT infrastructure, and changing capital expenditures to operating costs. Enterprises are migrating their services to private or public “clouds”, which are shared pools of computing resources such as network, servers, storage, and applications that can be rapidly and conveniently provisioned. In particular, according to NIST (2011), Cloud Computing is “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (i.e. networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction”. Cloud Computing is on-demand, available through broad network access, characterized by a multi-tenant model (i.e. a pool of resources serving multiple consumers), provided elastically and measurable. It can be deployed through Private Cloud, in which the infrastructure is provisioned for exclusive use by a single organization; through Public Cloud, in which it is provisioned for open use by general public; or through Community Cloud, in which it is provisioned for exclusive use by a specific community of consumers. It can be also a Hybrid Cloud, as a composition of two or more distinct cloud infrastructures. Furthermore, Cloud Computing can be delivered according to three models: the first one is Software as a Service (SaaS), providing applications running on cloud infrastructure. Then, Platform as a Service (PaaS) provides to customers the capability of deploying onto a cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the cloud provider. In this case, consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems or storage, but has control on deployed applications. The third model is Infrastructure as a Service (IaaS), which provides to consumers processing, storage, networks and other fundamental computing resources where they are able to deploy and run arbitrary software that can include operating systems and applications (Mell & Grance , 2011). As shown in Figure 3 Mainetti (2015) adds another delivery model referred to as Business Process as a Service (BPaaS). According to Gartner (2016), BPaaS is the delivery of business process outsourcing services that are sourced from Cloud and constructed for multi-tenancy. These services are accessed via Internet-based technologies and are often automated.

25 Literature review

Figure 3 Cloud Computing Delivery models (Mainetti, 2015)

In general, using Cloud services, companies pay only for the IT resources they use and deliver software through a new as-a-service model, saving more than a quarter of their earlier IT spending and increasing convenience for their end-consumers. However, they have to overcome anxiety about moving core functions to cloud-based services in order to benefit not only from savings and flexibility, but also from a level of reliability and resilience that they could not deliver in-house. The first challenge they will face is acquiring the right competences from an organizational point of view: according to Italian CIOs, these competences refer mainly to contract management, enterprise architecture and project management. Disruptive innovations require to introduce new models in ICT management such as agile and recursive iterations in order to govern Cloud projects. The second challenge is the evolution of Information Systems architecture towards a hybrid logic, in which infrastructures and applications are integrated in a flexible and rapid way with Cloud services. These aspects are leading to the transition from silos models of architecture to mechanisms of applicative cooperation and structured information exchanges as a core of the company Information System. The challenge is harder from the application point of view rather than the infrastructure one. It is rare that companies adopt a strategic approach in terms of integration and Cloud migration: they do not provide a centralized management of applications portfolio evolution, but follow an approach focused on single choices, that makes them loose the broader viewpoint of the Information System and consequently reduce the potential advantage coming from Cloud services (Osservatorio Cloud & ICT as a Service, Politecnico di Milano, 2016). Companies applications’ inheritance, coming from their evolution, consists of Legacy Systems,

26 Literature review which are historical applications still managing the company core (often productive) processes. Along the company history, these applications have been developed using the state-of-the-art of technologies and design methodologies of that moment, from client-server, to three tier, or in a service oriented logic (SOA). Due to this heterogeneity, integration among these elements is generally realized through ETL flows or manual users support, but, nowadays, as the company exploits Cloud services coming from external providers, Information System needs to be seen as a continuum from outside to inside the company and realized through flexible instruments of integration (Osservatorio Cloud & ICT as a Service, Politecnico di Milano, 2011). Indeed, there is a trend of opening legacy systems towards a service oriented logic in order to rationalize the application portfolio. However, very often, IT function has the role of supporting a set of systems and applications components that were implemented in a disorganized way without a plan of growth but just following business needs. This approach led to temporary responses that created isolated applications, difficult to update, manage, integrate, and protect (Osservatorio Cloud & ICT as a Service, Politecnico di Milano, 2012). In the following chapters, we will detail aspects related to both the governance of enterprises’ applications portfolio and to software architecture, covering many of the mentioned topics.

A trend strictly related to services, cloud architecture and hybrid information system, is that of Open Application. McKinsey in 2013 hasn’t enlisted this trend among the top 10, but according to the Enterprise Application Governance Observatory it has a relevant impact on application portfolio choices. This trend involves the possibility to extend functional coverage of applications integrating them with third-party applications through standard Application Programming Interfaces (API). Thanks to Open Application, application functionalities can be easily extended or combined with others, providing more value to the involved stakeholder (internal and external); this trend also brings a better user experience to internal and external developers, and enables new business models, like API economy (Osservatorio Enterprise Application Governance, Politecnico di Milano, 2016). However, the implementation of Open Application requires a standardization of integration methods, both for internal and external software, and the usage of structured methodologies: API usage and internal data should be controlled through API management tools, as we will see in chapter five of the present research.

Automation of knowledge work As mentioned before, this trend is related to Big Data analytics, machine learning and natural user interfaces, such as the ability of a computer to interpret instructions in natural human language.

27 Literature review

These elements, combined with unprecedented computing power and connectivity, made possible to automate knowledge work. The natural user interfaces refer to a new approach towards applications, now based on User Experience, which means designing applications with the aim of making user experience effective and satisfying. This brings many benefits such as improving the user productivity and reducing errors, reducing time needed for training to the use of systems, and increasing users’ satisfaction (Osservatorio Enterprise Application Governance, Politecnico di Milano, 2016). “User experience” is the term used by Enterprise Application Governance Observatory to identify this trend.

Integrated digital/physical experience This trend deals with new people habits such as shopping online and meeting in virtual spaces. Online world is replicating specific experiences of the real one, and trends, such as mobile and user experience, are giving the physical world characteristics of the digital one. Therefore, this impacts both on consumer experience and on workforce activities. Businesses are exploring the potential of simple tools like tablets to integrate the digital into physical work activities, and to improve productivity, sales, and product development. Towards business Mobility, they are separating applications access from single working place and device. This allows new working styles, such as remote working, that are closer to users’ expectations. Moreover, Mobility improves processes productivity, response velocity, and personal commitment. Applications functionalities can be powered by devices’ sensors and by exploiting mobility situations. Beside the introduction of new functionalities, this provides an advantage in reducing time needed to learn how to use an application due to their design for increased usability and their similarities with applications used by workers in their personal life. Mobile Biz-Apps, which are mobile applications supporting business processes, are similar to consumers’ applications since they provide high usability through simple and effective interfaces and interactions models (e.g. touchscreens). These applications can be aimed at supporting specific business processes, organizational and administrative processes, and at visualizing information. Obviously, Mobility has strong impacts on IS and applications architecture, influencing applications development methodologies since they can be mobile native, hybrid, or web applications, impacting on users’ interfaces that have to be developed for different types of devices in adaptive or responsive logic, and changing applications compatibility requirements since it has to deal with different browsers and operating systems. (Osservatorio Enterprise Application Governance, Politecnico di Milano, 2016). Enterprise Application Governance Observatory uses the term “Mobility” when referring to this trend.

28 Literature review

Me + free + ease This trend refers to the change in customers’ expectations towards how to shop, watch, read, seek information and interact on the Internet. They expect more services to be free, personalized and easy to use without instructions, otherwise they are likely to voice their disappointment on Facebook or Twitter. Customers have more power than ever in the Internet era, since competitors are a mouse-click away and switching costs are low. Therefore, companies need to respond to increased pressure from customers identifying alternative sources of revenues and new business models, such as freemium. Moreover, they will have to think about more personalization in their products and services changing the back-end systems, that are often designed for mass production, to a new mass customization. This means finding new ways to collect information that enables personalization, even persuading consumers to provide relevant data. Products and services testing will completely change, introducing new methods into their lifecycle, such as A/B testing, which are randomized experiments that compare variants. In this perspective, social media provide an opportunity to see how consumers actually use products, rather than relying on focus groups and surveys. Therefore, companies need to become data driven in order to be able to define the right business model.

The e-volution of commerce It is related to e-commerce that is getting a jolt from the rise of mobile internet and the evolution of base technologies that reduce costs and vastly simplify the process of doing business and completing transactions online. Therefore, barriers to entry have fallen, and new marketplaces, new kinds of payment systems and new business models are emerging. In particular, new mobile payment platforms are leveraging on Cloud and Big Data in providing additional services to client businesses, such as paying through credentials. This allows using advances in IT to enable faster, cheaper, secure, and less intrusive financial transactions both in developed and developing markets, for example through virtual currencies. Moreover, this trend is leading to new models, such as “sharing economy”, in which individuals are provided with platforms to exchange their unused assets and offer services to a wide pool of consumers, and new customers preferences that can be disruptive for existing companies. Large organizations can catch the opportunity of participating in these new markets and monetize assets, for example selling data and renting out proprietary software.

29 Literature review

The next three billion digital citizens This trend refers to expected growth of users connected to Internet from 2.5 billion to 3 billion. According to McKinsey (2013), by 2025, most of this growth will occur in developing economies and more than 1.8 billion people will move up into the global consumer class, represented by those who earn to buy goods and services after meeting basic needs. Through mobile payment and banking services, financial inclusion will be extended to the category of “unbanked”. The expanded access to digital services will encourage economic development through the growth of local entrepreneurship. Moreover, multinational and local companies alike will develop products and IT- enabled business models specifically for local conditions, despite infrastructural challenges. The combination of online and offline strategies needed by this digital economy will be a big challenge for companies requiring a range of investments in talent and capabilities.

Transformation of government, health care and education Internet and sophisticated IT tools have strongly changed the way companies operate in many industries except for government, healthcare, and education. Indeed, they have been slow to adopt web-based platforms, Big Data analytics, and other IT innovations, but they could benefit from entering a new era of IT-enabled productivity growth. Public and social services will be better delivered at lower cost by increasingly overcoming deep resistance to change.

3.2. Digital transformation: from First to Fourth platform In order to describe the digital transformation journey, it is common to structure the description in “computing eras” or according to the emergence of new types of platforms (Hinchcliffe, 2015).

Figure 4 Evolution from First to Fourth Platform (Hinchcliffe, 2015)

30 Literature review

According to IDC, from 1964 to 2014, companies evolved from the first to the second computing platform, facing a “digitize” stage, during which digitalization impacted pervasively on media, processes, and intelligence (Chused, 2014). Companies have moved from the First Platform, dominated by mainframes and terminals able to process thousands of apps for millions of users, to the Second Platform, which have seen the rise of Internet, personal computer and client-server model. From the Second to the Third Platform, the number of applications has grown from tens of thousands to millions, and the number of users from hundreds of millions to billions. The Third Platform era has been dominated by Mobile, Cloud, Big Data and Social: in fact, in order to accomplish the process of “digitize”, companies built “clouds” to easily access their digitized data and make it available on multiple devices. Gartner describes the above-mentioned trends through the Nexus of Forces, a framework which describes how the convergence of Mobile, Social, Cloud, and Information has become the platform for digital business, which means creating new business designs blurring the boundaries between digital and physical world (Gartner, 2014). The context of Figure 5 Gartner Nexus of Forces this framework is an unprecedented combination of new technologies, focusing on client experience and business transformation, generating revenue and value (Dreyfuss, 2014). But what is next? The step after “digitize” is “materialize” and it will guide companies’ strategy at least until 2021. Some signals are intelligent home appliances, self-driving cars, and wearables, which, since now, have not been part of users’ every-day-life. Practically, once built well-run “clouds” and fine-tuned Big Data analytics capabilities, the Fourth Platform represents the opportunity to truly innovate the material world (Chused, 2014).

31 Literature review

4. Managing enterprise evolution: the adaptive enterprise To survive in fast changing markets and under increasing uncertainty, enterprises have to be adaptive: adaptive enterprises are highly flexible organizations, which have the ability to change or adjust in almost real-time by altering routines and practices in response to environmental changes (Moitra & Ganesh, 2005). Indeed, adaptive enterprises can deal better with risk and uncertainty than those with traditional structures. According to TechTarget (2005) an adaptive enterprise is “an organization in which goods or services demand and supply are matched and synchronized at all times”. This kind of enterprises are able to optimize the use of their resources, including Information Technology, on the base of the real need.

In Adaptive Enterprises, IT services provision and business needs are matched and aligned (Gartner, 2014). Therefore, Information System dynamically evolves, following and supporting the pace of business. This means structuring a company strategy for applications evolution and stopping tactical management focused on ad hoc solutions to business requests, since it only produces complex, fragile and expensive Information Systems. Indeed, this kind of approach makes applications rigid and complex, impeding transparency of decisions across different projects and forcing to the lack of shared and up-to-date knowledge of the systems. Moreover, it forces to re-project IT solutions from scratch for every new initiative with never ending prototype phases. Instead, in Adaptive Enterprises, projects with similar objectives have a common orientation, allowing to exploit their synergies and build a solid base for the future development of new solutions (Mainetti, 2015). Tactical IT management is generating many problems for companies: IT systems are very costly and complex to maintain and are hindering the company ability to react to current and future market conditions in a timely and cost-effective way. Moreover, mission- critical information is inadequately managed in a way that it is frequently out-of-date or unsuitable. All these factors generate a distrust between business and technology sides of the organization, creating a non-collaborative environment (Sessions, 2007).

To strategically manage IT and successfully become Adaptive, an Enterprise should consciously manage the so-called Enterprise Architecture (EA), whose aim is to show the essence of enterprise operations beyond their realization and implementation. In today’s ever changing environment, EA is a commonly accepted mean to support an enterprise transformation process and furthermore enhance the alignment between business and IT. Indeed, EA management creates architectural descriptions of current, planned, and future states of the enterprise (Mykhashchuk, et al., 2011), an abstraction which is fundamental to manage the business complexity (Hinkelmann, et al., 2015).

32 Literature review

4.2. IT and business divergences: the shadow IT Before better defining Enterprise Architecture, we think it is important to point out how the context which IT functions nowadays face is changed, and how this can limit the alignment between business and IT.

Due to technological progress and new IT trends, Lines of Business are living a period of profound change. On one hand the boundaries between personal and business technologies are blending as consumer-oriented technologies, like mobile applications, are having a big impact on businesses (the so-called “IT consumerization”, employees expect to be able to use the good technology they have at home at work too); on the other hand, due to a growing IT pervasiveness, some topics stop being an exclusive domain of IT functions and become a spread expertise within Line of Businesses (Osservatorio Enterprise Application Governance, Politecnico di Milano, 2016). This situation is leading Lines of Business (LoBs) to a high interest towards technology as an enabling driver for innovation, and technology is becoming part of almost every transformation project underway. Enterprise IT functions are thus often at the front of a wave of investment and exploration in technology-enabled business innovation: LoBs look for technological solutions which must be delivered as fast as possible and at the lowest possible cost (Mazzucco, 2015). Therefore, there is a paradox for IT which is not new, but is highlighted as the divergence between what users experience ad what they required is increased: as the technology they employ and deploy becomes easier to use and simpler to manage, it is actually increasing complexity (Evans, 2012).

Nowadays, several companies use IT delivery as a Service (ITaaS): they consider IT as a commodity, like water or energy, focusing on cost efficiency, decisional centralization, and standardization; in the same way, ICT sourcing is seen as a commodity sourcing, with the right amount resources are delivered for an agreed monthly fee (TechTarget, 2012). This has led to the so-called “shadow IT”, which means that IT devices, software and services are outside the ownership or control of IT organizations: if enterprise IT functions are not able to answer LoBs requests, the latter will look for technological solutions elsewhere, surpassing the IT function and looking towards external suppliers. This happens often, as IT is commonly managed with a tactical approach, described in the previous pages: IT systems are rigid and complex, not being able to satisfy the performances asked from business. For example, due to the pervasive growth of public clouds, in many companies business units and internal customers have used and are accustomed to IT as a service, building business processes and budget plans with cloud computing in mind; if IT organizations do not match requests for IT as a service from internal customers, the risk they will bypass the IT

33 Literature review organization and consume IT service from the external cloud is high, and places the company at greater risk (Howard, et al., 2012).

This situation results in a downsized IT function, considered only as a cost center which must be optimized, shifting under the influence of buyers and CFOs towards an increasing externalization. This also reduces the magnitude of innovation projects pushed by IT, that risk to remain just marginal pilots (Mazzucco, 2015).

Figure 6 Lines of Business dynamics and impacts on IT function (Mazzucco, 2015)

It is a harmful situation for enterprises, as today, given the exponential technological evolution, collaboration between IT and LoBs to exploit the synergies between their competences is crucial to bring innovation within the company. Today, the need of considering IT as an innovation center, which has to be managed as a research laboratory, focusing on innovation, proximity to business and creativity, is growing. IT-business alignment is essential since those responsible for product/service management, supply chain, manufacturing and customer service must prepare to incorporate digital innovations into the way they operate (Gartner, 2016). ICT sourcing can’t be considered a commodity, it must be treated as the access to fundamental innovative competences (Mazzucco, 2015). IT departments must change from supporting the business to being the business, as IT is becoming more and more a part of the actual product or service delivered to customers (Evans, 2012).

Even if it is not simple, IT functions must support this massive transformation, otherwise business stakeholders will do it in other ways, which are risky and dangerous. IT must be able to satisfy the new performance requirements of business, becoming quick, agile and flexible, ensuring velocity and executional capabilities. As its objectives and role changes, an internal transformation of the IT function is needed, in terms of governance, organization, competences, processes,

34 Literature review methodologies and sourcing (Mazzucco, 2015). In this perspective, its overall structure has to be simplified while the focus needs to shift to governance rather than practical development; furthermore, CIOs should move IT competences towards a greater proximity to business in order to effectively support the company innovation processes. CIOs have to provide a proactive management of internal IT services demand, keeping IT and business strategy aligned, adapting costs and technological solutions to business needs, respecting time-to-market while considering security limits, optimizing IT performances and change management, and aligning technical and business domain languages.

Figure 7 CIOs' competences evolution towards collaboration (Mazzucco, 2015)

The new requirements for IT functions, related to the need for a new enabling technological architecture, the need for alignment between IT and LoBs and the subsequent transformation requested to IT departments, are influencing IT working processes as a considerable effort is required to consistently evolve enterprise information systems, in a context which is ever more heterogeneous and complex. To handle this effort and manage complexity, two things are required:  a new governance of organizational architecture (Mazzucco, 2015), which is identified in Enterprise Architecture;  a structured and effective approach, with new decision-making criteria, new architectural models, new internal processes and methodologies to support IT functions transformation.

However, value from IT is created and sustained by how the business uses IT investments: this requires more than delivering IT solutions and services, but IT alone can’t be responsible for achieving this value: an organizational change is needed (Thorp & Leadership, 2003) We will deepen the former topic in the following pages, and the latter in chapter five.

35 Literature review

4.3. Enterprise Architecture management Enterprise Architecture (EA) management supports enterprise transformation in response to on-going change, such as globalized markets, specialized customers’ demand, shorter time to market, and emerging regulations (Mykhashchuk, et al., 2011).

Since the early nineties, when the idea of describing enterprise as composed by different dimensions emerged within different disciplines, multiple definitions of EA have been developed according to the input received by many domains, such as systems engineering, organizational science, industrial engineering, information systems and ICT (Sessions, 2007). Particularly, ICT gives a perspective on the notion of enterprise and what it is necessary to do to align, design, engineer or change it. Indeed, almost twenty years ago, IT systems complexity began to grow, and now they have reached a point of crisis due to the rapid pace of technological evolution; they are ever more expensive and difficult to align with business’ needs: practically, their cost has grown but the value that they are able to provide to the business has dramatically decreased. IT systems are losing agility since technological evolution is creating applications’ stratification: Cloud computing is changing the way IT services are delivered, data availability is hugely increasing, information technology is more and more pervasive in everyday life and companies’ application portfolio is thus exploding. Therefore, EA management is needed to evolve the enterprise aligning these costly systems with the business (Sessions, 2007). Indeed, Enterprise Application Governance Observatory (2016) identified two layers of Enterprise Architecture that has to be coherently aligned:

 A business layer composing the Business Architecture which consists of business processes;  A technological layer which consists of Data, Applications and Technologies.

Figure 8 Enterprise Architecture layers (Osservatorio Enterprise Application Governance, Politecnico di Milano, 2016)

36 Literature review

We think the right approach to define EA is to start with single terms:  Enterprise: “any collection of organizations that has a common set of goals and/or a single bottom line.” (The Open Group)  Architecture: “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.” (ISO/IEC/IEEE 42010:2011)

Enterprise Architecture thus seems to be related to the analysis of the single components of organizations, like business processes and information systems, showing how they are related and interact. This is aligned with MIT CISR definition (2016), which view architecture as the strategic exercise of describing a shared vision of how a firm operates, thus providing a common understanding of the role of IT. Gartner (2016), indeed, defines Enterprise Architecture as “a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes”. As EA is critical to align IT and business strategy, it delivers value presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions. According to Mainetti (2015), Enterprise Architecture role is the alignment between the Enterprise Strategy and the Executional activities.

Figure 9 Role of Enterprise Architecture (Mainetti, 2015)

EA’s practical result is a graphical roadmap of milestones and deliverables needed to evolve an enterprise from a present state to a future one in a specific amount of time (Mainetti, 2015). There are three types of roadmap: the first one, dedicated to strategic planning, is Enterprise Roadmap; the second one, aimed at Strategic Execution, is Evolution Roadmap; the third one, dedicated to Operational Execution is Lifecycle Roadmap. From the perspective of application portfolio management, Lifecycle Roadmap supports software lifecycle, whose typical phases are Analysis and Planning, Design and Development and Deployment as we will see in chapter five.

According to Mainetti (2015), Enterprise Architecture is useful to:

 abstract the business functioning logic irrespective of the implemented technical solutions;

37 Literature review

 plan a roadmap of strategic interventions;  analyze the relationships and interdependences among projects;  design according to standard and up-to-date procedures;  manage every initiative according to a predefined blue print;  coordinate different initiatives referring to the same areas.

The basic idea behind EA is that as systems become more complex, they require more planning (Sessions, 2007). Therefore, abstraction is needed to show the essence of enterprise operations beyond realization and implementation. EA is a conceptual model developed to manage the complexity of the business. In particular, designing an enterprise is a continuous process in which Information Systems have to be continuously adapted. Usually, an ICT project does not start from scratch with a greenfield approach: in fact, while the business is running, the challenge is to react on change, keeping business and IT aligned (Hinkelmann, et al., 2015). In order to successfully achieve the results of an ICT project along its lifecycle, it is fundamental to have a systemic and holistic approach towards Enterprise Architecture Governance and Management (Mainetti, 2015).

A deep understanding of Enterprise Architecture is fundamental to manage company’s changes and complexities. EA is a complicated concept and, in order to carry out its description, a large number of frameworks has been developed, and we will analyze some of them in detail. However, despite the plurality of publications on the subject, still no common understanding of what EA management actually is has yet been developed, as the term is used by authors without a proper definition or explanation (Mykhashchuk, et al., 2011).

Zachman Framework The most popular framework to describe Enterprise Architecture is the Zachman’s one. Zachman contributed to the birth of Enterprise Architecture field through the article “A framework for Information Systems Architecture” (1987), in which he described the challenge of managing the complexity of distributed systems and of developing the vision of Enterprise Architecture. The framework was originally thought and named as an Information Systems Architectural Framework and soon renamed to be an Enterprise Architecture Framework, enlarging the vision. His idea is that business value and agility could best be realized by a holistic approach to systems architectures since they lead to concentrate on very important issues from very important perspectives. In fact, his framework has a multi-perspective approach combining in a matrix different stakeholders, who

38 Literature review are planner, owner, designer, builder, subcontractor and enterprise, with different descriptive focuses, which are what, how, where, who, when, and why.

The framework is complete if every intersection between focuses and perspectives contain an artifact, which is a specific document, report, analysis, model or other tangible that contributes to architecture description.

Figure 10 The Zachman's framework (Zachman, 1987)

Synthetizing each Zachman’s focus (Lapalme, et al., 2015):

 “What” refers to a set of things that enterprises must track and manage, for example input/output of transformation processes, input/output of decision making processes, and means to realize them. From the IT perspective, one of these sets is represented by enterprise data. In this sense, companies are facing the challenge of managing a vast amount of data from multiple sources, many of them outside its boundaries. They have to be able not only to understand each datum, but to look across data sets, integrating them to gain information.  “How” deals with work and processes design and execution within the enterprise. Complexity and uncertainty are increasing due to the rapidly changing environment, and

39 Literature review

processes have to be highly adaptive in order to allow the company survival. The center of this innovation lies in people: they are the main agents dealing with complexity, and, starting from design, processes have to become human-centric. It is opposite to the common design based on standardization and compliance, fitting machines but unfitting people.  “Who” refers to organizational stakeholders, and their respective roles and responsibilities. The heterogeneity of work forces is contributing to the organizations complexity, with challenges regarding power, ownership, roles and responsibility. The main trends include the increasing presence of more educated workers, work professionalization, cultural and generational diversity, and last but not least co-creation and co-production. In fact, customers are becoming active participants in production and ideation processes, extending the boundaries of the company.  “Where” and “When” refers to the changes regarding space and time of the organization. Traditionally, companies had clear geographic locations and time zones. With the advent of globalization and especially of ICT technologies, they can span the globe in terms of targeted customers, production locations and operating hours. This kind of virtualization and its related challenges will become a day-to-day issue for companies.  “Why” deals with intentions, values and motivations that drive organizational behaviors, decision-making and concerns. This refers more to companies’ capacity of addressing a triple sustainability issue regarding social, environmental and financial concerns.

Concerning the perspectives, which represent different stakeholders’ viewpoint, they are the following (Lapalme, et al., 2015):

 Executive perspective (or business context planner) refers to the challenges executives are facing in guiding enterprises in a turbulent environment, dealing with rapid shifts in market trends and technologies, and company openness toward customers, partners and competitors.  Business management perspective (or business concept owner) refers to managers of the future. Complexity and uncertainty are leading them to change organizational structures and management practices, that until now were focused on achieving stability, conformance and standardization.  Architecture perspective (or business logic designer) is related to identifying the components of the enterprise and the relationships between them. As the complexity increases, the causal relationship is no more valid and understanding all the consequences of changes becomes

40 Literature review

impossible. This is the case of disruptive technologies and new architectural models, such as cloud computing. For example, companies will exploit contextual data of customers to efficiently gain competitive advantage, adding prediction and scenario analysis as tools for architecting.  Engineer perspective (or business physics builder) is related to designing aspects of the enterprise. Traditionally, approaches to design aimed at identifying an organizational structure in order to achieve a predictable efficiency controlling all the resources. Nowadays, the turbulent environment is leading to designing approaches taking into account that enterprise may not necessarily have control over resources. However, they are in a state of constant design to remain relevant and agile using resources from more than one source with a varying level of control, consistency and reliability.  Technician perspective (or business component implementer) refers to execution. From this perspective, the challenge of future organizations is to adapt skills, performance expectations, organizational structures and enterprise knowledge to complexity and uncertainty within and outside the enterprise.

It is possible to present an example to understand the problems that the framework wants to solve. Taking into account the above mentioned instance of “what” focus, data are seen in a completely different way by a business owner and by who has to implement a database: for the first one a datum is a business entity, such as customers, products, or inventories, while for the second one it is rows and columns organized into tables (Sessions, 2007). They have different perspectives on the same issue but this does not mean that one perspective is better than another, they are equally important to understand overall system architecture. As stated by Zachman, “we are having difficulties communicating with one another about information systems architecture, because a set of architectural representations exists, instead of a single architecture” (Zachman, 1987).

TOGAF Framework The second well known framework is the TOGAF one. In 1995, the Open Group developed the first version of this framework and it was based on Technical Architecture Framework for Information Management (TAFIM) carried out by the US Department of Defense. TOGAF central core is the Architecture Development Method (ADM), which describes a process of nine phases to manage EA development. The Open Group standard modeling language for EA is Archimate and it provides instruments to describe, analyze, and visualize relationships among

41 Literature review business, applications and technology domains in an unambiguous way. Archimate allows to describe construction and operations of business processes, organizational structures, information flows, IT systems, and technical infrastructure through a common language. It is organized into three core layers and two extensions (Castiglioni, 2012):  Business layer that models organization structure and produced services, business roles and processes, and business objects such as products and contracts;  Application layer that describes application components and their interactions, logical data entities and their relationships, and the resulting services, offered to the upper business layer;  Technology layer that models hardware and software systems and the connecting networks, showing how they translate into services provided to the upper application layer;  Motivation, which is the first extension added in Archimate 2.0 specifications, refers to motivational concepts used to model motivations and reasons that influence, guide, constrain, or partly change the EA design;  Implementation and migration, which is the second extension, includes concepts for modeling change programs and migration planning, as well as to support program, portfolio, and project management.

According to TOGAF, architecture is a continuum, called Enterprise Continuum, ranging from highly generic to highly specific architectures. The most generic architectures are Foundation Architectures, which are architectural principles that can be used by any organization in the world. On the opposite side, there are Organizational Architectures, which are specific to a given enterprise. The process used to get Organizational Architectures from Foundation Architectures is the above-mentioned Architecture Development Method (ADM). Between Foundation and Organizational Architectures, there are Common Systems Architectures and Industry Architectures, which contain more and more details. For a growing level of detail, the Common Systems Architectures can be used by many types of enterprises, but not all, and Industry Architectures only by enterprises in the same domain. An example of Common Systems Architecture is the Security Architecture, which solves a single problem domain but is not enough to describe the overall Information System Architecture (Sessions, 2007).

The ADM is an iterative process which must be followed to develop an architecture adequately addressing business requirements, differently from Zachman who gives a method to categorize them. The architectural work should produce deliverables, artifacts and architectures building

42 Literature review blocks. According to ADM, a company should prepare the organization for a change developing a preliminary vision for its success. Then, in order to prepare business, information and technology architectures, it should define targets and analyze gaps. Once defined them, architecture should be implemented, taking into account the business requirements and controlling costs, benefits and risks. Finally, the change should be implemented and continuously improved (Weisman, 2011). ADM is iterative at three levels: over the whole process, between phases, and within phases. It is a generic method and it can be tailored to suit the specific needs of the organization (Castiglioni, 2012).

Mainetti Framework According to Mainetti (2015), EA can be explained by a framework consisting of five interdependent architectural layers that has to be developed simultaneously in order to accomplish the alignment between IT and Business Strategy (Mainetti, 2015). In particular, these layers are the following:

 Enterprise Strategy: competitive positioning, business strategy, enterprise services;  Business and processes: process flows, organization, functional coverage;  Applications: application portfolio and business logic;  Information and data: structure, relationships and semantics of data and information;  Technologies and infrastructures: infrastructure (network, storage, computing capacity, operating system, virtualization) and middleware (application platform, integration environment, database management system).

How to use Enterprise Architecture Giving a practical example, EA and particularly the TOGAF model can be used to integrate Cloud services in the enterprise. Indeed, Archimate, a modeling language4 used for enterprise architecture, is about services and service realization, and this fits well with the Cloud model. SaaS can be easily defined as application services exposed to support a business process, implemented through application components. Equally easily, PaaS can be defined as a technology service to support components and data of a specific application. Therefore, requirements for SaaS can be described by (Castiglioni, 2012):  Motivation of involved stakeholders;

4 A definition of modeling language is given in chapter five of the present paper.

43 Literature review

 Business model to be supported;  Interfaces exposed to or from other applications;  Services requested to the consumer’s technology level if connectivity between Cloud and on premise systems is required;  Non-functional aspects of SaaS solution.

For example, let’s imagine an insurance company that has identified its existing CRM as an inhibitor to the achievement of business objectives and wants to externalize the process. Using the Open Group Archimate standard, we can model the motivation layer related to this migration, as in the following picture.

Figure 11 Motivation model for a new CRM in a hypothetical insurance company (Castiglioni, 2012)

CEO’s motivation is twofold:

 Increase the number of repeated sales to a given customer;  Earn money before year-end.

From CFO’s point of view, the concern is the ROI of capital expenditure in a period of tight cash, while the CIO is mainly worried about the floor space available in the existing data center. The security department opposes every off-site solution since they are scared of losing company vital data, such as customers’ records, and require the implementation of company security practices. As modelled in the Figure 11 Motivation model for a new CRM in a hypothetical insurance company , from CEO, CFO, CIO, and Security department requirements, it seems that the choice is between a Cloud solution and more traditional outsourcing, with additional points in favor of the first. However, security requirements are difficult to accommodate and will restrict the number of eligible providers. Moreover, SaaS solution selected cannot be a “pure” cloud service, because

44 Literature review it must include a mechanism for protecting data from unauthorized access and data alignment between Cloud and existing data center. Therefore, it will be a hybrid solution.

Supposing that the supported business model remains the same as before, once defined functional and non-functional requirements of the SaaS solution, the insurance company should model the Archimate Application layer, designing the new application portfolio.

Figure 12 The new application portfolio coming from the migration of CRM to the Cloud in an insurance company (Castiglioni, 2012)

As shown in Figure 12, application portfolio will change from the one on the left to the one on the right since CRM has become external to the enterprise. The CRM role will not change, but it is important to consider its interface with other components, such as Customer Data Access and Policy Data Management, because those could change exchanged data and used protocol. Redrawing this model, making application components and interfaces explicit, the result is Figure 13 (Castiglioni, 2012).

Figure 13 Diagram of the revised application model for a new CRM in an insurance company (Castiglioni, 2012)

45 Literature review

For example, Enterprise Service Bus (ESB) technical component has been added to offer web services interfaces to company data, using a secure ESB and a secure FTP service toward enterprise data warehouse in order to satisfy the requirements of the company’s security manager.

For instance, for the interface with the web portal, simple HTTP redirect supported by a single user ID and password schema is enough. Therefore, the contact agent will use a single ID and password pair to log on to internal systems and to the new CRM application (Castiglioni, 2012).

Benefits of Enterprise Architecture According to Mainetti (2015), approaching EA management brings several benefits to organization and IT, reducing the cost of changing processes and procedures and the cost of systems maintenance, and making costs more flexible. In adaptive enterprises, software is divided in components, which are able to implement a consistent set of functionalities and are suitable to be reused, providing simultaneously personalization of application environments, compliance with the market standards, and alignment between business and IT, as we will see in chapter five. Moreover, organization evolves to an agile configuration, characterized by less rigidity toward change, dynamic orchestration of processes, people empowerment, and easier inter-functional and organizational collaboration.

Observatory for Enterprise Application Governance (2016) identified different possible benefits deriving from a correct management of Enterprise Architecture:  Information System is more flexible and ready to respond to business needs;  Application portfolio is less complex;  IT management costs decrease;  Architectural decisions take a strategic and homogeneous direction;  IT organization improves its control and knowledge on application portfolio.

Moreover, Enterprise Application Governance Observatory (2016) identified the following possible issues for EA management5:  Low commitment of management;  Resistance of project teams;  Lack of competences in the IT function;

5 These issues will be covered by the empirical survey carried out by the Observatory and described in chapter six of the present document.

46 Literature review

 Previous experiences that had inadequate results.

4.3.1. Organizational unit for Enterprise Architecture Enterprise Architecture was born in the ‘80s as an IT-centric exercise in mapping, controlling, standardizing and consolidating technology platforms, but it deeply changed in the last years. Traditionally, companies could have two main organizational approaches toward EA management (Osservatorio Enterprise Application Governance, Politecnico di Milano, 2016): 1. Centralized governance, which provides an abstracted normative approach aimed at finding an overall optimization of different projects. This approach leads to extreme rigidity, high risk of infighting, and out of control technical debt6.

2. Autonomy of project teams, which means a lack of centralized orchestration leading to local optimization without a strategic vision. In this case, architectural and technological choices risk to be inhomogeneous and IT services not to be reused in a cross-project perspective, missing the chance to exploit advantageous synergies among different projects. The consequence is a reduction of the overall long-term benefit deriving from them.

Now, the approach is shifting toward delegation and empowerment with a distributed governance. This means there is an organizational unit devoted to Enterprise Architecture management, aimed at giving centralized architectural guidelines and entrusted with creating a permanent process for business and IT alignment, moving from IT architecture (data and infrastructures) to business architecture (applications and process). This organizational unit consists of the so-called “architects”, whose role is to operatively participate to every new project. This leads to acceptation and well-management of technical debt and overall Enterprise Architecture (Osservatorio Enterprise Application Governance, Politecnico di Milano, 2016).

Observatory for Enterprise Application Governance (2016) identified different possible tasks of this kind of organizational unit:  Defining guidelines for software development;  Active participation to development projects;  Managing architecture at an infrastructural level;  Managing security;  Managing software lifecycle.

6 A detailed definition of technical debt is available in the glossary (Annex B).

47 Literature review

According to Richard Buchanan (2010), managing Enterprise Architecture, EA teams need to institute a collaborative and shared planning process called EA program. This consists of six steps:  “Strategize and plan” step, in which they gain agreement on the major problems to be solved, charter the EA program, and develop a future-state description comprising requirements, principles and models.  “Assess current state”, in which they identify the company current level of strategy and EA maturity, gathering documents that describe business, technological capabilities, practices, formal process models, data and systems.  “Assess competencies” step, in which they identify budgetary, staffing and other types of requirements. They also review the established budgeting mechanisms and processes and consider refining them.  “Gain approval” step, in which, leveraging the charter from phase one, they provide business and IT executives with a formal plan, and bring business and IT experts together for a shared strategic-planning exercise.  “Implement” step, in which they analyze the findings from strategic-planning and previous EA efforts to prioritize the gaps to be filled. Then, they develop investment plans using business cases that emerged from EA efforts, and present the findings to stakeholders and leaders to get investment plans approved.  “Operate and evolve” step, in which they improve and refine the efforts.

As already explained, an effective EA program will help the company align IT investments with long-term strategy, reduce risk, deliver high quality information and engineer adaptive solutions and technical services (Buchanan, 2010).

48 Literature review

Enterprise Architects The described frameworks for Enterprise Architecture (Zachman’s framework, TOGAF model, and Mainetti’s model) are specific for developing the overall architectural vision for the organization, which is the broadest possible view of architecture within an enterprise, and they are a responsibility of the Enterprise Architects (Sessions, 2007). Enterprise Architects are new organizational roles facilitating Enterprise Roadmap on page: they span across LoB and IT domains, such as security, infrastructure, information, and development (2007). While enterprise roadmap is owned by Enterprise Architects, its content is owned by business leadership. The enterprise architect is the architect of architects, having the broadest view on architecture: in order to build complex, distributed and enterprise-wide Information Systems, Domain Architects, focusing on a specific domain and having expertise in that area, are needed. A Domain Architect can be a Business Architect, a Security Architect, an Information Architect, an Infrastructure Architect, or a Communications Architect (Sessions, 2007). Then, for a more technical expertise in development, developers (Solutions Architects) who focus on one solution at a time are needed (Walker, 2007).

Figure 14 Architecture roles, breadth vs. depth of IT illustration (Walker, 2007)

Enterprise Architects decisions are complex, span multiple domains and switch between different levels of detail. When making decisions, either on a project level or enterprise level, Enterprise Architects have to consider many factors, generating trade-offs. For example, as shown in Figure 15, organizational factors can be significant in how technology decisions are made (Walker, 2007).

49 Literature review

Figure 15 Architecture trade-offs (Walker, 2007)

Specifically, there are three levels of decision making required to an Enterprise Architect (Walker, 2007): 1. Organizational policy: it consists of policies, standards, and reference models used to facilitate IT governance. By defining these rules, organization is aware of which technology practices are right to applicate and IT community knows the basis of its evaluation. Enterprise Architects often participate in committees that are responsible for building these policies since their expertise is valuable in these exercises. In fact, they have insight on both long- term strategy and organizations’ IT landscape. This kind of exercises brings many benefits to the organization, such as IT costs saving, improved vendor relations, focused IT, and empowerment of architects and developers. 2. IT strategy: strategy creation is a core function of an Enterprise Architect, who contributes defining the future state of architecture (i.e. to-be), capturing its current state (i.e. as-is), and building the transition architecture (i.e. iterative roadmap to follow for the transition). This consists of figuring out how the current architecture is working, measuring the health of key business processes, and results in a roadmap for the enterprise to follow. The lifecycle of IT strategy is iterative and agile-oriented. This means that when architects capture the current state, it is not necessary complete, otherwise they risk to lose sight of the end goal and get lost in details. Dividing work in small and consumable chunks is key to success. Then, when building future state architectures, transition state architectures enable future state models and plans while taking into

account the current state. Future states are Figure 16 IT strategy lifecycle (Walker, 2007)

50 Literature review

documented mainly in models and, when they are complete, they act as a roadmap that should be used when making technology decisions because it provides context and perspective about the progress of architectures in the organization. Instead of a “big bang approach” where everything needs to change at once, this provides a set of steps to move gradually toward future architecture. 3. Program and Project decisions: usually, at this level, project teams are isolated to only a specific LoB focusing on a single view of decision making. This can inhibit EA efforts to unify areas across the enterprise. Avoiding consideration of the big picture around an IT project generates a huge amount of work consisting in maintaining solutions. In this case, Enterprise Architects can contribute reviewing the work done on the organizational policies and IT strategy. The benefits are multiple: they ensure consistent IT decisions, create repeatable processes, facilitate strategy traceability, remove conflicts of interest, enable decision making auditability and accountability, and ease governance.

Enterprise Architect can encounter many problems not involving technology, such as organizational considerations and barriers. These barriers refer to (Walker, 2007):

 Appetite: this means what an organization is willing to support. Organizational principles and politics need to be considered when proposing a new solution;  Maturity: organization may not be ready for progressive idea of Enterprise Architects due to factors such as education, infrastructure, or software capabilities;  Incentive: localized interest, on a personal or team level, is a common organizational barrier. Architects are typically individual contributors with little organizational power.

In addition to these barriers, there are also organizational forces that challenge architects’ work:  Buy-in: when there is no management tie between architects and personnel to influence, it becomes increasingly difficult to accomplish EA goals. Gaining buy-in from internal organization on strategies, projects, or participation on key activities is fundamental.  Resources: even if a LoB manager buys in on strategy, being willing to shell out cash or personnel to support EA is another story. Particularly, Enterprise Architects generally do not have formal budget and personnel resources, so they have to share a group’s financial resources and to justify efforts to get IT and business groups to provide personnel for projects.

51 Literature review

From the identification of EA challenges, it is clear that technical capabilities are not enough for them. They need to possess great communication skills, to be homed in on the business, and to be great decision makers.

52 Literature review

5. IT governance: how to evolve the IT function In the previous chapter, we have seen that fast-digital progress leads companies to become adaptive to survive. A strategic alignment between business and IT is key for adaptiveness, and managing Enterprise Architecture, which has grown from being just a set of small pilots to being a fully sponsored and supported initiative within enterprises, helps companies with the alignment.

Companies have also to manage the transformation of the IT function, which is required reduced costs, increased agility, and standardized environments. A critical tool for CIOs to support this change is IT governance, which also creates clarity and alignment between business goals and IT projects (Shuptar, 2012).

Indeed, according to CIO magazine (2005), IT Governance is a prerequisite and an enabling factor for evolution of EA from IT architecture to business architecture. Indeed, an EA focused on business, needs institutionalized and repeatable governance processes that promote IT and business alignment at the highest company levels. Particularly, making architecture review a condition for investment approval is crucial for the evolution, and it can be done only allowing the discussion of IT and business strategy for making investment decisions. IT governance (ITG), that we will describe in the following pages, is seen as the best way for doing this. IT governance is enabling for another reason: it’s the right approach to optimize IT organizations making them more agile and quick in responding to EA requests, thus making EA truly effective. Furthermore, EA- ITG is a two-sided relationship, as EA also enables a genuine and better IT Governance as it clearly reveals deficiencies in the interactions of business processes, applications and infrastructures (Niemann, 2006).

The IT Governance Institute describes ITG as “leadership, organizational structures and processes to ensure that the organisation's IT sustains and extends the organisation's strategies and objectives” (IT Governance Institute, 2003). According to Gartner (2016), IT governance enables organizations to achieve their goals ensuring effective and efficient use of IT. ITG deals with structuring a process to align IT strategy with business strategy, a process that companies need in order to be sure to reach their strategies and goals, to measure IT performance and to make sure that all stakeholders’ interests are taken into account (Schwartz, 2007). A key role of ITG is effective IT management, that is determining what return IT gives back to business from the investment being made. This role is perfectly aligned with the idea that Information Technology should no longer considered as a decoupled support activity: IT should be an integral part of

53 Literature review business, boosting the companies’ value creation, as we have seen in the previous chapter (Osservatorio Enterprise Application Governance, Politecnico di Milano, 2016). IT governance is also key to support decision making: thanks to ITG, organizations can easily define and deploy a roadmap, effectively evaluating, selecting and prioritizing IT investments, overseeing their implementation and extracting measurable business benefits (Gartner, 2016).

According to the IT Governance Institute, ITG has five main domains or focus areas (IT Governance Institute, 2005; Schwartz, 2007):

 Strategic Alignment: that is linking business and IT, allowing them to work well together. Usually, true alignment occurs only when the corporate side of the business communicates effectively with line-of-business leaders and IT leaders about costs, reporting and impacts.  Value Delivery: it refers to ensuring that the IT department does what’s necessary to deliver the benefits promised at the beginning of a project or investment.  Risk Management: ITG can reduce risk, especially if a formal risk framework, that allows IT to measure and manage risk, is established.  Resource Management: there are different ways to manage resources more effectively, one of them is, for example, organizing staff by skills instead of by line of business thus allowing employees deployment on a demand basis.  Performance Measurement: making IT more accountable, that is measure where and how it contributes to achieving business goals, is key. IT Balanced Scorecard, with both qualitative and quantitative indicators, is a good instrument for this purpose (Schwartz, 2007).

Furthermore, ITG can be integrated with wider Enterprise Governance approaches, supporting companies in facing the ever-increasing legal issues and compliance requirements affecting the use of IT (The National Computing Centre, 2005; TechTarget, 2016). However, unlike other governance approaches, is not limited to embodying management through stringent regulations, standards and policies: regulation is just a subset of the enabling force which is IT governance (Mueller & Phillipson, 2007).

Despite all the benefits it can bring, ITG is not an easy subject: implementing everything involved in IT governance can be difficult, and many different tools and frameworks born to support ITG implementation. For what concerns frameworks, the most popular are the following (NH Learning Solutions, 2016):

54 Literature review

 Control Objectives for Information and related Technologies (CoBIT) from the Information Systems Audit and Control Association (ISACA). It’s a worldwide accepted set of guidelines and supporting toolset for ITG; it is used to Govern the Enterprise IT in order to generate the maximum creation of value by the business.  Information Technology Infrastructure Library (ITIL) from the government of the United Kingdom. More close to operations, it a way to manage the IT services across their lifecycle. ITIL offers eight sets of management procedures: service delivery, service support, service management, ICT infrastructure management, software asset management, business perspective, security management and application management.

ITG frameworks are constantly updated to match modern trends and requirements, such as the spread of agile methodologies that we will see in the next pages; for example, in 2011 ITIL has been updated to Version 3 (Version 1 dates back to 1989), becoming more flexible and agile (Kelly, 2016) and “perfectly fitting” modern methodologies like SCRUM, as shown in Figure 17 (Lichtenberger, 2014). Also, new frameworks have born after the boom of agile, like Disciplined Agile 2.X for Lean IT Governance (Disciplined Agile 2.X, 2016).

Figure 17 Scrum & ITIL: A perfect fit on high level (Lichtenberger, 2014)

55 Literature review

5.2. Bimodal IT: a new way to deliver IT services According to Stacey (1992), successful organizations, that are those continually innovative, cannot choose between tight and formal structures and informal systems that provoke learning: they must do both at the same time. In accordance with Stacey thoughts, IT organizations can deliver value through two kinds of service in a separate but coherent way (Mazzucco, 2015):

 continuous and recurring services, where efficiency, security and reliability are essential (mode 1);  innovative services, where rapidity and agility are fundamental (mode 2).

This approach is called Bimodal IT, and the main elements characterizing the two modes of delivering IT services as summarized in Figure 18.

Figure 18 Two modes of Bimodal IT (Gartner, 2016)

Bimodal IT leads to new operational and strategic decisions (Osservatorio Cloud & ICT as a Service, 2015). From a strategic viewpoint, companies need to rethink IT organization in terms of:  Governance model, which needs two separated but coexisting teams with different competences, tasks, and peculiarities;

 New and heterogeneous units of competences to manage relationships with suppliers, such as scouting, rating, and contracts analysis;

 New mechanisms and roles aimed at orienting IT function and entire organization towards innovation;  New mechanisms to manage relationship between IT and Lines of Business: those mechanisms have to be formal and standardized but able to flexibly adapt to contingent needs.

56 Literature review

From an operational viewpoint, for each project and initiative belonging to Mode 1 or 2, there are specific choices to be made in terms of (Osservatorio Cloud & ICT as a Service, 2015):  Depth of knowledge about the project;  Implementation time and project complexity;  Types of goals, which can be more oriented to reliability or agility;

 Categorization of the project within the company’s project portfolio, according to specific KPIs.

Figure 19 Strategic and operational decisions made to introduce a Bimodal approach (Osservatorio Cloud & ICT as a Service, 2015)

One of the main enabling factor to be ready to introduce Bimodal IT is establishing a collaborative and proactive relationship between IT organization and Lines of Business. They should continuously interact with each other to quickly respond to new business needs (Osservatorio Cloud & ICT as a Service, 2015). However, as found out by Gartner’s CIO survey (2014), organizations currently using Bimodal approach faced internal culture as the main roadblock, both within business and IT. Indeed, IT–Lines of Business relationship is not always collaborative as required.

5.2.1. Bimodal organization Starting within IT, bimodal principles can rapidly expand to the whole enterprise, mixing a more predictable evolution of products and technologies, with a new and innovative one (Gartner, 2016). When referred to the whole company, the two modes are the following:

 Mode 1 focuses on predictability and has a goal of stability. It fits organization’s areas where requirements are well-understood in advance and can be identified by a process of analysis. It includes the necessary investments in renovating and opening up the legacy environment.

57 Literature review

 Mode 2 is exploratory. Requirements are not well-understandable in advance. It is best- suited for areas where an organization cannot make an accurate, detailed, predefined plan because not enough is known about that area. Efforts are aimed at allowing future to reveal itself in small pieces. This work usually begins with a hypothesis that is proven, disproven or evolves during a process typically involving short iterations/projects.

A bimodal capability can emerge from any part of the organization as a collection of principles, capabilities, methods, behaviors, and approaches that enable to differentiate evolution from revolution and continual improvement from disruptive innovation; it affects the whole organization requiring an integrated effort. The leadership team must explore the previously mentioned technology-enabled opportunities, being willing to take on new risks and manage those risks in a way that differs from the traditional approach. It must invest in a capability that allows a continuous evolution of products, services, and business models.

58 Literature review

5.3. IT portfolio management An important activity to support IT governance is IT portfolio management, which helps in managing IT resources across an enterprise in terms of their investments and financial viability, thus considering risk. The term portfolio management comes from the financial world, and it deals with making decisions about investments mix and policies, matching investments to objectives and balancing risk against performance; the topic also has a mathematical framework supporting it, the Modern portfolio theory (MPT), a framework through which risk-averse investors can construct portfolios to maximize the expected returns for a given level of market risk. With similar goals, IT portfolio management is built around tools and methodologies to map and manage IT resources and their dependencies, mainly focusing on three areas: application, project, and physical assets and infrastructures portfolios (Techopedia, 2016). IT asset and infrastructures management (IPM or ITAM) deals with installed hardware (e.g. systems, servers, storage, networks, etc.), software licenses and shared services, allowing better hardware maintenance and replacements and ensuring license compliance. Project portfolio management (PPM) on the other hand helps in tracking IT project investments, prioritizing them, avoiding project overlapping and redundancy and allowing results management (Shaw & Nam, 2007; Robertson, 2010). Finally, Application Portfolio Management (APM) is a pragmatic approach to manage the optimization and transformation of enterprise application assets, providing multiple criteria analysis compatible with the complexity of the modern application landscape (Vila, 2012). Portfolio management introduction in IT departments is important as, having constrained budgets, prioritizing investments is key for them. We will now see more details of the last two areas, the most interesting for the sake of this research.

Project Portfolio Management According to Berinato (2001), Project Portfolio Management was firstly used in the 1960s in the manufacturing industry: after a long boom, an economic slump had caused questioning about which activities were actually creating value. The same reasoning came up for IT in the ‘90s, after increasing concerns about high-profile IT investments which also lead the US government to publish an official act on IT investments: the Clinger-Cohen Act of 1996 required agencies of the US federal government to adopt an investment approach to IT projects. Proving the value provided by IT projects was becoming more and more necessary, and, after the early 2000s recession, it turn out to be compulsory to start new projects and keep running the oldest ones. According to McKenna (2005), the idea of applying Modern portfolio theory and other risk-based approaches

59 Literature review to IT investments wasn’t new: it was first suggested by F. Warren McFarlan in 19897 and then taken up again by the US General Accounting Office (GAO) firstly in 1994, in a report describing how organizations may use a portfolio investment approach to select, control and evaluate IT projects 8, and secondly in 19989, in an executive guide. In 1998 the topic has also been addressed by John Thorp, in its book “The Information Paradox: Realizing the Business Benefits of Information Technology”. Thorp placed portfolio management as one of the three fundamental components of benefits realization, demonstrating that it can be applied to minimize risk, maximize return, and evaluate projects in light of other projects. Indeed, according to Thorp, IT was the largest single capital investment for most enterprises, but identify and measure the real business benefits achieved by increased IT spending is not easy and sometimes seem impossible to prove: that’s the Information Paradox which gives the title to his book (Thorp & Leadership, 2003).

PPM applied to IT basically consists in cataloging all the projects, collecting and controlling them as one set of interrelated activities: besides providing a centralized overview of investments, it also helps in quantifying and manage their risk and return, prioritize projects and align them with business. Through PPM CIOs can easily identify redundant or too risky projects, shift resources from low value investments to strategic ones, being sure that IT value is maximized. Exploiting PPM doesn’t necessary involve applying Markowitz’s economic framework: many companies most likely have some form of informal portfolio management processes, that can simply be implementing a database. Having a quantitative risk-based approach is key for organization which faces very complex problems and situations, but just applying simple practices is beneficial for most company; in a long-term view, planning a journey from the most basic to the most advanced tools could be the right way (Berinato, 2001). Alignment with business is a crucial aspect of Project Portfolio Management: according to Berinato (2001), it is not possible to do apply PPM without being aligned with business, because “creating a portfolio requires close collaboration with the business”; the concept is also underlined in Thorp book, in which he argues that IT cannot deliver value alone, value is created and sustained by how the business uses IT. However, this requires more than simply implementing a set of tools, it requires changes that will bring IT at the same level of other part of the business, with CIO using the same tools and having the same accountability of CFO and sales executive, as we will see in chapter five.

7 F. W. McFarlan, Portfolio approach to Information Systems, from the HBR September 1981 Issue 8 GAO, Improving Mission Performance Through Strategic Information Management: Learning from Leading Organizations, 1994 9 GAO, An Executive Guide: Measuring Performance and Demonstrating Results of Information Technology Investments, 1998

60 Literature review

Application Portfolio Management APM provides IT managers with an inventory of company’s software applications with metrics to illustrate the business benefits and risks of each application, using information about age and lifecycle, quality and usage, interrelationships with other applications and maintenance costs (Rouse, 2011; Vila, 2012). APM involves an application overhaul, that is trying to rework the application portfolio to put companies in a better position to meet the future needs of business and IT; this overhaul is a concept born in 2009, after the already mentioned troubles with IT speed and flexibility, and increasing budget constraints and cuts: CIOs was forced to examine their application budget and therefore the application portfolio, often finding inhomogeneous and overlapping systems, costly integrations and unnecessary vendor maintenance payments (Genovese, et al., 2009). Today, as we have seen in the third chapter, continuously evolving technological trends foster the change of business needs sustaining such activities. Indeed, over time, many companies accumulated a huge and complex legacy applications, generating multiple applications that are redundant and overlapping; this is mainly due to technological evolution speed in software development, which we will discuss in the following pages: in a short period of time many new development technologies and new ways to use them was born (e.g. newer generation of developing languages and new techniques to implement them), as well as new architectural paradigms for building software and infrastructure enhancements (Walker, 2007). Mike Walker from MSDN has made an interesting analogy between enterprise technology portfolio and trees: as shown in Figure 20, like tree stumps, companies technology portfolio is made of different rings showing distinct phases of growth.

Figure 20 Tree rings are like enterprise technology portfolios (Walker, 2007)

This is a common scenario for many enterprise: according to Vila (2012), the number of applications in organizations spans from 100-1.000 in local organizations, 1.000-5.000 in

61 Literature review international organizations and more than 5.000 in very large global organizations. The management of legacy applications has raised a set of previously unknown issues resulting in dangerous consequences: in many cases, age and changes in technology and business needs has further enlarged the gap between maintenance costs associated with applications and the support applications provided to business; furthermore, low-quality systems and security gaps also produced hidden costs leading to technology risk (in terms of security and reliability) and business risk (in terms of losing competitive edge and market share) (Vila, 2012). Finally, as previously stated, the increasing diffusion of new software-related technologies, like Software as a Service, has allowed business users to get systems to solve their problems without asking anything to company IT function (Genovese, et al., 2009). For this reasons, and for reasons related to M&A, employee turnover and underinvestment in governance, many organizations have a surprising lack of visibility into their current application inventory (Bils, 2015). A re-alignment of application and business strategy was needed, through a rationalization of applications and portfolio strategy definition.

The classification of application assets performed through APM provides companies the maximum visibility into their applications’ inventory, which is essential for the re-alignment. APM provides IT function concrete insight about applications allowing the adoption of processes to manage the continuous evolution of the portfolio to its optimal state, like rationalization and roadmap definition and providing required information to make valid decisions (Vila, 2012). Nowadays, many vendors offer software applications to support APM processes, like application mapping software, and other tools and frameworks have been developed to further streamline the process. Among them, the most popular are Application Discovery and Dependency Mapping (the process of discovering, establishing and tracking relationships and dependencies between IT components) and Application Portfolio Analysis (a tool to divide current and proposed applications in three categories, based on the degree to which they contribute to enterprise performance) (Greene, 2016; Gartner, 2016).

Application Lifecycle Management Application lifecycle management (ALM) is a topic gaining momentum, and it’s strictly related to Application Portfolio Management. Even if there seems to be no consensus on the components of ALM and its relationship with APM, the community seems to agree in defining it as the continuous process of managing the life of an application, from initial planning through retirement. Although they are commonly equated, ALM is different from Software Development Lifecycle

62 Literature review

(SDLC), which we will describe in the following pages: while SDLC deals with phases of software development, ALM deals with a broader perspective, including the entire time during which a company is spending money on an application asset, from the initial idea to the end of its life (Chappell, 2008).

According to Parker (2013), while APM allows informed business decisions, dealing with decisions about creating, improving and replacing applications and with the main task of determining the value of software assets, ALM works at a more operational level, defining and implementing the activities needed to satisfy APM decisions; ALM doesn’t deals with deciding which tasks should be done, it’s about turning requests into tasks and executing them.

Chappell (2008) instead divides ALM into three areas (governance, development and operations) and defines three big events: the idea from which the whole process begins, the deployment stage when the application goes into production and the end of life when it’s removed from service. Concerning the three areas, governance deals with decision making and project management of the application, development with the process of creating the application and operations with the work required to run and manage it. In this view, PPM works in the governance area when application development starts, while APM provides governance for all the deployed applications, as shown in Figure 21.

Figure 21 Governance extends over the entire application lifecycle (Chappell, 2008).

Finally, according to Gartner, there has been a convergence of APM and PPM with ALM, and a convergence between ALM and Release management in DevOps, which has led to an ambiguous usage of the term, thus requiring a change of it to Application Development Lifecycle Management (ALDM) (Murphy, 2011).

63 Literature review

The application overhaul To perform the application overhaul, companies have to rethink their information systems and application portfolio, in order to identify and capitalize opportunities coming from digital transformation, without being moved only by the need for consolidation and cost reduction (Bils, 2015). Moreover, even companies more aware of their applications often do not understand which are very critical to business and how to align them with business goals and KPIs (Bils, 2015). Therefore, beside an up-to-date applications’ mapping, it is important to rethink portfolio in the light of business priorities: APM should not be confined into IT function boundaries, and EA could be the right link for bringing application portfolio choices closer to business. For what concerns more operational activities, according to Scott Bils (2015), there are three ways to practically evolve applications portfolio:  Rewrite applications, especially those associated with customer engagement, to achieve the promise of the Third platform;  Replatform applications to more flexible and efficient public, private, or hybrid cloud models;  Retire and decommission legacy applications and archive legacy data to reduce cost and foster innovation.

These activities cannot be performed through a traditional sequential and inflexible approach, as business stakeholders cannot wait. Therefore, more agile approaches that enable to rapidly identify and deliver business impacts are required. The new techniques and methodologies of managing IT projects and developing software, which we will analyze in the following pages, directly address this subject.

64 Literature review

5.4. Managing modern IT projects Enterprise information systems can be developed in various ways, but given the complexity and customization of the final output, development is often organized in the form of a project. The way of managing these projects also needs to change to cope with new business needs.

Considering a generic information system as a software system, different models has been developed to support the management of this kind of projects, known as Software Process or Software Development Lifecycle Models (SDLM). These models find their origins in the 60s and 70s, when researchers and practitioners realized that developing a software was not just an issue of creating effective programming languages and tools: “the quality of a software product heavily depends on the people, organization and procedures used to create and deliver it” (Fuggetta, 2000). Research on software was thus focused on three goals: the development of structured programming languages, the development of design methods and principles and the definition of software lifecycles, like the Waterfall model that we will describe in the following pages.

A software lifecycle explains which are the different phases in the lifetime of a software product, and defines the principles and guidelines that must be followed in carrying out each stage. Usually, the lifecycle stages are the following: requirements analysis and specification design, development, verification and validation, deployment, operation, maintenance and retirement (Fuggetta, 2000). For the scope of this research, we will group the stages in three key phases, as identified by Observatory for Enterprise Application Governance (2016):

 Analysis and Planning  Design and Development  Deployment

Software Process In the 80s, thanks to an increasing awareness that developing a software is a complex process, a concept strictly related to software lifecycle was born as an autonomous discipline: software process. According to Fuggetta (2000), software process is “the coherent set of policies, organizational structures, technologies, procedures, and artifacts that are needed to conceive, develop, deploy and maintain a software product”. The underlying assumption under this concept is that there is a direct correlation between the quality of the process through which the software is developed and the developed software. The concept of software process builds on the notion of software lifecycle, providing a broad and comprehensive concept to practically guide and control a software

65 Literature review development project. Fuggetta (2000) says that, to address the problems and issues of software development, paying attention to “the complex interrelation of a number of organizational, cultural, technological, and economic factors” is needed. Software process exploits these factors:

 Software development technology: technological support that make possible and economically sustainable the development of complex software. It comprises tools, infrastructure and environments.  Software development methods and techniques: methodological guidelines to exploit technology effectively and to realize software development.  Organizational behavior: people carrying out software development need to be coordinated and managed in an effective organizational structure.  Marketing and economy: like other products, software must address real customers’ needs, so the context where the product is supposed to be used must be taken into account in developing software.

Looking at software development as a process has been key to establish effective practice in the field. In the following pages, we will look further into methodological guidelines, while later in the paper we will deepen aspects related to software development technology.

Today, different terms are used interchangeably for the same software engineering principle, the software development process; the models that we will describe in the following pages are sometimes referred to as software process models, other times as system development methodology, other time as SDLC, an acronym which can be both interpreted as Software or System Development Lifecycles, as software development encompasses software system development (Ruparelia, 2010). Analyzing the concept, it is clear it can be applied to any project or system which involves software development, such as information systems and other Information Technology projects realized inside firms. For example, according to the United States Centers for Medicare & Medicaid Services, a system development methodology refers to “the framework that is used to structure, plan and control the process of developing an information system” (Centers for Medicare & Medicaid Services, 2008).

Process modeling Whatever the framework chosen, in the development process of an information system there is one key and common part: modeling. Generally speaking, a model describes in a textual or graphical form the system to be designed, abstracting from aspects that are not relevant for the

66 Literature review model itself: the purpose of the description is thus crucial (Van der Aalst & Stahl, 2011). According to Van der Aalst & Stahl (2011), in information systems we can distinguish two types of models: abstract description, models used to analyze and describe an existing information system, and specification, models used to build a new information system. Several different languages and modeling formalisms has been created to make it possible to represent in a precise and comprehensive way complex entities, like software processes. Modeling languages are artificial languages, textual or graphical, used to express information, knowledge or systems in a pre-defined way: a complete definition of a modeling language indeed consists of a complete description of its syntax, rules and notation, and its meaning, or semantics (Harel & Rumpe, 2004). Modeling languages have been crafted from different sources, like programming languages or rule-based and Petri net-based languages (García-Borgoñóna, et al., 2014). Languages are very important for the software development process: having a common semantics avoids misunderstanding and allows the interoperability between tools (Grönninger, et al., 2014). Modeling is not useful just for software system, but also to deeply understand what they should support, that is business processes; therefore, several languages to describe business processes, like Business Process Modeling Language (BPML), has been developed in past years (Mili, et al., 2010).

Requirements Engineering The requirements analysis phase is an important part of the software process. Indeed, a software is successful if it meets the purpose for which it was intended: discovering that purpose is the aim of software systems requirements engineering (RE), identifying stakeholders and their needs and documenting these in a form that is suitable for analysis, communication and subsequent implementation (Nuseibeh & Easterbrook, 2000). The RE process is not free of challenges: stakeholders can be numerous and distributed, with different, ambiguous and conflicting goals depending on their perspectives on the environment and on the tasks they want to achieve (Nuseibeh & Easterbrook, 2000). According to Nuseibeh & Easterbrook (2000), one of the clearest definition of Requirements Engineering is that from Zave (1997): “Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families.” This definition is interesting for different reasons; first, the reference to “precise specifications” provides the basis for requirements analysis and validation against what stakeholder wants, and helps in defining what designers must build and verify their final work. Second, the definition

67 Literature review considers the evolution of specifications, stressing the reality of a changing environment, and highlights the importance of “real world goals”, which motivate the development of software and specifies what it should do. Indeed, RE practices often ignore or presume a stable context, which nowadays is a no longer valid assumption: environment changes can influence stakeholders’ goals and their choices to meet them (Ali, et al., 2010), thus different models to analyze goals, their evolution and their relation with context have been developed. Among the most renowned, we have the Goal-Based Requirements Analysis Method (Anton, 1996) and the Goal-based Framework for Contextual Requirements Modeling and Analysis (Ali, et al., 2010). In recent years, there has also been a criticism against RE in general, claiming that most of the requirements committed in software projects are not necessary condition of success, the literally meaning of “requirement”; maybe they are just design decisions, preference or other desiderata, but calling them “requirements” subconsciously generates a wide variety of cognitive biases, systematic deviations from optimal judgment (Ralph, 2013; 2013).

Lightweight vs. Heavyweight Generally speaking, we can divide software development methodologies in two widely recognized categories, that are heavyweight and lightweight or agile methodologies (Khan, et al., 2011). Heavyweight methodologies are the oldest one, also known as traditional methodologies; they are focused on detailed documentation on the process, inclusive planning and expansive upfront design. Lightweight methodologies focus instead is on short iterative development cycles, relying on the knowledge within a team and on working prototypes rather than documentation and detailed processes (Khan, et al., 2011); the reason for being “light” is to counterattack change (Khan & Balbo, 2004). Nowadays lightweight methodologies are called agile, as they embrace what is stated in the Agile manifesto (Beck, et al., 2001):  Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan.

In the past years many models belonging to those categories have been developed and are described in the literature; for the sake of this research we will introduce two heavyweight methodologies, the Waterfall model (Royce, 1970) and the Spiral model (Boehm, 1986), and a set of lightweight methodologies usually grouped under the name of Agile methods (Beck, et al., 2001). After

68 Literature review describing the characteristics of these popular models, we will discuss more in detail the benefits brought by agile methodologies in software development.

After these premises, we can proceed in analyzing SDLC, starting from heavyweight models.

5.4.1. Heavyweight lifecycle models

Waterfall model It is the first documented model, first seen in 1956 (Bennington, 1987), and then formally described by Winston Royce in 1970 (Royce, 1970). Besides being the first development model, the waterfall method is also widely used in governments’ and companies’ projects (Munassar & Govardhan, 2010).

The model emphasizes planning in early stages, and foresees an intensive documentation, being good in projects in which quality control is a main concern. Indeed, a document explaining objective and requirements is created at each stage (Munassar & Govardhan, 2010). Furthermore, quality is assured splitting each stage in two parts: the first performs the activities suggested by the stage name, while in the second part the work done in the first one is reviewed and verified in order to determine whether the project can proceed to the next stage (Ruparelia, 2010).

The pure model, as firstly explained by Bennington, consists of several non-overlapping development stages, starting from the analysis and ending with the evaluation one (Ruparelia, 2010). Royce recognized that if a baseline is created at the end of each stage, in the following stages there could be unforeseen difficulties: he improved the model providing feedback loops which give the ability to revisit each stage and allowed them to overlap. Loops can be simple (the orange arrows in Figure 22) or complex (dashed arrows in Figure 22); complex feedback loops were introduced to allow transcending stages in iterations.

The model was termed “waterfall” because flow of the method was similar to the flow of water: one stage must be fully completed before moving on to the next, and once a stage was finished, it was frozen in time (Varhol, 2015). Royce contribution helped in facing the lack of flexibility of the pure waterfall method, consisting of discontinuous and non-overlapping phases; the waterfall model has been modified and improved by other contributors, for example using prototyping, or using methods to gather requirements in overlapping phases (Kuhl, 2002), or attaching the operational or maintenance cycle to it, like in the B-model (Birrell & Ould, 1985). Furthermore, to

69 Literature review cope with the waterfall model problems and looking for faster results, less up-front information and greater flexibility, new models were born (Munassar & Govardhan, 2010). For example, the Incremental model, also known as the iterative waterfall model, divides the main project in iterations which are small waterfall processes, while the V-Shape model, another sequential model, which puts a higher influence on testing (Munassar & Govardhan, 2010). Unfortunately, despite all these improvements, in practice, schedules and budgets often made it impossible to be flexible and to reconsider project decisions (Varhol, 2015).

The main stages of the waterfall model can be described as follows (Munassar & Govardhan, 2010):

 Requirements: establishes the components, needed for building the system (system requirements, including hardware and software components) and the expectations for software functionality. During this phase, interaction needed with other applications and databases, performance and user interface requirements are also defined.  Design: includes both architectural aspects, the software framework needed to meet requirements, and the detailed design of each component defined in the architectural design.  Development: in this phase, also known as coding phase, detailed design specifications are implemented.  Validation: the developed software is tested to find code errors and to determine whether or not it meets the specified requirements.  Deployment and maintenance: includes installation and configuration, maintenance of the system and support, addressing problems and enhancement requests.

Figure 22 - Waterfall model with Royce's iterative feedback (Ruparelia, 2010)

70 Literature review

Spiral Model Another relevant modification of the waterfall model is the Spiral Model, presented in 1986 (Boehm, 1986). The philosophy underlying the model is start small, think big: several iterations spiral out from small beginnings (Ruparelia, 2010). As argued by Ruparelia, the Spiral lifecycle puts a lot of emphases on risk analysis, representing a paradigm shift from the waterfall’s specification driven approach.

Figure 23 Boehm's spiral life-cycle (Ruparelia, 2010) The model includes four sections identifying iterative phases (Munassar & Govardhan, 2010), as shown in Figure 23:  Planning: in this section, specific objectives, alternatives and constraints are identified. Requirements are also gathered in the baseline iteration.  Risk Analysis: during this phase, risk is assessed through a process that involves the identification of risks and alternative solutions, and the realization of activities needed to reduce key risks. Iterations in this sections always end with the production of a prototype.  Engineering: software is developed and then tested and validated.  Evaluation: in this phase, the output of the project to date is reviewed with stakeholders before starting the next cycle, which is also planned in detail during this phase.

In the spiral model, a software project repeatedly passes through these phases in iterations: at the end of each cycle, a prototype is built, verified against its requirements and validated through testing. Risk management is used as a tool to control the cost of each cycle: through risk analysis

71 Literature review and categorization, performed at the end of each cycle, the time and effort to be expended for all the activities during the next cycle are determined (Ruparelia, 2010).

Looking at the model, two questions arise: how does the spiral get started? How and when you get off the spiral?

To answer such questions, Boehm introduced a complementary model, the Mission Opportunity Model (Boehm, 1986), which can be used as a central pivot: testing the spiral against a set hypotheses (requirements) you can initiate or terminate the spiral. Indeed, failure to meet the hypotheses leads to Figure 24 TOGAF's ADM as a wheel-and-spoke model the spiral being terminated.

Also, the spiral model has been modified and improved by several contributors. One important model derived from the spiral one is the wheel and spoke model (Ruparelia, 2010): a bottom-up approach designed to work with small teams that can be scaled up in advanced stages to build value faster. The model shares with the spiral model the concept of multiple iterations. In the first phase, system requirements are established and a preliminary design is created; the design is then transformed in a prototype which is verified against the requirements from the first spoke: feedback from validation are gathered and propagated back to the prototype. With this approach, the next stage adds value to create a more redefined prototype, which forms the second spoke. Each successive stage goes through a similar validation process to develop a new spoke. The wheel and spoke model has many uses: from the creation of a set of programs related by a common API, in which conformance to the API is the center of the model, to an application in the Architecture Development Method of TOGAF10, where the spokes are used to validate the requirements during architecture development (see Figure 24).

10 Described in chapter four of this paper.

72 Literature review

5.4.2. Agile methods

Brief history The Agile Manifesto (Beck, et al., 2001) is an important moment in the history of lightweight software development methodologies, but these methodologies have their roots much earlier. Everything began in the early 1990s, with the proliferation of Personal Computing in enterprises and “the application development crisis” or “application delivery lag”: business moved faster, and industry experts assessed that the time passing between a validated business need and an actual application in production was about three years, a timeframe in which entire businesses were likely to change (Varhol, 2015). Many projects were thus cancelled, and many completed project, even if meeting the original objectives, didn’t meet all the businesses’ current needs. As we will see in detail below, it became clear that software development needed an approach different than the waterfall model, still prevalent at the time (Varhol, 2015). This new approach started being developed with iterative techniques and the Rapid Application Development model (Martin, 1991), whose purpose was to reduce the preparation time and quickly start the development, allowing business to collaborate with the development team by seeing a working prototype. More specific iterative methodologies started being created, like the Scrum process (Sutherland & Schwaber, 1995) and Extreme Programming (Beck, 1999), which we will delve in the next pages. As stated before, the turning point for the diffusion of agile and iterative techniques has been the Agile Manifesto (Beck, et al., 2001) published in 2001: despite the uncertain goals of the group of people who codified it, it is the clearest and most succinct statement of purpose of an approach that was the antithesis of the waterfall model. According to Varhol, that was only a needed starting point, as today the agile philosophy is helping in promote a continuous delivery of change in applications, with very quick releases and feature development based on user reaction: something which today is referred to as DevOps.

Agile methodologies fundamentals According to Varhol (2015), waterfall was born in response to chaotic and unplanned approaches often used in the early days of software, and it brought a sense of engineering and organization to software development; however, it’s important to point out that software projects significantly differ from traditional engineering projects: they don’t have the same stability because business needs change faster than months or years needed to complete a software application. Furthermore, unlike other engineering disciplines, software is associated with imperfections and human

73 Literature review limitations: it is not easy to define software very well as it is difficult to precisely define what is needed before starting to build the product, and the defined requirements must be translated into design specifications by humans, a process which can lead to further ambiguities. According to Wells (2009) “building software is more like creating a work of art, it requires creativity in design and ample craftsmanship to complete. Software remains malleable, often illogical, and incomplete forever.”. The Agile model responds to change quickly and efficiently, and it’s an answer to the eager business community asking for lighter, faster and nimbler software development process (Khan, et al., 2011). Agile software development is based on the following different shifts in the approach towards software development (Wells, 2009):

 There are no Agile processes and methods, there are only Agile teams; processes described as Agile are just environments for a team to learn how to be Agile; the way a team works together is far more important than any process.

 The person who funds software development and is a domain expert, the customer, must become a valuable and essential team member. Real knowledge is hard to put in a document, even if it has plenty of information: true domain expertise the customer should make scope decisions a little at a time throughout the project.

 As stated before, software requirements are not stable in terms of needs, budget, schedule, resources and technology: Agile processes address the problem of changing requirements accepting “the reality of change versus the hunt for complete rigid specification” (Wells, 2009). Indeed, in most cases, being ready to accept changes can cost less than ensuring requirements will never change.

 Developers can produce working software starting with the first week of development: in Agile processes this software must be shown to the customer, as in the context of a working system developers can learn much more about requirements.

 Finally, in Agile also the way to manage projects changes: the progress is measured by how much is delivered in a precise moment, the management shifts from activities to requirements, working software is done a little at a time and each new version is demonstrated to the customer.

The different practices mentioned and described in the following pages, reflects the principles of the Agile Manifesto, and this is the reason why they are grouped under the name of “Agile Methods”.

74 Literature review

Extreme programming Extreme Programming, also known as XP, is a development method evolved from the problems caused by long development cycles of waterfall: the XP process is incremental, based on the development and delivery of very small increments of functionality and relying on constant code improvement, user involvement in the development team and pair wise programming (i.e. programmers working in pairs) (Munassar & Govardhan, 2010). XP stresses customer satisfaction: the development process releases needed functionality exactly when it is needed, responding to changing customer requirements even late in the lifecycle (Wells, 2013). Teamwork is also emphasized: every contributor to the project is an integral and equal part of the Whole Team, a collaborative and self-organized team which forms around a business representative, the Customer (Jeffries, 2011). Jeffries (2011) says XP is “a discipline of software development based on values of simplicity, communication, feedback, courage, and respect”. Indeed, Extreme Programmers: constantly communicate with their customers and fellow programmers, keep the design simple and clean, get feedback by testing software from day one, deliver the system as soon as possible and implement changes as suggested; furthermore, every success deepens their respect for the unique contributions of every team member. With this foundation, XP teams can respond to changing requirements and technology with much courage (Wells, 2013). Among other significant XP terms and practices, we have (Khan, et al., 2011; Munassar & Govardhan, 2010; Jeffries, 2011):

 Incremental planning: requirements are recorded in the form of stories; programmers estimate the effort needed for developing each story, and the stories to be included in a release are determined by the time available and relative priority.  Metaphor: XP teams develop a common vision of how the system works, with a common system of names to be sure that everyone can understand.  Refactoring: as soon as possible code improvements are found, the system is restructured without changing the functionality. This way code is kept simple, flexible and maintainable.  Collective Ownership: no single person owns or is responsible for individual code segments.  Continuous Integration: as soon as a task is completed and a new piece of code is ready, it is integrated with the current system.  Sustainable pace: large amounts of over-time are unacceptable, as they would reduce code quality and medium term productivity.  Coding Standards: programmers follow a common coding standard to bring consistence to all the written code and improve communication among fellow developers.

75 Literature review

Scrum methodology Scrum is “an agile way to manage a project, usually software development” (Mountain Goat Software, 2016); the scrum process was created in 1993 for software development projects, and its name derives from the scrum formation used by Rugby teams to restart play. Scrum is not a process or technique: it is a framework for managing product development in which various processes and techniques can be employed (Schwaber & Sutherland, 2016). Scrum is focused on the outcome: processes and best practices are tools aimed at producing working software, and even if the way which produce results is important, the outcome itself is the most important thing (Bruna, 2015). Scrum relies on self-organizing and cross-functional teams: they are not directed by others outside the team, and they have all the competencies needed to accomplish the work; indeed, instead of providing complete and detailed descriptions on how everything must be done on a project, in scrum much is left up to the team (Mountain Goat Software, 2016). In scrum, roles and responsibility are clearly defined: the scrum team is made up of three members, a Product Owner, the Development Team and a Scrum Master, as described below (Schwaber & Sutherland, 2016).

 Product Owner: is the person representing the customer or users, who guides the team toward building the right product; he is responsible for managing the Product Backlog, as defined in the following pages. Only the Product Owner can tell the Development Team what to do.  Development Team: it consists of professionals who work on creating and delivering a potentially releasable increment of working product. As already said, it is self-organized and cross-functional: development teams are structured and empowered to organize and manage their own work. In terms of size, Development Team should be small enough to remain nimble and large enough to complete a significant work during a Sprint.  Scrum Master: is like a coach for the team, responsible for ensuring scrum is understood and enacted in order to let the team perform at the highest level; it is a role different than the traditional project manager: it does not provide daily directions nor assign tasks.

Events are the heart of scrum, and they have the peculiarity of being prescribed: each event has a fixed duration, to create regularity, minimize the need for not defined meetings and avoid waste in the process. Beside this, each event is a formal opportunity to inspect and adapt something, enabling critical transparency and inspection (Schwaber & Sutherland, 2016). Scrum suggests that projects progress via a series of Sprints, the main event unit: sprints are the container for all other events, and during a sprint, a working and potential releasable product is created. Sprints have

76 Literature review consistent durations, no more than one month, commonly two weeks, and a new sprint starts immediately after the conclusion of the previous. At the start of each sprint there is a planning meeting in which goals and scope are defined, and the Sprint backlog, a list of the tasks to perform during the sprint, is created (Mountain Goat Software, 2016). Sprint goals and quality goals don’t change during a sprint, while the scope may be clarified and re-negotiated as more is learned (Schwaber & Sutherland, 2016). In software development, a goal could be a small set of features to be coded from the idea, tested and integrated in the system. On each day of the sprint, all team members, including the Scrum Master and the Product Owner, attend a daily Scrum meeting of maximum 15 minutes during which team members share what they have done the previous day, what they will do on that day and identify impediments to progress, if any (Mountain Goat Software, 2016). At the end of each sprint, a Sprint review is conducted by the team to demonstrate the new functionality to the Product Owner or any other stakeholder who wishes to provide feedback that could influence the following sprint.

We can now face the main artifacts in scrum, beside the product itself and the already defined sprint backlog. High level requirements in scrum are defined as Stories, short descriptions of functionality defined from the perspective of a user or customer. Each story has a title, a brief description and eventual external references; stories can be divided in user stories, functional user- facing requirements, technical stories and bug reports (Bruna, 2015). Stories are used to populate the Product backlog, the complete list of functionality that must be added to the product; product backlog is prioritized by the product owner, so the team always works on the most valuable features first (Mountain Goat Software, 2016). User stories aren’t like use cases or usage scenarios: they are much smaller artifacts, and don’t provide such a level of detail needed by teams to complete their work; in the Scrum process, indeed, this detail emerges organically during meetings with the Product Owner, removing the need to write other usage requirement artifacts (Boost, 2012; Ambler, 2014). Other artifacts of scrum are the burndown charts, which show the amount of work remaining in a sprint or in a release, and are an effective tool to determine whether a sprint or release is on schedule to be completed for the desired date (Mountain Goat Software, 2016).

77 Literature review

Figure 25 Scrum visual introduction (Mountain Goat Software, 2016)

User Story Mapping – The new Product Backlog As stated before, in scrum methodology stories are usually used to document requirements; we have also specified that good stories are small, and good product backlogs are prioritized lists of stories. In 2008 stories were rather criticized by Jeff Patton, an independent consultant. According to Patton (2008), a prioritized backlog helps understand where to start and what to do next, but doesn’t explain what the system does with the risk for teams of not seeing the big picture; indeed, with flat backlogs it’s difficult to grasp where you are and where you should go, especially for big projects, with hundreds of stories and issues (Scrum Alliance, 2013). A user story map is a useful model in which user stories are arranged to help understand the functionality of a system, identify holes and omissions in a backlog and effectively plan holistic releases that deliver value to user and businesses. The model, as proposed by Patton (2008), has the structure of a grid, like that described below. At the top of the grid, there are user activities, the “big stories”: something which have a lot of steps and doesn’t always have a precise workflow, like a grouped functionality goal. Beside this, we have user tasks, which are smaller stories: something that must be done to reach a goal, to complete the activity; continuing to arrange small things under bigger things, below tasks we find sub-tasks or task details (Figure 26). Time is conventionally moving left to right: things which are more important or simply done earlier are on the left. Each release is based on a horizontal “swim lane”: if activities are not vertically prioritized, as they are essential capabilities the system needs to have, tasks placed high in the story map have the highest priority. The same promoter of user story says this is a pattern more than else: different people has used and still use the same basic concept arranging and constructing the model in different ways (Patton, 2008); the model can be thus organized in different ways, for example using colors to split between technical and business stories, to identify complexity or to organize tasks in other ways (Scrum Alliance, 2013).

78 Literature review

Figure 26 Story Map Diagram (Patton, 2008)

Lean Software Development Lean Software Development is the application of the successful Toyota Production Development System, the engineering principles used to develop vehicles, to software development” (Poppendieck, 2007), first introduced in 2003 in a book by the same name, written by Mary and Tom Poppendieck (2003). Pursuing the paradigm “80% today is better than 100% tomorrow”, and in accordance with the agile principles, Lean Software Development attempts to deliver a project with a minimal functionality as early as possible (Ruparelia, 2010). According to its creator, when correctly applied, lean software development results in high quality software, developed quickly and at the lowest possible cost. Furthermore, understanding the principles of Lean Software Development, is possible to explain the success of many Agile Software Development practices; the seven lean principles are the following: Eliminate Waste (i.e. everything not adding value to the customer), Build Quality In, Create Knowledge, Defer Commitment, Deliver Fast, Respect People, Optimize the Whole (Poppendieck, 2007).

Dev-Ops In the hyper-competitive world of current years, enterprise success depends upon their ability to deliver applications into production more quickly and reliably, enabling them to respond better to their customers’ needs and to outpace their rivals. Different changes have brought to this situation (Bruna, 2015):  Requirements are increasingly challenging, and having reached the state of the art has significantly raised the bar.  Applications are consumerized and commoditized.  Users are ever more demanding.

79 Literature review

 Technological solutions are increasingly complex in terms of extension, complexity and integration.

Following the increasingly need to improve IT service delivery agility, developers had some negative and positive responses, explained below (Bruna, 2015).  Negative reactions: lower code quality, little to no documentation, no unit/integration testing, unsound architecture which does not scale, poor performance.  Positive reactions: use of agile frameworks and project management methodologies, new standards and protocols and new tools. IT operations were thus prompted for stability and compliance with safety rules on one side, and for agility and flexibility on the other. This situation led to a lack of cooperation and disagreements between IT operations and developers: the former complained about the lack of documentation for deployment and poor software performance, while the latter criticized operations for long deployment and provisioning times (Bruna, 2015).

In this situation, the concept of DevOps has started to gain ground as a solution to the problems emerged. DevOps is an evolving concept, so it is still not clear whether DevOps is a culture or a movement, a way of thinking or organizing, or a set of practices: there is no universally acknowledged definition of DevOps (New Relic, 2016; Orlando, 2015). The ideas behind the term were presented for the first time at Agile 2008 in Toronto, while the term was made popular thanks to the “devopsdays”, a series of conferences on the same matter introduced in 2008 (Agile Alliance, 2015). Beside the landscape developing inside businesses, DevOps was the result of the converging of adjacent topics like Agile, Operations Management, Theory of Constraints, LEAN and IT Service management: if Agile already allowed continuous development, deployment was still waterfall-oriented until this convergence (New Relic, 2016). The concept stresses communication, collaboration and integration between software developers and IT operations professionals, as they are two interdependent elements who need to work together to improve software delivery agility (New Relic, 2016). DevOps tries to minimize the differences among various targets, cultures and tools, to define a unique end-to-end process to manage the release flow (Figure 27), and to remove the disconnection between activities traditionally considered development, and activities considered operations, a disconnection which generates conflicts and inefficiencies (Bruna, 2015). Finally, to extend the continuous development goals of Agile to continuous integration and release, DevOps also fosters the automation of the change, configuration and release processes through “automation tools that can leverage an increasingly programmable and dynamic infrastructure from

80 Literature review a lifecycle perspective” (New Relic, 2016). This tools are key to ensure frequent deploys with a low failure rate; among the most impactful and popular tools, there are version control and automating code deployments tools, but there are many other useful tools like configuration management, build automation, advanced IDE, unit testing framework, ticketing systems, monitoring and provisioning11 (New Relic, 2016; Bruna, 2015).

Since everything started, DevOps has supported many areas of technology operation, including in recent times: Automated Infrastructure Provisioning, Continuous Integration, Development Environments, Automated Delivery, Continuous Delivery11 (Orlando, 2015).

Wrapping up, the main benefits of using DevOps in IT project management are: improved deploy frequency (which can lead to faster time to market), shortened lead times, faster mean time to recovery and lower failure rates (New Relic, 2016).

DevOps, intended as a way to unite developers and IT operations, has recently been said to be already dead; indeed, thanks to the explosion of cloud, nowadays many developers are turning to managed services for toolsets and infrastructures, as these services reduce the complexities of managing infrastructures and deployment, allowing developers to focus on software development. As the things they were forced to deal can now be automatically managed by external providers, DevOps teams are no longer needed in their original role (Akselrod, 2016).

Figure 27 DevOps Infinite Loop (Tricentis, 2016)

11 A description of DevOps tools and areas is available in the glossary (Annex B)

81 Literature review

5.4.3. Why moving to agile? As we have seen in the first chapters, enterprises are facing the need of business and IT alignment, in order to be more fast and reactive to the changing world. In this section, we will sum up problems of traditional methods and how agile is solving them, and what are the possible barriers for agile implementation, according to Observatory for Enterprise Application Governance research (2016).

Analysis and Planning Traditional approaches generate different problems in the first phases of software process:

 Deviation from actual user goals;  Redundancy of applications and features;  Long times for analysis and assessment;  Limited information available to take important design decisions.

TRADITIONAL AGILE The focus is on the solution/product The focus is on the business need The feature scope is adaptable throughout the Features must be clear from the beginning project Analysis is highly detailed High-level analysis, made to support planning Project is faced with an iterative process, with Activities are approached sequentially stepwise refinements Just one estimation, which is challenging Different estimations, with varying reliability

Table 1 Traditional vs. Agile methods for analysis and planning

Thanks to agile, it possible to face analysis and planning phases with iterations of increasing level of detail.

Figure 28 Analysis and Planning (Osservatorio Enterprise Application Governance, Politecnico di Milano, 2016)

82 Literature review

Design and Development In this phases, traditional methods have led to:

 Risk of having obsolete solutions, not suitable to current business needs;  Lack of user feedback during the project;  Delays and extra costs, unlikely to be recovered.

Scrum methodology, described above, is the most suitable agile practical solution to all of them.

TRADITIONAL AGILE Scope and features cannot vary Scope and features can vary Decisions are deferred to the latest possible Detailed planning made in advance moment Design and development are based on iterative Activities are approached sequentially cycles Many releases towards end users and Just one final release continuous looking for user feedback Supplier relationship is based on negotiation Suppliers are partners

Table 2 Traditional vs. Agile methods for design and development

Deployment Finally, for what concerns deployment, these are the main problems of traditional approaches:  Large effort charged to operations;  Lack of rapidity in making applications available;  Poor communication between development and deployment;  Difficulties in balancing “day-by-day” with new releases.

To address these problems in practice, we have seen the DevOps approach.

TRADITIONAL AGILE Decoupling from development Close collaboration with development Tools focused on system management Shared tools between development and activities deployment Manual release management Automation and repeatability of releases Provisioning is made on dedicated Infrastructural decoupling infrastructures Supplier relationship is based on negotiation Suppliers are partners

Table 3 Traditional vs. Agile methods for deployment

83 Literature review

Incentives and barriers to adoption Observatory for Enterprise Application Governance (2016) identified the following possible pushes and barriers to the adoption of innovative methodologies to manage IT projects12.

INCENTIVES BARRIERS  Poor knowledge of new methodologies  Greater control of project activities  Inadequate technical skills  Reduction of activities execution times  Lack of appropriate suppliers  More timely response to LoB  Limited contexts of application  Increased operational efficiency  Perception of limited effectiveness  Reduction in activities due to recycles  Risks related to the change  Enablement of greater IT proactivity  Lack of economic resources  Increased end-user satisfaction  Limits of contracts towards suppliers  Greater flexibility to change requests  Difficulties in quantifying costs and  Improved relationship with LoB benefits of the adoption  Improved estimations accuracy  Strong impact on current IT function  Increased team engagement and  Resistance to change by IT motivation  Lack of LoBs cooperation

Table 4 Incentives and barriers to the adoption of agile methodologies

12 The identified incentives and barriers will be covered by the empirical survey carried out by the Observatory and described in chapter six of the present document.

84 Literature review

5.5. Information Systems Architecture We have seen how companies can leverage on Enterprise Architecture to become more adaptive to the changing environment, and we have seen that EA was firstly born to create a unified IT architecture. Indeed, the concept of architecture is often applied also in other fields. For example, systems architecture is the conceptual model that defines the structure, behaviour and more views of a system (Jaakkola & Thalheim, 2011). According to Gartner (2016), when referring to Information Technology, architecture can be defined as:  “the overall design of a computing system and the logical and physical interrelationships between its components. The architecture specifies the hardware, software, access methods and protocols used throughout the system”;  “a series of principles, guidelines or rules used by an enterprise to direct the process of acquiring, building, modifying and interfacing IT resources throughout the enterprise. These resources can include equipment, software, communications, development methodologies, modelling tools and organizational structures”.

The relationship with Enterprise Information Systems is evident, especially in the second definition. Furthermore, Information Systems Architectures is also the name of one phase of the TOGAF framework, presented in the fourth chapter of this paper; TOGAF Phase C has indeed the objectives “to develop the target information systems architecture for data and application and to identify candidate Architecture Roadmap components based upon the gaps between Baseline and Target Architectures” (Orbus Software, 2016; The Open Group, 2011). Power (2015) defines IS Architecture as: “a formal definition of the business processes and rules, systems structure, technical framework, and product technologies for a business or organizational information system”. According to Power, IS Architecture usually consists of four layers: business process architecture, system architecture, technical architecture and product delivery architecture, encompassing the hardware and the software used to deliver an IT service to its final customer, and including other documented information like long term plans and priorities and a detailed inventory of current hardware, software and networking capabilities. Lastly, we have also seen that Information and Communication Architects are among the most common Domain Architects in organizations.

After having seen how software development projects can be managed in innovative ways, we will now face details about how Information System and, therefore, Software architecture can be designed and developed to support the ever-changing business requirements and needs.

85 Literature review

5.5.1. Software development and architecture elements The following pages will be more related to technical topics about design and development stages of SDLC; indeed, we have seen that software development should be continuous and rapid: developers need to have the appropriate architectural foundation and tools to achieve this goal. Describing some fundamental themes of software development and software architecture is needed to fully understand their evolution and today’s best practices, subject that we will face in the next chapters.

Architectural patterns for software development Beside Enterprises and Information Systems, as previously stated, also single software systems have their own architecture, which refers to its fundamental structures, the discipline of creating such structures, and the documentation of these structures; each structure includes software elements, relationship between them, properties of both elements and relations, and the foundation for the introduction and configuration of each element (Garlan, et al., 2010).

Looking at SDLC, decisions about software architecture are high-impact decisions that regards the design of the software (architectural design, not detailed design); for this reason, they often happen at the beginning of the lifecycle. Making the right architectural decision is an important but difficult task, as it has to be taken early, without many information available; this also seems to be contrasting with some modern methodologies we have presented in this chapter, like agile and lean software development, which among their principles have the deferment of decisions until the last responsible moment. This moment is not always clear to be identified, thus there are concerns that software architecture can lead to a big up-front design situation; different methods have been designed to manage the trade-off between architecture and agility, leading to define just the enough architectural foundations at the early stages of SDLC or to consider architecture as an asset to re- evaluate at each iteration (Boehm & Turner, 2004; Abrahamsson, et al., 2010; Kruchten, 2013; Morisio, 2010).

Software architecture has also a contact with the Requirements Engineering, a topic we introduced in the previous pages. The two approaches are often considered complementary, even if they quite overlaps: if RE addresses the “what” (i.e. the problem), SW architecture targets the “how” (i.e. the solution); however, the choices of required behaviour given a problem impacts the architecture of the solution addressing that problem, and vice versa (Shekaran, et al., 1994; Boer & Vliet, 2009).

86 Literature review

Approaches to exploit synergies between requirements and architecture have also been developed, like the Twin Peaks model (Nuseibeh, 2001).

Each software has its own architecture, but during software history, sets of high level principles and patterns have been developed to provide abstract frameworks and reusable solutions: these are commonly called architectural styles or architectural patterns. According to Microsoft (2009), architectural styles can describe different aspects or domain of applications: some styles can refer to deployment factors, other to communication factors and other to structure and design issues; therefore, an application can use a combination of more than one style.

Software layers, frontend and backend In computer programming, layering is “the organization of programming into separate functional components that interact in some sequential and hierarchical way” (Rouse, 2007). Indeed, related functionalities are grouped into distinct layers or logics, vertically stacked on top of each other. According to Microsoft (2009), the main layers are:  Presentation layer, supporting the graphical user interface  Business layer, includes the logics or “rules” that determine how data can be created, displayed, stored and changed.

 Data layer, which includes the databases where information is stored.

Application layers may reside on the same physical computer (similarly to monolithic applications), or may be distributed over separate computers or “tiers”, with components in each layer communicating through well-defined interfaces. Traditionally, layers have been included in two tiers (client and server), with data and business logic combined on the server. This can negatively impact system scalability and reliability, thus 3-tier and generically n-tier architectural style has been developed to address this issues and provide additional benefits. Client-server is a popular example of layered architecture style; the term describes distributed systems that traditionally involve a separate client and one server system, connected by a network. The client initiates one or more requests, waits for replies from the server and then processes replies on receipt; the server instead authorizes the user and then carries out the processing required to generate the result; communication between client and server may happen through a range of protocols and data formats. Web-based applications, along with desktop applications which retrieves data from a local or remote stores, are all client-server applications; client-server architecture is useful when many

87 Literature review different clients need to be served or when the applications involve many services for other applications to consume.

Frontend and backend are two important concepts related to layering. Even if there isn’t a common definition, as the meaning of the terms slightly varies according to the context in which is used, generally speaking, frontend has to do with things related to clients and are user facing (e.g. the presentation layer or interface), while backend is related to server-side elements (e.g. applications rules and data).

Integration and data management The integration of business processes and information systems is not an easy subject, as it involves economical, technological, cultural and organizational aspects. However, given the continuously increasing complexity companies need to face, as described in the first chapter, managing integration is key for companies. Indeed, integration allows companies to be more fast in responding to business needs and to effectively and efficiently manage their assets, thus increasing their competitive advantage (Bruna, 2015). For example, by correctly managing integration, organizations can reduce the costs of information systems evolution and reach business objectives in the most flexible and economical way possible (Piraccini & Rossini, 2006).

The amount of information enterprises need to manage has dramatically increased in the past years, from data collected through companies’ processes, to data coming from outside enterprises’ boundaries. Traditionally, this data has been stored in information or data silos, repositories of fixed data which are under the control of a single department and are isolated from the rest of the organization (Rouse, 2015; Bruna, 2015). Also, business processes were traditionally isolated in silos, as accessing to data in other silos was difficult. This has led to the inability to exploit the full potential of information through correlation, as the value that can be extracted from a central view of information is higher than the value given by the sum of isolated information (Bruna, 2015).

88 Literature review

The first attempts to solve integration problems followed a vertical approach, which fostered information silos with tight and limiting integrations. This kind of integration is referred to as point-to- point: if the usage of external features is relevant inside a specific application, the “ad hoc” integration with the application providing the feature is realized. This strictly connects the two applications with a solution that cannot be used elsewhere, generating the so-called spaghetti integration (Figure 29): if the Figure 29 Spaghetti integration (Piraccini & Rossini, 2006) number of needed connections is high, complexity hugely increases leading to a not-scalable system with high evolution and maintenance costs (Piraccini & Rossini, 2006). For what concerns data, the first integration attempts were made through Batch File Transfer systems: files were shared between applications through dedicated processes, which need to agree on file format and position, and on the timing of read, write and delete actions. Batch processes can be more or less structured and flexible, but they can hardly deal with coherence and synchronization, thus generating misalignment between data on different databases (Piraccini & Rossini, 2006).

Many business processes need to be horizontally distributed over the organization, and integration is an attempt to facilitate these processes; however, poor approaches towards integration, like point-to-point and file transfer, can lead to many problems like data and features duplication and excessively coupled components, which cannot be removed for the fear of unwanted consequences or because of the size of the investment they had required. Therefore, maintenance and licence costs rise, and, while cost and complexity are high, software quality is low (Bruna, 2015).

Troubles in managing integration further underlines the importance of having a defined software architecture; indeed, through architecture, companies can easily adopt structured strategic approaches to integration, reaching all of its benefits. Business processes integration strategies can be classified according to the software layer they involve: presentation, business or data layer. Three relevant examples of complementary integration strategies impacting on software levels are the following (Piraccini & Rossini, 2006).

89 Literature review

 Portal Integration: with portals, integration happens at the presentation layer, bringing together different applications in a common user interface. It’s a non-invasive approach, allowing simple and rapid integration of heterogeneous systems.  Enterprise Application Integration (EAI): it involves the integration of the application logic, sharing the business layer between different systems or re-using already developed logics into new processes. EAI usually entails centralized solutions to manage connections between applications, using different kinds of middleware, such as Integration Brokers or Enterprise Service Buses.

 Enterprise Information Integration (EII): it focuses on data integration, as in many companies’ problems are not related to the sharing of business logics, but the main issue is having a homogenous way to access and manage data. This is usually done through technology and methods exploiting database federation, which maps multiple autonomous database systems into a single database. Master Data Management (MDM) is another term used to describe similar integration practices, with the aim of providing a single point of reference for organizations data.

Application and infrastructure management For what concerns the management of information systems, both hardware and software can be sourced in two ways:  Internally or “in-house”: application development is made by people inside the organization; the hardware infrastructure on which applications run is kept in company- owned datacentres or server rooms.  Outsourcing: software development can be outsourced either by tendering out development, or by purchasing Commercial off-the-shelfs solutions. IT infrastructures can be outsourced at different levels, from hardware colocation to hosting, or through cloud infrastructure providers (Clark, 2013).

Programming languages and development frameworks Programming languages are the formal computer languages designed to communicate instructions to a computer machine; they are the basic element required to develop a software. Programming languages were first low-level or machine code, providing little abstraction between the language itself and the language used by machines; high-level languages instead use a more natural language,

90 Literature review and born to be more understandable by humans. Today low-level languages are used just for drivers, firmware and hardware interfaces. According to the intended domain of use, computer languages can be divided into general purpose (i.e. languages broadly applicable across application domains) or domain specific (i.e. languages specialized to an application domain). Among domain- specific languages there are computer languages not strictly used for programming, but still essential for software development, like mark-up and style sheet languages, used to annotate and format documents (e.g. HTML and CSS, widely used in web applications), or query languages, used to make queries in databases (e.g. SQL). Programming languages can be also divided in programming paradigms, which share an idea and a basic discipline relevant for performing computations; a programming language can fall in just one or in multiple paradigms, according to their features.

Nowadays, while computing power has become cheap, programmer time is expensive: the most appreciated languages are thus those which provide a higher level of abstraction of the internal computer hardware details, being less complex and more programmer-friendly. Alongside ease of use, other important characteristics languages should offer are: power, speed and flexibility (Segue Technologies, 2012). Beside the features stated above, it’s difficult to identify a language better than other, as the domain where it should be used deeply impacts the choice of a language over another. However, data about the usage of programming language can provide some insightful information. According to IEEE Spectrum (2016), the most popular programming languages in 2016 is C, followed by Java and Python; C++, R and C# are respectively at the fourth, fifth and sixth position, with PHP, JavaScript and Ruby immediately afterwards. Among these languages, C is the oldest one and it’s not the most productivity-oriented language; the reasons for it still being at the first place are many, starting from the fact that, given its age, many of the hardware and software systems used by millions are programmed in the C language; furthermore, its portability and closeness to the hardware, its versatility and good performances are other possible reasons, making C the ideal language for different development scenarios, as further detailed by Muñoz Trejo (2015).

91 Literature review

5.5.2. Software architecture evolution In the following chapter, we will describe and analyse high level styles and patterns used to develop and manage companies’ information systems in the past 20 years, according to a classification made by Mainetti (2015). For each period, architectural topics and impacts on integration and data management, infrastructures and application sourcing will be presented.

Late ’90 and early 2000 Enterprise information systems are mainly composed of legacy monolithic applications, like departmental mainframe and applications for individual productivity. This period has seen the born of layered architectural styles, like the client-server model mentioned in the previous pages, which have been enabling for distributed architectures and thus the Web and internet. Figure 30 IS architecture, late '90 - early 2000 In this period, integration between applications happened just with data, through Extract Transform and Load (ETL) solutions.

Finally, software was mainly developed in-house, and information systems were hosted on infrastructures inside companies’ boundaries.

Years 2000-2005 The usage of web oriented client-server applications begins to spread. Thanks to Portal Servers, these applications integrated existing information systems (legacy and web) offering access to them through a single user interface, and thus constitute the primordial example of modern Intranets. Full-text search, techniques for searching a single document or collections in computers and databases, also started to gain ground in enterprises. Figure 31 IS architecture, 2000-2005

Beside very few exceptions, information systems are still hosted in internally managed infrastructures.

92 Literature review

Years 2005-2008 Enterprise Portals as collections of Web Enterprise Applications start to spread, while search engines become more important at an infrastructural level to perform federated searches among different enterprise applications.

Virtualization techniques to consolidate IT infrastructures begin to spread, also Figure 32 IS architecture, 2005-2008 fostered by green computing trends.

Finally, also outsourced applications start spreading, firstly using Active Server Pages (ASP) technology, and later with the first Software as a Service products.

Years 2008-2011 Companies put a strong focus on virtualization, with the first experimentations of internal/external cloud with IaaS solutions.

The usage of SaaS solutions is being strengthened especially for non-core processes (e-mail, CRM, etc.).

Service Oriented Architectures (SOA) Figure 33 IS architecture, 2008-2011 start to spread for the integration between internal and external applications (often integration between services still happens with point-to-point calls).

Ever-increasing attention to multichannel experiences, especially through mobile.

93 Literature review

Years 2011-2015 Cloud computing starts getting more relevance, in its different and previously explained facets: private and public cloud, Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). Figure 34 IS architecture, 2011-2015 Service Oriented Architectures (SOA) also begin to spread, allowing the integration between internal on premise applications and cloud applications, while flexibility is achieved through the usage of Business Process Management (BPM) techniques.

Indeed, with SOA, business processes can be packaged into interoperable services, using a range of protocols and data formats to communicate information. Services in SOA are autonomous and loosely coupled, as they use standard-based interfaces that can be invoked, published and discovered; they can be accessed locally or remotely by clients or other services. Having standard interfaces, common services can also be reused increasing business and technology opportunities and reducing costs. SOA paradigm was specifically developed for horizontal integration of applications; indeed, with SOA it’s possible to provide application functionalities as set of services, which can be used inside front-end integrations or by other applications through a middleware (Piraccini & Rossini, 2006).

Finally, for what concerns infrastructures, this period has seen the introduction of external and internal PaaS solutions. Primarily used to integrate external cloud applications, they soon started to be used for the realization of core applications.

94 Literature review

5.5.3. What’s best in 2016 After overviewing what happened in the past, now we will briefly discuss which are todays’ best practices, according to the Observatory for Enterprise Application Governance (2016). For each theme, we will firstly summarize the disadvantages of past practices, and then explain the most innovative solutions and their advantages.

Architectural patterns

MONOLITHIC SERVICE ORIENTED Possible functional redundancy and Finding the right service granularity is not easy inconsistency Creating generalizable services requires High maintenance and evolution costs additional costs Blocking of generational evolutions, vendor Risk of similar services duplication lock-in is widespread Systems are difficult to scale Over-complexity and high management costs Table 5 Limits of Monolithic and Service Oriented architectures Beside the SOA approach itself, the listed problems arose with some wrong SOA implementations, which were too much focused on technological aspects (Bruna, 2015). Microservices approach was born as a solution to these problems: with microservices, an application is broken into smaller, completely independent components, which have a great agility, scalability and availability (Clark, 2016). Microservices offer a better way to decouple components within an application boundary; in microservices architectures, services have a small granularity and a decoupled data model: they are independently deployable through service exposition using lightweight protocols. This allows different advantages and possibilities (Osservatorio Enterprise Application Governance, Politecnico di Milano, 2016):

 Higher loads scalability  Easier reuse of services  Ability to incrementally add new features to applications  Possibility to delegate the development of services to diversified teams  Transparent management of individual services evolution or of vendor switching

95 Literature review

Integration methods

SPAGHETTI INTEGRATION ENTERPRISE SERVICE BUS Orchestration logics are delegated to a single Fragmented orchestration logic point Loss of control on flows and data ownership A costly centralized government is required Integrations can’t be standardized Fully exploiting the real potential is hard Maintenance is complex Cost-benefit trade-off is not always positive Table 6 Limits of Spaghetti integration and Enterprise Service Bus ESB itself is not a wrong concept, what is wrong is the meaning many people associate to the term: a central inflexible backbone for a whole enterprise. However, modern ESB, also called service delivery platforms, are flexible, distributed and scalable infrastructures which allow deployment and monitoring of services in an agile and efficient way (Wähner, 2015). Having simplified enterprise integration, the new challenge for companies was to provide appealing interfaces to consumers. The rise of smartphone usage shoot up APIs popularity, as these devices run rich client- side applications, creating a new and disruptive business channel; mobile application developers needed a simple access to back-end functions and data, which APIs could easily provide (Clark, 2016). Companies’ approach to APIs was something they have never seen before, and a complete new market was born under the term API economy; new business models to increase profitability through APIs, which are a saleable product, new players, API providers, and a new type IT capability, API management tools, populated this market. Particularly, among API management activities, the most relevant are: creating and publishing APIs, enforcing usage policies and analysing usage statistics, managing security by controlling access. The benefits of adopting API Management can be summarized as follows:  Ability to manage connections between APIs and applications  Consistency between multiple implementations and versions of APIs is ensured  Protection of APIs from improper usage  Integration with an external ecosystem of cloud services is enabled

96 Literature review

Data management

DATA SILOS MASTER DATA MANAGEMENT Projects require additional costs to ensure Lack of specific ownership of business entities consistency Data misalignment Centralized data model governance is complex Synchronization between the master and the Data duplication and loss of data quality local databases is costly Table 7 Limits of Data Silos and Master Data Management Using a centralized approach to manage data, like MDM, requires the definition of a standardized data model of all the exchanged business objects, which allows the communication between applications using different data formats. This model, usually called Common or Canonical Data Model (CMD), allows having just one kind of Customer, Order or Product, with a set of attributes and associations on which all the applications agree. Defining a and manage a CMD is not easy, as it requires a lot of coordination among different enterprise actors, which have different needs in terms of data attributes (Tilkov, 2015). A better approach to data integration is avoiding the definition of a CMD by using bounded contexts, a structuring mechanism derived from Domain-Driven Design. In a bounded context approach, a single large data model is divided into smaller contexts, thus allowing different modelling for business objects according to specific needs of each context. The interrelationship between contexts is explicit: bounded contexts have both unrelated and shared concepts (Fowler, 2014). The advantages of such approach are the following: Figure 35 Bounded Contexts, adapted from Fowler (2014)  Subdomains are decoupled, ensuring a more streamlined governance  Interdependence between subdomains is minimized

97 Literature review

Application sourcing

IN-HOUSE DEVELOPMENT SAAS SOLUTIONS Need for upfront investments Loss of control on applications evolution Know-how must be developed and kept inside Vendor lock-in on adopted systems the company Ongoing expenses to avoid obsolescence Internal competences are lost Table 8 Limits of In-House development and SaaS solutions The diffusion of the cloud computing’s business model, as mentioned in the third chapter of the present paper, has deeply changed the approaches towards software development: large capital expenditures were no longer needed to develop and deploy software internally. However, public cloud and Software as a Service may not meet companies’ requirements in terms of availability, price and scalability and raise concerns related to the risks of vendor lock-in and data security and competences loss (Howard, et al., 2012). Hybrid IT, relying on Hybrid cloud infrastructures, comes as a solution to these problems, combining internal and public clouds in supporting various business outcomes. Indeed, many IT organizations are adopting public cloud computing for noncritical IT services, keeping in house critical IT services and data; this way, they can refocus efforts on core capabilities which provide competitive differentiation to business, being more quick and efficient in responding to the changing business conditions. However, as IT services are sourced from a variety of internal and external suppliers, the success of such practices also depends on the final user experience: a seamless experience obtained through Client- side Mashups and Single Sign On implementations is crucial. The main benefits of a Hybrid IT approach to application sourcing can be summarized as follows: Figure 36 Hybrid IT (Gartner, 2012)  SaaS solutions for components more standardized or nearer to consumer logics  Internally developed software to implement specific and differential functionalities  Applications are composed integrating offered services client-side or server-side

98 Literature review

Development frameworks

ELEMENTAR LANGUAGES GENERAL PURPOSE PLATFORMS Usage of non-standard solution which are not Very complex usage reusable High implementation times Initial training is hard Problems in following technological Rigidity and lack of flexibility evolutions Table 9 Limits of Elementary languages and General Purpose platforms To improve the efficiency of creating software, in terms of developer productivity and code reusability, and to improve the quality, reliability and robustness of new software, different frameworks, code libraries and other toolkits have been developed (Cimetrix, 2010). Integrated Development Environments (IDE), the applications providing software development tools to programmers, have also been updated to sustain the extent of development productivity and software quality, including support to framework and libraries and integrating testing tools. Software design patterns, which work like architectural patterns but at a lower level, are another helpful solution for the same purpose. Development should thus move from simple high level languages, not standard and not reusable, to general purpose platforms, with steep learning curves and high rigidity, to modular and flexible specialized platforms, which have the following benefits:

 High degree of components modularity  Libraries to implement high level functionalities  Rapid development using standard configurations  Development as basic services mashup

99 Literature review

5.6. The need for high level organizational changes A structured IT Governance is a prerequisite to bring IT at the same level of all the other parts of the business, enabling the evolution of Enterprise Architecture from dealing with just IT architecture to also manage business architecture in terms of application and processes. Through IT Governance the CIOs can use the same tools and have the same accountability of other C-levels (Berinato, 2001).

However, a profound organizational change to promote IT and business alignment at the highest level is needed. According to CIO magazine (2005), the first step for this change regards reporting relationships: the CIO has to report to the CEO, as this would allow EA to be an alignment force. Indeed, if IT doesn’t get access to the business at the highest level, understanding what precisely the business wants from IT would be a hard task. To protect from the start over necessary if the relationship is personal and one of the parties changes, the CIO-CEO relationship should be institutionalized in a sustainable, repeatable process for discussing IT and business strategy and for making investment decisions; for example, an executive committee composed of the CEO, CIO and other C-levels could be created, together with a shared investment decision process.

Moreover, a step back from the executives involved in the high-level investment process is needed: they should comfortably cede some power and control to Enterprise Architects, allowing them to review every investment or project; this will force mid-level business people to care about EA. However, architects’ reputation shouldn’t be just that of the hated investments blockers: to be accepted from business, CIOs must take care that EA isn’t hated, while EA must evolve from its first approach, offering more valuable products and benefits. This is possible only if EA directly reports to the CIO, not one or two levels below him. In a future, if EA is done right, it may not report to IT anymore, becoming an independent entity reporting to the strategic planning group or the COO (CIO, 2005).

100 Research findings, discussion and conclusions

6. Findings from the survey

6.2. Sample description 6.2.1. Introduction Starting from the first section, we carried out an analysis of sample characteristics. In order to evaluate companies results without considering their dimension, we calculated their turnover per employee founding the following groups:

 Companies with a turnover per employee lower than 0.19 million €;  Companies with a turnover per employee between 0.2 and 0.39 million €;  Companies with a turnover per employee higher than 0.4 million €.

Finally, we grouped companies according to number of employees in the IT department as following:

 Companies with less than 10 IT employees;  Companies with 11-30 IT employees;  Companies with 31-100 IT employees;  Companies with more than 101 IT employees;

6.2.2. General description Dividing companies according to sector, the majority of the sample belongs to the Manufacturing industry (39%), followed by Wholesale & Retail (14%), Finance (10%), and Utilities (11%). A 17% of the sample belongs to other sectors.

In terms of company size, we identified as Large Enterprises (LE) companies with more than 249 employees and Small & Medium Enterprises (SME) companies with less. The majority of companies belongs to LEs (75%). In particular, SMEs are present in three sectors: Manufacturing, Service & Utilities, and Wholesale & Retail.

Concerning turnover, for the 16% of them it is lower than 50 million €, for the 39% between 50 and 500 million €, and for the 45% higher than 500 million €.

The company size in terms of turnover is rather aligned to what emerged considering employees number, also looking at sectors: in fact, there are companies with less than 50 million € of turnover just in Manufacturing and Service & Utilities sectors.

101 Research findings, discussion and conclusions

While, looking at turnover per employee, the sample results to be almost equally distributed on the three identified groups, as shown in Chart 4.

30% <0.19 million € per 35% employee 0.2-0.39 million € per employee >0.4 million € per employee 35%

Chart 4 Companies turnover per employee

6.2.3. IT function description Analyzing the sample IT function, in about the 38% of companies it consists of less than 10 employees: among them, the 26% has only 1 employee. Only in the 14% of cases, the IT staff is more than 100 employees. Looking at the IT spending, about the 72% of companies spends less than the 1.5% of turnover on IT and only the 5% spends above 3.5%.

5% 6% 14% Less than 10 employees More than 3.5% of turnover 38% 39% Between 11-30 17% 2.5%-3.5% of turnover 21% employees 1.5%-2.5% of turnover Between 31-100 0.7%-1.5% of turnover employees 33% 27% More than 100 employees Less than 0.7% of turnover

Chart 5 Companies IT staff and IT spending on turnover

As shown in Chart 6, It is interesting to notice that the 54% of LEs has an IT function consisting of less than 30 employees and the 23% with less than 10%.

102 Research findings, discussion and conclusions

SME 79% 14% 4%3%

LE 23% 31% 28% 18%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Less than 10 employees Between 11-30 employees Between 31-100 employees More than 100 employees

Chart 6 IT staff size by company size

Looking at turnover clusters, among those companies having a revenue between 50 and 500 million euros, the 51% has less than 10 IT employees and another 41% has between 10 and 30.

Comparing IT staff data with outsourcing usage, it is notable that just the 12% of companies with less than 10 IT employees do not outsource IT.

As shown in Chart 7, the most IT staffed sector is Finance (60% with more than 100 employees and not even one company with less than 10 employees). The less staffed sectors are Service & Utilities (92% with less than 30 employees), Public Sector & Healthcare (73%), and Manufacturing (72%). Wholesale & Retail sector is quite heterogeneous. As described in Chart 8, Finance is also the sector which spends the higher percentage of turnover in IT: the 80% of finance companies spends more than 3.5% of turnover in IT. On the contrary, Public Sector & Healthcare is the least spending sector, with 91% of companies spending less than 1.5%.

100% 7% 9% 8% 90% 25% 80% 20% 18% 70% 60% 42% 60% 21% 25% 50% 46% 40% 30% 31% 52% 50% 20% 40% 27% 10% 19% 0% Finance Manufacturing Public Sector & Service & Utilities Wholesale & Retail Healthcare

Less than 10 employees Between 11-30 employees Between 31-100 employees More than 100 employees

Chart 7 IT staff size by sector

103 Research findings, discussion and conclusions

100% 5% 9% 7% 90% 15% 22% 18% 14% 80% 15% 70% 14% 60% 80% 34% 50% 39% 36% 40% 73% 30% 20% 39% 31% 10% 20% 29% 0% Finance Manufacturing Public Sector & Service & Utilities Wholesale & Retail Healthcare

Less than 0.7% of turnover 0.7%-1.5% of turnover 1.5%-2.5% of turnover 2.5%-3.5% of turnover More than 3.5% of turnover

Chart 8 IT spending on turnover by sector

We expected Finance companies as leading ones in IT spending since many of their processes are IT-based. On the contrary, it is strange that a sector like Manufacturing, where a technological trend like Industry 4.0 is leading, is investing less than 1.5% of turnover in the 73% of cases.

It is interesting to notice that data about IT spending on turnover do not seem to be related to companies results in terms of turnover per employee. Therefore, IT priority does not change a lot according to companies’ economic capabilities.

Concerning investments in digitalization, as shown in Chart 9, the 57% of companies are spending in it between 6-30% of the IT spending, the 24% less than 6%, only the 4% more than 50%.

4% 13% Less than 3% of IT spending 15% Between 3-6% of IT spending 11% Between 6-15% of IT spending

Between 15-30% of IT spending 29% 28% Between 30-50% of IT spending

More than 50% of IT spending

Chart 9 Companies investments in digitalization

This result is strongly led by SMEs, in fact, as shown in Chart 10, the 79% of them spends less than 15% of IT spending in digitalization. Among LEs, the 52% spends in digitalization between the 15% and 50%. This is confirmed also in terms of turnover.

104 Research findings, discussion and conclusions

SME 35% 7% 38% 10% 10%

LE 6% 12% 25% 36% 16% 5%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Less than 3% of IT spending Between 3-6% of IT spending Between 6-15% of IT spending Between 15-30% of IT spending Between 30-50% of IT spending More than 50% of IT spending

Chart 10 Investments in digitalization by companies’ size

From the analysis of IT spending, it is clear that giving to IT the right economic priority is hard: 39% of companies spends less than 0.7% of turnover in IT and 72% less than 1.5%. This result is confirmed by data about investments in digitalization: in fact, just the 19% of companies is able to invest more than 30% of IT spending in digitalization. However, combining the two results, companies spending more in IT seem to be able to invest more in innovation.

More than 3.5% 20% 60% 20%

Between 2.5%-3.5% 66% 17% 17%

Between 1.5%-2.5% 6% 24% 35% 29% 6%

Between 0.7%-1.5% 12% 9% 43% 27% 6% 3%

Less than 0.7% 23% 12% 20% 28% 12% 5%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Less than 3% of IT spending Between 3-6% of IT spending Between 6-15% of IT spending Between 15-30% of IT spending Between 30-50% of IT spending More than 50% of IT spending

Chart 11 Companies investments in digitalization by IT spending

105 Research findings, discussion and conclusions

Indeed, just in the two groups spending less than 1.5% of turnover in IT, there are companies investing less than 3% of this spending in digitalization. Among companies with the highest percentage of spending, there is just a minority investing less than 6% in innovation. However, it is anyway hard finding companies which invest more than 30% of IT spending in digitalization. We can conclude that companies are using IT budget for other aims, such as maintenance, not focusing their efforts on innovation.

Analyzing the IT function responsibility in digitalization projects, in the 42% of cases it has full responsibility, in another 40% it has more than 50% of responsibility.

5% 13% IT function is responsible for 100% of projects

42% IT function is responsible for more than 50% of projects

IT function is responsible for less than 50% of projects

40% IT function is involved marginally or operationally

Chart 12 Who is responsible for IT projects

Therefore, in order to simplify future analysis, we divided companies in two groups based on centralized or shared responsibility on digitalization projects. In particular, we considered:

 “IT centric” those companies in which IT function is responsible for 100% of digitalization projects;  “IT collaborative” those companies in which responsibility is shared with Lines of Business.

“IT collaborative” companies turned out to be the majority of the sample (58%).

42% IT centric

58% IT collaborative

Chart 13 Groups by responsibility for IT projects

106 Research findings, discussion and conclusions

Technologies consumerization is leading LoBs to sponsor and collaborate for their introduction, sharing with IT competence and responsibility with the IT function. Being collaborative could be an advantage since it increases the capability to align business requirements with IT. However, as explained in the literature review, having Lines of Business too responsible for IT projects, could lead to undesired consequences such as shadow IT, which means LoBs take all the initiatives without a control by IT function. In fact, its pervasiveness is transforming IT from being an exclusive domain of the IT function to a diffused competence in Lines of Business. When projects responsibility is too unbalanced towards LoBs, shadow IT prevails reducing opportunities for innovation. Fortunately, just in the 5% of cases IT is involved in projects just marginally.

Looking at outsourcing usage for IT services, it is rather spread in the sample: just the 10% of companies do not outsource any service and the 63% outsource both application and infrastructure management.

11% 10% No outsourcing

16% Both Application and Infrastructure management

Infrastructure management only

63% Infrastructure management only

Chart 14 Companies usage of IT outsourcing

Outsourcing usage do not seem to be related to company size both in terms of turnover and employees number. However, the classification by sector gives interesting results: the 37% of those who do not outsource belongs to the Wholesale & Retail sector.

Wholesale & Retail 37%

Manufacturing 27%

Finance 18%

Service & Utilities 9%

Public Sector & Healthcare 9%

0% 5% 10% 15% 20% 25% 30% 35% 40%

Chart 15 Outsourcing by sector

107 Research findings, discussion and conclusions

Again Manufacturing, one of the most impacted sectors by digital revolution, is the second one by outsourcing usage, resulting that it is not strongly investing in building an internal IT capability.

Comparing IT staff data with outsourcing usage, we expected that those companies with a small IT function would have made more usage of outsourcing service. However, the link between the two results is not so evident: outsourcing usage is frequent despite the IT staff numbers.

108 Research findings, discussion and conclusions

6.2.4. Clustering We tried to segment the sample looking at how much companies spend in IT and digitalization. Therefore, we identified four possible groups based on investments in processes digitalization in order to define whether a company is moving to digital. We divided companies as following:

 “Static” those companies which invest less than 6% of IT spending in digitalization;  “Stable” those companies which invest between 6%-15% of IT spending in digitalization;  “Dynamic” those companies which invest between 15%-30% of IT spending in digitalization;  “Transformative” those companies which invest more than 30% of IT spending in digitalization.

Then, we combined these groups with those based on IT spending on turnover. In particular, in order to give a numerical significance to these groups, we took 1.5% of IT spending on turnover as a break between companies which give an economic priority to IT and the others. Combining data, we finally identified three clusters, as shown in Table 10.

 “Transformative” and “Dynamic” companies spending more than 1.5% of turnover in IT are considered “Strongly digital oriented”;  “Transformative” and “Dynamic” companies spending less than 1.5% of turnover in IT and “Static” and “Stable” companies spending more than 1.5% are considered “Medium digital oriented”;  “Stable” and “Static” companies spending less than 1.5% of turnover in IT are considered “Weakly digital oriented”.

less than 0.7% between 0.7%-1.5% between 1.5-2.5% between 2.5-3.5% more than 3.5% of turnover of turnover of turnover of turnover of turnover

Static Weakly digital oriented Medium digital oriented Stable

Dynamic Medium digital oriented Strongly digital oriented Transformative

Table 10 Clustering

109 Research findings, discussion and conclusions

6.2.5. Clusters analysis Carrying out a deeper analysis of the proposed clusters, the “Weakly digital oriented” group represents the majority of the sample (42%).

18%

42% Weakly digital oriented

Medium digital oriented 40%

Strongly digital oriented

Chart 16 Clusters size

“Weakly digital oriented” companies represent the majority of SMEs, while LEs are mainly “Medium digital oriented” (44%). The largest part of “Strongly digital oriented” companies belongs to the LEs group (94%). Looking at turnover, the situation is confirmed since 57% of companies with a turnover of 0-50 million € are “Weakly digital oriented”.

100% 4% 90% 23% 80% 27% 70% 60% 44% 50% 40% 69% 30% 20% 33% 10% 0% LE SME

Weakly digital oriented Medium digital oriented Strongly digital oriented

Chart 17 Clusters companies size

Analyzing clusters by sector, as shown in Chart 18, Finance turns out to be the most digital oriented sector with 60% companies in the cluster “Strongly digital oriented” and not even a single company in the cluster “Weakly digital oriented”. On the contrary, the Public Sector & healthcare is the one with the lowest number of companies in the “Strongly digital oriented” cluster” (just 9%).

110 Research findings, discussion and conclusions

100% 9% 90% 12% 15% 80% 36% 70% 60% 39% 39% 60% 55% 50% 28% 40% 30% 49% 46% 20% 40% 36% 36% 10% 0% Finance Manufacturing Public Sector & Service & Utilities Wholesale & Retail Healthcare

Weakly digital oriented Medium digital oriented Strongly digital oriented

Chart 18 Clusters by sector

Looking at the IT staff numbers, it is noticeable that the majority of companies in “Weakly digital oriented” cluster has an IT function consisting of less than 10 employees (53%). In the “Strongly digital oriented” cluster, the 39% of companies has an IT staff of 31-100 employees and the 28% of more than 101 employees.

100% 2% 90% 12% 18% 28% 80% 70% 33% 21% 60% 39% 50% 28% 40% 30% 53% 17% 20% 33% 10% 16% 0% Weakly digital oriented Medium digital oriented Strongly digital oriented

Less than 10 employees Between 11-30 employees Between 31-100 employees More than 101 employees

Chart 19 Clusters by IT staff size

111 Research findings, discussion and conclusions

6.3. Technological trends influencing application portfolio management Moving to the second section of the questionnaire, we analyzed which are the technological trends that are mainly attracting the interest of companies in the sample.

The technological trends analyzed by the Observatory are:

 Mobility;  Collaboration;  User experience;  Data Intelligence;  Open application;  Pervasive Computing.

The first question of the survey tries to identify the trends that are most impacting on application portfolio governance and especially on portfolio evolution choices. Mobility and Collaboration turn out to be the most impacting trends since they are considered among the three most important trends by 64% of companies. They are directly followed by User experience (61%), with a large break from the remaining three trends.

Collaboration 64%

Mobility 64%

User Experience 61%

Data Intelligence 44%

Open application 36%

Pervasive Computing 34%

0% 10% 20% 30% 40% 50% 60% 70%

Companies considering the trend as one of the three most impacting ones

Chart 20 Most impacting technological trends

However, looking at which trend is the most important one for each company, we can see a different situation. Indeed, Mobility and User Experience are the top two but are directly followed

112 Research findings, discussion and conclusions by Open Application and Data Intelligence. Generally, the break between the top three trends and the others is not as significant as in the previous chart.

User Experience 22%

Mobility 21%

Open Application 18%

Data Intelligence 14%

Collaboration 13%

Pervasive Computing 12%

0% 5% 10% 15% 20% 25%

Companies considering the trend as the most impacting one

Chart 21 Most impacting technological trends

Analyzing which trend is the second most impacting one, the situation changes again, as shown in Chart 22.

Collaboration 23%

User Experience 21%

Mobility 20%

Data Intelligence 15%

Pervasive Computing 12%

Open Application 9%

0% 5% 10% 15% 20% 25%

Companies considering the trend one of the two most impacting

Chart 22 Most impacting technological trends

113 Research findings, discussion and conclusions

This is probably related to sector and size of companies in the sample. In fact, as shown in Chart 23, breaking up this data according to companies’ sector, we can see very different results: Manufacturing and Service & Utilities guide the sample in terms of Open Application, since it is the most important trend for 23% of companies. For Manufacturing, this could be related to Industry 4.0 trends that is significantly increasing the number of applications in the portfolio of such companies: in order to maintain a flexible and efficient system, applications need to be open, interoperable and easy to integrate. In the same way, Public Sector & Healthcare and Wholesale & Retail lead in terms of Data Intelligence with 27% and 25% of companies considering it as the top trend. In Wholesale & Retail, the reason could refer to the strong significance of Marketing for the sector: customer journeys are becoming more and more omnichannel and the interactions between physical and digital touchpoints generate a huge amount of data to exploit. In Public Sector, data become important in order to support decision making in strategy definition as we will see in a Case Study below. In Healthcare, this result could be related to the trend of digitalizing patients’ data. Instead, Finance turns out to be the least interested sector in Collaboration with not one company identifying it as the most impacting trend. Another evidence is the interest of Services & Utilities in Mobility (39%) probably related to field force automation.

Wholesale & Retail 12% 25% 25% 6% 13% 19%

Service & Utilities 7% 8% 39% 23% 15% 8%

Public Sector & Healthcare 18% 27% 10% 9% 18% 18%

Manufacturing 19% 7% 21% 23% 7% 23%

Finance 18% 28% 9% 18% 27%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Collaboration Data Intelligence Mobility Open Application Pervasive Computing User Experience

Chart 23 Most impacting trend by sector

In the survey, companies were asked to identify for each trend who is the internal sponsor, choosing among Line of Business, IT and Top Management. As expected, IT function turns out to be the main sponsor for the majority of trends except for User Experience and Mobility, for which LoBs are the main sponsor in the 55% and 39% of cases. Indeed, they are two trends strictly

114 Research findings, discussion and conclusions related to LoBs way of working: thanks to Mobility, they are not forced anymore to work in a specific place at a specific time, being able to respect their lifestyle balance. Moreover, thanks to User Experience, a user-friendly application is easier for them to use, since it is similar to the applications they usually access in their everyday life. This all improves their working productivity and satisfaction.

User Experience 8% 55% 37%

Pervasive Computing 4% 28% 68%

Open Application 4% 1% 95%

Mobility 25% 39% 36%

Data Intelligence 23% 27% 50%

Collaboration 20% 21% 59%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Top Management Line of Business IT Function

Chart 24 Sponsorship for the trends

Looking at the application scope, companies were asked which trends mainly influence each of the following scopes.

Customer Facing Application 32% 36% 19% 6% 2%5%

Customer Relationship Management 22% 25% 21% 23% 1% 8%

Office Automation 25% 29% 37% 2%3% 4%

Enterprise Information Management 13% 22% 24% 31% 2% 8%

Industry verticals 7% 25% 25% 22% 8% 13%

Core management systems 6% 35% 17% 29% 4% 9%

Human Resource Management 16% 36% 32% 11% 1%4%

Supply Chain Management 16% 18% 35% 13% 6% 12%

Supplier Facing Application 13% 17% 46% 8% 2% 14%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Mobility User Experience Collaboration Data Intelligence Pervasive Computing Open Application

Chart 25 Trends impact on different application scope in a portfolio

115 Research findings, discussion and conclusions

As expected, Collaboration impacts more on Supplier Facing Application (46% of cases) and Office Automation (37%), in which for example file sharing could be made more efficient avoiding the use of emails. Obviously, Data Intelligence highly influences Enterprise Information Management (31%). Mobility and User experience influence Customer Facing Application (68% combined) and CRM (47%): it is probably related to the aim of improving customers’ experience, both internally and externally, in interactions with the company. Pervasive Computing and Open Application have a small impact but anyway higher in some of scopes: Pervasive Computing is more considered in Industry Verticals, while Open Application in Supplier Facing Application, probably in order to integrate applications to gain efficiency in procurement processes which are supported by EDI and Extranets.

6.4. Technological trends: current state evaluation We tried to combine the previous questions about technological trends in order to carry out a comprehensive and overall evaluation of the market in terms of trends impact on application portfolio. In particular, we identified four parameters of evaluation according to which each trend can be considered more or less important:

 Parameter 1: how many companies have identified the specific trend among the first three more impacting on application portfolio evolution;  Parameter 2: how many companies do not consider the specific trend of significant interest;  Parameter 3: in how many application scopes the specific trend has an impact higher than 20%;  Parameter 4: how many times the specific trend is mentioned as one of the two most impacting trends on each application scope. We gave to each trend a score going from 1 to 4 according to the different values of each parameters, as shown in Table 11. 1 2 3 4 Parameter 1 0-19% 20-39% 40-59% 60-100% Parameter 2 >=26% 16-25% 6-15% <=5% Parameter 3 0-1 2-4 5-7 8-9 Parameter 4 0-9% 10-19% 20-29% >=30%

Table 11 Value of parameters for trends impact evaluation

116 Research findings, discussion and conclusions

Making an average of the parameters scores for each trend, we got the following result.

Mobility 3,5 3,0 2,5 2,0 Open application User Experience 1,5 1,0 0,5 0,0

Pervasive Computing Collaboration

Data Intelligence

Chart 26 Evaluation of trends impact on application portfolio

As expected from previous analysis, User Experience (score of 3.3) and Collaboration (3.3) are the most interesting trend for companies in the sample, followed by Mobility (2.8) and Data Intelligence (2.3). The least interesting are Pervasive Computing and Open Application, probably because they are more technical and newer, and therefore there is a lack of competences in the market.

It is interesting to notice that the top three trends for companies’ interest have a higher sponsorship by LoBs or Top Management compared to the others. Indeed, Open Application and Pervasive Computing present IT department as the main sponsor. While, Top Management strongly promotes Mobility (25%), Data Intelligence (23%), and Collaboration (20%). LoBs sponsorship is the most impacting on User Experience (55%) and Mobility (39%), which on the contrary present a weak promotion by IT function. Indeed, LoBs and Top Management have a higher percentage of sponsorship in User Experience (63%) and Mobility (64%). Therefore, it is concludable that the boost for innovation comes from the IT function but, to become truly impacting on application portfolio management, a technology needs to get significant approval and sponsorship even by LoBs and Top Management.

We also tried to analyze this result breaking it down according to the proposed companies’ clusters not finding significant differences. Therefore, being weakly or strongly oriented to digital does not mean being significantly interested in a specific trend.

117 Research findings, discussion and conclusions

6.5. Role and processes of IT function Moving to the second section of the questionnaire, it is aimed at understanding how IT processes and roles change because of innovative methodologies for IT projects management. As previously explained, these new methodologies are the following:  Methodologies for analysis and planning (goal based analysis, user story mapping)  Methodologies for development (SCRUM, XP, lean software development)  Methodologies for deployment (DevOps)

The first question aim is finding out the diffusion of these methodologies in the sample. From results, it is clear that they are not used by the majority of companies, especially for what concerns the analysis phase.

Analysis Development 4 2 %10% % 12% 29% 19% 53% 37% 14% 20%

Deployment

5% 14% 39%

20%

22% Every IT projects is managed using these methodologies A significant part of IT projects is managed using these methodologies Just few IT projects is managed using these methodologies Methodologies adoption is under evaluation/testing Not one IT projects is managed using these methodologies

Chart 27 Diffusion of Agile methodologies

In particular, for all the phases, the methodologies are mainly not used or under evaluation (in around the 50% of cases) and companies using them for all the projects management are always under the 6%. The usage of advanced methodologies is more spread in the development stage

118 Research findings, discussion and conclusions

(52% of companies using it at least for few projects), followed by deployment (39%) and analysis (32%).

However, avoiding the division among the three phases, the situation turns out to be less severe. Indeed, even if just the 14% of companies is using all the methodologies in all the phases, only the 15% does not use any methodology in any phase of the process and the 12% of them is evaluating to adopt at least one methodology. Moreover, the 75% of companies is introducing organizational changes in the IT function: among them, 54% is introducing new processes and methodologies and 48% new working methods with LoBs. Therefore, we can conclude that the market is backward but still evolving.

An introduction of new working processes, methodologies and 54% tools is under way 25% The adoption of new working methods with LoBs is under way 48%

75% A review of the IT organizational model is under way 39%

An introduction of new figures Introducing changes in IT function and competences is under way 29% Not introducing changes in IT function

Chart 28 Organizational changes diffusion and type

Since one of the main objectives of innovative methodologies is to get a final product that better meets the requirements, it is strange to notice that methodologies for analysis phase are the least diffused. Analysis methodologies registers the highest number of companies which do not use them because of a lack of knowledge, as shown in Chart 29.

119 Research findings, discussion and conclusions

Lack of knowledge on new methodologies Lack of technical competences Difficulties in costs and benefits quantification Low collaboration from LoBs Lack of economic resources LoBs perception of low effectiveness Lack of competence and willingness of vendors Strong impacts on current IT organization Methodologies are appliable in too limited contexts Risks of new methodologies introduction Resistence to change in IT function Limits of contractual tools with vendors

0% 5% 10% 15% 20% 25% 30% 35% 40%

Analysis Development Deployment

Chart 29 Limits to adoption of innovative methodologies

Concerning the perceived benefits, in the analysis phase the main one is higher control on project activities (16%), improved relationship with LoBs (15%), and higher users’ satisfaction (14%). In the development stage, they are higher timeliness of response to LoBs (25%) and reduction of activities execution time (21%), while in deployment phase it is higher operational efficiency (22%).

Higher timeliness of response to LoBs Reduction of activities execution time Higher operational efficiency Higher control on project activities Higher flexibility to change requests Less activities related to recycling Higher users' satisfaction Improved relationship with LoBs Higher IT proactivity Higher teams motivation and engagement Improved accuracy

0% 5% 10% 15% 20% 25% 30%

Analysis Development Deployment

Chart 30 Motivations to adoption of innovative methodologies

120 Research findings, discussion and conclusions

6.6. Evolution of Information Systems architecture Passing to the third section of the survey, the aim is analyzing the evolution of applications architecture needed to enable the previously described trends and working models. In particular, questions are proposed to understand more about companies’ situation in terms of Application Portfolio Management, modern software architecture, and Enterprise Architecture.

Concerning APM, companies were asked about their tools of application mapping: in particular, whether in their companies an application mapping exists and how frequently it is updated. They turned out to be advanced in this since 74% of them maps applications systematically or at least periodically.

12% 18% Present and updated at each change 6% Present and periodically updated 8% Present but no more upadated

Absent but under evaluation

56% Absent and not expected introduction

Chart 31 Application portfolio mapping

Then, looking at software architecture, they were asked whether they are investing in applications architecture rationalization and evolution. Again, the market situation is rather advanced with 33% of companies investing a lot and continuously and in architecture evolution.

33% Many and continous investments 29% Many and discontinous investments Few investments Very few or no investments

33%

Chart 32 Investments in application architecture evolution and rationalization

However, there is not a big break from those companies which are investing discontinuously (33%) or not significantly investing (29%). It is anyway positive that just 5% of companies does not invest.

121 Research findings, discussion and conclusions

The next question was about the presence of an organizational unit dedicated to Enterprise Architecture. Here the situation is more backward: indeed, 35% of companies does not have this kind of organizational unit. Anyway, the 34% have it, even if the 16% has recently introduced it. The 25% does not have an organizational unit but at least some employees managing architectures. Therefore, even if more backward, the situation is quite positive as well.

Present and consolidated 18% 35% Present but recently introduced

Not present but some employees manage architectures 16% in their field of work Not present but under evaluation

6% Not present 25%

Chart 33 Organizational unit devoted to Enterprise Architecture

Companies using Enterprise Architecture were then asked which roles it is dedicated to. The majority of companies recognize EA as fundamental for giving development guidelines, probably in order to align portfolio evolution with the evolution roadmap of the business. Moreover, EA is considered important in participating to development projects and managing infrastructures.

Definition of guidelines for application development 33%

Participation to development projects 32%

Management of infrastructure architecture 30%

Security management 19%

Software lifecycle management 11%

0% 5% 10% 15% 20% 25% 30% 35%

Chart 34 Roles of Enterprise Architecture management

122 Research findings, discussion and conclusions

However, even participation at development projects (32%) and Infrastructure management (30%) are considered important, and they probably are more specifically related to Domain Architects and Solution Architects, who have a smaller scope compared to Enterprise Architects.

Finally, companies were asked to describe difficulties and benefits related to proper management of EA. This time, we do not find lack of competences as the main difficulty (just 17% of cases): management commitment turns out to be low and seen as a problem in 25% of cases. The second main difficulty is related to budget (18%): in fact, as seen before, IT spending is quite low in the sample.

Low management commitment 25%

Lack of budget 18%

Lack of competences 17%

Resistence by projects teams 14%

Previous unsuccessful experiences 6%

0% 5% 10% 15% 20% 25% 30%

Chart 35 Limits to EA adoption

The main perceived benefits of EA are flexibility of Information System to business requests (58%) and uniformity between business strategy and architecture evolution (57%). This was expected from literature review, since the main objective of EA is aligning business and IT evolution. Therefore, we can conclude that, if EA is correctly managed, this result can be achieved. Furthermore, EA is a base for rationalization of application portfolio, resulting in a reduced complexity, as the third main perceived benefit (36%).

123 Research findings, discussion and conclusions

Making Information System more flexible and ready to respond to business requests 58%

Giving a strategic and uniform direction to architectural choices 57%

Reducing application portfolio complexity 36%

Improving IT control and knowledge on application portfolio 21%

Reducing IT management costs 14%

0% 10% 20% 30% 40% 50% 60% 70%

Chart 36 Benefits from EA correct management

6.7. Role of IT function and Enterprise Architecture: state-of-the-art evaluation We tried to understand how the market and the previous proposed clusters are positioned in terms of IT role and processes and Enterprise Architecture. To do so, for each company we used four areas of assessment, each of them related to an evaluation parameter:  Innovative methodologies - Parameter 1 [section II, question 7 from Observatory survey]: in how many IT projects innovative methodologies are used;

 Application Portfolio Management (APM) - Parameter 2 [section III, question 11 from Observatory survey]: existence and update level of an application portfolio mapping;

 Modern software architectures - Parameter 3 [section III, question 12 from Observatory survey]: how much company is investing in architectures evolution and rationalization;

 Enterprise Architecture - Parameter 4 [section III, question 13 from Observatory survey]: existence and development level of an organizational unit dedicated to enterprise architecture.

We have given to each company a score going from 1 to 4, according to different values of each parameter as shown in Table 12. Scores were given not only according to what emerged from literature review, but also in order to have a significant number of companies in each score range.

124 Research findings, discussion and conclusions

Therefore, it was not possible to base the evaluation on a standard range between 1 and 5 because numbers were not significant.

An example can be useful to practically explain the used method: in question 9, companies were given a score going from 1 to 5 according to the usage of methodologies in each phase of IT projects; then, to determine Parameter 1, we took the average score of the three phases to give a unique evaluation and, since no companies had an average close to 5, we brought this numbers to a range between 1 and 4 eliminating the decimal points. 1 2 3 4 Average score Average score Average score Average score Parameter 1 < 2 between 2-3 between 3-4 >= 4 Absent and Present but no more Absent but Present and updated not expected updated/periodically Parameter 2 under evaluation at every change introduction updated Many and Many and Very few or no Few investments discontinuous continuous Parameter 3 investments investments investments Absent but under evaluation/some Present but Present and Absent Parameter 4 employees manage recently introduced consolidated architectures

Table 12 Value of parameters for IT governance evaluation

Once computed this evaluation for each company of the sample, we positioned the general situation on a radar chart as shown in Chart 37.

Innovative methodologies 3,5 3,0 2,5 2,0 1,5 1,0 0,5 Application Portfolio Enterprise Architecture 0,0 Mapping

Modern SW Architectures

Chart 37 Evaluation of sample IT governance

125 Research findings, discussion and conclusions

As expected from single questions analysis, the sample turns out to be advanced in terms of APM (score of 2.8 on 4) and software architectures (3.0), while more backward in terms of Innovative methodologies (1.9) and EA (2.2). Breaking up this result according to companies’ dimension, LEs turn out to be significantly more advanced compared to SMEs (about 0.5 points more) in all the evaluation areas except for Innovative methodologies where, following the entire sample tendency, they are steady at a score of 1.9.

Innovative methodologies 3,5 3,0 2,5 2,0 1,5 1,0 0,5 Enterprise Application Portfolio LE 0,0 Architecture Mapping SME

Modern SW Architectures

Chart 38 Evaluation of SMEs and LEs IT governance

Looking at the proposed clusters of digital orientation, they are positioned as shown in Chart 39.

Innovative methodologies 3,5 3,0 2,5 2,0 1,5 1,0 Weakly digital oriented 0,5 Enterprise Application 0,0 Medium digital oriented Architecture Portfolio Mapping Strongly digital oriented

Modern SW Architectures

Chart 39 Evaluation of proposed clusters IT governance

126 Research findings, discussion and conclusions

Clusters present differences on the 4 evaluation axes, especially for Modern software architectures where “Strongly digital oriented” companies overcome “Medium digital oriented” by 0.5 and “Weakly digital oriented” by 0.7. In Enterprise Architecture, they overcome the others by respectively 0.3 and 0.5. Instead, on the other axes, the situation is more homogeneous, since for Innovative methodologies the difference is 0.3 and 0.2, and for APM all the sample clusters seem to be rather advanced with nearly the same score. We can conclude that companies investing more in IT and innovation could be following a more structured roadmap of change, rationalizing architectures and strategically planning company and information systems evolution. However, we are talking about companies that are in an average score between 2 and 3 on 4, therefore, spending more does not imply being significantly advanced in any of the 4 axes.

Trying to identify which companies are the most advanced of the sample, we analyzed the occurrence of best scores combinations and we found just 13 companies (“advanced” group) with a score between 3 and 4 in all the areas (12% of the entire sample), as shown in Chart 40.

Innovative methodologies 4 3 2 1 Application Portfolio Advanced Enterprise Architecture 0 Mapping Backward

Modern SW Architectures

Chart 40 Groups of companies with similar profile score in IT governance: backward and advance

Together with the most advanced companies, we plotted those with the worst profile (“backward” group) having a score between 1 and 2 in all the areas (14% of the entire sample). “Advanced” companies are LEs for the 77% and belong to the Wholesale & Retail sector for the 30%, to Manufacturing for the 23%, and to Service & Utilities for 23%. “Backwards” companies are instead SMEs for the 57% and belongs to Manufacturing sector for the 44%.

Then, considering the occurrence of other scores combination, we identified those companies which are in the middle being nor totally advanced neither totally backward in all the evaluation areas. The market situation is very heterogeneous, since we could find 6 main groups with similar

127 Research findings, discussion and conclusions profiles consisting in a number of companies between 5 and 15. As shown in Chart 41, the remaining 27 companies (24% of the sample) have too different profiles looking at each evaluation axis and then are not significant to be represented in a radar chart. Focusing on the significant groups, we called them “medium” and discriminated among them using a number.

Advanced 12% Medium 24% Medium 1 13% Medium 2 Medium 3 7% 14% Medium 4 7% Medium 5 Backward 12% 4% 7% Heterogeneous

Chart 41 Numerousness of groups of companies with similar score profile in IT governance

As shown in Chart 42, the first “Medium” profile, which consists of 15 companies (largest group), is quite advanced in modern architectures and APM, while close to the “backward” group in terms of innovative methodologies and EA. “Medium 1” is very similar but much more advanced in innovative methodologies.

Advanced Medium Medium 1 Backward

Innovative methodologies 4

1 Application Portfolio Enterprise Architecture 0 Mapping

Modern SW Architectures

Chart 42 Groups of companies with similar score profile in IT governance

Instead, as shown in Chart 43, “Medium 2” is significantly advanced just in modern architectures, while in other areas it is weak, especially in innovative methodologies. “Medium 3” is close to advanced group in terms of EA and APM but in the middle in terms of software architectures and weak in innovative methodologies.

128 Research findings, discussion and conclusions

Advanced Medium 2 Medium 3 Backward

Innovative methodologies 4 3 2 1 Application Portfolio Enterprise Architecture 0 Mapping

Modern SW Architectures

Chart 43 Groups of companies with similar score profile in IT governance

Finally, “Medium 4” is weak in all the areas except for APM and, on the contrary, “Medium 5” is advance in all the fields except for innovative methodologies.

Advanced Medium 4 Medium 5 Backward Innovative methodologies 4 3 2 1 Enterprise Architecture 0 Application Portfolio Mapping

Modern SW Architectures

Chart 44 Groups of companies with similar score profile in IT governance

It is clear that even the identified groups are rather different from each other, and it is thus difficult to find a general trend describing the entire sample. Therefore, we can evaluate the market as mediumly positioned with some areas of success and others of neglection. In particular, looking at Chart 39, the overall sample, even if broken down in the proposed clusters about digital orientation, appears in a medium position in all the 4 axes. While, considering each company situation, “advanced” and “backward” groups are just a small percentage of the sample, and the majority of cases shows a heterogeneous score, with some axes of success, and some others of backwardness.

129 Research findings, discussion and conclusions

Trying to understand the characteristics of “advanced” and “backward” companies, it is interesting the correlation between their state of progress in IT governance and their results in terms of turnover per employee, as shown in Chart 45.

Backward 57% 29% 14%

Advanced 18% 46% 36%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

<0.19 million € per employee 0.2-0.39 million € per employee >0.4 million € per employee

Chart 45 Advanced and Backward companies in IT governance by turnover per employee

The two data seem to be related: the 57% of “backward” companies are earning a low turnover. On the opposite, most “advanced” companies turn out to have a high turnover: 46% with a revenue of 0.2-0.39 million € and 36% with 0.4 million € per employee. Therefore, what emerged from literature review is confirmed by survey results: companies aligning IT and business gain more competitiveness and get better economic results.

130 Research findings, discussion and conclusions

7. Case studies

7.2. Company 1

Company profile Company 1 is an Italian company producing pest control systems. Its mission is to create safe internal environments for privates and companies through a productive cycle based on a Made in Italy philosophy. Production quality and flexibility allow the company to have a large portfolio of customers throughout Europe.

Application Portfolio and IT function Company 1 is small, with just 30 employees: there is no IT function, the General Manager is managing IT among other responsibilities. Its Application Portfolio consists of an ERP realized with a client-server architecture in 2005 but currently used for the 80% of its potential. In the ERP, Operations, Quality management and accountability are integrated. Moreover, the portfolio includes Office and Exchange on premise. Unfortunately, where the company is located, there are broadband problems that precludes the migration towards Cloud services.

Project: company needs and technological solution Company 1 works mainly in a make-to-order logic, in which for each production order it has to manage and track a significant amount of documents, such as technical specifications, products sheets, and change requests. The effective management of this information is fundamental to meet an order and guarantee respect of ISO 9001 standards for which the company is certificated. Internal documents preparation for technical specifications and information flow management in case of order acceptance are processes that require frequent information exchanges between employees at different organizational levels. These exchanges are not predictable and traditionally happened via many heterogeneous communication tools.

E-mails and Instant Messaging were the only digital tools supporting these communication flows, while documents storage was on company file servers. Consequently, communication and documents sharing were totally ineffective and the amount of exchanged e-mails was hard to manage. These problems had significant negative impacts on operations and management: too much time lost in information research or recreation and too difficult monitoring activities.

131 Research findings, discussion and conclusions

In order to improve processes efficiency satisfying the need for collaboration, Company 1 began a scouting activity in order to find the best technological solution. Once identified the right collaboration platform, its vendor started an internal information flow and processes analysis, re- projected data exchanges and activated the right platform functionalities according to company needs. The core of the solution is a document management functionality, which, together with collaboration support, allows teams to communicate and cooperate in a single digital workspace.

Project management Thanks to a good platform configuration, the project did not overturn the company processes and ways of working. The main element of success has been involving a sample of the key users since the phase of flows and functionalities design. This bottom-up involvement allowed to identify specific needs and cooperate in projecting peculiar solutions. Particularly, this was helpful in limiting the internal organizational resistances, very common in case of imposed solutions. Therefore, the company identified a sample of key users for whom gradually activated the collaboration tool functionalities. In this way, they understood how to use the instrument and how to exploit its benefits, becoming themselves facilitators to the solution diffusion in the overall company.

Benefits Centralizing company information led to a significant improvement of operative processes. Indeed, the new platform allows to track and optimize the collaborative flows among stakeholders through a complete and integrated support, and to reduce the overhead caused by excessive e-mail usage.

Criticalities In terms of functionalities, the solution misses a timetable to organize teams’ activities and schedule projects deadlines. The vendor assured that this feature is under development and the company is still waiting. Moreover, as already explained, there was no resistance in lower organizational levels thanks to stakeholders’ involvement; Top Management, however, has been reluctant to use the collaboration solution probably due to concerns about information sharing and, therefore, decision making sharing.

132 Research findings, discussion and conclusions

Next steps Company 1 is evaluating an enlargement of solution functionalities in order to completely digitize processes. Moreover, this initiative is seen as a starting point for the future introduction of Agile methodologies, such as Scrum, towards which the company is strongly interested despite the challenge of changing the current ways of working.

7.3. Company 2

Company profile Company 2 operates in the Home & Building Automation sector designing and producing technological solutions for houses, buildings, and collective spaces control. It offers integrated solutions for parking, access control, security, and flows management, oriented to the new needs of an increasingly connected world. Company had a turnover of 240 million euros in 2015 and consists of 60 proprietary headquarters, 480 distributors in 118 countries, and 1500 employees distributed all over the world.

Application Portfolio and IT function IT function consists of 36 employees worldwide and has been created in 2010, when Company 2 decided to start a project of digitalization with the aim of centralizing and consolidating management and provision of systems and applications services. Company’s application portfolio is large and heterogeneous, including more than 100 applications available through a Private Cloud managed on internal data centers.

Project: company needs and technological solution Technological trends, such as consumerization and industrialization of IT services, are significantly impacting on the Home & Building Automation sector. In particular, market expectations in terms of services digitalization and automation is high. This has generated in Company 2 the need to reduce time-to-market and to make decisions more efficiently and effectively. The information system managed a huge amount of data and did not allow real time KPI monitoring, even for those measures that are critical for decision-making. Particularly, this information was computed with a delay of even some days, involving a too burdensome process. Therefore, the company decided to extend digitalization acquiring a solution able to elaborate data in real-time, even for complex processing. It decided to introduce SAP HANA and chose a partner to implement the project. The

133 Research findings, discussion and conclusions application is based on an in-memory database technology able to measure KPI in real-time, giving users a way to automate processes of information extraction and analysis.

Project management The project had a total duration of one year and was divided in various phases. The first step was the installation of servers certified for the use of SAP HANA, which have been deployed in a high reliability configuration in order to guarantee business continuity. The second step was the implementation of a SAP component able to guarantee real time data synchronization from Core Management System to SAP HANA. Then, Company 2 involved specific business areas (Operations, Logistics, Purchasing) to identify KPIs and relative data to use. Finally, it carried out configuration and realization of data integration and aggregation logic on SAP HANA. The introduction of this solution required to reinforce IT function and LoBs competences on in- memory database management and Data Intelligence. From an organizational point of view, the project had a significant impact since it was necessary to redesign operational strategies and information flows for decision-making. Indeed, in order to benefit from in-memory technologies, it is necessary to align information management logics with SAP HANA logics.

Benefits The main perceived benefit has been the introduction of best practices in using data and information that enabled the evaluation of critical KPIs from a business viewpoint.

Criticalities The company initially faced the challenge of identifying the right time window of KPI assessment: in fact, since data became dynamic, there was the risk of abusing them with a consequence of ineffective support to decision-making.

Next steps Company 2 is now evaluating to enlarge the number of KPIs managed by SAP HANA, with the aim of using it also for predictive analysis in Sales business area.

134 Research findings, discussion and conclusions

7.4. Company 3

Company profile Company 3 operates in the Italian market since 90s as a leader in the Fashion industry. It consists of 800 employees and has one of the highest growth rate in the sector. Its products are distributed all around Europe, Russia, Middle East and Asia through 58 owned boutiques, a wholesale channel, a franchising, and an e-commerce channel.

Application Portfolio and IT function Company 3 IT function consists of 15 employees, organized according to three areas: application development and maintenance, infrastructure management, and business intelligence and analytics. The IT function objective is to achieve a central role in fostering innovation in the company, with a proactive approach in supporting business processes.

Its application portfolio is heterogeneous and managed according to three main scopes:  Customer management, including CRM, store management, e-commerce and order collection systems;  Product management, including PDM and CAD systems;  Management systems, including accounting, treasury management and SCM systems.

Project: company needs and technological solution Top management wanted to improve digital support to wholesale channel through the introduction of a salesforce automation tool. The aim was enriching user experience during a sale process, moving from a traditional transactional application to a more dynamic instrument. Therefore, company started a project called “Virtual Showroom” with the aim of introducing a solution combining functionalities of schedule management, customers profile management, purchases history monitoring and budget sharing with the central headquarter. To improve User Experience, functionalities suggesting possible related products of a purchase have been introduced. Moreover, each product description has been enriched by pictures with different varieties and colors. Additionally, this application can be accessed by users through mobile devices.

135 Research findings, discussion and conclusions

Project management The project started in December 2015 with a predicted go live in May 2016, in parallel with 2017 spring-summer campaign. In order to respect this time objective, the company, partnering with a solution vendor, identified key organizational figures for functionalities requirements definition, such as salesforce, agents, customer service, merchandising and graphic office. Key users have been involved in solution design and testing. The new application has been integrated with PDM and analytics systems. From an organizational viewpoint, personnel followed specific training activities through courses and video tutorials. Finally, once launched and exploited the solution for the first campaign, a survey was subjected to all the users in order to assess project quality in terms of help desk timeliness, training completeness and user experience. The overall users’ satisfaction has been high and, despite the significant organizational impact of the solution, there were no particular resistances.

Benefits Thanks to the new digital support, Company 3 is now able to better control salesforce suggesting related and coordinated products to sell.

Criticalities The only problem faced during the project has been an unexpected complexity of requirements analysis that caused a budget overrunning.

Next steps As a future evolution, Company 3 is evaluating to integrate this solution with data on products availability from the Management System. This integration could extend the usage of the solution to flash campaigns, which are based only on available products.

136 Research findings, discussion and conclusions

7.5. Company 4

Company profile Company 4 is an Italian regional administration offering services to 6 million inhabitants. It consists of various offices directly responding to political summit and General Directions.

Application Portfolio and IT function Its IT services are managed by an external office which represents its IT function.

Project: company needs and technological solution In order to improve its offer towards citizens, professionals and companies, Company 4 started a project for its first Geographic Public Cloud. The solution is a SaaS, accessible through mobile devices, able to digitalize processes related to territorial governance, to simplify territorial knowledge management flows, to support the General Direction in decision making, and to publish regional geographic information in an Open Data logic. The project is part of a greater evolution roadmap aimed at migrating all the regional infrastructures to the Cloud, in order to have shared tools, data and services. The new platform consists of:

 A Data Hub that will be the only access point to regional data, in which data generated by different offices will be georeferenced in different information layers;  A Decision Support System (DSS) that aims at supporting strategies definition through traditional charts and dynamic cartographic maps, even using predictive analysis;

 A Collaboration functionality aimed at sharing data and information to combine evaluations and observations from different viewpoints.

Project management The project started in October 2015 and will be finished by 2017. From an organizational viewpoint, involved actors are provided training activities, especially specific users who become data domain expert. The organizational impact of the project is significant, since it involves the creation of new competences and responsibilities, the selection and certification of regional databases, and the monitoring of data quality. In order to face the risk of organizational resistance, Company 4 dedicated a large part of project budget to specific change management support activities for final users, like workshops and training courses through an e-learning platform. From a

137 Research findings, discussion and conclusions technological point of view, it was necessary to adapt current infrastructures integrating the platform with existing applications and information systems. The platform is already used in some offices with a good diffusion among users also thanks to a beta tester that contributed to the creation of awareness about the solution existence and potentialities.

Benefits The platform is involving benefits in terms of quality and transparency of company’s services, rapid access to information, increased accessibility to public services, enriched personalization of user interfaces, and improved procedures monitoring thanks to standardization.

Criticalities As already described, the main expected challenge is related to organizational resistance and competences creation, for which specific activities have been carried out.

Next steps Thanks to the platform open nature, it is possible to specialize the solution to more vertical scopes, like fire emergency and cultural goods management. Moreover, company expects to integrate the platform with smart objects, such as drones, in order to support regional strategy formation through predictive analysis.

138 Research findings, discussion and conclusions

7.6. Final remarks We resumed what emerged from case studies in the following table, which shows results with a more comprehensive vision.

COMPANY 1 COMPANY 2 COMPANY 3 COMPANY 4

Sector Manufacturing Manufacturing Manufacturing Public Sector

Home & Building Pest control systems Automation systems Fashion collections Activities Services to citizens production design and for women production

IT function size 1 employee 36 employees 15 employees External

Application 3 applications 100 applications 9 applications N.A. portfolio size

Virtual Showroom Social Collaboration In-memory database Geographic Project for wholesale solution solution Public Cloud channel

Sponsor IT function Lines of Business Top Management Lines of Business

Data Intelligence, User Experience, Collaboration, Involved Trends Collaboration Data Intelligence Mobility Open Application, Mobility

No, but key users’ Usage of Methodologies involvement in innovative adoption is under No No requirements methodologies evaluation definition

Quality and transparency of Processes efficiency, Introduction of best services and optimization of practices for Better monitoring information, easier Project benefits collaborative flows, information access, on sales access to reduced amounts of improved decision- information, e-mails making collaborative information sharing

Organizational Lack of features, Competences about Difficult resistance, Project criticalities small resistance by dynamic data requirements competences few users management analysis creation

Application Present and updated Present and updated Absent N.A. mapping at every change at every change

Investments in modern No investments N.A. N.A. N.A. architectures

EA presence Absent Absent Absent N.A.

Table 13 Case studies roundup

139 Research findings, discussion and conclusions

8. Discussion on findings Trying to derive some insight about the previous analysis, we integrated quantitative results coming from the research survey with some qualitative reflections emerged from case studies, during thematic workshops organized by Enterprise Application Governance Observatory, and discovered from literature review.

Firstly, from survey results analysis, we can conclude that companies of the sample are not giving a high economic priority to Information Technology since the majority of the sample is investing in it less than 1.5% of turnover (72%). Moreover, even companies that are able to spend a high percentage of turnover in IT, are not spending a large amount of it in digitalization and innovation. In fact, the 52% of the sample invests less than 15% of IT spending in digitalization. This is strange in the light of what emerged from literature review about the incidence of digital revolution on business: investments in digitalization are today fundamental for companies’ competitiveness and the fact that they are not investing seems incoherent. The reason is probably that their investments are focused into aligning complex, stratified and fragile Information Systems with business needs. As companies have to face a transformation led by the pervasiveness of technology, IT departments are becoming more than a simple support process, sharing projects responsibility with LoBs, resulting in an IT competence more diffused and diluted throughout the company. However, diffused IT competence can also lead to undesired consequences when responsibility of projects becomes too unbalanced towards Lines of Business that decide to bypass IT function, causing the so-called shadow IT. We defined companies with a shared IT projects responsibility as “IT Collaborative” and found out that they represent the 58% of the sample: fortunately, those involving IT department just marginally in IT projects are just the 5%; this could be a signal that shadow IT is under control.

Outsourcing is quite spread in the sample, the majority of companies is giving outside both Application and Infrastructure management. As outsourcing is very frequent despite of IT function employees, probably companies are using outsourcing to reduce complexity and cost of internal assets management, and to innovate their processes with a lower time-to-market.

We based our subsequent analysis on a proposed clustering, made according to IT spending on turnover and investments in digitalization, since we wanted to discriminate companies which are advanced in terms of digital transformation as those that are able to spend a good part of turnover in IT and invest this amount primarily in digitalization. Therefore, determining which companies

140 Research findings, discussion and conclusions are actually moving towards digital transformation, we identified three groups: “Weakly digital oriented” (42% of the sample), “Medium digital oriented” (40%), and “Strongly digital oriented” (18%) companies. “Weakly digital oriented” companies are mostly SMEs, while LEs are mainly “Medium digital oriented”. This orientation strongly depends on companies’ sector; in particular, Finance and Wholesale & Retail have the largest part of companies “Strongly digital oriented”. Regarding Finance, processes are mainly IT-based and, therefore, it is normal that they are embracing digitalization. Concerning Wholesale & Retail, strong digital orientation could instead be related to the incidence of multichannel strategy on marketing and store configuration; we thus expected a good interest of these companies in Data Intelligence, which is confirmed by following considerations. It is also interesting to notice that Public Sector & Healthcare companies are fitting the tendency emerged from literature review, in which they emerged as backward in Digital Transformation compared to the others, since they are slowly adapting to technological progress and digitalization. In fact, it is the industry with the smallest number of “Strongly digital oriented” companies, but also the one with the highest number of “Medium digital oriented” ones, confirming that the situation is still evolving. “Strongly digital oriented” group turned out to be also the one with the largest IT staff, confirming that it is giving economic priority to IT processes. Indeed, as found out during the vertical workshop on the Fashion Industry organized by the Observatory, it is common that companies, having lack of budget, seek to cut IT budget since it is considered just a support process more expendable than the core ones. For example, one of the present Fashion companies complained a staff cut that reduced the IT function from 40 to 7 employees in just one year. This clustering will be used for following considerations about IT management.

The first analysis direction followed by the Observatory aims at quantifying how much Italian companies’ application portfolio evolution choices are impacted by emerging technological trends. In the empirical analysis, we presented results from the research survey and now we try to integrate them with qualitative cue coming from the thematic workshop “Trends that are changing application portfolio choices”. Generally, the identified technological trends are traversal to the various application scopes and are influencing criteria used by companies to select applications and their evolution roadmap. In order to define which trends are the most impacting ones, we carried out an evaluation based on 4 parameters taking into account different survey questions, as detailed in chapter 6. We obtained a radar chart with a score going from 1 to 4, as shown in Chart 26. The result is that Collaboration, User Experience and Mobility are top influencing trends, followed by Data Intelligence, Open Application and Pervasive Computing. Again, the situation significantly changes according to companies’ sector; while Manufacturing and Service & Utilities are very interested in Open

141 Research findings, discussion and conclusions

Application, probably due to Industry 4.0 phenomenon, Wholesale & Retail sector is very impacted by Data Intelligence due to omnichannel strategy and interrelations between physical and digital touchpoints in customers’ journey, as expected. In the same way, Data Intelligence is important for Healthcare because of the importance of digitalizing patients’ data.

Beside this overall vision on the matter, it is interesting to detail the impact of each trend on different application scopes in a portfolio, as shown in Chart 25. In particular, Collaboration is traversal to the value chain, impacting companies both internally and externally, towards suppliers and customers. Indeed, its influence is perceived more on Supplier Facing Application, Supply Chain Management, Office Automation and Human Resource Management. The importance companies give to this trend may be related to the fact that it enables them to enrich structured processes with collaborative interactions among different actors, avoiding the use of separated systems such as emails; indeed, the abuse of these systems is terribly reducing processes productivity due to time and information lost in emails and meetings. Therefore, this trend requires a massive organizational change, both in processes management and behavioral models.

Looking at User Experience, it is very significant in terms of designing and developing an application, since the aim is enabling users to achieve their objectives in a simple, fast and natural way. This trend, traditionally more impacting on customers’ experience, now is gaining momentum even inside the company, since it increases personnel productivity. In fact, its impact is mainly perceived on Customer Facing Application, Human Resource Management, Core Management Systems and Office Automation systems. Again, it requires a huge organizational change since it involves a collaboration between developers and key users to identify their real needs and get their immediate feedbacks. This reflection anticipates the subsequent analysis on Agile methodologies to manage IT projects, confirming that technological trends are fostering an internal change of IT function role and processes.

Concerning Mobility, which is changing the way applications are accessed by users, it is impacting not only on those applications thought for customers, as expectable, but also on those devoted to internal use, since it is enabling new working styles that improve productivity and timeliness. Indeed, its main impacts are on Customer Facing Applications, Customer Relationship Management and Office Automation.

Data Intelligence follows the first three impacting trends with a break of nearly 1 point in our scale, even if, as seen before, this varies a lot according to different sectors. Probably the reason for this

142 Research findings, discussion and conclusions interest reduction is that this trend is more complicated and difficult to understand in all its potential. Data are increasing in amount, volume and heterogeneity. They are coming from touchpoints with customers, social networks, smart devices, open data and many other sources. Extracting value from them is fundamental to improve companies’ performances: they enable more advanced analysis, even predictive and prescriptive, make possible to automate processes in real time, and create new business models and services. However, to exploit this opportunity, it is necessary to change internal systems architectures and infrastructures. In fact, as deepened in the third section of analysis, focusing on Enterprise Architecture, a systemic and structured evolution of architecture is needed to correctly manage technological trends impact keeping business and IT aligned. As expected, Data Intelligence impacts more on choices about Enterprise Information Management, Core Management Systems and Customer Relationship Management.

Moving to Open Application, the trend related to the opportunity of having interconnected business processes, both inside and outside the company, blurring its boundaries, on average it is considered less impacting. Probably, the reason is that it is difficult to orient a strategy understanding all its impacts on applications development and integration; indeed, this trend impacts on applications architecture and integration, since they have to be open and structured in simple and standard services, and it is not easy to manage since technologies are numerous and various. Open Application is mainly impacting on Supplier Facing Applications and Industry Verticals.

Finally, Pervasive Computing is the least impacting trend, probably since it is evolving and its consequences will be clear only in the future. Therefore, its influence on portfolio choices is only marginal and mainly concentrated on Industry Verticals and Supply Chain Management. This trend will enable more efficient and effective processes and new business models, but will also require companies to manage a heterogeneous and disperse hardware portfolio, introducing new challenges for network infrastructure and security.

As shown in Chart 24, internal sponsorship for the trends is mainly concentrated in the hands of IT function, even if frequently shared with LoBs, especially for those trends related to technologies consumerization, employees’ lifestyle and way of working, such as Mobility and User Experience. Top Management sponsorship is slighter but anyway important for Mobility, Collaboration and Data Intelligence trends, probably for a purpose of increasing employees’ productivity, processes efficiency and effectiveness, and introducing new services, since these improvements have clear economic implications. Finally, it is interesting to notice that the most impacting trends are also those with a shared sponsorship.

143 Research findings, discussion and conclusions

Once analyzed which technological trends are impacting on application portfolio evolution and how they are impacting on it, we deepened new roles and processes of IT function detailing the Agile methodologies. This part was divided according to IT projects phases: analysis and planning, development and deployment. As shown in Chart 27, even if a large part of companies does not use these innovative methodologies in any project or are just evaluating them, there is a significant part of enterprises using them at least for few projects. Their diffusion changes significantly according to the different projects phases: methodologies for analysis and planning are the least exploited, while those for development are the most spread. Avoiding the division in three phases, the main limit to adoption is the lack of knowledge and technical competences about the methodologies. As shown in Chart 30, motivations of adoption change a lot among different project phases: for analysis and planning, the main motivation is higher control on project activities, for development it is higher timeliness of response to business, and for deployment it is higher operational efficiency.

Generally, moving from traditional waterfall-based methodologies to the agile ones requires a deep change that involves creating new internal competences: the rigorous application of methodologies is fundamental to the success of initiatives in inexpert teams. In fact, also during the thematic workshop “Role of IT function and management of internal processes”, challenges of moving from traditional waterfall models to innovative methodologies emerged turning out to be again mainly related to competence and knowledge. However, analyzing those companies which are successfully facing this change, they are able to combine high commitment by IT managers and a structured approach based on pilot initiatives that have been extended gradually to other areas. Moreover, a mindset evolution is critical to success: IT function, LoBs and Top Management have to embrace this change sharing a common vision. Indeed, new models promote intensive collaborations between actors who generally work in different units with various and diverse cultures, languages and objectives; even if a large part of companies is using methodologies at least in one phase of the IT projects, just 14% of companies are using all the methodologies during the entire project, proving that just a small slice of the market is in a state of maturity.

Beside this generally backward situation, there is a positive signal: the majority of companies (75%) is introducing organizational changes in the IT function, as shown in Chart 28, and particularly in terms of processes, methodologies and working models with LoBs. Therefore, we can conclude that companies are not steady: they understand the significance of this change in order to win over the challenge of digital transformation.

144 Research findings, discussion and conclusions

Moving to the last analysis direction followed by the Observatory, it is related to the evolution of application architecture and its management through tools like Application Portfolio Management and Enterprise Architecture. As shown in Chart 31, the majority of companies turned out to have an interest in APM, having a frequently updated application mapping. Moreover, the majority of them is investing, even if discontinuously, in some cases, in architecture evolution and rationalization, as shown in Chart 32. The situation is different for Enterprise Architecture, in which, due to low management commitment and lack of budget, companies are quite backward. Anyway, the 34% of the sample has an organizational unit dedicated to EA, even if recently introduced, and perceives benefits from a correct management of EA flexibility of IS, uniformity of architectural choices and reduced complexity of application portfolio. Therefore, if correctly managed, EA can provide an improved business-IT alignment and a base for rationalize application portfolio.

During the thematic workshop “How Information Systems architectures are evolving”, the Enterprise Application Governance Observatory tested a framework describing companies’ application architecture according to six areas (see Annex D):

 Architectural Paradigms;  Integration models;  Data Management;  Architectures Governance;  Development Frameworks;  Application Services Sourcing.

For what concerns Architectural Paradigms, as already seen in the literature review, companies have seen an evolution from monolithic architectures, to centralized SOA, to modern microservices. Monolithic architectures turned out to be widespread and mainly related to traditional legacy systems, while centralized SOA architectures are spread in those organizations having suffered from complex management of monoliths, such as Finance companies and multinational enterprises. Interest towards microservices is high in the market, since even centralized SOA started to be too rigid. Microservices are mainly under experimentation and are likely to become more diffused in the coming years.

Regarding the Integration Models, companies evolved from point-to-point integration, to Enterprise Service Bus, to more flexible logics related to API management which enable an easy integration also with external services. In fact, even companies using centralized ESB complained problems of

145 Research findings, discussion and conclusions integration causing anyway the appeal to point-to-point. Increasingly, companies are opening their integration models to API in order to gain flexibility and more interconnected processes.

In Data Management, companies are evolving from a silos approach, in which data were for exclusive use of single applications, to Master Data Management, which centralize them giving a single vision for the entire organization. Even this approach is frequently expensive and complex to realize, being unsuccessful in many cases. The evolution is Bounded Context, a more decentralized approach easier to manage even if it is likely to need some specific integrations. This approach is spread in those companies which skipped the stage of Master Data Management due to a lack of investment capabilities.

Moving to Development Frameworks, they evolved from basic languages to general purpose platforms able to abstract application complexity. However, this kind of platforms requires an intensive phase of training to be used and impose some limits to development. Therefore, the tendency is to move to easier and more specialized development frameworks combining the two mentioned approaches, guaranteeing a good modularity thanks to libraries and standard customizable configurations.

Looking at Application Services Sourcing, Cloud Computing is challenging the traditional on premise model, based on control and ownership of IT assets. Companies are anyway scared of migrating to SaaS services, since they have to manage too stratified legacy systems and want to maintain internal competence and control. This contrast can be solved through Hybrid Systems, which are gaining momentum in the market. This kind of systems are able to combine advantages coming from the two approaches.

Concerning Architectures Governance, interest in EA is growing and many companies tried to create dedicated organizational units, frequently unsuccessfully. The reason is that organizational units’ risk to be too theoretical and far from project’s needs. For many companies, the solution is making architects more introduced in project’s activities in order to give guidelines for architectures maintaining control on technical debt and evaluating specific trade-offs.

Once got quantitative and qualitative insights on IT function and EA role in companies, we tried to evaluate how the market is positioned in terms of IT governance, according to four parameters (valued from 1 to 4) based on the usage of innovative working methodologies, APM, evolution of software architectures and EA, as shown Table 12. The evaluation was made combining questions in the survey in order to have an overall vision on the market.

146 Research findings, discussion and conclusions

Firstly, we computed the evaluation for the entire market finding what we already commented: as shown in Chart 37, market is rather advance in terms of APM and Software Architectures, while more backward regarding EA and innovative methodologies. As shown in Chart 38, LEs are clearly more advanced compared to SMEs. Detailing the analysis for the proposed clusters of digital orientation, “Strongly digital oriented” companies are more advanced compared to other groups even if the difference is slight, as evident from Chart 39. Therefore, higher investments in IT and particularly in digitalization do not necessarily result in managing IT in a better way. Moreover, looking at the entire sample, even if divided into three clusters, the market results mediumly positioned, without giving particular insights about the presence of companies which are truly advanced in the matters.

Therefore, we analyzed the situation of each company, finding advanced and backward cases, as shown in Chart 40. Just the 12% of the sample can be considered advanced in the overall IT governance, with a score between 3 and 4 in all the parameters. However, as a positive signal, just 14% of companies can be considered as backward with a score between 1 and 2 in all the parameters. Advanced companies are mainly LEs and belong to Wholesale & Retail sector, while backward ones are mainly SMEs and belong to Manufacturing sector. Then, we tried to group the remaining companies with a similar score profile, in order to identify other possible tendencies. We found 6 similar groups with a numerousness between 5 and 15 companies. These cases are mediumly positioned, with some areas of success and some other of backwardness. For example, the most numerous one (12% of the sample) is quite advanced in modern architectures and APM, while very similar to the backward group in innovative methodologies and EA. Despite our effort in grouping companies according to IT governance situation, a remaining 24% of them have too heterogeneous profiles in each evaluation parameter, making it impossible to identify other tendencies. Therefore, we can conclude that there is not a general trend describing the sample’s IT governance, even if it is clear that the way is still long to become advanced achieving all the advantages this means to business. In fact, it is interesting to see the relation between IT governance and economic results of companies: as shown in Chart 45, advanced companies turned out to have better results in terms on turnover per employee when compared to those of backward ones. This is a slight confirmation of the importance that IT and business alignment represents in terms of competitiveness. Even if this analysis should be detailed in terms of IT expenditure and governance peculiarities, this result tells us that IT cannot be seen any more as a mere support to business but it is becoming the business itself.

147 Research findings, discussion and conclusions

Finally, we tried to derive confirmations about the previous findings analyzing 4 case studies. We found some acknowledgements; firstly, all the companies have a small IT function: one has no internal IT, all the services are outsourced, another has just 1 employee managing IT, while the remaining have less than 40 employees. Their application portfolio is heterogeneous and impacted by many technological trends: Collaboration, Data Intelligence, Mobility, User Experience and Open Application are the main significant in terms of portfolio evolution choices. Moreover, one company is planning to extend the solution functionalities through the integration with smart objects, thus evolving towards Pervasive Computing. Each company has introduced a new software solution in order to benefit from the introduction of these trends in their business. Therefore, the importance of embracing new technological trends is perceived by Italian companies, which are trying to adapt even if often with a lack of structure in managing the change.

Companies that introduced these solutions perceived a strong impact on business results: introducing digitalization in processes like sales, knowledge management and project management, they improved efficiency and effectiveness, transparency and quality of information, activities monitoring, and decision-making. All these consequences have clear economic implications and impacts on competitiveness. As already stated, the main challenge to digitalization is the creation of competence in order to exploit all the advantages coming from new technological solutions. Moreover, since IT trends strongly impact on people way of working, an effective change management is fundamental to project success.

148 Research findings, discussion and conclusions

9. Conclusions Conclusive considerations aim at highlighting results in order to give an answer to research objectives that guided the present paper.

The preliminary objectives were focused on literature review, since the matter is rather new and it was difficult to find scientific documents summarizing all the directions of analysis. Therefore, the first purpose was identifying those emerging IT-enabled business trends that are leading companies to rethink their approach to IT management.

We identified ten main trends, emerged in the recent years:

 Social matrix, in terms of introducing in companies’ social platforms to communicate and share information in order to improve processes efficiency and effectiveness;

 Internet of All Things, related to the explosion of smart objects in our every-day life and the consequent growth of data available for companies to improve process monitoring and optimization;  Big Data and analytics, referred to availability of abundant and diverse data to be processed in real-time, in order to develop insights and inform decision-making;  Realizing anything as a service, related to internet-based models for acquiring IT resources in a pay-as-you-go approach;  Automation of knowledge work, referred to machine learning and natural user interfaces to automate processes;

 Integrated physical/digital experience, linked to people habits of migrating their every-day activities, like shopping, in virtual spaces, also thanks to mobile devices and user-friendly mobile applications;

 Me + free + ease, related to customers’ expectations in terms of interaction with companies in the internet era;

 The e-volution of commerce, related to the growth of e-commerce thanks to mobile internet and technologies simplifying online transactions;

 The next three billion digital citizens, referred to the explosion of connected people and the consequent impact on developing economies;  Transformation of government, health and education thanks to internet and sophisticated IT tools, which is slower if compared with other sectors;

149 Research findings, discussion and conclusions

Keeping a focus on application portfolio evolution, Enterprise Application Governance Observatory identified six trends able to resume all the considerations emerging from this part of literature review: Collaboration, Mobile, User Experience, Data Intelligence, Open Application and Pervasive Computing. These comprehensive trends have been the base for our analysis.

Once recognized the main emerging IT trends, we analyzed their impact on companies in the so- called Digital Transformation. In fact, the unprecedented convergence of these trends is forcing companies to rethink Information Systems and application portfolio in order to be able to exploit opportunities coming from digitalization. This change requires a different approach in managing IT resources in various directions. First of all, company needs to become adaptive, aligning IT resources provisioning to real business needs. In order to achieve this result, it is important to correctly manage Enterprise Architecture, which is a tool aimed at supporting enterprise transformation process keeping business and IT aligned. In fact, EA management creates architectural descriptions of current, planned, and future states of the enterprise. Improving IT governance, which means efficiently managing IT rationalizing resources and aligning decisions with business strategy is crucial for successfully managing EA. IT governance can be achieved through:  IT Portfolio Management, which means having a clear idea of company’s IT resources and the value they bring to business, in order to make better decisions;  Agile Methodologies to manage IT projects, as they allow rapid and effective development of applications;  Investments for rationalizing and evolving Information Systems Architectures towards modern and flexible architectures, like microservices and API management platforms.

This requires to change the organizational mindset towards a more collaborative approach between business and IT, and to introduce new competences and organizational roles, such as Enterprise Architects. A top-down sponsorship of this organizational transformation could be a critical success factor.

All the tools we have mentioned for IT management have not been recently invented, but are only now gaining momentum since companies need an IT transformation to survive. Indeed, years of unstructured and sequential approach to change have resulted in complex and fragile Information Systems that are no longer able to provide value keeping the pace of technological progress, consumerization, and the consequent new improved performances required to IT.

150 Research findings, discussion and conclusions

Once identified critical factors to analyze, we defined the objectives of empirical analysis. Firstly, we wanted to understand how Italian companies are coping with Digital Transformation in terms of processes digitalization. Therefore, from survey results, we segmented companies according to their IT spending on turnover and the percentage of this amount invested in digitalization. We found out that, according to this measure, the majority of the sample has a weak orientation towards Digital Transformation, not giving it an economic priority among other IT expenditures. That is probably related to the general mindset of considering IT as a support process, more expendable than the core ones: from the workshops emerged that, while IT budget and staff size has been significantly cut down over recent years, IT is required to deliver more value; prioritizing investment through a portfolio management approach is thus crucial. Another problem limiting investments in digitalization could also be to the complexities that companies are facing in managing fragile Information Systems, deriving from traditional ways of managing IT.

The second objective was to identify which emerging technological trends are mostly impacting on Italian companies’ decisions about application portfolio evolution. The main impacting are Collaboration, User Experience and Mobility, even if with different weights according to each application scope. The most important trends are also those with the most shared sponsorship between IT, Top Management, and Lines of Business. Particularly, Top Management promotes trends having economic implications (Mobility, Collaboration, Data Intelligence), while Lines of Business foster trends leading to an improvement of their tools and ways of working (Mobility, User Experience).

Finally, the last two objectives were related to understanding Italian companies state-of-the-art in terms of IT governance and Enterprise Architecture. Therefore, we developed an evaluation framework consisting of 4 parameters based on: presence of Application Portfolio Management, investments in architectures evolution and rationalization, usage of Agile Methodologies, presence of Enterprise Architecture. The result is that companies are generally mediumly positioned, nor being particularly successful or backward. However, it is difficult to identify an overall tendency since groups with similar score profiles in all the 4 parameters have a low significance in terms of companies’ number; therefore, companies can be highly advanced in one parameter, and completely backward in the others. Anyway, a positive signal is that completely backward companies represent a low number, even if it is the same for advanced ones; moreover, the 75% of the sample is introducing organizational changes in IT function, confirming that the urgency of this transformation is perceived. From case studies and workshops, we found out that the main

151 Research findings, discussion and conclusions challenges to the change are the introduction of new competences and the effective management of organizational resistances since a mindset evolution is required.

As a conclusive reflection, in results, we found a confirmation about the strict relation between IT and business, making clear that Information Technology cannot be seen any more as a mere decoupled support to business, working during the night to ensure business can run the day after. In fact, results show that IT-business alignment has become essential for companies’ competitiveness, having impacts on their economic results. Indeed, we found a slight correlation between companies’ state in IT management and their results in terms of turnover per employee, even if this aspect should be deepened through a future research. Moreover, from case studies, we recorded strong positive effects of technological solutions related to new emerging technological trends on business processes.

152 References

List of references Bibliography

Aalst, W. v. d. & Hee, K. v., 2004. Workflow Management: Models, methods and systems. s.l.:The MIT Press.

Abrahamsson, P., Babar, M. A. & Kruchten, P., 2010. Agility and Architecture: Can They Coexist?. IEEE Software, 27(2), pp. 16-22.

Agile Alliance, 2015. The agile root of devops. [Online] Available at: https://www.agilealliance.org/the-agile-root-of-devops/ [Accessed 9 10 2016].

Akselrod, A., 2016. Managed services killed DevOps. [Online] Available at: https://techcrunch.com/2016/04/07/devops-is-dead-long-live-devops/ [Accessed 10 09 2016].

Ali, R., Dalpiaz, F. & Giorgini, P., 2010. A Goal-based Framework for Contextual Requirements Modeling and Analysis. Requirements Engineering, 15(4), pp. 439-458.

Alter, S., 2002. The Work System Method for Understanding information systems and information system research. Communications of the Association for Information Systems.

Ambler, S. W., 2014. User Stories: An Agile Introduction. [Online] Available at: http://www.agilemodeling.com/artifacts/userStory.htm [Accessed 7 10 2016].

Anton, A. I., 1996. Goal-Based Requirements Analysis. ICRE '96 Proceedings of the 2nd International Conference on Requirements Engineering, p. 136.

Beck, K., 1999. Extreme programming explained: embrace change. Boston: Addison-Wesley Longman Publishing Co..

Beck, K. et al., 2001. Manifesto for Agile Software Development. [Online] Available at: http://agilemanifesto.org/

Bennington, H. D., 1987. Production of large computer programs. ICSE '87 Proceedings of the 9th international conference on Software Engineering, pp. 299-310.

153 References

Berinato, S., 2001. Using Project Portfolio Management to Demonstrate IT Value. [Online] Available at: http://www.cio.com/article/2441263/it-organization/using-project-portfolio- management-to-demonstrate-it-value.html [Accessed 2 11 2016].

Bils, S., 2015. EMC InFocus - Rewrite, replatform, retire: what's your application transformation strategy?. [Online] Available at: https://infocus.emc.com/scott-bils/rewrite-replatform-retire-whats-your- application-transformation-strategy/ [Accessed 13 Agosto 2016].

Birrell, N. D. & Ould, M., 1985. A practical handbook for software development. New York: Cambridge University Press.

BloombergGadfly, 2016. Technology Conquers Stock Market. [Online] Available at: https://www.bloomberg.com/gadfly/articles/2016-08-02/tech-giants-form-fab- five-to-dominate-stock-valuation-chart [Accessed 2 9 2016].

Boehm, B. & Turner, R., 2004. Balancing Agility and Discipline. s.l.:Addison-Wesley.

Boehm, B. W., 1986. A Spiral Model of Software Development and Enhancement. ACM SigSoft Software Engineering Notes, 2(4), pp. 22-42.

Boer, R. C. d. & Vliet, H. v., 2009. Controversy Corner: On the similarity between requirements and architecture. Journal of Systems and Software , 82(3), pp. 544-550.

Boost, 2012. Use cases vs user stories in Agile development. [Online] Available at: http://www.boost.co.nz/blog/2012/01/use-cases-or-user-stories/ [Accessed 9 10 2016].

Bourgeois, D. T., 2014. Information Systems for Business and Beyond. s.l.:Saylor Foundation.

Brown, N. et al., 2010. Managing Technical Debt is Software-Reliant Systems, s.l.: s.n.

Bruna, S., 2015. Adaptive enterprise. Milan, MIP - Politecnico di Milano School of Management.

Brynjolfsson, E., Hitt, L. & Kim, H., 2011. Strength in numbers: How does data-driven decision making affect firm performance?, s.l.: Social Science Research Network.

154 References

Buchanan, R., 2010. Gartner - Enterprise Architecture Program. [Online] Available at: http://www.gartner.com/it/initiatives/pdf/KeyInitiativeOverview_EnterpriseArchitecturePlann ing.pdf [Accessed 26 Settembre 2016].

Business Dictionary, n.d. What is information system? Definition and meaning. [Online] Available at: http://www.businessdictionary.com/definition/information-system.html [Accessed 22 09 2016].

Carr, N. G., 2003. IT Doesn’t Matter. Harvard Business Review.

Cass, S., 2016. The 2016 Top Programming Languages. [Online] Available at: http://spectrum.ieee.org/computing/software/the-2016-top-programming- languages [Accessed 3 11 2016].

Castiglioni, F., 2012. IBM - Enterprise Architecture in the age of cloud services. [Online] Available at: http://www.ibm.com/developerworks/rational/library/enterprise-architecture- cloud/ [Accessed 23 Settembre 2016].

Centers for Medicare & Medicaid Services, 2008. Selecting a Development Approach. [Online] Available at: https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information- Technology/XLC/Downloads/SelectingDevelopmentApproach.pdf [Accessed 18 09 2016].

Chappell, D., 2008. What is Application Lifecycle management?, s.l.: Chappell & Associates.

Chused, B., 2014. EMC - In Focus. [Online] Available at: https://infocus.emc.com/ben_chused1/here-comes-the-4th-platform/ [Accessed 11 Luglio 2016].

Cimetrix, 2010. What is a Software Framework? And why should you like 'em?. [Online] Available at: http://info.cimetrix.com/blog/bid/22339/What-is-a-Software-Framework-And- why-should-you-like-em [Accessed 3 11 2016].

155 References

CIO, 2005. The Relationship Between Enterprise Architecture and IT Governance. [Online] Available at: http://www.cio.com/article/2448774/enterprise-architecture/the-relationship- between-enterprise-architecture-and-it-governance.html [Accessed 20 10 2016].

CIO, 2015. Why big companies need to become more entrepreneurial to survive. [Online] Available at: http://www.cio.com/article/3015451/leadership-management/why-big-companies- need-to-become-more-entrepreneurial-to-survive.html [Accessed 15 06 2016].

Clark, J., 2013. Colo, Hosting or Cloud: How Should You Outsource?. [Online] Available at: http://www.datacenterjournal.com/colo-hosting-cloud-outsource/ [Accessed 5 11 2016].

Clark, K., 2016. Microservices, SOA, and APIs: Friends or enemies?. [Online] Available at: http://www.ibm.com/developerworks/websphere/library/techarticles/1601_clark- trs/1601_clark.html [Accessed 6 11 2016].

Cunningham, W., 1992. The WyCash Portfolio Management System. OOPSLA '92 Addendum to the proceedings on Object-oriented programming systems, languages, and applications (Addendum), pp. 29-30.

Disciplined Agile 2.X, 2016. Lean IT Governance. [Online] Available at: http://www.disciplinedagiledelivery.com/agility-at-scale/it-governance/ [Accessed 1 11 2016].

Dreyfuss, C., 2014. Nexus of Forces, 2014: Unleashing the Power of Digitalization, s.l.: s.n.

Evans, N. D., 2012. The IT paradox: A diminishied role in technology, but greater clout in the business. [Online] Available at: http://www.computerworld.com/article/2503872/it-transformation/the-it- paradox--a-diminished-role-in-technology--but-greater-clout-in-the-business.html [Accessed 10 9 2016].

Fowler, M., 2014. BoundedContext. [Online] Available at: http://martinfowler.com/bliki/BoundedContext.html [Accessed 5 11 2016].

156 References

Fuggetta, A., 2000. Software Process: A Roadmap. Proceeding ICSE '00.

García-Borgoñóna, L. et al., 2014. Software process modeling languages: A systematic literature review. Information and Software Technology, 56(2), pp. 103-116.

Garlan, D. et al., 2010. Documenting Software Architectures: Views and Beyond. 2nd ed. s.l.:Addison- Wesley Professional.

Gartner, 2014. Taming the Digital Dragon: the 2014 CIO Agenda, s.l.: s.n.

Gartner, 2014. The Nexus of Forces: Social, Mobile, Cloud and Information. [Online] Available at: http://www.gartner.com/technology/research/nexus-of-forces/ [Accessed 11 Luglio 2016].

Gartner, 2016. Applications Portfolio Analysis (APA) - Gartner IT Glossary. [Online] Available at: http://www.gartner.com/it-glossary/application-portfolio-analysis/ [Accessed 1 11 2016].

Gartner, 2016. Architecture - Gartner IT Glossary. [Online] Available at: http://www.gartner.com/it-glossary/architecture/ [Accessed 4 11 2016].

Gartner, 2016. Bimodal IT, s.l.: s.n.

Gartner, 2016. Gartner IT Glossary. [Online].

Gartner, 2016. IT Governance (ITG) - Gartner IT Glossary. [Online] Available at: http://www.gartner.com/it-glossary/it-governance/ [Accessed 1 11 2016].

Genovese, Y., Nelson, S., Duggan, J. & Gaughan, D., 2009. Application Portfolio Management— Strategies to Successfully Overhaul Your Application Portfolio. s.l., Gartner.

Greene, J., 2016. What are Application Dependency Mapping Tools, and Why are they Critical to IT Operations?. [Online] Available at: https://www.cherwell.com/blog/what-are-application-dependency-mapping-tools- and-why-are-they-critical-to-it-operations [Accessed 2 11 2016].

157 References

Grönninger, H., Ringert, J. O. & Rumpe, B., 2014. System Model-Based Deﬁnition of Modeling Language Semantics, s.l.: Cornell University Library.

Harel, D. & Rumpe, B., 2004. Meaningful Modeling: What’s the Semantics of “Semantics”?. Journal Computer, 37(10), pp. 64-72.

Hinchcliffe, D., 2015. On Digital Strategy | Dion Hinchcliffe. [Online] Available at: https://dionhinchcliffe.com/2015/05/04/the-rise-of-the-4th-platform-pervasive- community-data-devices-and-intelligence/ [Accessed 11 Luglio 2016].

Hinkelmann, K. et al., 2015. A new paradigm for the continous alignment of business and IT: combining enterprise architecture modelling and enterprise ontology. Computers in Industry.

Howard, C. et al., 2012. Hybrid IT: How Internal and External Cloud Services Are Transforming IT. [Online] Available at: https://www.gartner.com/doc/1918214/hybrid-it-internal-external-cloud [Accessed 6 11 2016].

IT Governance Institute, 2003. Board Briefing on IT Governance, Rolling Meadows, IL: s.n.

IT Governance Institute, 2005. Optimising Value C Creation From IT Investments, Rolling Meadows, IL: s.n.

Jaakkola, H. & Thalheim, B., 2011. Architecture-Driven Modelling Methodologies. Proceedings of the 2011 conference on Information Modelling and Knowledge Bases XXII, pp. 97-116.

Jeffries, R., 2011. What is Extreme Programming?. [Online] Available at: http://ronjeffries.com/xprog/what-is-extreme-programming/ [Accessed 6 10 2016].

Kelly, A., 2016. ITIL – Agile IT Governance… What a Concept!. [Online] Available at: http://corgovinstitute.com/itil-agile-governance-concept/ [Accessed 1 11 2016].

Khan, A. & Balbo, S., 2004. A Tale of two Methodologies: Heavyweight versus Agile. [Online] Available at: http://ausweb.scu.edu.au/aw04/papers/edited/balbo/ [Accessed 3 10 2016].

158 References

Khan, A. I., Qurashi, R. J. & Khan, U. A., 2011. A comprehensive study of commonly practiced heavy and light weight software methodologies. IJCSI International Journal of Computer Science Issues, 8(4), pp. 441-450.

Kruchten, P., 2013. Agile architecture. [Online] Available at: https://philippe.kruchten.com/2013/12/11/agile-architecture/ [Accessed 3 11 2016].

Kuhl, J., 2002. Project Lifecycle Models: How They Differ and When to Use Them. [Online] Available at: http://www.business-esolutions.com/islm.htm [Accessed 26 09 2016].

Kurzweil, R., 2001. The Law of Accelerating Returns. [Online] Available at: http://www.kurzweilai.net/the-law-of-accelerating-returns [Accessed 16 06 2016].

Lapalme, J. et al., 2015. Exploring the future of enterprise architecture: A Zachman perspective. Computers in Industry.

Laudon, K. C. & Laudon, J. P., 2012. Management Information Systems: Managing the Digital Firm. 12th ed. s.l.:Prentice Hall.

Lichtenberger, A., 2014. Integrating Agile and ITSM. [Online] Available at: http://blog.itil.org/2014/07/allgemein/integrating-agile-and-itsm/ [Accessed 1 11 2016].

Mainetti, S., 2015. L'Adaptive Enterprise, s.l.: s.n.

Martin, J., 1991. Rapid application development. Indianapolis: Macmillan Publishing Co..

Mazzucco, M., 2015. Le leve organizzative per l'Adaptive Enterprise e la trasformazione della Direzione IT, s.l.: s.n.

McKenna, P., 2005. Modern Portfolio Theory: Driving project portfolio management with investment techniques. [Online] Available at: https://www.ibm.com/developerworks/rational/library/aug05/mckenna/ [Accessed 1 11 2016].

McKinsey Global Institute, 2013. Ten IT-enabled business trends for the decade ahead. [Online] Available at:

159 References http://www.mckinsey.com/~/media/mckinsey/industries/high%20tech/our%20insights/ten% 20it%20enabled%20business%20trends%20for%20the%20decade%20ahead/mgi_it_enabled_tre nds_report_may%202013_v2.ashx [Accessed 15 Luglio 2016].

Mell, P. & Grance , T., 2011. The NIST definition of Cloud Computing, s.l.: s.n.

Mell, P. & Grance, T., 2011. The NIST definition of Cloud Computing. [Online] Available at: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf [Accessed 14 Settembre 2016].

Microsoft, 2009. Architectural Patterns and Styles. [Online] Available at: https://msdn.microsoft.com/en-us/library/ee658117.aspx#KeyArchitectureStyles [Accessed 3 11 2016].

Microsoft, 2009. Layered Application Guidelines. [Online] Available at: https://msdn.microsoft.com/en-us/library/ee658109.aspx [Accessed 4 11 2016].

Mili, H. et al., 2010. Business Process Modeling Languages: Sorting Through the Alphabet Soup. ACM Computing Surveys (CSUR), 43(1).

MIT CISR, 2016. Enterprise Architecture. [Online] Available at: http://cisr.mit.edu/research/research-overview/classic-topics/enterprise- architecture/ [Accessed 10 9 2016].

Moitra, D. & Ganesh, J., 2005. Web services and flexible business processes: towards the adaptive enterprise. Journal Information and Management , 42(7), pp. 921-933.

Moore, G. E., 1965. Cramming more components onto integrated circuits. Electronics, 38(8).

Morisio, M., 2010. Agility and Architecture. [Online] Available at: https://www.computer.org/portal/web/computingnow/archive/april2010 [Accessed 3 11 2016].

Mountain Goat Software, 2016. Scrum Methodology and Project Management. [Online] Available at: http://www.mountaingoatsoftware.com/agile/scrum [Accessed 2 10 2016].

160 References

Mueller, L. M. & Phillipson, A., 2007. The emerging role of IT governance. [Online] Available at: http://www.ibm.com/developerworks/rational/library/dec07/mueller_phillipson/ [Accessed 3 10 2016].

Munassar, N. M. A. & Govardhan, A., 2010. A Comparison Between Five Models Of Software Engineering. IJCSI International Journal of Computer Science Issues, 7(5), pp. 94-101.

Murphy, T., 2011. Should we stop using the term ALM?. [Online] Available at: http://blogs.gartner.com/tom_murphy/2011/12/02/should-we-stop-using-the- term-alm/ [Accessed 2 11 2016].

Mykhashchuk, M., Buckl, S., Dierl, T. & Schweda, C. M., 2011. Charting the landscape of enterprise architecture management, s.l.: s.n.

New Relic, 2016. What is DevOps?. [Online] Available at: https://newrelic.com/devops/what-is-devops [Accessed 9 10 2016].

NH Learning Solutions, 2016. COBIT VS. ITIL. [Online] Available at: https://nhlearningsolutions.com/Blog/TabId/145/ArtMID/16483/ArticleID/1514/COBIT- vs-ITIL.aspx [Accessed 1 11 2016].

Niemann, K. D., 2006. From Enterprise Architecture to IT Governance. s.l.:Vieweg+Teubner Verlag.

Nuseibeh, B., 2001. Weaving Together Requirements and Architectures. Computer, 34(3), pp. 115- 117.

Nuseibeh, B. & Easterbrook, S., 2000. Requirements engineering: a roadmap. ICSE '00 Proceedings of the Conference on The Future of Software Engineering , pp. 35-46.

Open Group, 2011. Introduction to the ADM. [Online] Available at: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap05.html [Accessed 10 Luglio 2016].

Orbus Software, 2016. Information Systems Architectures. [Online] Available at: https://www.orbussoftware.com/enterprise-architecture/togaf/what-is-the-

161 References adm/phase-c-information-systems-architecture/# [Accessed 28 10 2016].

Orlando, T., 2015. DevOps: Is There One Definition?. [Online] Available at: https://www.3pillarglobal.com/insights/devops-one-definition [Accessed 9 10 2016].

Osservatorio Big Data Analytics & Business Intelligence, Politecnico di Milano, 2015. Il Journey verso i Big Data. Milano, s.n.

Osservatorio Cloud & ICT as a Service, Politecnico di Milano, 2011. Cloud & ICT as a Service: Fuori dalla nuvola!. Milano, s.n.

Osservatorio Cloud & ICT as a Service, Politecnico di Milano, 2012. Cloud Economy: ultima chiamata. Milano, s.n.

Osservatorio Cloud & ICT as a Service, Politecnico di Milano, 2016. Cloud: è arrivata l'età della ragione?. Milano, s.n.

Osservatorio Cloud & ICT as a Service, 2015. La gestione dei progetti Cloud e gli impatti sulla Direzione IT. Milano, s.n.

Osservatorio Enterprise Application Governance, Politecnico di Milano, 2016. Come cambiano il ruolo e i processi della Direzione IT. Milan, s.n.

Osservatorio Enterprise Application Governance, Politecnico di Milano, 2016. Come evolvono le architetture dei sistemi informativi. Milano, s.n.

Osservatorio Enterprise Application Governance, Politecnico di Milano, 2016. I trend che cambiano le scelte del portafoglio applicativo. Milano, s.n.

Osservatorio Social Business Collaboration, Politecnico di Milano, 2015. Social Business Collaboration: stato dell'arte e linee guida. Milano, s.n.

Oxford Economics, 2011. The New Digital Economy - How it will transform business, s.l.: s.n.

Parker, K., 2013. How does application portfolio management tie into ALM?. [Online] Available at: http://searchsoftwarequality.techtarget.com/answer/How-does-application- portfolio-management-tie-into-ALM [Accessed 1 11 2016].

162 References

Patel, J., 2016. Software is still eating the world. [Online] Available at: https://techcrunch.com/2016/06/07/software-is-eating-the-world-5-years-later/ [Accessed 12 9 2016].

Patton, J., 2008. The New User Story Backlog is a Map. [Online] Available at: http://jpattonassociates.com/the-new-backlog/ [Accessed 6 10 2016].

Piraccini, M. & Rossini, S., 2006. Architetture d‘Integrazione. [Online] Available at: http://www.mokabyte.it/2006/03/Integration-1/ [Accessed 5 11 2016].

Poppendieck, M., 2007. Lean Software Development. ICSE COMPANION '07 Companion to the proceedings of the 29th International Conference on Software Engineering , pp. 165-166.

Poppendieck, M. & Poppendieck, T., 2003. Lean Software Development: An Agile Toolkit. Boston: Addison-Wesley Longman Publishing Co..

Power, D. J., 2015. http://dssresources.com/glossary/116.php. [Online] Available at: http://dssresources.com/glossary/116.php [Accessed 30 10 2016].

Ralph, P., 2013. The illusion of requirements in software development. Requirements Engineering, 18(3), pp. 293-296.

Ralph, P., 2013. Why system requirements are a dangerous illusion. [Online] Available at: http://sdtimes.com/why-system-requirements-are-a-dangerous-illusion/ [Accessed 7 10 2016].

Rashid, M., Hossain, L. & Patrick, J., 2002. The Evolution of ERP Systems: A Historical Perspective, Enterprise Resource Planning: Global Opportunities and Challenges. s.l.:IGI Global.

Robertson, B., 2010. Infrastructure Portfolio Management (IPM) — APM for Shared Services. [Online] Available at: http://blogs.gartner.com/bruce-robertson/2010/02/09/ipm/ [Accessed 2 11 2016].

Romero, D. & Vernadat, F., 2016. Enterprise information systems state of the art: past, present and future trends. Computers in Industry, Issue 79.

163 References

Rouse, M., 2005. SearchDataManagement. [Online] Available at: http://searchdatamanagement.techtarget.com/definition/extract-transform-load [Accessed 23 Ottobre 2016].

Rouse, M., 2007. What is layer?. [Online] Available at: http://searchsoftwarequality.techtarget.com/definition/layer [Accessed 4 11 2016].

Rouse, M., 2011. SearchDataManagement. [Online] Available at: http://searchdatamanagement.techtarget.com/definition/NoSQL-Not-Only-SQL [Accessed 23 Ottobre 2016].

Rouse, M., 2011. What is Application Portfolio Management (APM)?. [Online] Available at: http://whatis.techtarget.com/definition/application-portfolio-management-APM [Accessed 2 11 2016].

Rouse, M., 2015. What is data silo?. [Online] Available at: http://searchcloudapplications.techtarget.com/definition/data-silo [Accessed 4 11 2016].

Rouse, M., 2015. What is Middleware?. [Online] Available at: http://searchsoa.techtarget.com/definition/middleware [Accessed 4 11 2016].

Rouse, M. & Martinez, C., 2015. What is IS (information system or information services)? - Definition from WhatIs.com. [Online] Available at: http://whatis.techtarget.com/definition/IS-information-system-or-information- services [Accessed 4 09 2016].

Royce, W. W., 1970. Managing the development of large software systems: concepts and techniques. Proceedings of IEEE WESCON, August, pp. 1-9.

Ruparelia, N., 2010. Models, Software Development Lifecycle. ACM SIGSOFT Software Engineering Notes, May.

164 References

Schwaber, K. & Sutherland, J., 2016. Scrum Guide. [Online] Available at: http://scrumguides.org/scrum-guide.html [Accessed 2 10 2016].

Schwartz, K. D., 2007. IT Governance Definition and Solutions. [Online] Available at: http://www.cio.com/article/2438931/governance/it-governance-definition-and- solutions.html [Accessed 1 11 2016].

Scrum Alliance, 2013. Creating an Agile Road Map Using Story Mapping. [Online] Available at: https://www.scrumalliance.org/community/articles/2013/august/creating-an-agile- roadmap-using-story-mapping [Accessed 6 10 2016].

Scrum Alliance, 2016. What is Scrum? An Agile framework for completing complex projects. [Online] Available at: https://www.scrumalliance.org/why-scrum [Accessed 3 10 2016].

Segue Technologies, 2012. The Evolution of Modern Programming Languages. [Online] Available at: http://www.seguetech.com/the-evolution-of-modern-programming-languages/ [Accessed 3 11 2016].

Sessions, R., 2007. Microsoft Developer Network. [Online] Available at: https://msdn.microsoft.com/en-us/library/bb466232.aspx [Accessed 7 Luglio 2016].

Shaw, M. J. & Nam, C.-B., 2007. IT Portfolio Management, s.l.: Center for IT and e-Business Management - University of Illinois.

Shekaran, C. et al., 1994. The Role of Software Architecture in Requirements Engineering. s.l., s.n.

Shuptar, D., 2012. IT Governance – What is It and Why is It Important?. [Online] Available at: http://www.digitalistmag.com/innovation/2012/05/07/it-governance-what-is-it- and-why-is-it-important-04961 [Accessed 1 10 2016].

Stacey, R., 1992. Managing the Unknowable: The Strategic Boundaries Between Order and Chaos. s.l.:Jossey-Bass.

165 References

Sutherland, J. V. & Schwaber, K., 1995. In: Business object design and implementation: OOPSLA '95 workshop proceedings. s.l.:The University of Michingan, p. 118.

Techopedia, 2016. IT Portfolio Management. [Online] Available at: https://www.techopedia.com/definition/27220/it-portfolio-management [Accessed 2 11 2016].

TechTarget, 2005. Adaptive Enterprise. [Online] Available at: http://searchcio.techtarget.com/definition/adaptive-enterprise-or-adaptive- organization [Accessed 06 Luglio 2016].

TechTarget, 2012. IT as a Service (ITaaS). [Online] Available at: http://whatis.techtarget.com/definition/IT-as-a-Service-ITaaS [Accessed 6 9 2016].

TechTarget, 2016. IT governance and legal compliance strategies for CIOs. [Online] Available at: http://searchcio.techtarget.com/feature/IT-governance-and-legal-compliance- strategies-for-CIOs [Accessed 1 11 2016].

The National Computing Centre, 2005. IT Governance Developing a successful governance strategy, Manchester: The National Computing Centre.

The Open Group, 2011. Phase C: Information Systems Architectures. [Online] Available at: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap09.html [Accessed 29 10 2016].

Thorp, J. & Leadership, F. C. C. f. S., 2003. The Information Paradox: Realizing the Business Benefits of Information Technology. s.l.:McGraw-Hill.

Tilkov, S., 2015. Why You Should Avoid a Canonical Data Model. [Online] Available at: https://www.innoq.com/en/blog/thoughts-on-a-canonical-data-model/ [Accessed 5 11 2016].

Trejo, D. A. M., 2015. After All These Years, the World is Still Powered by C Programming. [Online] Available at: https://www.toptal.com/c/after-all-these-years-the-world-is-still-powered-by-c-

166 References programming [Accessed 4 11 2016].

Tricentis, 2016. Testing the Missing Piece in DevOps. [Online] Available at: http://www.tricentis.com/solutions/devops/ [Accessed 9 10 2016].

Triumph, T., 2014. A Hypercompetitive World: Part 1 – Globalization & Technology. [Online] Available at: https://www.linkedin.com/pulse/20140821153342-20153120-a-hypercompetitive- world-part-1-globalization-technology [Accessed 15 6 2016].

Valacich, J. & Schneider, C., 2009. Information Systems Today: Managing in the Digital World. 4th ed. Upper Saddle River: Prentice Hall Press.

Van der Aalst, W. & Stahl, C., 2011. Modeling Business Processes: A Petri Net-Oriented Approach. s.l.:The MIT Press.

Varhol, P., 2015. The complete history of agile software development. [Online] Available at: http://techbeacon.com/agility-beyond-history%E2%80%94-legacy%E2%80%94- agile-development [Accessed 1 10 2016].

Vila, F., 2012. Turn Application Portfolio Management into a Governance Tool for the CIO, s.l.: MEGA.

Wähner, K., 2015. Do Good Microservices Architectures Spell the Death of the Enterprise Service Bus?. [Online] Available at: https://www.voxxed.com/blog/2015/01/good-microservices-architectures-death- enterprise-service-bus-part-one/ [Accessed 6 11 2016].

Walker, M., 2007. Integration of Enterprise Architecture and Application Portfolio Management. [Online] Available at: https://msdn.microsoft.com/en-us/library/bb896054.aspx?f=255&MSPPError=- 2147217396 [Accessed 2 11 2016].

167 References

Walker, M., 2007. Microsoft Developer Network - a day in the life of an Enterprise Architect. [Online] Available at: https://msdn.microsoft.com/en-us/library/bb945098.aspx [Accessed 28 Luglio 2016].

Weisman, R., 2011. An Overview to TOGAF Version 9.1. [Online] Available at: http://www.opengroup.org/public/member/proceedings/q312/togaf_intro_weisman.pdf [Accessed 10 Luglio 2016].

Wells, D., 2009. Agile Software Development: A gentle introduction. [Online] Available at: http://www.agile-process.org/ [Accessed 2 10 2016].

Wells, D., 2013. Extreme Programming: A gentle introduction. [Online] Available at: http://www.extremeprogramming.org/ [Accessed 6 10 2016].

Zachman, J., 1987. A Framework for Information Systems Architecture. IBM Systems Journal, 26(3), p. 276.

Zachman, J. A., 2015. Zachman International - Enterprise Architecture. [Online] Available at: https://www.zachman.com/about-the-zachman-framework [Accessed 7 Luglio 2016].

Zave, P., 1997. Classification of Research Efforts in Requirements Engineering. ACM Computing Surveys (CSUR), 29(4), pp. 315-321.

Zebra Technologies, 2012. Building Value from visibility. [Online] Available at: https://www.zebra.com/content/dam/zebra/white-papers/en-us/zebra-iot-report- en-us.pdf [Accessed 11 Settembre 2016].

Zwass, V., 2016. information system | Britannica.com. [Online] Available at: https://www.britannica.com/topic/information-system [Accessed 22 09 2016].

168 References

Wikipedia pages used for Chapter 5.3 (retrieved in November 2016)  Architectural pattern - https://en.wikipedia.org/wiki/Architectural_pattern  Client-server model - https://en.wikipedia.org/wiki/Client%E2%80%93server_model  Domain-specific language - https://en.wikipedia.org/wiki/Special- purpose_programming_language  Federated database system - https://en.wikipedia.org/wiki/Federated_database_system  In-house software - https://en.wikipedia.org/wiki/In-house_software  Integrated development environment - https://en.wikipedia.org/wiki/Integrated_development_environment  Mashup - https://en.wikipedia.org/wiki/Mashup_(web_application_hybrid)  Master Data Management - https://en.wikipedia.org/wiki/Master_data_management  Microservices - https://en.wikipedia.org/wiki/Microservices  Monolithic application - https://en.wikipedia.org/wiki/Monolithic_application  Multitier architecture - https://en.wikipedia.org/wiki/Multitier_architecture  Programming language - https://en.wikipedia.org/wiki/Programming_language  Service-oriented architecture - https://en.wikipedia.org/wiki/Service- oriented_architecture  Single sign-on - https://en.wikipedia.org/wiki/Single_sign-on  Software architecture - https://en.wikipedia.org/wiki/Software_architecture  Software design pattern - https://en.wikipedia.org/wiki/Software_design_pattern  Software development kit - https://en.wikipedia.org/wiki/Software_development_kit  Software framework - https://en.wikipedia.org/wiki/Software_framework  Software testing - https://en.wikipedia.org/wiki/Software_testing  System integration - https://en.wikipedia.org/wiki/System_integration

169 Appendix

Appendix

Annex A - Introduction to Information Systems As it is difficult to find a unique understanding of what an information system is, we report definitions from four different authoritative sources:

 “combinations of hardware, software and telecommunications networks that people build and use to collect, create, and distribute useful data, typically in organizational settings.” (Valacich & Schneider, 2009)  “the interrelated components working together to collect, process, store, and disseminate information to support decision making, coordination, analysis, and visualization in an organization.” (Laudon & Laudon, 2012)  “the collection of technical and human resources that provide the storage, computing, distribution, and communication for the information required by all or some part of an enterprise.” (Rouse & Martinez, 2015)  “an integrated set of components for collecting, storing, and processing data and for providing information, knowledge, and digital products. Business firms and other organizations rely on information systems to carry out and manage their operations, interact with their customers and suppliers, and compete in the marketplace.” (Zwass, 2016)

From these definitions two key points emerges. Firstly, the reference to enterprises, as IS are commonly used inside organizations. The second aspect is related to the way of describing IS: the definitions are focuses on the components that make up IS, and on the role those components play in an enterprise. Regarding the second aspect, it is important to better define both components and the role of Information Systems.

For what concerns components, the definitions encompass six components (Bourgeois, 2014). Technology components are hardware (physical parts, like computers and servers, mice and keyboards, tablet and smartphones), software (intangible sets of instructions which tell the hardware what to do) and data (intangible collections of facts, which are organized and analyzed to become meaningful). Networking communication, even if technically made of hardware and software, can be considered a fourth technological component: nowadays, it’s difficult to imagine a computer that does not connect to another device or a network, and this idea is becoming more and more

170 Appendix persistent thanks to pervasive computing and IoT trends. The last two components are not related to technology: they are people and process: many different people are involved in IS, from those who build them, to those who use and benefit from them, and, to gain competitive advantage and obtain real value from IS, they must be used to manage and improve business processes (i.e. the steps undertaken to achieve desired outcomes).

The role of Information System is related on how these components work together and what their interaction can provide to businesses (Bourgeois, 2014). A clear explanation of how IS components interact together is given by Alter’s work system framework, which encompass six entities (slightly different from those identified by Bourgeois) in describing a work system, which an information system is (Alter, 2002).

Figure 37 An integrated view of an information system (adapted from Alter's Work System Framework)

The framework describes information systems with an integrated view through six entities: customers interact with information systems through the exchange of products, that are manufactured in business processes through participants, information and technologies (Van der Aalst & Stahl, 2011). Beside interactions, Information Systems have historically provided competitive advantage to organizations: from the late 1960s, when computers were used to store and organize large volumes of information and support manufacturing processes, to the personal productivity revolution of PC in the 80s, to local and global networks connecting businesses to other companies and to consumers. Even if some years ago the idea that information technology has become a commodity raised among certain practitioners (Carr, 2003), nowadays IT and IS are still providing great value for companies in every industry (Bourgeois, 2014).

Even if they can be used also outside businesses, we will consider only enterprise information systems, that are systems tailored toward the support of an organization as argued by the same authors. Enterprise IS play a crucial part in many organizations, and, despite excluding them from IS definition, business processes have a central role in enterprise IS: companies mainly build IS to support their business processes. Given their importance and their complexity, enterprise IS often

171 Appendix provide challenges to the human resources which have to manage and use them, challenges which must be faced in a systemic way, as we will see in this chapter.

Enterprise information system can be generic, that is system supporting functionality that can be used by a wide range of organizations, or information systems for certain types of enterprises, which offer functionality tailored toward certain industries or organizations. Examples of industry specific information systems are: hospital IS for radiology or electronic patient records, bank IS to make calculations related to interests and mortgages, airline reservation systems and electronic learning systems. In the following pages, we will define the most important ones using Observatory for Enterprise Application Governance classification (2016) and extended descriptions of specific systems from Van der Aalst & Stahl (2011).

Core management systems Solutions to support corporate management process, like administration/audit, budgeting and management control systems.

 Enterprise Resource Planning Systems (ERP): this kind of systems supports the main business processes of organizations, such as human resource management, sales, marketing, management, financial accounting, controlling and logistics. ERP was developed as an integrated IS, reducing the effort organizations have to put in synchronizing data across all the different information systems dedicated to single business processes which use related data. ERP are typically used by large multinational companies, thus they need to support multiple languages and currencies, beside country-specific business practices. All these elements make ERP systems large and complex, and thus complicated to deploy and maintain.

 Workflow Management Systems: systems which help companies fully or partly automating business processes. Workflow management systems (WMS) “ensure that the right information reaches the right person at the right time, or is submitted to the right computer application at the right moment” (Aalst & Hee, 2004).

 Finance Systems: system that supports the flow of money within and between organizations, providing accounting functionalities. These systems produce and maintain a set of books for reporting and management support.

172 Appendix

Supplier facing applications Software enabling collaboration and interaction with suppliers (e.g. extranet, vendor portal, EDI).

Supply Chain management Tools for the internal management of the supply and logistics chain (e.g. e-procurement, inbound logistics).

 Procurement Systems: it’s an information system which supports the purchasing process of organization with automation. A procurement system must purchase at the right time and from the right source, the amount of material needed to keep a business process running, through inventory level and forecasts. The system automatically generates new orders and tracks order arrivals and have the goal of reducing costs as much as possible. Procurement is an important part of supply chain management (SCM) and is related to electronic data interchange (EDI), the electronic exchange of information based on a standard set of messages.

 Delivery Systems: software which support the delivery of goods to customers, planning and scheduling shipments and deliveries. These systems aim to find a good solution to the complex problem of creating an optimal and flexible schedule, which considers variability deriving from circumstances like traffic jams and production problems. Tracking and tracing features are becoming more and more popular features offered by vendors.

Human Resource management Tools to manage human resources, from recruitment to roles and permissions, payroll, training, appraisals, etc.

Enterprise information management Systems to support the management and sharing of internal information (e.g. Enterprise Content Management, Knowledge Management, Business Intelligence).

 Data Warehouses: large databases that stores historical and updated information from different sources and are optimized for fast query answering. Data Warehouses are typically subject to an Extract, Transform, Load (ETL) process: data are extracted from homogeneous or heterogeneous data sources at regular intervals, transformed for storing in the proper format and loaded in the final target database. These kinds of systems are

173 Appendix

essential for an organization to efficiently use for planning and decision-making purposes the vast amount of information collected over years through operational software.

 Business Intelligence Systems: systems that provides tools and techniques to analyze the performance of business processes in terms of efficiency and effectiveness. Data can be obtained from Data Warehouses and the tools can be more or less sophisticated, for example making usage of statistical analysis.

Office automation Tools that support individual productivity in creating content and managing communication and collaboration (e.g. email, Unified Communications and Collaboration software, etc.).

Sales and Marketing systems Systems which must support process related to product, price, place and promotion, processing customer orders. These systems can be strictly related to sales, like marketing automation systems and tools to support the sales force, or related to customers’ contacts and relationship, like contact center management and customer relationship management (CRM) systems, which store all customer-related information, including past purchases. The aim of these software is to improve marketing helping to meet customer needs.

Customer facing applications Tools available for final customers to interact with the company or to use company’s services, like mobile apps and electronic commerce software.

Industry specific solutions Solutions supporting specific processes of single industry. In this category, we can also find solutions used by different industries, like Product Lifecycle Management systems (PMS), manufacturing and product design systems.

 Manufacturing Systems: systems that support the production process of organizations, planning production using demand requirements, bill of materials (BOM), inventory levels and available capacity. Production automation is continuously growing, but to work properly precise scheduling and material movement are needed, and a manufacturing system can provide both. Examples of manufacturing software are Master Production

174 Appendix

Schedule (MPS) and Computer-aided manufacturing (CAM), but also Material Requirements Planning (MRP) and its successors like Manufacturing Resources Planning (MRP2), which have also been the starting point of many ERP systems.

 Product Design Systems (PDM): software which supports product design through graphical representations, the design of product specifications and versioning functionality. Example of these systems are computer-aided design (CAD) systems and product data management (PDM) systems.

175 Appendix

Annex B – Literature review glossary Application Programming Interface (API): An application program interface (API) is code that allows two software programs to communicate with each other. The API defines the correct way for a developer to write a program that requests services from an operating system (OS) or other application. APIs are implemented by function calls composed of verbs and nouns. The required syntax is described in the documentation of the application being called. Typically, APIs are released for third-party development as part of a software development kit (SDK) or as an open API published on the Internet. If the applications are written in different languages or have been written for different platforms, middleware can provide messaging services so the two applications can communicate with each other. Cloud computing has fueled interest in APIs, as companies experiment with ways to integrate a cloud provider's service with on-premises systems or other cloud services (TechTarget, 2014).

API economy: API economy (application programming interface economy) is a general term that describes the way application programming interfaces (APIs) can positively affect an organization's profitability. There was a time when only software professionals knew about APIs. Today, business leaders are aware of the financial impact APIs can have and companies are generating revenue by exposing APIs as business building blocks for third party applications. The emerging financial effects of APIs on businesses have gained steam thanks in part to mobile and social media technologies. Major companies that have gained revenue from APIs include SalesForce.com, Amazon, Facebook, Twitter, and Google (TechTarget, 2014).

Business Process Modeling Language (BPML): Business process modeling, often called process modeling, is the analytical representation or illustration of an organization’s business processes. It is widely viewed as a critical component in successful business process management (BPM). It is used to map out an organization’s current (or “as-is”) processes to create a baseline for process improvements and to design future (or “to-be”) processes with those improvements incorporated. Process modeling often uses Business Process Modeling Notation (BPMN), a standard method of illustrating processes with flowchart-like diagrams that can be easily understood by both IT and business managers (TechTarget, 2012). In fact, a diagram in BPMN is assembled from a small set of core elements, making it easy for technical and non-technical observers to understand the processes involved. Elements are categorized into three major groups called flow objects, connecting objects and swim lanes. Flow objects, denoted by geometric figures such as circles, rectangles and diamonds, indicate specific events and activities. Flow objects are

176 Appendix linked with connecting objects, which appear as solid, dashed or dotted lines that may include arrows to indicate process direction (TechTarget, 2010).

Business Process Management: Business process management (BPM) is a systematic approach to making an organization's workflow more effective, more efficient and more capable of adapting to an ever-changing environment. A business process is an activity or set of activities that will accomplish a specific organizational goal. The goal of BPM is to reduce human error and miscommunication and focus stakeholders on the requirements of their roles. BPM is a subset of infrastructure management, an administrative area concerned with maintaining and optimizing an organization's equipment and core operations. BPM is often a point of connection within a company between the line-of-business (LOB) and the IT department. Business Process Execution Language (BPEL) and Business Process Management Notation (BPMN) were both created to facilitate communication between IT and the LOB (TechTarget, 2011).

Data Model: data modeling is the process of documenting a complex software system design as an easily understood diagram, using text and symbols to represent the way data needs to flow. The diagram can be used as a blueprint for the construction of new software or for re-engineering a legacy application (TechTarget, 2016). A data model is a diagram that uses text and symbols to represent groupings of data so that the reader can understand the actual data better (TechTarget, 2007).

Domain-Driven Design: Domain-driven design (DDD) is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts. Its premise is place the project’s primary focus on the core domain and domain logic, base complex designs on a model, and Initiate a creative collaboration between technical and domain experts to iteratively cut ever closer to the conceptual heart of the problem (Domain- driven design community, 2007).

Enterprise Service Bus: An enterprise service bus (ESB) is a software architecture for middleware that provides fundamental services for more complex architectures. ESB can be thought of as a mechanism that manages access to applications and services (especially legacy versions) to present a single, simple, and consistent interface to end-users via Web- or forms-based client-side front ends (TechTarget, 2007).

Extract, Transform, Load (ETL) consists of three functions carried out into a single programming tool used to manage databases. First, the extract function reads data from a specified

177 Appendix source database and extracts a desired subset of data. Then, the transform function works with the acquired data – using rules or lookup tables, or creating combinations with other data – to convert it to the desired state. Finally, the load function is used to write the resulting data to a target database (Rouse, 2005).

Integration Broker: Also called an interface engine or a message broker, an IB is a third-party intermediary that facilitates interactions between applications. IBs minimally provide message transformation and routing services. They mostly communicate program to program; they integrate previously independent applications at the application-logic level of the software design (Gartner Glossary, 2016).

Master Data Management: Master data management (MDM) is a comprehensive method of enabling an enterprise to link all of its critical data to one file, called a master file, that provides a common point of reference. When properly done, MDM streamlines data sharing among personnel and departments. In addition, MDM can facilitate computing in multiple system architectures, platforms and applications (TechTarget, 2010).

Middleware: in software programming, the term middleware generically involves a software that serves to “glue together” other separate programs (Rouse, 2015).

Monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program, which is self-contained and independent from other computing applications, being able to perform every step needed to complete a function. Monoliths are also called one-tier applications, even if strictly they are not client-server applications (client and server are physically and logically the same).

NoSQL database: it is an approach to data management and database that is useful for very large sets of distributed and unstructured data. NoSQL systems could be non-relational (i.e. prohibit structured query language) or simply avoid selected relational functionalities, such as fixed table schema, and join operations (Rouse, 2011).

Petri net-based languages:

Silos architecture: models organizing data in information silos, repositories of fixed data which are under the control of a single department and are isolated from the rest of the organization (Rouse, 2015; Bruna, 2015).

178 Appendix

Single Sign On: Single sign-on (SSO) is a session and user authentication service that permits a user to use one set of login credentials (e.g., name and password) to access multiple applications. The service authenticates the end user for all the applications the user has been given rights to and eliminates further prompts when the user switches applications during the same session. On the back end, SSO is helpful for logging user activities as well as monitoring user accounts (TechTarget, 2016).

Technical Debt: technical debt is a metaphor coined by Ward Cunningham (1992); according to this metaphor, delivering increasingly complex software-reliant systems demands better ways to manage the long-term effects of short-term expedients. The idea is that developers sometimes accept compromises in a system in one dimension (e.g. modularity) to meet an urgent demand in some other dimensions (e.g. a deadline), and that such compromises incur a “debt”, on which “interest” has to be paid, and whose “principal” should be repaid at some point for the long-term health of the project. Effective management of such debt is perceived as critical to achieving and maintaining software quality. Left unmanaged, such debt creates significant long-term problems, such as increased maintenance costs (Brown, et al., 2010). Giving an example, even if a company gives common architecture guidelines for development projects, a technical debt could rise due to different understandings of those guidelines. This is a typical undetected debt that results in enormous amounts of effort into understanding and gradually refactoring the system towards the common architecture. One way to understand technical debt is to characterize the gap between the current state of a software system and the hypothesized “ideal” state in which the system is optimally successful in a particular environment. Therefore, technical debt could be also tracked in a software project, such as known defects and unimplemented features. But it can include obvious and less visible aspects, such as architectural and code decay and outdated documentation.

Twin Peaks Model: The Twin Peaks model draws attention to the synergistic relationship between requirements and architectural design. It emphasizes the need to progressively discover and specify requirements while concurrently exploring alternative architectural decisions. The Twin Peaks model addresses the problems found in more linear development processes in which either the requirements are specified and frozen without considering the implications on the architectural design, or the opposite case occurs in which the architecture is designed without negotiating emerged conflicts, balancing trade-offs and making desirable changes in the requirements (Twin Peak, 2015 - http://www.se.rit.edu/~mehdi/twinpeaks/).

179 Appendix

Use Case: A use case is a methodology used in system analysis to identify, clarify, and organize system requirements. The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal. The use case should contain all system activities that have significance to the users. A use case can be thought of as a collection of possible scenarios related to a particular goal, indeed, the use case and goal are sometimes considered to be synonymous (TechTarget, 2007).

Usage Scenario: A usage scenario, or scenario for short, describes a real-world example of how one or more people or organizations interact with a system. They describe the steps, events, and/or actions which occur during the interaction. Usage scenarios can be very detailed, indicating exactly how someone works with the user interface, or reasonably high-level describing the critical business actions but not the indicating how they're performed (Agile modeling, 2014).

Main DevOps tools:

Version control: a category of processes and tools designed to keep track of multiple different versions of software, content, documents, websites and other information in development. Any system that provides change tracking and control over programming source code and documentation can be considered version control software (TechTarget, 2016).

Configuration management: the detailed recording and updating of information that describes an enterprise's hardware and software. Such information typically includes the versions and updates that have been applied to installed software packages and the locations and network addresses of hardware devices. Special configuration management software is available (TechTarget, 2014).

Build automation: the process of automating the creation of a software build and the associated processes including: compiling computer source code into binary code, packaging binary code, and running automated tests (Wikipedia, 2016).

Unit testing framework: unit testing is a software development process in which the smallest testable parts of an application, called units, are individually and independently scrutinized for proper operation. Unit testing is often automated but it can also be done manually. Unit testing frameworks are most often third-party products that help simplify the process of unit testing (TechTarget, 2007 - Wikipedia, 2016).

180 Appendix

Issue tracking system: a software application that allows an enterprise to record and follow the progress of every problem or "issue" that a computer system user identifies until the problem is resolved. With an ITS, an "issue", which can be anything from a simple customer question to a detailed technical report of an error or bug, can be tracked by priority status, owner, or some other customized criteria.

Monitoring: there are two distinct types of monitoring; application performance monitoring tools, which enable code-level identification and remediation of performance issues, and server monitoring tools, at the infrastructure level, which provide visibility into capacity, memory, and CPU consumption (NewRelic, 2014).

Main technology operations areas supported by DevOps:

Automated Provisioning: also called self-service provisioning, is the ability to deploy an information technology or telecommunications service by using pre-deﬁned procedures that are carried out electronically without requiring human intervention (TechTarget, 2011).

Continuous Integration: a software engineering practice in which isolated changes are immediately tested and reported on when they are added to a larger code base. The goal of CI is to provide rapid feedback so that if a defect is introduced into the code base, it can be identified and corrected as soon as possible. Continuous integration software tools can be used to automate the testing and build a document trail (TechTarget, 2008).

Development Environments: the set of processes and programming tools used to create the program or software product. The term may sometimes also imply the physical environment. An integrated development environment is one in which the processes and tools are coordinated to provide developers an orderly interface to and convenient view of the development process (or at least the processes of writing code, testing it, and packaging it for use) (TechTarget, 2007).

Automated Delivery:

Continuous Delivery: an extension of the concept of continuous integration (CI). Whereas CI deals with the build/test part of the development cycle for each version, CD focuses on what happens with a committed change after that point. With continuous delivery, any commit that passes the automated tests can be considered a valid candidate for release (TechTarget, 2014).

181 Appendix

Annex C - Enterprise Application Governance Observatory – Research survey

Osservatorio Enterprise Application Governance

Questionario Ricerca 2016 Indirizzata a CIO, IT Manager e Enterprise Architect

Anagrafica

Nome e Cognome: Nome Azienda: Ruolo in azienda: Mail: Telefono:

Note per la compilazione: Nel caso di azienda appartenente a un gruppo, si prega di compilare il questionario, indicando risposte relative ai dati consolidati se si tratta della capogruppo, oppure relative alla singola azienda nel caso si tratti di una controllata.

Settore di appartenenza: Fatturato 2015 della sua Azienda (in milioni di euro): Numero di addetti impiegati nella sua Azienda nel 2015: Numero di addetti impiegati nella Direzione IT nel 2015: Percentuale di spesa IT rispetto al fatturato: Fino a 0,7% Da 0,7% a 1,5% Da 1,5% a 2,5% Da 2,5% a 3,5% Sopra 3,5% Non sa/non risponde

1. Nell’ultimo anno quanto ha investito la sua Azienda in progetti di sviluppo applicativo cioè nella digitalizzazione dei processi ? Meno del 3% della spesa IT Tra il 3% e il 6% della spesa IT Tra il 6% e il 15% della spesa IT Tra il 15% e il 30% della spesa IT Tra il 30% e il 50% della spesa IT Più del 50% della spesa IT

182 Appendix

2. Per quanto riguarda i progetti di sviluppo applicativo, cioè in digitalizzazione dei processi, in Azienda, quanti sono piena responsabilità della Direzione IT e quanti delle Line of Business? 100% sono responsabilità della Direzione IT Più del 50% sono responsabilità della Direzione IT Meno del 50% sono responsabilità della Direzione IT La Direzione IT è coinvolta in questo tipo di iniziative marginalmente o con ruolo solo operativo

3. Per quanto riguarda l’approvvigionamento di servizi IT, si fa ricorso ad outsourcing per: Solo per Application Management Solo per servizi infrastrutturali Sia per servizi infrastrutturali, sia per Application Management Non si fa ricorso a servizi in outsourcing

SEZIONE I – I trend emergenti che cambiano le scelte del portafoglio applicativo In questa parte del questionario si indagheranno quali trend emergenti e quali priorità di business stanno condizionando le scelte relative all’evoluzione del portafoglio applicativo. Consideriamo come trend emergenti i seguenti: - Mobility: rendere le applicazioni aziendali utilizzabili su qualsiasi device per favorirne l’utilizzo in mobilità, sfruttando inoltre le opportunità offerte dai nuovi device e dalle situazioni di mobilità - User Experience: progettare le applicazioni considerando come elemento chiave l’esperienza d’uso del singolo utente, in modo da migliorarne la propensione all’utilizzo e la produttività - Collaboration: supportare in modo integrato il flusso strutturato delle attività ed il relativo flusso collaborativo, rendendo possibile il monitoraggio di tutte le attività correlate al processo e diminuendo l’overhead causato dalle e-mail - Pervasive Computing: sfruttare le opportunità di interazione con la realtà fisica attraverso la raccolta di dati e l’impiego di nuove forme di automazione - Data Intelligence: utilizzare logiche di intelligenza artificiale/machine learning per ricavare il massimo valore dai dati disponibili, abilitando analisi predittive e reazioni in real time - Open Application: rendere possibile l’estensione della copertura funzionale delle applicazioni, integrando in maniera standard (tramite API) altre applicazioni

4. Quali fra i Trend Emergenti hanno un maggiore impatto sulle scelte di evoluzione applicativa, all’interno della sua Azienda? Assegnare ordine di importanza da 1 (maggiore) a 6 (minore) Mobility User Experience Collaboration Data Intelligence Pervasive Computing Open Application

5. Chi è il principale promotore in Azienda, per ognuno dei seguenti Trend Emergenti? Indicare una risposta per ogni trend emergente User Data Pervasive Open Mobility Collaboration Experience Intelligence Computing Application

183 Appendix

Top Management

Line of Business

Funzione IT

Non viene ritenuto un elemento di interesse

6. Indicare, per ogni ambito applicativo, quali trend emergenti incidono maggiormente nella selezione ed evoluzione del portfolio applicativo? Per ogni ambito indicare massimo 2 risposte

User Data Pervasive Open Mobility Collaboration Experience Intelligence Computing Application

Supplier Facing

Applicationxiii

Supply Chain

Managementxiv

Human Resource

Managementxv

Sistemi Gestionali

Corexvi

Verticali di Industryxvii

Enterprise Information Managementxviii

xiii Supplier Facing Application: strumenti abilitanti l’interazione e la collaborazione con i fornitori (es. extranet, portale fornitore, EDI) xiv Supply Chain Management: strumenti per la gestione interna della filiera di fornitura e della logistica (es. e-procurement, logistica inbound) xv Human Resource Management: strumenti per la gestione HR, recruitment, ruoli e permessi, paghe, formazione e sviluppo, valutazioni, etc. xvi Sistemi Gestionali Core: soluzioni per il supporto ai processi aziendali di gestione (es. amministrazione, controllo di gestione, budgeting) xvii Verticali di Industry: soluzioni verticali specifiche a supporto dei processi peculiari della singola industry (es. CAD/CAM, PLM, MPS, MRP) xviii Enterprise Information Management: applicativi a supporto dei processi di gestione e condivisione delle informazioni interne (es. Enterprise Content Management, Knowledge Management, Business Intelligence)

184 Appendix

Office Automationxix

Customer Relationship Managementxx

Customer Facing

Applicationxxi

SEZIONE II – Ruolo e i processi della Direzione IT In questa sezione si vuole rilevare come cambiano i processi interni della Direzione IT, rispetto all’avvento di nuove metodologie di lavoro innovative. Per metodologie di lavoro innovative si intendono: - Metodologie evolute di analisi, quali Goal Based Analysis, User Story Mapping, etc. - Metodologie di sviluppo Agile, come Scrum, Lean Software Development, Extreme Programming, etc. - Metodologie di gestione del rilascio del software (DevOps).

7. Qual è il grado di diffusione delle diverse metodologie all’interno della Direzione IT nella sua azienda? Indicare una risposta per ogni metodologia Una parte Si sta Tutti i significativa Solo alcuni Nessun valutando / progetti IT dei progetti progetti IT progetto IT è sperimentando sono gestiti IT sono sono gestiti gestito con l’adozione con questa gestiti con con questa questa della metodologia questa metodologia metodologia metodologia metodologia

Metodologie evolute di analisi (Goal Based

Analysis, User Story Mapping, etc.)

Metodologie di sviluppo Agile come Scrum, Lean Software Development,

xix Office Automation: strumenti a supporto della produttività individuale per la creazione di contenuti e per la comunicazione e collaborazione (es. mail, UCC) xx Customer Relationship Management: strumenti per la gestione della relazione con il cliente, raccolta e analisi delle informazioni, supporto alle forza vendita, marketing automation e gestione contact center xxi Customer Facing Application: strumenti messi a disposizione dei clienti per l’interazione con l’azienda o per la fruizione di servizi (es. mobile apps, e-commerce, sito web)

185 Appendix

Extreme Programming, etc.

Metodologie di gestione del rilascio

del software (DevOps)

8. Sono in corso azioni di cambiamento all’interno della sua Direzione IT? Possibilità di indicare più risposte Sì, stiamo rivedendo il modello organizzativo della Direzione IT Si, stiamo introducendo nuovi processi, metodologie e strumenti di lavoro Sì, stiamo introducendo nuove figure e competenze all’interno della Direzione IT Sì, stiamo adottando nuove modalità di lavoro con il business No

9. Quali ritiene essere le principali motivazioni per l’adozione, all’interno della sua Direzione IT, di metodologie di lavoro innovative? Indicare per ogni metodologia le 2 principali motivazioni

Metodologie di Metodologie evolute sviluppo Agile come Metodologie di di analisi (Goal Based Scrum, Lean Software gestione del rilascio del Analysis, User Story Development, software (DevOps) Mapping, etc.) Extreme Programming, etc.

Maggiore controllo delle

attività di progetto

Riduzione dei tempi di

esecuzione delle attività

Maggiore tempestività di risposta alle Line of Business

Aumento dell’efficienza

operativa

Riduzione delle attività

dovute a ricicli

Abilitazione di una maggiore proattività dell’IT

186 Appendix

Maggiore soddisfazione

degli utenti finali

Maggiore flessibilità alle

richieste di modifica

Miglioramento della relazione con le Line of Business

Miglioramento

accuratezza delle stime

Aumento engagement e

motivazione dei team

10. Quali ritiene essere i principali limiti per l’adozione, all’interno della sua Direzione IT, di metodologie di lavoro innovative? Indicare per ogni metodologia i 2 limiti principali

Scarsa conoscenza delle

nuove metodologie

Insufficienti competenze

tecniche specifiche

Mancanza di competenze e disponibilità dei fornitori

Metodologie applicabili

in contesti troppo limitati

187 Appendix

Percezione di scarsa efficacia delle nuove metodologie

Rischi legati all’introduzione delle nuove metodologie

Mancanza di risorse economiche da dedicare al cambiamento

Limiti degli strumenti contrattuali disponibili verso i fornitori

Difficoltà nel quantificare costi e benefici dell’adozione

Forti impatti sull’attuale

organizzazione dell’IT

Resistenza al cambiamento dei collaboratori IT

Scarsa collaborazione

delle Line of Business

SEZIONE III – Evoluzione delle architetture dei Sistemi Informativi In questa sezione del questionario si vogliono approfondire le trasformazioni che stanno subendo le architetture applicative dei Sistemi Informativi Aziendali, soprattutto in ottica di abilitare nuovi modelli di fruizione dei servizi IT

11. All’interno della sua Azienda è presente una mappatura del portfolio applicativo? Sì, viene costantemente aggiornata ad ogni modifica Sì, viene periodicamente aggiornata Sì, ma non è più aggiornata No, ma è in fase di valutazione l’introduzione No e non si prevede l’introduzione nel breve periodo

12. Quanto sta investendo la sua Azienda in iniziative di razionalizzazione ed evoluzione dell’architettura applicativa del sistema informativo? Molto e in maniera continuativa

188 Appendix

Molto, ma in modo discontinuo Poco Molto poco o niente

13. All’interno della sua Direzione IT esiste un’unità organizzativa preposta all’Enterprise Architecture? L’unità organizzativa di Enterprise Architecture ha il compito di definire, condividere e gestire i modelli architetturali di riferimento (processi, applicazioni, dati e infrastruttura) del Sistema Informativo Aziendale. Presidia la visione, governa le architetture e definisce un piano di azione attuabile per rispondere ai cambi di esigenze ed alle necessità di evoluzione, acquisendo dati e informazioni utili a definire e governare un percorso di cambiamento.

Sì, è presente e consolidata Sì, ma è di recente introduzione No, ma alcune persone si occupano di architetture all’interno delle proprie aree No, ma è in fase di valutazione No

14. Se è presente, quali sono i principali compiti che svolge? Possibilità di indicare più risposte o nessuna Definizione delle linee guida per lo sviluppo applicativo Partecipazione attiva ai progetti di sviluppo Gestione dell’architettura a livello infrastrutturale Gestione della security Gestione del ciclo di sviluppo del software Altro (specificare)

15. Quali sono le principali difficoltà legate alla corretta gestione dell’Enterprise Architecture all’interno della sua Azienda? Possibilità di indicare massimo 2 risposte Ridotto commitment del management Mancanza di budget Resistenza dei team di progetto Mancanza di competenze all’interno della Direzione IT Esperienze pregresse di scarso successo

16. Quali ritiene essere i principali benefici derivanti dalla corretta gestione dell’Enterprise Architecture all’interno della sua Azienda? Possibilità di indicare massimo 2 risposte Rendere il sistema informativo più flessibile e pronto per rispondere alle richieste del Business Ridurre la complessità del parco applicativo Ridurre i costi di gestione dell’IT Dare un indirizzo strategico e uniforme alle diverse scelte architetturali Migliorare il controllo e la conoscenza dell’IT sul proprio parco applicativo

189 Appendix

Annex D - Enterprise Application Governance Observatory - Interactive frameworks

Trends impacting on application portfolio evolution – map and stickers

190 Appendix

191 Appendix

Architectures evolution – map and stickers

192 Appendix

193 Appendix

Evolution of IT process – map and stickers

194 Appendix

195 Acknowledgements - ringraziamenti

Acknowledgements - ringraziamenti Vorremmo ringraziare in primo luogo il Prof. Mariano Corso, per averci offerto la possibilità di approfondire un tema tanto nuovo quanto interessante.

Un ringraziamento particolare agli Ing. Alessandro Piva e Luca Dozio per la cortesia e la disponibilità con la quale ci hanno seguito in questo lavoro, a Clara Carnevaletti e a tutto il team Piva degli Osservatori Digital Innovation per il supporto morale.

Marina

Il primo ringraziamento va a mia Nonna Carmen, che mi ha insegnato il valore dello studio e mi ha sempre incoraggiata e sostenuta nel raggiungere qualsiasi obiettivo. Grazie ai miei genitori, Barbara e Fabrizio, perché sono sempre stati la mia forza e senza il loro appoggio tutto questo non sarebbe stato possibile. Grazie a Gabriele, che mi ha supportata (sopportata) nei momenti più difficili di questo percorso universitario e ha sorriso con me per le soddisfazioni ottenute. Infine, ringrazio il mio amico e compagno di tesi Nicolò, nonché tutti gli amici che mi sono stati vicini in questi anni, sia quelli che ci sono da una vita, sia coloro che ho conosciuto proprio tra i banchi del Politecnico.

Nicolò

Il grazie più grande va alle persone che mi sono state vicino durante il percorso universitario; alla mia Famiglia, a Roberta, alla mia compagna di tesi Marina, agli Amici e a tutti coloro che mi hanno dato uno stimolo in più per raggiungere questo obiettivo.

196