Collaborative Method to Develop an Enterprise
Architecture in a Public Institution
Nuno Paulo Rocha Roboredo
IST - Instituto Superior Técnico, Lisboa, Portugal CINAV - Base Naval do Alfeite, Almada, Portugal
Abstract— The growth of organizational complexity degrades business processes efficiency. Enterprise Architecture (EA) is an instrument to manage organizational complexity, through the improvement of organizational self-awareness. EA improves alignment between business and IT to ensure the business value of IT, and enables rationalization of organizational resources. However, depending of organizational culture and characteristics, there are several issues hindering the EA development within an organization. Actual frameworks, like TOGAF, require a significant number of skilled human resources (HR), which some organizations, like public institutions, cannot assign to EA activities. Our research goal is to provide an EA capability to public institutions, enabling these institutions to take advantage of EA benefits. Public institution contexts and stakeholder concerns were explored as well as issues acting as enablers or as inhibitors for an EA development. We propose a collaborative method to develop an EA, applying lean and agile principles, focusing on public institution specificities. Our collaborative method tries to capture organizational knowledge, spread among employees, into an EA model, to map the enterprise cartography of the institution. Our method has been demonstrated and evaluated in the IT sector of the Portuguese Navy.
Keywords— Enterprise Architecture, Enterprise Cartography, Public Institutions, Collaborative Method, Lean, Agile.
INTRODUCTION
Increasing complexity in organizations and their context led to the need of methodologies and practices to manage this complexity in a systematic and holistic approach. Otherwise, lacking such methodologies and practices, misalignments tend to occur and grow between business goals and organizations’ internal efforts, consuming organizational resources on inefficient or ineffective activities.
EA is concerned with the management of organizational complexity to improve realization of business goals and to rationalize organizational resources. EA can promote several benefits like improve business confidence in IT, decrease IT risks, optimize integrations in IT landscape and reduce development effort of applications [1, p. 8]. EA is one of the available tools to promote systemic governance within organizations.
However, despite EA goals and benefits, evidence shows the implementation and operationalization of an EA capability in organizations face several difficulties, especially to develop same architecture and to keep it updated.
Our motivation is try to understand the main barriers public institutions face to implement an EA capability and propose a method to overcome these barriers, enabling public institutions to benefit from EA. This institutions, in general, lack appropriate tools to provide capabilities of systemic governance [2].
Design Science Research Methodology (DSRM) [3] was used to develop our research, in order to guide the development and evaluation of our proposed method.
We identify the low level of EA capability in public institutions as an important and relevant research problem [4].
The objectives which our artifact should achieve, to address the research problem include: the improvement of stakeholders’ awareness and value recognition about EA utility and benefits to the organization and for themselves; the rise of stakeholders’ willingness to collaborate to maintain the model of Enterprise Cartography updated and to improve this model and their views; and develop the EA capability in the organization.
We propose a collaborative method to develop EA capability in a public institution, based on the collaboration of organizational HR, coordinated by an EA unit. Our collaborative method was instantiated in the IT sector of Portuguese Navy and was evaluated against evaluation criteria from system dimensions [5], through an online evaluation form, applied to participants in demonstration.
RESEARCH PROBLEM
Organizations can be abstracted as dynamic systems [6][7, p. 9]. To articulate interactions within an organization, in line with organization purposes, we need to have an integrated and systemic vision of the organization [2]. Such vision is a requisite to enable systemic governance of organizations.
An enterprise cartography is a tool to map the internal reality of an organization, showing what exists, what they do, how they do, who do, when do, why do [8]. Such cartography, mapping the AS-IS of an organization, is essential to uncover misalignments, support change planning, manage transformational projects, share and align internal conceptions and visions.
Systemic governance includes also the governance of organizational transformations and change management, to adapt organizations to their context in permanent evolution, to rationalize resources, to promote efficacy and efficiency.
along with the underlying restrictions and design principles [9]. The enterprise cartography, as a part of EA discipline [6], is needed to show where we are (AS-IS) and help us to realistically define where we want to be, when, and how to reach this point in the future (TO-BE) [2].
We can see an organization as a network of independent actors in collaboration with each other, creating a dynamic collaborative network with common purposes. These actors are people and computers [6], which makes organizations and their IS as sociotechnical systems [1]. Build the cartography of a sociotechnical system and keep it updated is itself a sociotechnical problem [1] requiring insights from both technical and social features of these systems.
Public Institutions
Public sector institutions have in common some contextual premises which can influence their ability to setup an EA capability, such as:
1. Are not aimed to profit, but as much as sustainability; 2. Have an annual budget granted by the Central
Government, which depends on unclear and mutable rules, and is managed in a decentralized matter;
3. Have a more rigid organizational structure, but its departments tend to be governed in a more autonomous way;
4. Hiring HR and allocate new staff, with new expertise, involves a lot of bureaucratic work, with plenty of hurdles; 5. A significant number of employees are distantly aware (or
motivated) from cost efficiency;
6. Scarcity of HR highly skilled with the time and objective to dedicate to an EA activity;
7. Resistance in promoting change in business processes and in communicating between departments.
These organizational characteristics are determinant to understand the sociotechnical problem we want to tackle under the present work. The analysis of which characteristics are specific to public institutions, determining which act as an advantage and which don´t is a part of our investigation.
Support and commitment of the executive board to an EA initiative, is necessary but not sufficient. Often a gap arises between high-level visions and ground-level reality of the organization. Collaboration of employees working at ground-level is essential to accurately map the AS-IS state. However, employees need to understand some concepts and benefits of an EA capability, and recognize its value, otherwise they will resist to contribute to it, leading to the death of the EA initiative [1].
We need to address this natural resistance as a part of our sociotechnical problem. Public servants’ time is valuable and scarce. Even if we have a big support from the high-level management, we should not expect be allowed to focus the institution around our EA initiative. We need to have sparingly when asking for use the public servants’ time.
Problem Formulation
Our research problem is the low level of EA capability in public institutions that hinders these institutions to take advantages of EA benefits [2].
The relevance of the problem can be measured by the need that the Portuguese government felt to legislate to make mandatory the existence of EA in all public administration and the creation of procedures to feed and update these EA [4][10].
As a sociotechnical problem, we also discuss the impact of EA social dimension and the need for organizational culture to promote an updated and effective EA in a public institution.
RELATED WORK
Enterprise Architecture
Small organizations can be understood and managed by a single human mind without help of any tool [11], not needing a formal EA effort to be managed efficiently and holistically.
With the growth of organizations, increases its complexity. The understanding and management of an increasing network of relationships between actors of an organization, is no more manageable by a single human mind. The knowledge of such network spreads by collaborators of the organization, where each one understands and manages a portion of this network. A systematic management requires appropriate tools capturing and managing such knowledge.
An organization is a network of independent actors, who can be humans or computers [6]. When a change in the network is required, people will try to map the portion of the network implied by this change, sometimes with diagrams. When the task finishes, the mapping effort is lost, once soon appear new changes, making these diagrams outdated. All mapping effort needs to be reworked once a new change is required.
EA discipline brings a systemic approach to address these concerns. EA is a coherent whole of principles, methods, and models, used in the design and realization of an enterprise's organizational structure, business processes, IS, and infrastructure [9]. From EA models, we can make EA artifacts to represent viewpoints addressing concerns of specific groups
of organization’s stakeholders.
The purpose of EA is to optimize across the enterprise the often fragmented legacy of processes into an integrated environment that is responsive to change and supportive of the delivery of the business strategy [7].
EA models and their views help architects and stakeholders to reason about systems and organizations, helping to deal with the complexity.
Enterprise Cartography
Enterprise Cartography is the mapping of the AS-IS state of an organization.
Zachman Framework
The Zachman Framework analyses an organization through six different perspectives: – executive; business management; architect; engineer; technician and enterprise – each one addressing concerns of a specific group of stakeholders. Six questions are asked in each perspective: what; how; where; who; when and why. The interception of each perspective with each question is a six by six matrix where we can put, in each cell, artifacts (blueprints) that answer the column question for the line perspective. Zachman framework suggests what artifacts an EA should produce [12].
TOGAF
TOGAF is an EA framework that provides methods and tools for assisting setup and development of an EA. The core of TOGAF is the Architecture Development Method (ADM), which is a full life-cycle process for planning, designing, realizing and governing EA. ADM is an iterative cycle of continuous architecture definition and realization that allows organizations to transform their enterprises in a controlled manner in response to business goals and opportunities [7].
According to TOGAF, a typical architecture team undertaking the development of an EA would comprise roles like: Architecture Board Members; Architecture Sponsor; Architecture Manager; Architects for Enterprise Architecture, for Business Architecture, for Data Architecture, for Application Architecture and Technology Architecture; Program and/or Project Managers; IT Designer; and many others [7].
However, there are many organizations, particularly public institution, cannot afford the assignment of such number of skilled HR to EA activities.
Lean
All work effort that does not add value to the processes results is considered waste and must be eliminated. The core idea of lean is to maximize customer value while minimizing waste.
This methodology opens our eyes to all kinds of waste, such as piles of unread specifications or extra processing due to following bureaucratic governance. Lean gives us a systematic way to eliminate waste to come to a streamlined, demand-driven delivery process. Lean techniques bring pragmatism, reduction of bureaucracy, and lightweight processes [1].
Agile
Agile was influenced by the ideas of lean. Both have a very similar philosophy [13].
The goal of agile methodologies is to develop products fitting the most possible customer needs. Agile methodologies propose a development process with regular demonstrations of the product progress, to involve the customer. They propose iterative and incremental processes to deliver working software frequently, and to allow requirement changings.
Agile teaches us how to approach a problem in an iterative manner. It allows us to learn with a managed trial-and-error approach having short-term feedback cycles, which is
characteristic of an evolutionary problem-solving strategy. The feedback cycles bring all stakeholders together with a constant heartbeat, thereby guaranteeing collaboration [1].
Scrum
Scrum is an agile methodology with an iterative and incremental workflow, based on cycles of work called “sprints” [14]. Scrum delivers periodically a meaningful product from the stakeholder’s perspective at the end of each sprint, which leverages the stakeholder’s commitment and collaboration.
Customer Development Methodology
The methodology is proposed by Steve Blank to improve the product success of startups and entrepreneurs [15]. It follows a scientific approach to research and understand the customers of a product under development.
The product development must be driven by the real needs and wants of customers. To achieve the customer understanding, entrepreneurs need to contact and interview real people who are likely to become customers.
Based on the initial customer understanding, the first step is the development of a Minimum Viable Product (MVP). The MVP is a low cost product that should contain the smallest feature set that customers will pay for in the first release. The low cost of MVP reduces the risk of developing features not valued by customers. This first reality check uncovers a lot of relevant information about willingness of customers that will be used to develop the features of the new product. This approach prevents the development of products or features in the products not valued by customers.
RESEARCH PROPOSAL
We propose a collaborative method to develop an EA capability in a public institution, which takes a special care to the motivational issues and to the context of such institutions. Our method has an iterative and incremental approach, like proposed by agile principles, to show quickly results obtained with few resources, for stakeholders. This approach aims to show to the management how the abstract concepts of EA materialize in their specific institution and how the institution reacts, values and takes advantages of the benefits of an EA capability.
Objectives
The solution should meet the following objectives: 1. Develop EA capability in a Public Institution;
2. Improve awareness of public servants about EA utility and benefits;
3. Improve value recognition of the EA to the institution and to its public servants;
4. Create willingness to collaborate in the process of improving and updating the EA, by public servants; 5. Make EA activities intrinsically attached to
Proposed Method
We propose a collaborative method to develop an EA, which aims to develop a strong involvement of stakeholders to obtain their commitment in EA improvement and update activities. If our collaborative method achieves this required involvement by stakeholders, we expect to overcome the constringent imposed by scarcity of dedicated HR to EA by having the responsibility for updating the EA atomized and widespread throughout the organizational structure, rather than having this responsibility concentrated in the EA board. To coordinate a collaborative development of EA artifacts, we propose to raise an EA unit with a small structure, having 1 or 2 elements.
Our collaborative method has five phases:
Phase 1 - EA-MVP creation
Our EA-MVP will be constituted by a model of the institution, stored in a repository, and viewpoints defining views of the model. We need to develop a product which public servants may value[16][15]. This EA-MVP should be developed with a minimum amount of effort and the least amount of development time[16].
Our initial model should begin with a small part of the network that constitutes our institution. The business layer is the part of this network which most public servants better knows.
We start with the definition of a metamodel for our EA model. Figure 1 shows a possible example of a simple metamodel modelled in the Archi tool [17].
Figure 1: Initial metamodel example - only in the Business Layer
Public institutions already have IS that manage information related with the business layer, e.g. the HR system should have the assignments of public servants to job positions. We should to take advantage of this fact in the construction of our initial metamodel. On the one hand, we can leverage the value recognition of our EA-MVP if we present a model pre-populated with valuable information. On the other hand, we need to evaluate the required effort to integrate these IS with our EA tool. So, we should to construct our metamodel thinking how can we populate our future model with information from other IS.
We try to construct a model, from the metamodel, with information gathered from existing IS, improving the both (model and metamodel) in an iterative and incremental way.
In this process, we will evaluate what can be valued by public servants, but managing sparingly the integration effort.
Finally we need to define initial viewpoints to allow views of the model showing the parts that interest to each public servant. We will construct a special viewpoint focused in the public servants, which we named “Employee Context”. This viewpoint generates views showing the network of elements that directly relate whit a given public servant. With these views, we expect a part of public servants easily recognize what EA has to do with each of them.
This initial cartography will show to public servants the concepts and potential benefits of an EA model of the organization. It also allows the EA unit elements gain or deepen insights over the organization.
Phase 2 - Key Stakeholders Involvement
In this phase we will conduct interviews with public servants selected from the middle management that are accountable for a part of the institution and have a deep knowledge of how it works in the ground-level.
In these interviews we present our EA-MVP, we put our doubts about the department specificities, we ask for contributions to improve viewpoints and suggestions for new viewpoints, among other relevant contributions. In addition to the relevance of information gathered, we need to construct the idea that the EA model has a shared ownership, and is the result of a collaborative effort, that can be useful to each one and to the institution.
The objectives of these interviews are the validation of data and viewpoints our EA-MVP, to their improvement, and the emotional involvement of key stakeholders in our mission.
Phase 3 - Workshops
We will explain to public servants the EA concepts, their expected benefits, how to implement it in their specific institution, how EA is related with each of them and how it can be useful to their work.
All participants should have access to the EA-MVP through the EA tool during the workshop and the sprint week after that. They should be able to navigate through the views of the EA-MVP, so that they can to suggest updates and improvements about the data, the model and the viewpoints.
Our workshops are the following agenda: 1. EA concepts, goals and benefits;
2. How to implement an EA capability in the institution; 3. The Collaborative Method;
4. EA-MVP presentation and navigation; 5. The special viewpoint: “Employee Context”; 6. Public servants collaboration.
populated whit information that public servants easily recognize from their institution.
In point 3 we explain our collaborative method and their objectives, along with the way we construct and feed our EA-MVP. This collaboration should focus in three aspects: Data: correction and update; Viewpoints: suggestions for improvements and for creation of new ones; Collaborative Method: suggestions to improvements.
In the 4th point we explain how public servants should collaborate and how to browse through the EA-MVP views. For this purpose, we invite our attendees to open the EA-MVP at EA tool and browse through the EA-MVP views to reach their own “Employee Context” view. When all participants reach their own “Employee Context” view, we explain the origin of the data they are seeing: which IS fed our model. We also highlight the missing data in the “Employee Context” views which we expect the collaboration of public servants to fill. We will ask public servants to focus on pointing out errors in exiting data and on adding missing relationships to the model.
In the last point of the workshop (point 6), we explain the collaborative process that allows public servants to propose updates to the EA model. Public servants are invited to complete their own view in the “Employee Context” viewpoint during the workshop. Public servants are also invited to send updates of this first collaboration during the sprint that starts with the workshop and lasts the next week.
Phase 4 - Sprints
All suggestions and contributions gathered during workshops and during the sprint time should be immediately implemented or registered in a backlog or eventually rejected. As soon as the EA-MVP is updated with the information of one public servant, the EA unit sends an e-mail inviting him to visit the EA-MVP and asking for their validation and for new updates.
Suggestions requiring significant time from the EA unit, should be registered on the backlog to be analyzed, discussed and eventually implemented later.
During the sprint week, the EA unit should maintaining close contact with the participants, sending them notices of new updates, discussing suggestions and alternatives. The aim is get their involvement and build a feeling of shared ownership of the EA model.
At the end of the sprint, we should have a coherent EA model representing the part of the institution that we proposed to model. We should have a set of viewpoints, from which we can generate views from our model, which public servants understand, value and use.
Phase 5 - Result Analyses
With the end of a set of sprints, the EA unit should analyze the results and evaluate the relevance of suggestions registered in the backlog. The analyses should be made with the collaboration and involvement of key stakeholders which are responsible for the part of institution represented in the EA model impacted by the suggestions.
The analyses should address the following issues:
1. Assess Metamodel: Is it adequate to answer the public servants concerns? Should we add other concepts and relationships? Should we remove concepts and relationships that do not add value to the model?
2. Assess Viewpoints: Are their views adequate to visualize relevant parts of the EA model that answer the public servants concerns? Are there simple and comprehensible? Are there overcrowded with irrelevant information to public servants? Should we create new ones? Which improvements can we do in our viewpoints?
3. Assess data coherence and consistency in the model: Likely, during the sprints we uncover errors, incorrectness, incoherence or inconsistency in the data provided by existing IS. However the owners of these data and IS cannot be the EA unit. This assessment should address and propose an easy and simple way to validate, correct and update these data in the IS that is the data source.
4. Assess collaborative method: our collaborative method can be continuously improved to better fit the context of each institution. We should follow the lean principle of “Seek perfection”, looking to eventual wasted steps or practices in our method. Is our way to collect suggestions and data updates efficient? Can we automatize some steps? Public servants value our EA?
DEMONSTRATION
Our method was demonstrated in the IT sector of the Portuguese Navy, which is composed by the “Superintendence of Information Technologies” (STI) and their three
subordinated military units: DAGI, DITIC and CDIACM. These four units have about one hundred and sixty public servants, including civilian and military.
Phase 1 - EA-MVP creation
The metamodel was developed in the Archi tool [17]. After several iterations, we obtained the metamodel in Figure 2.
Figure 2: EA-MVP metamodel
The EA-model (our EA-MVP) was developed in EAMS, which is an information integrator and a visualizer [18] of our EA model.
related with each employee: the military unit where he is serving, their job position assignments, roles that composes job positions, functions of each role, etc. The EPM manages projects of the Navy, and includes the employees’ assignments to project manager and project team.
In parallel with the design of our metamodel, we start to populate our EA model with data gathered from HR database and from EPM. We populate part of our model in a semi-automatic way. The HR database provided data for populate the blue shaded part in Figure 3, and the EPM provided data for the red shaded part.
Figure 3: Part of the model filled in a semi-automatic way
Later we will ask the collaboration of public servants to verify the correctness of this data and to populate the unshaded part.
In addition to the building of our model, we developed nine viewpoints on EAMS to generate blueprints from our model. Figure 4 is a view generated from viewpoint “Employee Context”. This viewpoint shows elements of EA model
directly related with a concrete employee. Information inside the blue rectangle was gathered from HR database. The red rectangle shows projects assigned to “CTEN EN-AEL ROCHA
ROBOREDO” as we gather from EPM.
Figure 4:“Employee Context”view
We will ask to public servants to populate our model with the following information: in which business process they participate as executors and in which of their role.
Phase 2 - Key Stakeholders Involvement
This phase occurs simultaneously with the previous one and contributes to the creation of our MVP.
We started with a presentation of the project to the high-level management of the IT sector of the Navy, which includes the admiral superintendent of informational technologies, three directors of their subordinate units and senior officers of the IT sector, rounding twelve participants. The involvement of participants on the discussion and their intervention is indicative of an improvement in their awareness about EA utility and benefits. We conveyed our message and obtained their support to the initiative of our demonstration.
Taking advantage of other initiative of elicitation of business processes, we performed another session where we discuss and explore complementarity and synergies of the two initiatives: Building of an EA capability and elicitation of business processes of IT sector. In this second session, we stress again the EA utility and possible benefits.
We conducted five interviews with officers of DITIC, DAGI and CDIACM. Each of these five interviews constituted the first approach to an iterative process that produces a list of business processes from the IT sector to populate our EA model.
The interaction with our key stakeholders allowed us to better understand the ground-level reality. We showed the EA-MVP to stakeholders, however it was not possible to collect contributions to improve our initial viewpoints, once our stakeholders were not yet familiar with the EA tool and with the EA model and views.
At the emotional field, we conveyed the message of the potential benefits of EA, through the initial presentations and through the fieldwork developed with the key stakeholders. Asking the stakeholders’ opinion about the relevance of having an EA capability in the Navy, we felt we won allies to help us to convey our message.
Phase 3 - Workshops
In this phase we prepared a presentation to conduct workshops, we selected our 38 participants, we invited them, we scheduled five workshops plus one only the three directors, we managed the availability of participants and finally we performed six workshops. Were selected military with rank of officer to participate in our workshops, because they are involved in the management of the organization.
Our presentation to the workshops had the following agenda:
1. Enterprise Architecture;
2. Enterprise Architecture in the Navy;
found to overcome some limitations in the EAMS features to collect contributions.
Phase 4 - Sprints
After each workshop we received the excel files by email and we updated our EA model with the information relative to each participant. As soon as we had processed one file, we sent an email to the respective participant inviting them to visit again the EA model through the EAMS to check the updates. We also ask them to send us updates of their excel file with more accurate information and new suggestions.
Figure 5 shows an example of one view generated from the viewpoint “Employee context” before the sprints, which belongs to the employee “CFR SEP FONSECA DE OLIVEIRA”.
Figure 5:"Employee Context" view before sprints
Figure 6 shows the same view updated and improved with the contributions of participants after the sprints.
Figure 6:"Employee Context" view after sprints
Differences are not limited to the business processes updating. It was added an accumulation role “DAGI-C001
OFICIAL ADJUNTO” to this employee. Although this role was already written in the HR database, was not possible to extract automatically the Accumulation relationship because this role is assigned to the officer with the highest rank, selected from the three heads of division.
Figure 6 have also three new projects inside the box “Membro de Equipa (Projetos em Execução)”: Team
Member (Ongoing Projects), which was not in Figure 5. This information was supposed to be automatically extracted from the EPM. However there was an error in the query that extracts this from the EPM database, which was only detected and reported during sprints, by some participants. We believe that if there was no involvement of participants in workshops and sprints, even if this error was detected by someone who eventually browsed the EA model views, it would be very unlikely that the inconsistency in views were reported.
The layout of the viewpoint was improved with two new boxes: “Gestor de Projeto (em Análise)”: Project Manager (under analysis), and “Membro de Equipa (em Análise)”: Team Member (under analysis). The reason was: Projects, in the EPM, can be in one of fifteen distinct states, ranging from “Draft” to “Guarantee – concluded”. If we had considered show all EPM projects, within the viewpoint “Employee context”, it would be generated some views overcrowded with a bunch of projects completed for a long time, other cancelled, others in proposal to approve, etc. We decide to include only the ongoing projects. However, there are projects already approved for execution, not started yet, which their project managers started working in their planning. When these managers did not see such projects in their view “Employee context”, they report us missing projects in the view. Despite the explanation of the reason for this miss, we realize the view of all projects that concern to public servants currently is important for them, regardless the projects state. Another reason: we realize if public servants do not find what they expect to find in EA views, their confidence lows in the reliability of the information which they see in the EA views. So, we decided to include these two extra boxes in the layout of the viewpoint “Employee context”, improving it based on what is valued by public servants.
We received suggestions to improve the excel file, such as increasing the rows for business processes, as changes and additions to business processes, or as the possibility to assign more than one accumulation role to the same employee.
Phase 5 - Result Analyses
Our initial list of business processes was very immature and needs great improvements to be consistent and valuable. It contains several levels of granularity, which ranges from very generic processes becoming meaningless, to processes at the task level. It will be worth to conduct a systematic initiative of elicitation of business processes before another iteration of our method.
Public servants value to see all the issues they are accountable, in the view “Employee context”. However there are assignments to activities which do not belong to projects in EPM nor are assigned under the context of roles registered in the HR database.
1. Metamodel Assessment:
We did several versions of our metamodel. The last changes were made during sprints, as a result of our findings.
easier to materialize and less ambiguous. So we added the “Activity” concept to our metamodel.
The concept of "Document" did not bring added value at this stage of maturity. It brings more misunderstandings than added value, so we consider not use it in future iterations.
We need to analyse whether we should to add new concepts to our metamodel, to enable the modelling of roles within projects under control of external entities, assigned from public servants of our institution.
2. Viewpoints Assessment:
We need to improve the viewpoint “Employee context” to include the “Duty roles” and the roles of public servants in projects under control of external entities, to see all the issues public servants are accountable.
During sprints we had developed three new viewpoints: Processes of a process, Unit Processes and Macro-processes. Viewpoint “Business Process Context” was improved to include activities of the business processes. We also improved the viewpoint “Employee context” to add two new boxes as shown in Figure 6. We also have registered in our backlog the intention to build the “Activity Context” viewpoint, and eventually the “Document context” viewpoint, if we preserve the “Document” concept. We will analyse the possibility of build a viewpoint to show the subordinates of a given public servant.
3. EA Model Assessment:
During sprints we found missing assignments, in the HR database, of public servants to their actual job positions. These public servants are only assigned to their military unit. There are also several vacant job positions formally approved.
We also found inconsistencies in the data gathered from EPM.
4. Collaborative Method Assessment
We cannot implement our method with a sequence of sprints to the same public servants, with one workshop between each sprint because workshops are time-consuming. However, we initial workshop is fundamental to enable the collaboration of public servants. It sets up a common understanding of the purpose of an EA initiative. We need to rethink the steps of our collaborative method without workshops beyond the first one. We think the sprint format is useful to establish rhythm and limit the time in which we ask the effort of the public servants.
Our method is very dependent on the public servants’ willingness to collaborate. The introduction of some kind of accountability for the network that respects to each public servant may be worthwhile.
EVALUATION
Our 38 practitioners, who participate in our demonstration, were asked to evaluate our collaborative method through an online evaluation form. This online evaluation aims to evaluate to what extent our method achieves its goals, through the evaluation of 11 of the 28 criteria from the hierarchy of criteria proposed by [5].
We obtained 37 responses, four of them invalid. The four invalid responses, plus the unanswered one, are about 13% of
the 38 responses. For these five public servants, our objectives for the solution are not achieved at all, since their behaviour is indicative of EA’s irrelevance to them.
The averages of each statement evaluation of the 33 valid responses are summarized in Figure 7. The overall rate average of all statements is 2,8.
Figure 7: Average of statements evaluation
Statements contributing negatively to criteria evaluation were rated reversely. Thus, a higher rating of a statement means a better evaluation of the collaborative method, regardless of how the statement is built.
Statements 5th and 6th were the worst rated:
5. “Most of public servants from my military unit will
update information in this system because they
will recognize usefulness on it.”
6. “Most of public servants from my military unit will
NOT update information in this system, unless
their chiefs order them to do so.”
It means respondents don’t believe the other public servants
of their military unit (not themselves) will develop willingness to collaborate in the update process of EA model.
Curiously, statements 3rd and 4th are similar to 5th and 6th, only changes the subject – instead of other public servants, the subject is the respondent himself:
3. “Information collected by the METHOD is useful,
so I will keep updated the information that
concerns to me.”
4. “I DO NOT intend to spend my time to update another system. I will only do so if my chief will
order me.”
Here the rate is about six tenths higher: 2,87 and 3,07 respectively, which is a big increase in our four-position scale. The evaluation form does not mention whether the other public servants have participated in a workshop. The respondents may have assumed that the others public servants have not participated. If so, the gap between rates is an indicator of the relevance of the workshops to improve the EA awareness.
The 3rd statement was rated below the 4th and the 5th below the 6th. It means the respondents consider that public servants could possibly collaborate in the update of the EA model, but that does not mean they recognize usefulness of it or is not the usefulness that will motivate their collaboration.
2. “The information I have provided to the MODEL will be useful to the Navy management.”
Followed by the 1st and 13th:
1. “The information I have provided to the MODEL
will be useful to other public servants of the
Navy.”
13. “The MODEL of the EA-Navy is important and necessary, whereby it should be built and
updated in all units of the Navy.”
The perception of a high usefulness of the information to be collected and of a high importance of having a model contrasts with the perception of the low willingness of public servants to update this information and the low usefulness of our concrete and existing model. We can interpret our results as the recognition of the usefulness and importance of the EA abstractly, despite the low quality of our method to collect information and manage a concrete EA model.
The overall average of the rates of all statements was 2,88, which is almost four tenths over than the middle of the scale, and eleven tenths below the maximum. The statement better rated obtained 3,39, which is nine tenths over the middle of the scale, and six tenths below the maximum. 23 statements were rated higher than middle of the scale. Only one statement was rated exactly in the middle; and only one rated below the middle.
This evaluation, although overall positive, is not enthusiastic, which means we need to work harder to improve our method to achieve consistently our objectives.
Figure 8 shows the mapping of the results from evaluation statements to the evaluation criteria.
Figure 8: Collaborative Method Evaluation
“Utility for the organization” was the highest rated criteria (3,12) followed by the “Utility for people” (2,98), which is consistent with our precedent analysis. Responders recognized the utility of an EA capability for the organization and for people. However they were not so convinced with the quality of our method, since they rated worse “Validity” and “Efficiency” (2,81), meaning the respondents had a low trust in the information provided by the EA model (Validity) and our method was time-consuming (Efficiency). The “Ease of use” and the “Fit with organization” criteria had a relative low rate also (2,87).
However, although low, all the criteria were rated positively.
CONCLUSION
Public institutions are unable to manage their own complexity, including their IT, in a systematic and holistic way, despite all theory from EA discipline and their expected benefits. We have studied the context of public institutions to understand what hinders them from raise an EA capability and how to overcome these barriers.
One of these barriers is scarcity of HR skilled in EA, in public institutions, to assign to an EA initiative as recommended by the most known EA frameworks. We proposed a collaborative method (our artifact) intending to spread the EA effort by their public servants, taking advantage of a crowdsourced effort. This EA effort is to raise an enterprise cartography of the institution and keep it updated.
To enable the collaboration, we need to obtain recognition of value of EA by public servants. The “Customer Development Methodology” was adapted to develop a product valued by public servants. Principles of “Lean Methodology” were also used to reduce waste. We were inspired by “Scrum methodology” to implement the iteratively in our collaborative method.
Our artifact was instantiated in the Portuguese Navy for demonstration purposes. The artifact performance was evaluated through an evaluation form filled by participants during the demonstration. We communicated our results to the board of directors from the IT sector of the Navy, and in the public discussion session of our thesis.
Lessons Learned
We cannot perform one workshop at the end of each sprint, since workshops are time-consuming to the public servants. The initial workshop is very important, since it enables a common understanding of the purpose of an EA initiative. It enables also the emotional involvement of public servants and the raise of the confidence in the initiative.
As our method is based in the willingness to collaborate, it doesn’t solve the cases of the public servants who don’t develop this willingness.The demonstration has exposed this weakness of our method, since there are public servants who were not willing to collaborate, or worst, they could update the EA model with erroneous information to avoid the EA unit bother them. We need to introduce some kind of accountability for the network that respects to each public servant.
Limitations
Our method is dependent of the public servants’ willing to collaborate, which in real world never happens completely. An outdated EA-model undermines the EA initiative.
Our method is designed to raise the business layer of EA cartography in public institutions. The other two EA layers – application and technology – require technical skills which common public servants usually do not have. Thus, our method is not adequate to solve the problem of the two other layers.
state of the organizations. EA is much more than just enterprise cartography.
Our demonstration had only one iteration, and had the participation of only 38 public servants, which is a limitation to extract robust conclusions. It also would be necessary perform more iterations of the DSRM process, which means the improvement of the collaborative method – our artifact – incorporating our findings as the removal of workshops from iterations after the first and the introduction of measures to establish accountability by public servants for their part of the EA model. These subsequent iterations could be performed in other military units of the Navy.
We have applied our method in the military institution, which is a special kind of public institution. The military institution has relevant particularities in their culture, which deeply differs from common public institutions. This fact can weaken the generalization of our findings to other public institutions. Thus, it would be necessary to perform our method in other public institutions to assess their generalization.
The EAMS feature for update the EA model is not sufficiently straightforward, which led us to a scheme of exchange of excel files with participants. Besides the extra work to the EA unit, this fact is a limitation that affects our results, as it requires an additional and annoying effort from participants, which can generate a sense of rudimentary work and can lowers their willingness to collaborate.
Future Work
To strengthen the findings of our thesis and to improve our artifact, it will be necessary:
• Implement suggestions gathered in the backlog and improve the procedures to update the EA model, since the exchange of excel files is not a good solution. After that we can perform another sprint with the same participants;
• Execute a second iteration of the DSRM process to improve our collaborative method, with the findings of this first iteration;
• Apply the method in other public institution.
To future work beyond our thesis scope, we recommend:
• Develop the EAMS feature of creation and submission of architectural scenarios.
• Develop a method to raise and update the application layer and technology layer of the EA cartography.
• Develop additional iterative procedures of collaboration, as new channels of communication, to leverage the involvement and accountability of public servants in the EA activities.
REFERENCES
[1] S. Bente, U. Bombosch, and S. Langade, Collaborative Enterprise Architecture. Elsevier, 2012.
[2] J. Tribolet, “Foreword of Plano global estratégico de racionalização e redução de custos nas TIC, na Administração Pública,” 2011.
[3] K. Peffers, T. Tuunanen, M. a. Rothenberger, and S. Chatterjee, “A Design Science Research Methodology for Information Systems Research,” J. Manag. Inf. Syst., vol. 24, no. 3, pp. 45–77, Dec. 2007.
[4] GP-TIC, “Plano global estratégico de racionalização e redução de custos nas TIC , na Administração Pública,” 2011.
[5] N. Prat, I. Comyn-Wattiau, and J. Akoka, “Artifact Evaluation in Information Systems Design-Science Research – A Holistic View,” 18th Pacific Asia Conf. Inf. Syst. Chengdu, China., p. 16, 2014.
[6] J. Tribolet, P. Sousa, and A. Caetano, “The Role of Enterprise Governance and Cartography in Enterprise Engineering,” Emisa, vol. 9, no. 1, pp. 38–49, 2014.
[7] The Open Group, TOGAF 9.1. The Open Group, 2011. [8] A. Brown, “Foreword to the Third Edition,” in Enterprise
Architecture at Work, 3rd ed., Springer, 2013, p. v. [9] Marc Lankhorst et al., Enterprise Architecture at Work:
Modelling, Communication and Analysis, 3rd ed., vol. 3. Springer, 2013.
[10] Conselho de Ministros, Resolução do Conselho de Ministros n.o 12/2012. Portugal, 2012, pp. 596–605.
[11] G. Wierda, Chess and the art of Enterprise Architecture. R&A, The Netherlands, 2015.
[12] J. F. Sowa and J. a. Zachman, “Extending and Formalising the Framework for Information Systems Architecture,” IBM Syst. J., vol. 31, no. 3, pp. 590–616,
1992.
[13] M. Fowler, “Agile Versus Lean,” 2008. [Online]. Available:
http://martinfowler.com/bliki/AgileVersusLean.html. [Accessed: 04-Mar-2016].
[14] J. Sutherland, “Scrum handbook,” Haettu, p. 66, 2010. [15] S. G. Blank, The Four Steps to the Epiphany, 3rd ed. K
& S Ranch, 2007.
[16] E. Ries, The Lean Startup, 1st ed. Crown Publishing Group, 2011.
[17] P. Beauvoir, “Archi - The Free ArchiMate Modelling Tool.” [Online]. Available:
http://www.archimatetool.com. [Accessed: 01-Mar-2016].
