• No results found

From fruit salad to apples Research on integration of pre-lending applications

N/A
N/A
Protected

Academic year: 2021

Share "From fruit salad to apples Research on integration of pre-lending applications"

Copied!
143
0
0

Bezig met laden.... (Bekijk nu de volledige tekst)

Hele tekst

(1)

From fruit salad to apples

(2)

Preface

This thesis presents the findings of research performed at Triodos Bank from February 2007 until September 2007. It was written for the fulfilment of the requirements of the study of University of Groningen program in Technology Management, leading to the conferment of the title of ‘doctorandus’ (equivalent to the title Master of Science).

In my honest opinion, two words are significantly applicable for the process of my research; “patience and flexibility”. Patience, since my mentors had to read all the versions of this thesis over and over again. Flexibility for all I made an appeal to during this research.

I would like to thank, first and foremost, my academic supervisors, Dr. G.H. Kruithof and Prof. dr. E.O. de Brock for pushing me in the right direction during this research. Secondly, I would like to thank Liesbeth Soer for being patient and conscientious every time she read the thesis and Ricko Kamp for being supportive as well as harshly accurate. I would also like to thank the rest of the staff at Triodos Bank, all of whom have been very helpful in providing advice and cappuccino at times you most need it. I should not forget to mention that the flexibility of the surveillance team of Triodos Bank has contributed to my research.

Last, but by no means least, I would like to thank my family, ‘de Heeren’, Valerie, MFWOT and my friends in both Groningen and around Utrecht for being exceptionally supportive during my stay in Utrecht.

Overall, I had a wonderful time working on this thesis, in that it was a unique opportunity to experience the social face of the banking world. Secondly, the research has inspired me to explore the world of Enterprise Architecture that fascinated me more than I thought.

Jurjen Rienk Helmus Utrecht September 6, 2007

(3)

Glossary

Concept Definition Author

Actual structure The structure of an organisation as it is in practice de Leeuw (2000) Application Software program that performs a specific function directly for a user and can be

executed without access to system control, monitoring, or administrative privileges.

National Information Assurance (IA) Glossary (2006)

Application software Applications that have specific business purpose TOGAF (2007) Architecture view A perspective from which an architecture may be viewed in order to ensure that a

specific topic is considered in a coherent matter

TOGAF (2007)

ARIS Architecture of Integrated Information Systems Leist et al (2005) As-Is Architecture The set of products that portray the existing enterprise, the current business practices,

and the technical infrastructure. It is commonly referred to as the ‘As-Is’ architecture.

TOGAF (2007)

BMD Branch Managing Director Triodos Bank

BPA Business Process Architecture Grigoriu (2006)

BPM (1) Business Process Modelling Grigoriu (2006) BPM (2) Business Process Management Grigoriu (2006)

BU Business Unit Triodos Bank

Capital Requirements The amount of equity mandatory to maintain BIS (2006)

CEO Chief Executive Offices Triodos Bank

CFO Chief Financial Officer Triodos Bank

CLH Corporate Lending Handbook: a framework for the branches to structure the work processes and procedures for the lending activities. It described processes at high aggregation level but leaves room for working processes

Triodos Bank

COO Chief Operations Officer Triodos Bank

CORBA

Common Object Request Broker Architecture is a standard defined by the Object Management Group (OMG) that enables software components written in multiple computer languages and running on multiple computers to work together

Targowski (2003)

COREP Common REPorting framework BIS (2006)

COTS Commercial Of the Shelve Targowski (2003)

Coupling Connect software (e.g. databases) with other software. Variations exists in loose coupling/ semi coupling/ tight coupling

Targowski (2003)

CRM Customer Relationship Management Targowski (2003)

CRSA Capital Requirements to Standardised Approach: A report to calculate the capital requirements as part of Basel II

BIS (2006)

CSA Current Systems Analysis Perks et al (2003)

DA Data Architecture TOGAF (2007)

Data aggregation Compilation of unclassified individual data systems and data elements that could result in the totality of the information being classified or of beneficial use to an adversary.

National Information Assurance (IA) Glossary (2006)

Data integrity Condition existing when data is correctly entered in accordance with its meaning and unchanged from its source and has not been accidentally or maliciously modified, altered, or destroyed.

National Information Assurance (IA) Glossary (2006)

Data uniformity Uniformity refers at the overall equality of data in sense meaning/ definition, format, size, data type, and requirement. In this thesis, overall equality refers to the equality between the branches and headquarters.

National Information Assurance (IA) Glossary (2006)

Database Structured or organized collection of information, which may be access by a computer, (in this thesis some

TOGAF (2007) Database Management

System (DBMS)

(in this thesis sometimes abbreviated as database) A computer program that accesses, manipulates and secures the database

TOGAF (2007)

DCB Dutch Central Bank or De Nederlandse Bank Website DNB

DCOM Distributed Component Object Model Leist et al (2005)

(4)

Enterprise architecture framework

Provides an organizing structure for the information contained in and describing an EA. The framework does not contain the EA itself. Many organizations can use the same EA framework, but each EA with its content is organization-specific. Note that there are also other definitions used in this thesis.

EABOK Glossary (2006)

ERP Enterprise Resource Planning Sommerville (2004)

FD Functional Design Sommerville (2004)

formal structure The structure of an organisation as it should be according to formal documentation de Leeuw (2000)

Framework A structure, usually rigid serving to hold the parts of something together or to support something constructed or sketched over or around it. The basic structure, arrangement, or system.

EABOK Glossary(2006)

Function Grouping of processes and the related people and technology executing the processes Grigoriu (2006)

Functional testing Segment of security testing in which advertised security mechanisms of an IS are tested under operational conditions.

National Information Assurance (IA) Glossary (2006)

GDS All elements of GODS except Operations Grigoriu (2006) GODS Organisational functions : Governance, Operations, Development and Support Grigoriu (2006)

HQ Headquarters, or the central level of the organisation Triodos Bank

IA Information Architecture TOGAF (2007)

Integration Integration links the efforts of organisational units through shared data. This sharing of data can be between processes to enable end-to-end transaction processing (See STP), or across processes to allow the company to present a single face to customers

Ross et al. (2006)

integrity (of data) Quality of an IS reflecting the logical correctness and reliability of the operating system; the logical completeness of the hardware and software implementing the protection mechanisms; and the consistency of the data structures and occurrence of the stored data. Note that, in a formal security mode, integrity is interpreted more narrowly to mean protection against unauthorized modification or destruction of information.

National Information Assurance (IA) Glossary (2006)

Interface Common boundary between independent systems or modules where interactions take place

National Information Assurance (IA) Glossary (2006)

KPI Key Performance Indicator BPM forum

JEDMICS Joint Engineering Data Management and Control System TOGAF (2007) Layer A physical entity spanning the whole Enterprise. There are three layers : process,

technology and people

Grigoriu (2006) MIS Management Information Systems the science, a general name for the academic

discipline covering the application of people, technologies, and procedures

Targowski (2003) Plane A filter showing only an aspect of an Enterprise Layer Grigoriu (2006) Risk assessment Process of analysing threats to and vulnerabilities of an IS, and the potential impact

resulting from the loss of information or capabilities of a system. This analysis is used as a basis for identifying appropriate and cost-effective security countermeasures.

National Information Assurance (IA) Glossary (2006)

Service As defined for SOA: a specialised function of the enterprise which returns a product in response to a specific request

Summerville (2004) Service-Oriented

Architecture (SOA)

In Service Oriented Architectures, services, data, and workflow processes are enabled, through object-oriented languages, XML protocols, and standards, to be shared across the distributed, inter-connected set of users. (more extended info can be found in the referred book)

EABOK Glossary(2006)

Software Architecture The structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time. Source: IEEE Transactions on Software Engineering Vol 21 No 4 April 1995 guest editorial by Garlan and Perry

EABOK Glossary(2006)

SQL Structured Query Language TOGAF (2007)

Standardisation Standardisation of business processes and related systems means defining exactly how a process will be executed regardless of who is performing the process or where it is completed

(5)

STP Straight Through Processing, STP refers to fully automating the processing of transactions. In order to better realize the STP vision, powerful real-time

data integration and transformation capabilities are required.

Pan et al (2004)

SwA

Software Architecture, the high level viewpoint of the software to be developed. It consists of components, connectors, constraints, styles, patterns, and the like.

Chung (2007)

SysA

System Architecture, the allocation of the requirements between hardware, software and the network

Chung (2007) System Collection of components organized to accomplish a specific function or set of

functions. In this thesis the system is a considered as a sociotechnical system in which the human interacts with software in order to perform a process

TOGAF (2007), Leist et al (2006)

System Stakeholder (in this thesis abbreviated to stakeholder) An individual, team or organisation (or classes thereof) with interests in, concern in, relative to a system

TOGAF (2007)

TA Technical Architecture Grigoriu (2006)

To-Be Architecture The set of products that portray the future or end-state enterprise, generally captured in the organization’s strategic thinking and plans. It is commonly referred to as the ‘To-Be’ architecture.

EABOK Glossary (2006)

Workflow Workflow describes the automation of internal business operations, tasks, and transactions that simplify and streamline current business processes (source – http://www.WFMC.org web site)

EABOK Glossary (2006)

XBRL eXtensible Business Reporting Language: an open standard based on XML to exchange financial data

Woods (2003) XML Extended Mark-up Language: a text mark-up that supports the interchange of

structured data

(6)

Table of Contents

Preface ... 2

Glossary ... 3

Table of Contents ... 3

1 Chapter Guide ... 3

2 About Triodos Bank ... 3

3 Scope of research ... 3

4 Problem Analysis... 3

4.1 Preliminary problem statement ... 3

4.2 Pluriform analysis ... 3

4.3 Conclusions on pluriform analysis ... 3

4.4 Architecture related to Triodos Bank ... 3

5 Problem statement... 3

5.1 Business Objective... 3

5.2 Research Question... 3

6 Theoretical framework... 3

6.1 Quest for Architecture... 3

6.2 Evaluation of Enterprise Architecture (EA) Frameworks... 3

6.3 Type and focus of Architectures ... 3

6.4 Foundation of Enterprise Architectures ... 3

6.5 Business process Architecture (BPA) ... 3

6.6 Technical Architecture (TA) ... 3

6.7 Information Architecture (IA) ... 3

6.8 Principles of (Technical) Architecture development... 3

6.9 Enterprise Architecture Methodology ... 3

7 Research Sub Questions ... 3

8 Research conditions and limitations ... 3

9 Stakeholders analysis... 3

9.1 Executive Board (EB) ... 3

9.2 Risk Management ... 3

9.3 Controlling... 3

9.4 Financial Administration (FA)... 3

9.5 Local / Central ICT... 3

9.6 BU management ... 3

9.7 Co-workers loan department ... 3

(7)

9.9 Conclusions on stakeholders analysis... 3

10 Business Process Architecture (BPA) ... 3

10.1 Conclusions on the BPA ... 3

10.2 Recommendations on the BPA... 3

11 Technical Architecture (TA)... 3

11.1 IT Landscape of Triodos Bank ... 3

11.2 Description of systems within scope ... 3

11.3 Common used systems ... 3

11.4 Technical Architecture within the Grigoriu framework ... 3

11.5 Current System Analysis ... 3

11.6 Conclusions on the Technical Architecture ... 3

11.7 Recommendations on TA ... 3

12 Information Architecture (IA)... 3

12.1 Fitting the IA in the framework... 3

12.2 Gap analysis... 3

12.3 Information Credibility view ... 3

12.4 Conclusions and recommendations on the IA ... 3

13 Developing the To-Be Architecture... 3

13.1 Options for the To-Be Architecture... 3

13.2 Selection ... 3

13.3 Developing the To-Be Architecture ... 3

13.4 Refutation ... 3

13.5 First intermediate Architecture ... 3

14 Conclusions ... 3

15 Evaluation ... 3

15.1 Evaluation of this research... 3

15.2 Evaluation of used theory... 3

16 Bibliography ... 3 17 Appendix... Error! Bookmark not defined.

17.1 CRSA report...Error! Bookmark not defined. 17.2 IT requirements explained ...Error! Bookmark not defined. 17.3 Information provision from the pre-lending systems ...Error! Bookmark not defined. 17.4 The table underneath displays the information provision from the offer database. [This section has been left out in the public version of this research, due to confidentiality issues.] GAP analysis ...Error! Bookmark not defined.

(8)

1 Chapter Guide

This thesis presents a research into the subject matter of developing an Enterprise Architecture, specifically applied to the lending process at Triodos Bank. The case is specifically interesting, since the trigger for the project was upcoming regulations to be complied with. The structure of this thesis is as follows.

Chapter 2 gives a small overview of Triodos Bank, its vision on entrepreneurship and its products. The overview is deliberately kept small, since the research itself provides extended information on the organisation. Chapter 3 aims to gives the reader an introduction as a handle for the upcoming chapters. It introduces the new regulations, Basel II, that triggered the organisation to start this research and ends with the open preliminary project goal, which is to be attuned in the upcoming chapters.

From chapter 4 on, the actual research begins with performing a pluriform analysis on the stakeholders in the organisation affected by the Basel II. The pluriform analysis gives not only insight in the problems that direct related stakeholders experience, but also mentions the underlying causes and consequences that have lead to the current situation at Triodos Bank. At the end of chapter 4 the methodology of Enterprise Architecture is linked to the results of the pluriform analysis. From the end of chapter 4, Enterprise Architecture forms the theoretic basis for this research.

In chapter 5 the problem statement is related to the Enterprise Architecture (EA) methodology and the research question is posed. Normally the research sub questions follow directly after the research question. Yet, the Enterprise Architecture methodology is both extended as well as profound and therefore the full theoretic framework is introduced in chapter 6 first. The research questions applied to the EA methodology are posed in chapter 7, directly followed by the research conditions and limitations in chapter 8.

From chapter 9 the methodology is applied. First in chapter 9 with performing a broad scoped stakeholders analysis and thereafter (chapter 10 to chapter 12) the As-Is state of Architectures at Triodos Bank are described. Each description ends with conclusions on the As-Is state and recommendations for a future state (To-Be) of the Architecture.

Chapter 13 and chapter 14 conclude this research with an advice for the To-Be Architecture and an evaluation of this research. It also debates the differences found in the Enterprise Architecture methodology and reflects upon the research’ business objective.

(9)

2 About Triodos Bank

Triodos Bank was founded in 1980 in The Netherlands and is now a European Bank with subsidiaries in Belgium, the United Kingdom and Spain. Currently Triodos Bank is investigating possibilities for establishing a subsidiary in Germany.

The mission of the bank is:

• To help create a society that promotes people’s quality of life and that has human

dignity at its core.

• To enable individuals, institutions and businesses to use money more consciously in

ways that benefit people and the environment, and promote sustainable development.

• To offer customers sustainable financial products and high quality service.

(source: www.triodos.com)

The activities of Triodos Bank are comparable to those of other banks. The difference is that Triodos Bank incorporates its sustainable vision on entrepreneurship throughout all activities. For instance, its policy on granting a loan is based not only on financial considerations, but also social, environmental and cultural considerations are taken into account. Several businesses are excluded due to (the nature of) their (business) conduct, and as a result will not be financed by Triodos Bank. This strategy has led to the opinion of some researchers that Triodos Bank to be the most environmentally friendly and socially conscious bank in The Netherlands (broadcast of Zembla on 10 June 2007).

The strategy of Triodos Bank for the coming years is a strategy of growth based mainly on the use of the Internet (source: Annual report 2006). Triodos Bank and its funds under management have realised average annual growth of 22% over the past 5 years. This sustained growth has prompted a campaign for issue of Triodos Bank shares. . The share capital is needed to extend Triodos Bank’s lending operations in Germany in 2008, together with the strategy of growth for the upcoming years.

(Source: www.triodos.com)

This paragraph gives some insight in the departments at Triodos Bank on which this research has impact. [This section has been left out in the public version of this research, due to confidentiality issues.] Two years ago, a new organisational structure with a Central Office (headquarters, HQ) and Business Units (BU’s) had been implemented. Previously, the banks’ structure was formed by a bundle of equal BU’s that worked together. Nowadays, HQ formally manages the whole bank. The BU’s have to get used to this new structure (previously they enjoyed more freedom in decision making).

The Executive Board for Triodos Group consists of three members: Chief Executive Officer (CEO), Chief Financial Officer (CFO) and Chief Operations Officer (COO). This research is performed at the Group Risk Management department, which reports directly to the Executive Board via the CFO. Risk Management is a staff function and has an advisory role to the BU’s, whereas the Executive Board takes decisions, taking into account the advice of Risk Management and the business opportunities.

(10)

have to comply with the internal policies of Triodos Group and the external legislation in their country. Next to the benefits, this freedom also causes problems with respect to differences in processes and organizational structures between the BU’s, especially when the need for harmonisation arises due to the central ICT requirements.

Triodos Bank has several Business Units, each differing in size, life cycle moment and focus on development. Triodos Bank started its activities 26 years ago in the Netherlands with the Dutch Business Unit. This BU is the largest and most mature. An important focus of the Dutch BU is formalizing and streamlining its processes.

The next BU in size is the UK BU, which was an existing bank (Mercury Provident) acquired by Triodos Bank.

Table 1 Key figures about the BU’s at the end of 2006 (Save and Loans in millions of Euro) (Source: Annual report 2006)

BU

Credit loan

Deposit and saving

account # Co-workers (fte)

Netherlands 370,0 559 173,5 Belgian 148,4 339 37,3 Spain 243,9 397 61,7 UK 91,8 65.5 40,6 Germany ((agency) - - 3,3

(11)

3 Scope of research

In the last years, the Committee of European Banking Supervisors (CEBS) has issued a new Capital Requirements Directive to be effective from 1-1-2008 latest for all European banks (in fact all banks), called Basel II. These new regulations have a threefold aim: (1) to harmonize risk reporting of banks to supervisors in Europe, (2) to create a risk-based approach in banking organisations and (3) to take into account the complexity of the different risks included in today’s financial services environment. Basel II consists of a set of guidelines existing of a risk-based framework with three pillars: (1) Minimum Capital Requirements, (2) Supervisory Review Process and (3) Disclosure to the environment (Discipline of market). This research focuses only on the first pillar, the Minimum Capital Requirements.

Triodos Bank is based in The Netherlands, so its ‘home’ supervisor is De Nederlansche Bank (DNB). This year, 2007, is a transitional reporting year, as the DNB feels that one-year of parallel calculations/reporting (reporting under Basel I1 and Basel II framework) is needed to have an overview on the impact and consequences of reporting within the Basel II reporting Framework (COREP). Therefore, on the 30th of June and the 31st of December the Basel II reports have to be created and delivered the host supervisor, in addition to the traditional reports.

Within the Basel II framework, several approaches can be chosen to calculate credit, operational and market risk. The former deals with the risk induced by grating loans, the second involves the risk of failing processes and the latter deals with the risk of fluctuating currencies. This research mainly focuses at credit risk.

Triodos Bank has chosen to implement the Basel II framework through the "Standardized Approach" since it is the least complex method for quantifying risk exposure. Under this approach, the banks are required to use ratings from External Credit Rating Agencies2 to quantify the risk weight and calculate required capital for credit risk. Disadvantage of this approach is that Triodos Bank is bound to a higher minimum capital requirement than if they would have chosen another approach. Nevertheless, given the size and stage of development of the bank, this approach is considered to be acceptable. More advanced approaches can still be developed in the coming years.

To comply with the first pillar of Basel II, all banks in Europe have to report to their home supervisor bank twice a year. In case of Triodos Bank, the report to be delivered is the CRSA (Capital Requirements: Standardized Approach, Figure 2) report, as part of the COREP framework (a new reporting framework developed by the DNB). This report contains all irrevocable credit facilities3, thus all credit obligations of the bank both on-balance as well as off-balance and categorizes it into several risk weight classes. The sheet is too large to fully place it in this part of the thesis, but in Appendix Error! Reference source not found.on page 3 a larger picture can be found. The upper row of the report contains the aggregation of all facilities. The two rows underneath contain the facilities broken down to balance and off-balance, where on-balance refers to the loans paid out and off-on-balance to all loans not (fully) paid out but legally obliged to payout. The off-balance facilities are risk containing since they are irrevocable.

The rows underneath, categorize all facilities into risk weight classes, varying from 0% to 200%. In the end, by multiplying the risk weights with the amount of loan in a class, the capital

(12)

requirements can be calculated. This is done in the upper right corner of the sheet. An extended description of the process to compile the report is given in 4.2.2 on page 3. De Nederlandsche Bank it turn, reports to the European Central Bank and in this way insight is given in the stability of the international banking system (BIS, 2006).

The whole reporting process results is sketched in Figure 1 and the scope of the research is displayed.

Figure 1 Field of research

In order to comply with Basel II requirements, Triodos Bank has started a project two years ago to implement the risk-based approach in the organisation. Part of this project was to acquire the required information to compile the mandatory Basel II reporting. Given the mandatory character of the report, this project has high priority within the Bank.

(13)

Figure 2 CRSA report (low resolution) for one exposure class

After preliminary investigation (performed by the project team), one of the conclusions of the Triodos Bank project team on Basel II reporting was, that work had to be done on the reporting connected with the pre-lending process. This is the process prior to the lending process and will be explained later in this thesis. The required information to create the CRSA report from the pre-lending process appeared to be difficult to gather, as a result of different IT systems used by the BU’s to support their own pre-lending process and different ideas about the information requirements.

While the project team investigated the current information provision from the pre-lending process in the BU’s, 2 situations became apparent: (1) more functions within the organisation could benefit from the information stored in the applications and (2) the BU’s could benefit from better IT applications as well. Given the complexity of these new options, this research focuses first on Basel II compliancy of the pre-lending applications with a possibility to broaden the scope in a next stage.

(14)

4 Problem Analysis

The purpose of this chapter is to arrive at a problem statement after identifying and analysing several issues found at Triodos Bank. Research in the business administration is characterized by a pluriform vision on the organization to reveal problems and set priorities (De Leeuw, 2001). Next to that, De Leeuw (2001) mentions that often integration with domain knowledge is needed. In case of this research the additional domain knowledge from the Management Information Systems (MIS) domain is used.

Characteristic in business administration research is the difference between the cause and consequence of a problem. De Leeuw (2001) mentions this as the difference between instrumental and functional issues. Functional issues are issues related with the performance of an organization’s primary process outcomes. Instrumental issues are the penultimate causes of functional issues.4 Often for an organization, the occasion for research is the functional problem, whereas the instrumental problem remains unnoticed. Solving the functional problem would help the organization temporarily, as the cause is not taken away. Therefore, at the end of this chapter a consideration is done on issues to be solved in this research. This can be done after classifying the issues as instrumental and functional problems.

This chapter starts with a preliminary research objective that is précised later on. Thereafter follows the problem analysis for this research, from which a research objective is derived. This is done by performing a pluriform analysis on the organization, which can be seen as a preliminary investigation. According to Verschuren (1999) this should lead to a problem definition. Verschuren (1999) states, that during the preliminary investigation the problem should be diagnosed and a clear, detailed problem definition should be developed.

Figure 3 on the next page displays the stakeholders involved in this research that will be investigated in the problem analysis. As can be seen in the scheme, the external supervisor is left out of the scope of this research. This is done, since role of the external supervisor is to check on the integrity of the bank from outside.

4

An example of how functional and instrumental problems relate is, the low revenue on products due to high costs related to outsourcing and flexibility problems.

(15)
(16)

4.1

Preliminary problem statement

During the preliminary investigations on the Basel II project the project team learned that the current information delivered to headquarters (HQ) from the applications supporting the pre-lending processes at the BU’s appeared to be difficult to gather and insufficient to create the required and desired reports. Required in this context refers to the CRSA report and desired refers to more optional reports for stakeholders beyond Basel II.

The project team learned that none of the currently used applications within the BU’s fully complied with the necessary information requirements to create the CRSA report. Secondly they found that the information provided within the BU’s could improve on parts of data more security and data integrity, since only 2 of the 4 BU’s use software dedicated to storing data from the pre-lending process and the others use self-made spreadsheets.

Before this research was started, the project team carefully attuned the project goal with the management stakeholders, see Figure 3 on the previous page. This project goal was stated as follows: “Create a project proposal containing recommendations for software development in

the pre-lending process - based on the investigation of functionalities of current pre-lending systems and the related information requirements of the stakeholders - in order to clear the deviations in reporting to the headquarter, reduce the operational risks and comply with Basel II reporting.” The scope is explicitly kept open (by not making all stakeholders explicit), since there is a possibility that more stakeholders could benefit from this project. The proposal mentioned should include conclusions to what extent it is possible to choose one system to be used by all BU’s.

4.2

Pluriform analysis

The Basel II legislation has an impact on the whole organisation from strategic to operational level and could be seen as the motivation for first revealing and then solving deeper problems in the organisation. The instrumental problems, rooted in the organisational history, are the drivers for the current state of the organisation. In this pluriform analysis all direct functions within the whole organisation effected by the Basel II legislation were inquired. As part of the pluriformity, during inquiries not only the issues related to the Basel II implications were investigated.

4.2.1 Central organisation view & Executive Board

At the top of the organisation, the Executive Board of Triodos Bank in the end bears the responsibility for the Basel II compliancy. The supervisor could disagree with the quality or content of the report or the quality of processes established to create the report. This could result in a higher risk profile for Triodos Bank and therefore the supervisor could take measures, including setting higher capital requirements. This higher capital requirement induces capital costs.

Next to that, the strategy of growth mentioned before is linked to the Basel II reporting obligations, since the (current) capital of the bank determines the maximum growth according to the Basel II regulations. The minimal amount of equity is set by DNB partly based on to the minimum capital requirements from the Basel II CRSA report. It is important to mention that the more precise the information for this report is delivered the lower the minimal capital requirements are supposed to be. The reason for this is the fact that obligations are classified as incorporating a greater risk if less information about these obligations is known. Or the other way around, more detailed information on an obligation leads to insight in the factual risk.

(17)

One of the business objectives of Triodos Bank is to improve the quality of the processes to market standards, both internal as well as external. This is in line with its strategy of growth, since these professional and structured processes could be seen as pre-conditions for healthy growth (Mintzberg, 1979).

[This section has been left out in the public version of this research, due to confidentiality issues.] . Yet, one legacy of the old structure is that the BU’s have their own processes and vision on these processes, since they were formerly independently managed, which also was a strategic choice. On the operational level of the BU’s there was a need to attune the business processes to the local cultural and environmental situation, which is different at all BU’s. This has lead to differences in reporting to headquarters, not specifically for reports connected to Basel II, but also other reports5.

[This section has been left out in the public version of this research, due to confidentiality issues.] Professionalising the organisation also refers to creating processes and reporting structures that are uniform at the organizational level. In conclusion it can be said that the current Basel II incompliancy and the possibility of low quality are functional problems for the organisation as a whole.

4.2.2 Risk Management & Financial Administration

The Risk Management department is project leader for the Basel II compliancy project, since Basel II aims to create a risk-based approach throughout the organisation. This research is performed from within the Group Risk Management department, which is a staff department advising the Executive Board via the CFO.

The aforementioned CRSA report contains information from different stages in the lending process, from the moment that a facility turns into an obligation. The complexity of the whole process lies in the facts that (1) a CRSA report exists of 15 sheets like Figure 2 for each risk exposure class, (2) different systems have to be consulted to create the report and (3) different currencies are used by the BU’s. The Financial Administration creates the CRSA report, as part of the COREP report, and delivers it to DNB. The process for creating this report is sketched in Figure 4. At first, for each BU the CRSA report is generated by the ERP system; 4 times 15 sheets. These CRSA reports are manually combined to one report. This is a labour intensive and failure sensitive process, since it requires search work. [This section has been left out in the public version of this research, due to confidentiality issues.]

One pre-lending CRSA report for all BU’s is created from the output delivered by the individual BU’ s, which implies at least 4 sheets to be aggregated. The creation of the pre-lending CRSA sheet is also a labour intensive process for both the BU’s as well as the FA. The separate output files, each in its own format, of the BU are first categorized over the 15 risk exposure classed and then combined in 1 pre-lending CRSA report.

Thereafter, manually a consolidation CRSA report is made for each exposure class for each BU by the financial administration by combining the information stored in the financial administration (Exact) with the ERP information and pre-lending information. In order to make the consolidation, the ledger information should fit the all the CRSA information. If the numbers do not match, the reports need to be manually checked to solve the deviations.

In the end, all CRSA reports have to be combined to one final report, which is done by the financial administration. The problem for the financial administration is that the creation of the Pre-lending CRSA report is labour intensive, due to [This section has been left out in the public version of this research, due to confidentiality issues.] and different formats of reports from the BU’s. For the whole process approximately 90 sheets have to be collected into one report.

(18)

Figure 4 Creation of CRSA report

The pre-lending systems used at the BU’s differ from a complete Database Management System (DBMS) as used in the Dutch business unit to an Application_Y in the UK and a CRM tool in Belgium. The pre-lending systems also differ in information provision, which lead to the fact that currently the information delivered by the BU’s is not uniform. None of the tools currently used at the BU’s fully complies with Basel II, since not all required information for Basel II is stored. Either the BU’s themselves add missing information or the Financial Administration adds this by giving the items in the report a higher risk exposure. This leads to a higher minimal Capital Requirement for the bank, which could have a negative effect on the maximum size of the loan portfolio, as this is also restricted by the amount of own capital available.

Another problem the Financial Administration faces concerns the output files of the pre-lending systems. In the current situation the output files are sent by the BU’s and thus the BU’s determine the start time for the FA. Since creating the reports takes a lot of effort, timely delivery is of importance.

Next to the Basel II reports, the Financial Administration has to deliver the traditional report, Basel I, to DNB as well. However, in the end, this report is to be replaced by the Basel II reports. The traditional report includes the liquidity, solvency and large loans of the bank. Like the Basel II reports, this report also contains information from the pre-lending applications, next to the ERP and the book keeping system.

And, like the Basel II reporting creating this report is labour intensive and the process is failure sensitive. The current situation for the financial administration could be more efficient and reliable if the pre-lending tools were adjusted to the requirements of the financial administration.

(19)

4.2.3 ICT Department

The ICT department is mentioned twice in Figure 3 as stakeholder, since there are ICT functions at the central level but also at the Business Units. In this section the central department is discussed, the BU specific ICT department is mentioned in the next section. The instrumental causes for the problems currently faced could be related to the ICT management of the organisation. The Central ICT department is organised in two sub departments: one focuses on the development and management of the ERP system and the other on IT infrastructure management.

Within the ICT department several issues are currently faced: • Basel II compliancy

• Capacity problems for the software development section

• Perceived usefulness of ERP system (Amaoka-Gyampah, 2005) • Management of Pre-lending systems

• More project to be implemented

The Central ICT department is responsible for building the functionality to comply with Basel II only for the (centrally managed) ERP system. The decentralised systems are out of their scope. The adjustments of the ERP system to comply with Basel II are implemented in 3 phases. Three releases of the ERP system are coming up with Basel II adjustments. One of the upcoming releases has a new functionality, resulting in a movement of the moment of entering loans in the ERP to an earlier stage. This should lead, to a shorter pre-lending phase and has consequences for the information stored on the pre-lending process, for the BU’s their pre-lending processes and for the Basel II reporting. Contrary to the ICT departments at the BU’s, the central department does not have a functional problem with the Basel II reporting, since the adjustments are planned, performed and will be implemented.

[This section has been left out in the public version of this research, due to confidentiality issues.] The reason for developing a system in-house is threefold: (1) the processes within the bank were too specific to implement in an existing ERP system, (2) the time to implementation was very short and (3) the costs for buying a system and adapting it to their needs were relatively high.

A problem related to the ERP system is that the perceived usefulness (Amaoka-Gyampah, 2005) of the ERP system is relatively low. [This section has been left out in the public version of this research, due to confidentiality issues.]

When waiting time for ERP development projects is too long, the users will to search for their own solution. This implies that systems are developed and used that are not connected to the ERP system. The consequences are twofold: (1) the information in the unconnected systems have to be entered twice in the systems, (2) unconnected systems have to be managed by the management section of the ICT department. The former induces problems for the users, and operational risk due to double data entry. The latter causes problems for the Management section of the ICT department since the independent systems are not easily managed and not always visible. Some (simpler) systems are managed by the local ICT department and will not cause labour for the central ICT department, but more complex systems, like DBMSs, require attention from both the local as well as the central ICT department. In these cases the local ICT departments takes care of keeping the system operational and functional, whereas the central ICT department enables the use of system within the infrastructure.

(20)

[This section has been left out in the public version of this research, due to confidentiality issues.] As mentioned, the processes within the organisation also deviate and in combination with different IT systems, centralisation of IT is difficult for the IT department. Regarding the pre-lending process for example, all BU’s have their specifically arranged process, individual focus on lending and in line with that a specific IT solution for support. Centralisation of pre-lending would be difficult as (1) requirements from the BU’s shall not be the same and (2) it would cause resistance from the users on operational level.

The project on Basel II pre-lending reporting with a possible broader scope, could contribute to a future pre-lending centralisation project, if this would start. Also this research could contribute to the vision on ERP development and to a solution for the capacity shortage on ERP development. Recently a new Chief Operations Officer has been engaged and a new vision and strategy on operations, processes and IT is considered.

Concluding can be said that the central ICT department faces functional problems, which are instrumental problems for other parts of the organisation. Also, the issues of this department could lead to research limitations and conditions for developing a solution.

(21)

4.2.4 Business Units

Next to the stakeholders at headquarters, the BU’s are stakeholders of the Basel II project. The gathering of information and input from the systems about the pre-lending process takes places at the BU’s. Therefore, the cooperation of the employees at the BU’s is of importance. Although in first place the BU’s did not indicate to have a need for improvements, after inquiries, it appeared that the Business Units did face several functional problems:

• The BU specific pre-lending application has to be adapted to the Basel II requirements • Inefficiency of processes due to adapting processes to ERP system

• [This section has been left out in the public version of this research, due to confidentiality issues.] Delivery of reports to Headquarters is time-consuming

• Internal information provision could be improved • Uncertainty about the future pre-lending project • Mutual comparison of BU’s

The adjustments of the pre-lending systems to the Basel II requirements are the most important issues due to the compulsory character of the information to be delivered. Each BU uses its individual system to support its processes for that part outside the ERP system. The BU’s indicated that some resistance existed against the Basel II project, since they need to perform more work, like storing more information about their processes and making and delivering the output files for Basel II. Also resistance appeared to exist due to the fear of implementing a new information system for their pre-lending process, which could lead to costs for implementation and adaptation of the business processes to the new system.

The processes of Business Units deviate, due to the following reasons: (1) some of the BU’s have been acquired by merging and previously had their existing business processes and IT systems; (2) the environmental aspects like regulations and business culture in the countries of the BU’s deviate, (3) the previous organisational structure and management gave the BU’s freedom to organize their processes and systems and (4) this aforementioned freedom is grafted entrepreneurial approach of the organisation. In line with the strategy and new organisational structure, centralisation and standardisation of processes at the BU’s had been started.

Important to mention is that not only the processes deviate, but also (1) the definition of pre-lending, (2) the functionalities needed for an IT system to support pre-lending and the definition of information within the pre-lending systems.

The intention to centralise the ICT systems could raise some resistance at the BU’s, since the current processes have to be adapted to the standards prescribed by HQ and the ERP system. This leads to lost of freedom for the BU’s in arranging their processes and using IT systems.

If in future headquarters makes the decision to centralise the pre-lending process, the BU specific vision and functionalities for the pre-lending process may be threaten. This would raise resistance against the pre-lending project, which makes it a problem for headquarters too. The decision for centralisation is for future concern and beforehand at least uniformity on data and functionalities should be accomplished. Since Basel II reporting also requires uniformity of information, this project could be a great opportunity for the BU’s to let them learn from each other and pick up best practices.

[This section has been left out in the public version of this research, due to confidentiality issues.]

(22)

reports themselves. The process of creating the reports could be improved. With the current process of pushing forward the information from one to another (from Business unit to the central level), both headquarters as well as the BU’s experience room for improvement.

Both the central level as well as the BU’s could benefit from comparable reports on the performance of the BU’s. In the current situation the performance reports are not comparable, since each has its own format.

Although not all BU’s admit that, the internal information delivery could be improved. There are several departments within the BU’s, which could use the information gathered in the pre-lending applications. For example marketing information could be derived from the ratio of offers that is agreed. On the other hand, liquidity forecasts could be made for the section that manages the payouts of loans. From the reports delivered to the central level the need for improvement clearly arises. This improvement of the processes at the BU’s is in line with the strategy of the bank mentioned on page 17 and thus has a certain priority.

(23)

4.3

Conclusions on pluriform analysis

In this paragraph, the conclusions derived from the pluriform analysis are drawn and a distinction is made between the main problem and side problems to be researched. In Figure 5, the current problems with direct influences on the organisation are displayed with a link to the problem owner. The problems displayed could in the end be linked to functional problems if a relation can be made with the performance of the organisation.

Scholars like De Leeuw (2001) and Jonker and Pennink (2000) mention that good research not does not only solve the superficial problems, but also takes away the deeper underlying causes of these problems. In the pluriform analysis some of these causes were described and in this part an explicit link is made.

From Figure 5 can be seen the difficulties of creating the CRSA report could result in problems for headquarters, since the higher capital requirements could influence the maximum growth. This could be seen as a functional problem, since it directly influences the output of the organisation. The arrow between the General reporting problems and the Difficulties with creation of the CRSA report refers to the fact that creating the CRSA report is one of the general reporting problems. In the current scope of the research only this report is of importance, but there are more problems with reporting to headquarters. The reporting problem is an instrumental problem, since it is not directly linked to the output of the organisation. The comparison of the business units is explicitly not only linked to the headquarters but also to the business units, since they could also benefit from each other’s reports.

(24)

relation with the experienced problems. The causes (with underlying relations with other causes) of the effects are mentioned at the left site of the effects. Some causes have relationships with other causes and some of them do not directly link to effects.

One note about Figure 6 should be made; the effect of improvement of internal information provision is left out the effects, since it does not suit the definition of a problem for a problem owner according to De Leeuw (2001). He states that a problem is based on the difference between the current situation and the desired situation The BU’s did not indicate that they experienced a need for improvement, but the central level does. The Risk Management department is added to the figure, since this department is project leader of the Basel II project team.

To come to a conclusion about what to investigate during this research in order to enable proper Basel II CRSA reporting to headquarters, the model should be consulted. This is done by iteratively focussing on the relations of one effect with the causes and the underlying causes. Thereafter iteration could be done from the problem causes to the effects to investigate which problems also could be solved by taking away the underlying causes.

When looking at the difficulties to create the CRSA report, which is a problem belonging to the Financial Administration, the direct underlying causes can be found in:

• The differences in reporting by the BU’s • The problem of the uniformity of data

(25)

These causes have direct relationships with:

• The use of different pre-lending systems at the BU’s (light grey arrow) • The differences in business processes at the BU’s (light grey arrow)

In the end the differences in processes and use of different IT systems had lead to a different vision of the BU’s about pre-lending. The freedom and independency within the old structure of the organisation can be seen the starting point for the problems. This freedom given at the BU’s in the past is rooted in the organizational history, as three out of four BU’s were previously independent banks and the conscious choice for adapting processes to local circumstances as part of the entrepreneurial approach of the organisation. When continuing the iterative cause-cause chain, the found issues could finally be dedicated to the organisational history, the ICT department and the cultural deviations between the BU’s6. The organisational history and cultural and environmental deviations cannot be changed and thus are out of scope of the research.

The adaptation of the pre-lending systems to make them Basel II compliant is a problem that belongs to the BU’s. The cause for need for adaptation of the pre-lending systems can be found in the combination of the facts that (1) there are pre-lending systems that (2) are aligned to the business processes at the BU’s and (3) developed during a period when reporting was not that complex. (As mentioned Basel I reporting is less complex.) The reason that these applications exist lies in the fact that the pre-lending phase was out of scope during the development of the ERP system.

Given the fact that Basel II is mandatory, the following conclusions can be drawn: 1. Basel II should be a must have for this research

2. Basel II reporting is part of a broader reporting problem in the organisation

3. Any solution for solving the Basel II reporting could influence the problems directly related in the model

4. Regarding the broader reporting problem, the information provision from the BU’s to headquarters could be improved and the Basel II research is a great opportunity to start from. Now that the conclusions on the problem field are drawn, the scope of the research could be defined, which gives insight in all problems found at Triodos Bank. Striking out elements in Figure 6 on the previous page in accordance with the conclusions lead to Figure 7.

First, the non-Basel II related effects were stroke out: general reporting problem, resistance against ERP, comparison of BU’s and the management of the pre-lending systems. Thereafter the causes behind the effects were considered out of scope and then the non-relevant problem causes, if any. The effect of the capital requirements on the limitation of growth is considered as marginal, since more aspects determine this limitation. Therefore, although it appears somewhat paradoxical, this effect is also stroke out.

The vision on pre-lending is an issue that is remained in the scope of research since it could be taken into account when defining solutions for the problem. Next to that, this research could raise awareness about the deviating vision on pre-lending within the organisation.

(26)
(27)

4.4

Architecture related to Triodos Bank

The aim of this section is to introduce the methodology that best applies to the problems of Triodos Bank and to relate it to the situation at Triodos Bank. It tries to relate all problems mentioned in the analysis to the same field of subject, next to the relation in cause and consequences.

There are many perspectives from which the problems could be solved, each of them leading to a solution that fits its methodology at best. For instance, it could be treated as a traditional software development problem probably leading to the best software development methodology.

Regarding the problems found at Triodos Bank, it appears that the research scope is broader than only the IT systems, see Figure 7 on page 3. It includes uniformity, a possible future project and business processes as well. Therefore, the methodology for this research should involve these elements too.

A possible point of view is Architecture, like Enterprise or System Architecture. The methodology behind Architecture involves business processes, strategy and organisational structure next to IT systems. Therefore the result could contain aspects like business process alignment, integration and communication between BU’s and headquarters, which probably would suit the problems at Triodos Bank better than software development methodology.

According to Leist and Zellner (2005), the term Architecture refers to any kind of sociotechnical system, and refers to the fundamental organization of its components and their relationships to each other and the environment as well as the design rules for developing and structuring the system.

Sociotechnical refers to a system in which human behaviour is related to technological aspects and was found in many articles and books about Architecture (Sommerville, 2004; Grigoriu, 2006; Targowski, 2003; Leist et al 2005). In the context of this research the term sociotechnical refers to the combination of the people, processes and the information technology to perform the processes. As can be seen in Figure 7, the problems at Triodos Bank contain these elements of a sociotechnical system and there is a need for restructuring the system. Therefore according to Leist at al. (2005) the problems at Triodos Bank can be related to Architecture.

Now that Architecture appeared to be an option for methodology in this research, the next step is to search for matching statements on Architecture related problems/ solutions in literature. Ross et al. (2006) come up with a list of warning signs of a company that doesn’t have a foundation that supports its strategy. Some signs in this list are clearly in line with the conclusions found in the pluriform analysis. These are:

• Meeting a new regulatory or reporting requirement has major effect on the organisation, requiring a push from top level and significant infrastructure investment

• IT as bottleneck of the organisation

• Information needed to make decisions is not available

• Different business processes across the organisation completing the same activity, each with a different system

• A significant part of peoples jobs is to take data from one set of systems, manipulate is and entering it to other systems

Ross et al. (2006) come with Enterprise Architecture as strategy as the solution for these typical problems.

(28)

When looking at the framework in Figure 7, the most important problem causer appears to be the freedom given to the Business Units during the old organisational structure, referred to in the model as organisational history. Durvasula et al (2006) mention this freedom in IT management often ends up in the deployment of multiple systems, which perform the same tasks within an enterprise or business unit in a different way. A possible problem could then be the connections between these systems. He relates the causes and consequences to the concept of Architecture7. According to Grigoriu (2006), the current structure of an organisation is often the result of organic growth and not usually the outcome of a deliberate process. Often the structure of the organization is not in line with its goals and more often the organization has little notice about its structure. The methodology behind Architecture aims to create a structure congruent with the goals, for Architecture methodology has its roots in the strategy and planning world of large organizations (VanBerg, 2007, Leist et. al. 2005).

Using the Architecture methodology would not only solve the problems for Basel II pre-lending reporting, but also could encourage a long-term solution for IT development and give directions for the possible future pre-lending project.

All problems revealed that are in the pluriform analysis can be related to information streams across the organisation. According to Grigoriu (2006) Architecture involves to the streams of information within the Enterprise. This fits exactly with the problems found at Triodos Bank. Whittle et al. (2004) formulated a definition of Architecture that is closely related to the scope used at the pluriform analysis, since they define it as the enterprise value streams and their relationships to all external entities and other enterprise value streams and the events that trigger instantiation. It is a definition of what the enterprise must produce to satisfy its stakeholders8. It is composed of architectures, workflows and events. The Architecture links the business processes, management and the information systems that support the processes. In case of Triodos Bank, there is a clear relation between stakeholders at the headquarters relying on the workflows of the business units.

The last thing to mentions for using Architecture as main methodology is that Grigoriu (2006) also states that the framework of Architecture enables risk managers to realize compliancy with regulatory rules, like Basel II, SOX, etc. Next, he states, “By 2007, Enterprise Architecture will be one of the most critical factors in risk management.”

7

He relates it to the Service Orientated Architecture, but this is not explained yet and whilst not explicitly mentioned in this paragraph

8

Whittle et al (2004) mentions: customers, compete in a market, deal with its suppliers, sustain operations and care for its employees

(29)

5 Problem statement

In the previous chapter, some issues were mentioned and conclusions on problems found were drawn. Next to that, an introduction was given into the goal of this research. This chapter formulates the problem statement according to Jonker and Pennink (2000). It consists of a research goal with a logical derived research question. The combination of both formulates the total scope of the research, including the research conditions and limitations.

The research sub questions will be introduced after the theoretical chapter, since they contain substantial technical aspects.

5.1

Business Objective

The business objective has been derived from the conclusions of the pluriform analysis. According to Peterson (2002), to define the business objective the wish of the organisation related to the project should be considered. From the pluriform analysis, it appeared that:

The headquarter of Triodos Bank wishes to have the ability to create reliable reports from uniform outputs delivered by the business units in order to clear the deviations in reporting to the headquarters, reduce the operational risks and comply the Basel II reporting. Whereas the BU’s of Triodos Bank whish to have a reliable application, that covers the pre-lending process according to its functional and reporting requirements.

The business objective is therefore to:

Make the pre-lending process systems compliant with the Basel II requirements and create an Architecture that satisfies the requirements of the stakeholders at best.

Compliant in this sense refers at fulfilling the requirements for information integrity and creating the Basel II reports and Architecture refers to the organization of business processes, strategy and organisational structure and IT systems. Architecture will be explained extendedly in the next chapter.

The research itself should result in a proposal with recommendations for future architecture development including conclusions to what extent it is possible to choose one integrated system to be used by all BU’s. It is important to mention that in the evaluation for the best applicable Architecture the possible resistance against mandatory changes on IT should be taken into account.

5.2

Research Question

The research question, which must be answered, in order to be able to fulfil the business objective, is stated as follows:

What is the ideal structure of an Enterprise Architecture for the pre-lending process that satisfies the requirements from the stakeholders at best given the current state of the Enterprise Architecture?

Normally in research, the sub questions follow immediately after the main question. Yet in this thesis first the theory is introduced, since the sub questions contain theoretical elements.

(30)

6 Theoretical framework

This chapter describes the academic background of the problem field of this thesis after a literature study had been performed. At first a quest for the type of architecture matching this research is performed. Thereafter the methodologies found for this type of architecture are described and a methodology for this research is chosen. This chapter ends with a model that describes the relationship of the relevant elements in this research.

6.1

Quest for Architecture

This section explains the different types of Architecture found, and the most applicable shall be chosen for this Architecture. From literature research it appeared that more, three, types of architecture methodologies exist, each with its found, each with its own organisational level of aggregation:

1. Software Architecture 2. System Architecture 3. Enterprise Architecture

Figure 8 Types of architecture (source: Hagan et al 2004)

The definition of Software Architecture (SwA) is given by Chung (2007) as “the high level viewpoint of the software to be developed. It consists of components, connectors, constraints, styles, patterns, and the like.” Sommerville (2004) also distinguishes the software architecture as a compact manageable description of how an information system is organised and how the components interoperate.

In literature (Targowski, 2003) some software architecture methodologies were found. For example CORBA and DCOM are two early service-based techniques for interface communication that have been around for a long time. The early launch of these technologies gained a lot of attention, but the technologies were not widely used due to the lack of network bandwidth and relatively sluggish performance by some of the early implementations of CORBA (Hagan, 2004). At this moment, these methodologies are decried and almost forgotten.

The System Architecture (SysA) considers the allocation of the requirements between hardware, software and the network (Chung, 2007). Since the Architecture is still part of a sociotechnical

Referenties

GERELATEERDE DOCUMENTEN

The reasons for this are manifold and range from the sheer scale of the infrastructure (with nearly a billion people using online tools); the level of sophistication of social

Mr Ostler, fascinated by ancient uses of language, wanted to write a different sort of book but was persuaded by his publisher to play up the English angle.. The core arguments

The question whether domestic monetary policy is able to control credit growth and bank lending in a globally integrated economy, can be answered by the

Although the field of economics, health and law investigate different theoretical questions, they have in common the use of neuroscientific research results for applied purposes

KVSJTQSVEFODF JUTJNQBDUPOQPMJUJDTBOE QVCMJDNFNPSZIBTCFFONPSFBNCJHV PVT5IFDSJNFTUIBUMFEUPUIF5PLZP

It does not incorporate the needs variables as set forward in the IT culture literature stream (e.g. primary need, power IT need, etc.) Even though some conceptual overlap exists

Poetically speaking, birds are the freest of creatures: they sear through the heavens without any regard for borders. Folktales and myths move in a similar fashion. Instead