Dashboard for evaluating the architecture of ICT projects in the Portuguese Public Administration
Dashboard for evaluating the architecture of ICT projects in the Portuguese Public Administration
T This plan includes 25 measures of rationalization divided in 5 main categories:Improving governance mechanisms; Since there is no tool to evaluate and determine which projects should be funded or not, there is the problem of the Public Administration to be spending money on projects that in the beginning areunable to provide benefits to the Government. Justifying the value of a solution has two objectives: to motivate the researcher and the audience of the research and it helps to understand the reasoningassociated with the researcher’s understanding of the problem.
1.3. Structure of the document
Some of these works will be used in the proposal so it isimportant for the reader to know some of these aspects that will be discussed in the solution description. In the last two Chapters, 5 and 6, it’s discussed the results obtained with the use of the artifact created, it’s proposed ideas for improvement and some limitations of this work.
2. Related Work
First are clarified three important concepts for the understanding of thisreport, the concept of architecture of information systems, ArchiMate and the description of one of the T measures of PGETIC, i.e., the current process of project evaluation. Then it’s described some studies about the process of enterprise architecture evaluation and studies that have attempted to createmetrics for evaluating architectures – first it’s presented metrics created based in a framework known as CEO Framework, and next it’s presented metrics created from architectural principles, based inArchimate.
2.1. Architecture of Information Systems
The IEEE Standard 1471-2000 defines architecture as “the fundamental organization of a system incorporating its components, and the relationships between them with the environment and the principles guiding its design and evolution” . In the context of Information Systems is usual to divide the concept of architecture in three different perspectives: Software, Enterprise and Information System.
Enterprise architecture is developed to detail the structure and the relationship of the enterprise. Using an architecture framework will speed up and simplify the architecture development and communication with the stakeholders, ensuring complete understanding of the designed solution.
2.3. Project and Costs Evaluation
The support tool that is used to evaluate the projects consists in an Excel sheet (called “Formulário de parecer prévio”) and in a To-Be scenario (called “Novo Cenário Arquitectural (NCA)”). This are the information that can be viewed and evaluated through the project architecture, and that’s the focus of this work.
2.4. Enterprise Architecture Evaluation
In the last phase the quality attributes arecalculated and the models are presented in the form of enterprise architecture diagrams. Also in this work the authors argue that it’s necessary to have a limited amount of views on thearchitecture to be able to make the evaluation in a fast way.
2.4.3. Critical Analysis
The first work descripted do not solve the problem of this paper because the second phase of the method is very time consuming because it’s needed the collection of information in the form ofquestionnaires and reading documents and that is impossible with the amount of received projects to evaluate. Related to the third and last reviewed work, in the context of this thesis, the first stage of this analysis is the formulation of the architecture of the projects carried out by various public entities.
2.5. CEO Framework and Metrics
The authors argue that with these metrics, architects can measure the impact of each of their decisions, and thereby are better equipped to build an architecture alignedwith the desired qualities. In the context of this work, with the use of these metrics, it would be necessary to transition from theArchimate framework to the CEO Framework for all projects submitted.
2.6. Architectural Principles and Metrics
A series of metrics to measure the quality of an architecture from architectural principles are proposed by Vieira . A principle can be used in the evaluation process, since it is considered an optimal solution.“Architecture principles fills the gap between high-level strategic intentions and concrete design decisions”  – ensure that Enterprise Architecture is future directed.
Evaluation Metrics Using the architectural elements identified and the extended metamodel, the authors defined a“formula” that allows to measure the suitability of a certain architecture decision facing a principle. 2 =# #$ $$ !% & #Business Service = the number of Business Service on the Architecture BSIR = is the value of the attribute “interfacesRequired” for the different Business Service on the Architecture.
This is possible by comparing the result of a given metric in as-is, with the changes to the architecture proposed in the project (to-be). Evaluation application flow Below, it will be detailed the changes that were necessary for the creation of the artifact, in particular in each of the two main phases – Open Standards Verification and Architectural Metrics Computation.
3.1. Open Standards Verification
– This second attribute has the objective to know if the Open Standard There are services that implement an additional security layer to that already existed this is the case ofHTTP / HTTPS for example. The artifact validates the information that is entered and checks if the level of accessibility is consistent with whatwas stipulated in the Open Standards document.
3.2. Architecture Metrics Evaluation
The three most important categories for Public Administration are the costs, risks and strategic alignment. To make this categorization it was used each of the metric description.
3.2.1. Applications Modularity Factor
Like is said in Appendix E.b, with this type of software the costs of software acquisition are lower making sense of this metric to be incorporated into the vector of costs. This metric calculates the ratio between the number of application that needs authentication and are using the Citizen Card authentication (#CitizenCardApp) and the totalnumber of applications that needs authentication (#TotalApp).
4. Demonstration n this section it will be explained how it was performed the demonstration of the proposal of this work
In the first section is described which software is used for modeling the architecture, next it’s described the artifact created and then the artifact is applied to a specific architecture. This language, called EALang, is used to populate a database, where the EAMS will read and create theblueprint to be able to view the architecture.
4.2. Dashboard for architecture evaluation
Dashboard login window After the insertion of credentials the dashboard presents a window where it’s selected the location where the architecture formatted in XML files are stored as well as the evaluation results of the OpenStandards. The user clicked in the green area of the chart and the dashboard presented that the Open Standard thatare being violated is the standard related with the PNG.
4.3. Artifact Demonstration
Although this was not the factor of choice for the selection of this organism, it is interesting to notice if the architecture of the reviewer complies with the standards that are evaluatedin all projects. Although the architecture does not have all theinformation to calculate all the metrics implemented, serves to demonstrate the use of the tool for the project evaluation and the current status (as-is).
Initially it’s presented the evaluation supported by the principles of Österle and then it’s presented adiscussion of the results shown. Abstraction – The artifact is applicable to all architecture projects submitted and to as-is Originality – Although some metrics that were used to evaluate the architecture have already Justification – The artifact is justified since it uses already published papers in conferences.
5.2. Results Discussion
In this case, among the metrics that were calculated, it is clear that the guideline that is being more respected is With this dashboard the evaluation became independent of the person who is doing because with this artifact all the projects submitted will be evaluated using the same metrics, in the same conditions. Because of this it will be possible to compare the as-is architecture with the changes that the project recommends and have an idea of what vector can be improved if the project is approved, based onthe results given by the artifact.
To balance the costs spent on a project, and the benefits to be derived therefrom, a national plan for I the rationalization of costs of IS/IT in Public Administration of Portugal (PGETIC – Plano Global Estratégico das TIC). It was also necessary to allow this tool to assess the current state of the architecture, so that it can beverified the impact of the approval of a particular project, in the current status.
6.1. Limitations of this work
6.2. Future Work
Then we will present some limitations that this work has:The dashboard is configured to receive XML files with a certain format, and this should be It is important to remember that the dashboard created is a prototype and this can and should be improved. Below is presented some suggestions for future work to improve the evaluation ofarchitectures, and in particular the dashboard created.
7. References 1 Diário da República. Decreto-Lei n. 107/2012. 2012
The State of IT Project Management in the UK (2003). Proceedings of the Second Annual Conference on Systems Engineering Research (2004).
POP3SRecommended IMAPS Recommended SMTP Obligatory SMTPS Recommended WCS Obligatory WFS Obligatory WMS Obligatory WPS Obligatory IPv6 Recommended TLS 1.0 Obligatory BPMN 2.0 Recommended LDAP Obligatory SAML 2.0 Obligatory SOAP 1.1 Obligatory WS-Addressing 1.0 Obligatory WS-RM 1.1 Recommended WS-Security 1.2 Recommended WS-Security Username Token Profile 1.0 Recommended
B. Metamodel used
C. Technology Services extended
D. Approach to the creation of an ISA (from )
E. List of Metrics
In this Appendix it’s presented the metrics used in the proposal. These tables was extracted and adapted to show only the information required for this work.
a. Applications Modularity Factor Name
This value decreases to zero accordingly to the number of dependencies between «Application Component»» that exist in the architecture. We want to measure the number of «Application Component» that have dependencies on other components facing the number of components of the Rationale architecture.
b. Open Source in IT Systems Factor Name
Open Source in IT Systems Factor # « SystemSoft ware » >i =1 SSOS i MetricA.38 =# « SystemSoft ware » Where, ComputationSSOS - is the number of «System Software» with the attribute openSource with i “TRUE” as value. We want to measure the number of «System Software» that are open source in the Architecture.
c. External IT Systems Integration Factor Name
External IT Systems Integration Factor 1 MetricA.56 =# « Applicatio nComponent » > i =1 ACEIT iComputation Where, ACEITi - is the number of «Application Component» with the attribute connectsExternalIT with ”TRUE”. According to principle A.56, usingdedicated IT components for integration with external IT systems is more efficient Rationale and manageable since interface costs are spent only once, and changes can be limited to one component.
d. Business Interfaces Required Factor Name
Business Interfaces Required Factor # « Bu sin essService » MetricA.2= # « Bu sin essService » > i =1 BSIR i Where, ComputationBSIR - is the value of the attribute ”interfacesRequired” for the different i «Business Service» on the Architecture. [0, 1]This value is zero when there are not any «Business Service», and approaches Value Range one when the number of ”interfacesRequired” from each «Business Service» is equal to the number of «Business Service» in the Architecture.