The implementation of e-administration is a challenge to be achieved in public administrations in all its levels. This objective, entails a set of strategic decisions of great impact on the organization from the organizational and technical point of view. These decisions are usually taken without any model or formal support that represent the reasoning. To solve this problem, we propose the use of modelling techniques using the language i* for designing a strategic system plan in a large public corporation, concretely, in the case of a regional government administration. For this purpose, we have used the strategic rationale and the system dependencies graphs by using the modelling language i*. So in this article we show a little part of the broad work consisting in the use of this modelling technique to decide how to approach the back-end infrastructure of this corporation taking into account that it inherits a very broad set of databases. We aim defining a working strategy on the back-end using modelling techniques.
In the last decade there is an increasing interest in the administration’s realm in implementing e-administration. Although this term has associated different areas of application and use, for the purposes of this article, we will refer it as the objective of bringing the administration closer to the citizen. More specifically, bringing the government processes that affect them using technology as an exclusive mechanism for interaction between the citizen and the administration. We are focused within the scope of the regional government of the Autonomous Community of Valencia, located at the east of Spain
There is many research written about this issue (
The application of modelling techniques using the i* language (
In this article we will reflect a small part of our work: specifically, we will perform a reduced exercise using fundamental reasoning for making decisions about the legacy databases conforming the back-end in the regional government information systems. The structure of the document is very simple: in the next section we will make a brief definition of the problem, then the practice use object of the article. To finish with the conclusions and the further work to be developed using these techniques.
In Spain, an autonomous community (regional government), is a first-level political and administrative division, created in accordance with the Spanish constitution of 1978, with the aim of guaranteeing limited autonomy of the nationalities and regions that make up Spain. Therefore, Spain is a highly decentralized unitary state in which the regional government is organized in a similar way to a state government, that is, distributing the competences into Regional Ministries, from now on in Valencia’s government, Consellerias. Valencia’s government (GVA, onwards) is a regional government that manages 5 million inhabitants, that is, the same order of citizens that countries such as Finland, Slovenia, Norway or Ireland.
The implementation of electronic administration is driven by European directives
and assimilated by the state’s administration (
Anyway, many decisions have to be made to implement this great objective. Our goal is to use modeling techniques that help make decisions in a government realm, both from a technical and organizational point of view. By applying this techniques, we are facing the challenge of implementing electronic administration definitively in the GVA.
Taking into account the unification of the entire ICT organic structure under a single leadership, the next important issue is what to do with all the legacy ICT infrastructure with the e-administration objective in mind. Concretely, how to consolidate or unify them without losing sight of the fact that ICTs have to work in a 24x7x365 mode.
In this article we develop a strategic decision exercise regarding the back-end which are the databases where all the data of the regional government reside. This includes the files of the students from school since university, even the judicial files going through all the information that makes up the government's ERP. It is a reduced scenario of the total complexity of this problem with the objective that the article be as consistent and complete as possible.
All this information resides in a set of almost a hundred databases of different sizes that are supported by different databases management systems (DBMS). These databases come from different Consellerias that had their own ICT administrators. This means that the different Consellerias manage their own databases that do not necessarily match the criteria of the others. Therefore, we have about 100 databases systems with different management criteria and different DBMS. The DBMS that were used were the following: • • •
SQLServer: 10%
Postgress: 5%
The different databases coming from the different Consellerias had very specific functional areas. For example, the databases that come from the Consellería de Agricultura (Regional Ministry of Agriculture) contain information and support information systems (SI, hereafter) that they have nothing to do with the databases that come from the Consellería de Justicia (Regional Ministry of Justice). That is, the competence areas are very marked and the IS and the data they use are clearly delimited.
That being the case, we propose to assess what to do with the legacy back-end in a strategically point of view. We will use the modeling language i* to represent the fundamental reasoning in decision making. This is part of large work focused on defining a strategic system plan of the corporation using modelling techniques. This research is part of a large work aiming to define a strategic system plan of the corporation, hence its novelty. It’s about applying a modeling language that helps to develop a strategic plan on technical issues in this regional government. Broadly, the differentiating aspect of designing the strategic system plan in this way, is that we are not only interested in technical issues, but we are also interested in the aspects such us intentionality (why?), social (who?) and strategic (how? how else?). The interests in modeling this way led us to the use of modeling language i*.
We expose the strategic rationale that guides us in the strategic decision making of what to do with all the databases inherited after organic unification.
In the databases case, we face with different characteristics that may be seek in one way or another. These characteristics, described next, are not objectives because the criteria or the way to achieve them cannot be clearly established: • • • • •
Optimal use of human resources (HR): What staff effort requires the chosen option? Direct improvements to the end user: will the action that we are going to perform be noticed by the end user in a direct way? Isolate the databases in case of problems: In case of problems in a database, the rest of the database may function normally.
Savings in infrastructure: Can we achieve savings in infrastructure in any of the cases? Ease of management: taking into account the volume of databases, it is not trivial to look for a solution compatible with the everyday tasks as well as the projects that have to do with the databases. The everyday tasks may not affect the normal development of project and vice versa.
Although desirable, it is extremely difficult to achieve all the issues exposed before. Thus, to reach a balance between all of the exposed criteria, we settled on a three fundamental options to decide. The first option to consider is to unify the databases instances, meaning that each DBMS are continue existing as they are and will not migrate from one DBMS to another. In this way, the three more extended DBMS installed are managed: ORACLE, Postgress and SQLserver. What we intend is to unify the databases by DBMS, each with its set of instances. In this case, necessary tasks will be performed in each of the three DBMSs for each database instance:
the same storage criteria with respect to all the operational structures of databases: data files, redologs, archivers, etc.
To consolidate naming criteria: All database objects names must have the same criteria.
To consolidate programming criteria: The use of the databases and the way they are attacked should be standardized.
These last two tasks imply that the databases must be revised by changing names of objects and, therefore, this work involves not only the database and system administrators but the development teams: these changes mean changes in database procedures that developers should do.
A second option is to consolidate the DBMS. That is, if we decide that our DBMS is ORACLE, then all the other DBMS (POSTGRES and SQLServer) have to be migrated to the target. This is a great effort: it requires a huge work in development by many technicians since everything has to be reprogrammed more radically, even than in the previous option.
This option may involve the option to unify instances: if all the the databases are using the same DBMS, it is normal to think about reducing the number of instances 1, repeating the tasks we have in that option. In the scheme this option appears as a subtask in different colour, meaning that is the same task with the same subtasks written in the schema.
The last option is to keep the instances as they are. This option requires managing them with the same common criteria but not doing anything about their own objects. We must bear in mind that having their functional separation can be an advantage as well. Once exposed the different options, a relationship between the different options and their characteristics will be discussed to address the objective.
Regarding the use of HR in the task: It is clear that all tasks involve HR. What happens is that the two consolidations involve large multidisciplinary teams. This means that, while addressing this issue, the applications do not advance from the functional point of view nor can new applications be created. To differentiate the greater impact in the case of the consolidation of instances rather than in the 1 An instance is any database started in an ORACLE database server consolidation of DBMS, a differentiating contribution of each one has been marked: break in one case and hurt in the other.
With regard on direct improvements for users, it is not expected that, in any case, end users notice any significant improvement. In the event of either consolidating the instances or the SGBDs, the work of reprogramming implies a huge investment in funds and HR. Therefore, in the best stage, the user perceives the applications as before. On the one hand, leaving the instances as they are, taking control by the systems team, is the simplest solution regarding investment and, it is the most affordable due to nothing has to be reprogrammed. On the other hand, it is the one that makes the best use of HR since it only involves system administrators. Therefore, developers can continue their tasks in new applications adding new functionalities.
Isolate database problems: The instances consolidation implies having databases running in a smaller number of instances. This means that any incident on the database management system will affect more users. Although in the graph we are not considering the number of instances, in the case of unifying instances or DBMS, the number of instances will be smaller, increasing the possibility for this to occur. However, if we leave the current diversification, the malfunction of one of them only affects a small (or rather concrete) set of users.
Regarding infrastructure savings. Without getting involved in issues of licensing, all the approach raised have improvements in saving infrastructure. However, the first two options imply a very significant investment in time, human and financial resources: we need programmers to adapt the data and procedures to the new criteria or to the new DBMS.
Ease in administration: in all three options, ease in the administration is guaranteed since taking control of all of them means that they will be known to the administrators. Nevertheless, the fact of consolidating instances means reducing their number, then, facilitating the administration. Yet, consolidating the DBMS implies the same consequences. The third option, which reduces the number of instances, is supposed to have more administration tasks Taking into account the factors explained above, it is reasonable to deduce that the best option is the third one: it can be applied without affecting news developments, it affects a smaller set of technicians, the tasks to carry them out are more economical, they allow us to have differentiated the IS in its data and to finish, this decision does not condition that, in the future, the other options can be addressed. 3
Conclusions and purpose of the work.
The goal of this paper is to report a practical use of i* to help in the decision making process of an organization where the involved information has a technological-oriented perspective. What we want to show is how the application of i* in this working context provides useful results and facilitate taking the right decision with a well-supported, conceptual basis. In the example we have raised the strategic rationale (SR) of an important concrete issue: to face the problem of having a large set of database systems from an enterprise unification process.
But we do not remain only in the use of strategic rationale for the construction of the organization systems plan. It is an objective of our work to model a global solution, also addressing the enterprise strategic dependencies reasoning to propose an organic structure.
In short, the object of the general work is, on one hand, to use these modeling techniques to make the basic reasoning to be able to build a systems plan from it and, on the other, to use the strategic reasoning to be able to build an organic model that helps in reaching the main government goal: implement e-administration taking into account the inherited 30 years old technical and organizational systems.