A simplified method to enhance the analysis for new information systems in corporate environments

The impact of efficient Information System Strategy Plans has proven crucial to modern-day corporations. However, during the analysis phase for a technical solution to fulfil an identified need in an enterprise, many teams tend to focus on a very issue-specific analysis and overlook its underlying global corporate impacts. On the other hand, it is difficult and time-expensive for these teams to analyse every existing corporate solution and how they are affected by their technical decisions. Moreover, such analysis still represents a significant organisational risk. To reduce such risks and perform a more efficient analysis we propose a simple method that considers an initial high-level analysis, focusing on the most common requirements of an enterprise in what concerns its Information Systems.


INTRODUCTION
These days, most enterprises heavily rely on Information Systems (IS) to assist in their business, making them the backbone of most modern organisations. Thus, Information System Strategy Planning (ISSP) is vital to continuing organisational success and efficient IS performance [1]. The ISSP works as a guide for the teams across the whole company to inline their project to the global objectives of their enterprise. However, it is quite common for many teams to focus on an extensive analysis of each proposal during the analysis phase of a technical solution for the fulfilment of an identified need in a company. Considering that most use-cases have an enormous amount of solutions available, requesting full technical analysis, demonstrations, and Proofs of Concept can be time expensive. Such analysis represents both an unnecessary expense and a possible organisational risk.
A quite common situation is that of a team to spend time on an extensive investigation to find out later that, even though the solution fits the requirements, it may not be fully compliant with the needs of the Enterprise itself, where in some more extreme cases the project can end up refused.
After experiencing the abovementioned situations during the analysis of a new technical monitoring solution we developed the following method for an initial high-level analysis to reduce such risks and perform a more efficient investigation, focusing on the most common high-level requirements of an Enterprise towards its Information Systems. This approach requires minimal effort and outputs a final score for each solution, which represents the solution's compatibility with the company, simplifying the comparison between different solutions. This document is structured as follows: Section II describes aspects relevant to the analysis of Information Systems. Section III describes our approach, and Section IV applies it to a usecase. Section V summarises the conclusions and the future work.

II. COMMON INFORMATION SYSTEM ANALYSIS ISSUES
Organisations are constantly evolving and technology tends to evolve with it, putting pressure on the markets to create better solutions. This phenomenon causes the market to be flooded with many solutions. Thus, when teams need to choose a new solution, it will require significant input to find what fits best to their needs.
During the analysis phase of a new solution, the teams identify new needs and define the requirements, and then a decision needs to be made. It is necessary to know if a new tool should be developed, an existing one extended, or a different tool acquired from an external provider. That can be a difficult decision to make and, consequently, teams tend to spend a significantly large amount of time analysing many possible solutions.
In most corporations, solutions from external providers are preferred because they can provide support and eventually a Service Level Agreement (SLA). However, tools coming from such solutions often fail to fit the requirements, as they are not developed considering details of the company's specific usecase. So, when adding the requirements inherited from the ISSP, it becomes even harder to find an adequate solution. The whole analysis makes it also very hard to understand which solution is a better fit, as it is possible for multiple solutions to partially comply with the requirements, always needing some specific configurations or extension development.
To improve this process of solution selection, many methodologies have been developed to improve the quality and efficiency of the decision-making process. These methodologies implement a more analytical approach to the selection of new Information Systems, Software and other tools. It is common for such selection processes to invite a group of experts and analyse the many alternatives. The analysis is then performed in workshops where different perspectives from the expert is discussed openly, or with several iterations of anonymous questionnaires and result analysis until the number of alternatives is significantly reduced obtaining a desired level of consensus using the Delphi method [2]. In some teams, techniques such as the Analytic Hierarchy Process (AHP) and Analytic Network Process (ANP) and its derivations are preferred for decision-making as these techniques are more focused on the objectives of the decision maker, instead of the alternatives [3][4] [5]. Although, these techniques have been extremely well tested and improved over the past decades, they do require trained experts to conduct the process, reducing the teams' flexibility to use their techniques of choice. In addition, with the growing number of available alternatives it can become very time expensive to perform a complete analysis.
The complexity, as mentioned above, does however not guarantee that the solution resulting from such extensive analysis is accepted, leading many teams to try to work around compliance rules and guidelines such as the ISSP and define a smaller, very specific scope to create their solution faster or even acquire the tools more easily. Such behaviour comes with a series of risks: among the obvious ones such as data reliability, integration with other IS, and security risks. In summary, many small Information Systems are created, and this can become difficult to manage.

III. PROPOSED METHOD FOR SELECTION OPTIMIZATION
To enhance the efficiency of the aforementioned methods of tool analysis, and consequently the adoption of teams to work with Information Systems that comply with the ISSP, we propose the following method, which is relatively simple to implement and can give an excellent high-level overview of the analysis of different IS solutions.

It consists of creating a questionnaire with binary questions
where the positive answer should translate to being compliant with a specific requirement, or corporate preference.
In most aspects, the method is quite similar to the checkliststyle approaches where the focus is to turn the analysis of the Information System easier to understand, and to allow the comparison of multiple solutions [6]. A widely-used example is a security audit checklist, however instead of auditing our internal solution we are pre-auditing a possible new solution.
The questionnaire can help in multiple scopes of the analysis: 1) on a corporate level, i.e., if it is compliant with the strategy plans, for instance, the ISSP; 2) on a project-specific level, i.e., if it is meeting the team's requirements; 3) on a topic's specific level, i.e., if it is compliant with the company's security rules.
The team that is performing the analysis uses the questionnaire to perform its initial investigation by answering the questions about the solution, repeating the process with the same questionnaire for every solution they want to investigate.
For ease of comparison between the analysed tools, the questions should be grouped into predefined topics or categories, being possible for some to have more questions than others. Then to calculate the result each answer should translate to the values 0 or 1, where the value 1 means the question has a positive answer. Then, within each group, we calculate an average of the values, which should give us a value between 0 and 1this is equivalent to the category score. When all the group scores are calculated, it is necessary to calculate the final score of the solution. For this step, a simple average can be used as well, so we still obtain a final value between 0 and 1.
The score indicates how compliant a solution towards all the defined requirements, as presented in the questionnaire. With this information, the analysis teams can easily have an overview of which solution should be analysed first. Moreover, it can also help analyse which high-level configurations or developments are necessary.
The calculation of the score between categories is not necessarily an average, in every company it is important to adapt it to their strategies.

A. Consideration to have when creating the questions
With such a wide-range of applications it is important that the teams in charge of creating the questionnaire of each scope perform an adequate ponderation of the questions they wish to raise.
To avoid complexity with the definition of questions when the subject is of greater importance, it should reflect on a greater number of questions with different levels of detail, instead of giving more weight to an existing one during the score calculation. We believe it is more effective to create follow-up questions that focus in more detail on a subject, making more levels of possible differentiation between the solutions. For instance, with this technique, to assess the maturity level of an IS we can add a question to know if it exists for more than a specified number of years. If more emphasis is necessary for this subject, one or more questions can be added, i.e. if it is still considered an Alpha or Beta release.
When answering the questions, it is important that one only considers it positive when it certain, if there is controversial information towards the questionpossible to be considered both 0 or 1 -it should always be answered negative. The assessment needs to be made with information available for everyone involved, this should include the internal corporate knowledge bases and information openly available on the Internet or in other information sources publicly available.

IV. METHOD EXAMPLE USE-CASE
As an example of this method, we will use our most recent use-case in BNP Paribas where we were analysing which Monitoring and Alerting tool should replace our older IS, which was developed in-house. The tool reached some limitations due to its Technical Architecture and we decided that it was time to develop or migrate to a platform that fits better our current needs.
To perform our initial analysis, we have defined a set of categories that should reflect on a logical grouping of the questions and requirements raised in an open workshop with experts from different technical areas. The following seven categories were defined: Architecture, Community, Support, Release Activity, Security, Code Knowledge, and Corporate Preferences.

A. Architecture
In the Architecture category, we described all the questions regarding the IS' Technical Architecture, as there are some risks related to it, such as described in the following questions:  Is the solution's Architecture explained?
 Is the solution fail-safe?
 Is the solution horizontally scalable?
 Can the solution be hosted independently by the enterprise itself?

B. Community
In the Community Category, we have analysed how strong is the current community of the solution; this can indicate how transparent and good a solution is, as better solutions tend to have stronger communities [7]. A strong community does normally also mean that the development team will be able to solve its issues faster as the probability that someone has had the same issue is high [8]. The questions from our use-case are as following:  Is there an official Discussion Forum or Q&A page for the solution (active during the last 3 months)?
 Is there an official Blog page for the solution?
 Was the solution presented in a recent conference (in the last year)?
 Using a web-based trend analysis tool (for example, Google Trend), did the mentions about the solution grow in the last year?
 Using a web search tool, did a new page appear in the last month that is mentioning the solution?
 Was a recent book published covering the solution (in the last year)?

C. Support
It is crucial for most businesses that their more critical IS have an external Support Plan, and if possible a Service Level Agreement (SLA). This reduces the risk of not having support when there is no team member available as it is possible to contact someone external to provide the required support. So, the following examples were formulated to analyse to ensure none of these topics is forgotten.
 Is there an organisation providing official support for the solution?
 Is there an organisation providing official training for the solution?
 Is there an organisation providing official 24/7/365 support for the solution?
 Is there an organisation guaranteeing official support with a response time < 1 day?
 Is there an official and open incident/ticketing page available, where anyone can report an issue?

D. Release Activity
The information about software's release activity can tell a lot about the tool. We can know how mature it is, how much development there is, how the documentation is managed. For instance, users tend to experience less the bugs in short release cycles [9]. Concerning these issues, we have created the following questions:  Does the solution perform release versioning?
 Did the solution perform a release in the past year?
 Did the solution perform > 5 releases in the past year?
 Is the solution NOT in an Alpha version?
 Is the solution NOT in a Beta version?
 Does the solution provide pre-release versions?
 Does the solution provide its previous versions for download?
 Is the documentation organised by release?

E. Security
Information security has become an increasingly important factor for many organisations. Over the years, there has been a fast dissemination of electronic commerce and a rising number of integrated systems, resulting in a growth of security threats [6][10] [11]. To avoid such risks, we question if the new solutions comply to some of the security rules and integrations of our organisation. Some examples of the questionnaire are provided below:  Does the application provide an authentication method?
 Does the solution provide tools for an enterprise's AD/LDAP/SSO solution be integrated?
 Is the API and node-to-node communication secured (IP Filtering, SSL/TLS encryption in communications, etc.)?
 Does the solution provide possibility to fully encrypt the stored data?

F. Code Knowledge
Although many corporations prefer commercial products due to its Support and SLA, it is important to know how much we can effectively analyse of the product's core itself. Thus, in this category, we consider that being able to analyse the source code can be beneficial in many aspects [7]. Another important point is if the source code and API is fully documented, as the productivity of any team working with the tool increases significantly. The following question examples reflect these topics:  Is there a free version of the solution available?

G. Corporate Preferences
Every corporation has its preferences on specific topics, sometimes related to technical or human resource related factors, or in some more unusual situations just because it was necessary to choose a specific direction. These factors can lead to situations where a specific feature or technology is preferred to the corporation although the alternatives are equally valid for that specific use-case. Thus, we defined the following examples that can be considered as a mere corporate preference:  Does the solution ONLY use the Programming Languages: Java, .NET or ExtJS?
 Is the solution prepared to be deployed on one of the following OS: RHEL or Windows Server?
 Is there a team in the Group using the solution already?
 Does a Member of the target Team have experience with the tool?

H. Results
To test the model and simultaneously analyse one of our usecases, we answered the above-mentioned questions for five tools and set up a spreadsheet to generate the results automatically.
The study was based only on Internet available information of five monitoring solutions, such as the tool website, web available information, Wikipedia page, and if the solution is open-source on its public repository (without fully analysing the source code which would be too time expensive). To calculate the final score, we used a simple average for the questions in the category and then an average of each category.
An interesting point to note is that the solution that was previously being considered because of its functionalities and Technical Architecture scored the lowest with this analysis, having enlightened us before we took unnecessary risks.

V. CONCLUSION AND FUTURE WORK
This paper proposes an easy to implement a method, based on a questionnaire, that can provide a high-level analysis overview of different IS solutions. We have provided use-case results achieved based on the method, and we have concluded that when teams prepare the questionnaire, the analyst acquires useful insight concerning the tools under analysis. That is especially useful multiple products are being compared simultaneously, which is very common situation considering the number of available products.