Ecosystem Architecture Management in the Public Sector – From Problems to Solutions

. Based on our research concerning enterprise architecture (EA) in the Finnish public sector, we discuss how EA concept and tool need to be developed to support government business ecosystem and organization design. Our research context indicates, beyond a federal government or a state one, that even a single municipality, like a city concern, can be perceived as an ecosystem of its sectoral domains, subsidiaries and such. We outline a vision of an overall ontology-based, shared EA repository for the-whole-of-government current state descriptions and specify the central design principles and functional requirements for such a system, illustrating some potential use cases of it. Based on interview data from four smart city cases in Finland, we suggest a management model for the government ecosystem architecture target state design, specifically a design process for co-creating new services in the ecosystem. Further, we outline some principles for government ecosystem architecture management.


Introduction
The world has become interconnected so that the organizations are intertwined with business partners and integrate into networked business models.This enhances efficiency by allowing companies to focus on their core competencies while leveraging capabilities of their partners.The concept of a business ecosystem is suggested as an economic community of interacting organizations and individuals [1] to create value through the increased information, services, and products for the customer [2].While the underlying complexity of the public administration is prone to increase, governments struggle to achieve public-policy endeavours by dividing complex issues into smaller pieces [3].Contrariwise, embracing holism and the interconnections among organisations might be a key to solve some of the problems occurring.Ecosystems have attracted interest also in the public sector, and inspired new models of public services delivery, where the ecosystems-enabled co-creation is suggested as key innovation [4].Recent examples include Nordic Smart Government project aiming at the data driven Nordic region, based on the interoperable digital ecosystem for data exchange between systems and authorized parties.Prevailing reform in Finnish Social and Health services aims at an ecosystem that will include shared IT services as the common platform for currently siloed and fragmented data resources.The ecosystem model is believed to improve the quality of social and health services, and create new opportunities for business, research, and societal growth [5].
While offering possibilities, operating in an ecosystemic environment might prove to be challenging, and the change from traditional government structures might be difficult to manage, requiring holistic yet detailed view.Enterprise architecture (EA) is commonly considered as a valuable approach to coherently manage and align the organizations' key assets, such as business processes and services, information systems, and data.EA has been applied in large and complex organizational change endeavours, business mergers [6], [7], electronic government (e.g.[8], [9]), and building business ecosystems platforms [5].However, EA methodologies fall short in bridging internal and external environments, and in involving customers, supplier, business partners and other various stakeholders for building successful ecosystems.Prior studies (e.g.[10]) for a thorough review, see [11]) have discussed Extended Enterprise Architecture.Further, Drews and Schirmer [12] propose a plausible idea of how intra-organizational EA should evolve to respond the organizations' interconnectedness.Still, the means of extending the focus of enterprise architecting from intra-organizational to the ecosystems level is an area not yet sufficiently studied.Although previous research (e.g.[13], [14], [15]) has discussed EA in a smart city context, we differentiate from these valuable contributions by focusing to government ecosystem architecture per se, and only use smart city as an example of public administration (PA) ecosystem.
This study is constructed as a design science research, based on our observations in Finnish public administration EA adoption, (e.g.[16], [17]), as well as the anticipations of the future EA in business ecosystems, (e.g.[12]).Based on these explorations, our objectives are the following.For the interconnectedness of the PA as a business ecosystem (later, government ecosystem): I. We aim to outline some basic functional requirements of an ontology-based, shared EA repository for government ecosystem and to propose a vision of a real-time information system support for such a repository.II.Based on our latest generate/test cycle, we use interview data from four smart city cases, and further develop previously introduced [18] management model for the government ecosystem architecture target state design, as well as outline some principles for government ecosystem architecture management.The usage of ontologies for EA integration and analysis [19] and combining EA modeling and enterprise ontology [7], [20], [21], [22] are not unheard of.Further, Fischer, Aier and Winter [23] and Hansen and Hacks [24] have discussed federated repository approaches for the maintenance of EA models.The rapid development of the enterprise modeling and metamodeling methodologies [25], [26] should anticipate the vision to be implementable in the near future.Artificial intelligence, among other solutions, could be the future option for creating and maintaining the as-is business ecosystem EA (BEA).Automatic data collection for EA models [27] modeling [28] and documenting EA [29] have already been discussed.As an example, Gladden [30, p. 1] discusses enterprise mega-architecture, which "disengages human enterprise architects from the fine-grained details of architectural analysis, design, and implementation, which are handled by artificially intelligent systems functioning as active agents rather than passive tools." We use Finnish National PA as an example to illustrate the given vision.This research aims to make a contribution to the discussion concerning the evolving discipline of enterprise architecture, and its usage in ecosystemic environments as well as enhancing the interconnectedness of the public administration as an ecosystem.First, we aim to contribute by advancing the work of EA usage on PA by envisioning requirements for information system (IS) for real-time current state analysis in PA ecosystem.Second, we outline the basic functional requirements of an ontology-based, shared EA repository.Third, we suggest a management model for the government ecosystem architecture target state design, specifically a design process for co-creating new services in the ecosystem, and outline some principles for government ecosystem architecture management.
The remainder of this article is structured as follows.In Section 2, the EA management is presented as a tool in collaborative networked environments.In Section 3, the research setting of the constructive study is described.In Section 4, the Finnish PA is illustrated as an example of the government ecosystem.We shortly outline the previous exploratory research of the EA adoption in Finland that inspired the vision at the article.In Section 5, we discuss the challenges presented for the execution of the business ecosystem EA management in [12], and present some solutions for these challenges.We discuss the vision of the public sector EA management IS, and describe its foreseen usage with some core requirements and illustrations.Further, the government ecosystem target state design process is illustrated along with the results of our latest research cycle.Section 6 presents conclusions and suggests further studies of the subject.

EA Management in Ecosystemic Environments
As the world moves towards networked and complex structures, the changes within the organizations and in the environments are becoming more frequent, yet more difficult to perceive and foresee.This creates the demand for organizations to evolve constantly, to move out of the traditional, possibly stagnant structures and operating models.
Organizations of different kinds are increasingly perceived as systems operating in ecosystems.For instance, Visnjic et al. [31] present cities as "ecosystems of ecosystems".Further, governments and even the society are perceived as complex social systems by several authors [32].As noted by Caputo et al. [3], "the society could be defined as a complex set of relationships based on the continuous sharing of resources and on the combination of several expectations culminating in the building of new value", thus making society a domain which "cannot be analysed in the light of a mechanistic approach; it requires the adoption of a holistic perspective".The idea emerged from the field of biology, different types of ecosystems have been widely discussed in academic disciplines, such as marketing, strategy, social sciences, innovation management, engineering and information technology, gaining popularity especially in recent years.Ecosystems have been defined in a variety of ways, and different kinds of ecosystems include business-, innovation-, service-, and platform ecosystems as well as various others.Adner [33] sees ecosystems as "the alignment structure of the multilateral set of partners that need to interact in order for a focal value proposition to materialize", and makes a separation between ecosystems-as-affiliation ("ecosystems as communities of associated actors defined by their networks and platform affiliations") and ecosystem-as-structure ("ecosystems as configurations of activity defined by a value proposition").In line with Adner, we see the latter as a suitable metaphor for government ecosystem, where diverse actors come together to meet a shared value proposition.Han, Lowik and de Weerd-Nederhof [34] have recognized common elements of different ecosystems, including focal roles, co-specialization, co-evolution and coopetition, pooled and loosely coupled interdependence, hierarchical structure, shared vision, system-level business model, and modularity.Further, ecosystems can be interpreted as nested in layers, ranging from micro-level (service exchange between actors) to interdependencies between co-existing ecosystems at mega-level [35].Ecosystems have been used as a conceptual paradigm in the public sector, as seen, as an example, in the case study of a national health information system, where public and private health care organizations act in meso-level, and the whole ecosystem represents macro-level [36].
Enterprise architecture (EA) has been defined as a discipline focused on the alignment between business and information technology (IT).With EA organizations can define their current and future states, as well as a roadmap between them, taking into consideration aspects such as processes, capabilities, applications, systems, data and IT infrastructure [37], [38], [39].However, as argued by Lankhorst [40, p. 205], "In practice these domains are not approached in an integrated way.Every domain speaks its own language, draws its own models, and uses its own techniques and tools.Communication and decision making across domains are seriously impaired".Kloeckner and Birkmeier [41] in their article about enterprise architecture from a systems perspective, state that "A comprehensive enterprise architecture therefore specifies, amongst others, the goals and strategies of an enterprise, its business processes as well as the associated resources like production systems, information systems and humans.While the former aspects are often included in current concepts of EA, especially humans, as integral parts of enterprises, are often not taken into consideration.But only such a complete picture would essentially support necessary transformations of organizations in a flexible and agile way".Current EA methodologies fall short in bridging internal and external environments, and in involving customers, suppliers, business partners and other various stakeholders for building successful ecosystems.
According to Magalhães and Proper [42], the research of social architecturesembodied in organizational design thinkingis concerned by social sciences.Contrary, technical architectures are discussed by engineering sciences, such as EA (ibid).In the same vein, Pennock and Rouse [32] state, that there are at least two broad perspectives viewing enterprises as systemsarchitecting enterprises (i.e.analyzing and designing the functions, structures and processes) and managing the enterprise.Bernus et al., [43, p. 96], note that "EA must encompass both soft [e.g.related to organizational of social phenomena] and hard systems [e.g.engineering problems], model complex systems behavior through self-design, and add the human interpretive behavior and cognition to organizations as living systems.".Interestingly, Poli [44] distinguishes between systems that are complex and those that are complicated: a complicated system can be understood through structural decomposition, whereas complex systems can be understood via functional analysis.This means, that while complicated systems can (in theory) be modelled fully, modeling complex systems is always incomplete.Regardless of the view, concerning the nature of social systems seems to be necessary when the emphasis is on an ecosystem of organizations.
Therefore, disciplines (e.g.enterprise architecture) which concern the analysis and design of an organization should possess a dualistic natureconcerning both complex and complicated systems [44], soft and hard systems [43], social and engineering problems [42] and architecting and management problems [32].In practice, this means combining two perspectives: modeling the state of, e.g. the infrastructure and data of the organization (complicated problem) as well as managing social phenomena in the midst of ecosystemic environment (complex problem).Two kinds of requirements of architectural development are apparent in said environments.First, the practices of enterprise architecture management (EAM) must allow flexible and responding designs to make it possible to answer the unexpected changes in environment, and to grasp the newly emerged requirements and possibilities that often ensue.On the other hand, operating in complex networked environments necessitates carefully planned EAM that considers various interconnected yet independent parties as well as able command of various concurrent contingencies.The development activities in complex business ecosystems call for possibility for emergent design at the same time as they necessitate strictly coordinated architecture planning and management.The former must extend to interfacing networked organizations operating in a same ecosystem and to acknowledge their individual business strategies and processes as well as software and technology landscapes.
To conclude, although a systemic stance has recently received notable interest in the EA field on research (e.g.[43], [45]- [50]), and EA has been studied as a means of understanding networked and ecosystemic settings (e.g.[13]- [15], [51]- [57]), the current EA methodology is still lacking in the capabilities of business ecosystems analysis and design (see, e.g.[10], [57], [58]).EA might need a reconceptualization on methods and tools, to provide requisite coherence and adaptability in reacting to internal and external change demands [59].
In the article, we suggest the current state EA modeling to follow the engineerable path as the complicated problem, by semi-automated models of the as-is, whereas the target state design of BEA is left with situational, heuristic practices, however, benefiting of the as-is repository.

Research Setting
This research follows the principles of the design science research (DSR) [60], where the theoretical knowledge base and the real-life environment are married for the researchers to create an artifact that is needed in the environment.DSR as discussed by Hevner et al. [60] is frequently used in studies concerning the modeling of ecosystems, such as smart cities (e.g.[61]), as well as in discussing EA in ecosystems [62].In this study, we envision an IS solution for EA descriptions' accessibility, and automated update in government ecosystem.Also, previously introduced [18] management model for the government ecosystem architecture target state design is further developed, and some principles for government ecosystem architecture management are outlined.These stand as design artifacts in terms of [60], forming hypothesis that is to be evaluated in future studies in government ecosystems, e.g. in a municipal corporate, or a national government.Beyond the EA research endeavors of the Finnish EA adoption, the authors hold EA development or EA education roles in Finnish PA.We build on the personal research and development endeavors, as well as the latest enterprise modeling and architecture knowledge base, where the most influential for the work have been the EA frameworks and methodologies [25], [63], [64], [65]; EA conceptual foundations [43], [48], [66]; EA studies from the business ecosystem perspective [12], [51] and enterprise modeling and engineering [26], [67], [68], [69].The described previous results are further enlarged by abductive logic reasoning to present the hypothesis for future iterative and constructive case studies.Abductive logic forms a 'process of discovery' where inferences are drawn to the next best explanation in each cycle, with wider set of data [70].
To elucidate our vision, we present excerpts from our most recent research cycle, a multiple case study of four smart cities in Finland.The interview data is used in a generate/test cycle [60] to further enhance our previously introduced [18] model for PA ecosystem target state design process.We conducted a total of eight interviews with seasoned enterprise architecture professionals as well as a diverse range of managers from Jyväskylä, Helsinki, Espoo and Turku.Of these, the latter three are part of a 6Aikaa collaborative smart city ecosystem of six of the largest Finnish cities [71], while Jyväskylä is a frontrunner of Finnish smart city endeavors with its smart city districts such as Hippos and Kangas [72].The interviewees were selected with the purposeful sampling.
We conducted semi-structured interviews between November 2018 and January 2019.The interviews were audio recorded, transcribed and analyzed using conventional content analysis, according to Hsieh and Shannon [73].The interviews lasted between 43 and 56 minutes, the average being 50 minutes.As discussed by Hsieh and Shannon (ibid), conventional content analysis can lead to concept development and model building.The excerpts presented in the following sections were translated into English and edited for brevity, thus removing hesitations, words and such, which were not essential for overall understanding of the data.
The proposed IS vision and the tentative government ecosystem architecture target state design process form a continuum in abductive DSR cycles concerning EA framework adaption in Finnish PA [5], [16], [74], that suggested two things.First, the current state EA descriptions of a government ecosystem were to be modeled as structural, rearrangeable descriptions, e.g.like in [63].Secondly, the current state descriptions elements were to be represented in relation to the prevailing management structures in real-time.This requires a common meta level representation of PA management structuresi.e. a contextual ontology.Finally, as for the current state EA descriptions, the EA framework for public sector was proposed to be implemented as a dynamic data model of the current management structures [16].

Challenges of the Finnish PA as an Ecosystem
Finnish national PA, as a 'whole-of-government' forms a complex ecosystem of actors.The actors are organizations of high complexity, e.g. with variety of products, services, official responsibilities, and complex administration structures.The political organization comprises a parallel hierarchy with the administration.Further, various cross-organizational management forms, such as policy programs are typical.According to our observations, these management structures are not always documented transparently.Re-organization of the administrative structures has become an established practice in Finnish PA.The trends to centralize and decentralize are simultaneous.New Public Management related reforms have taken place since 1987.Gradual outsourcing of prominent business areas can be perceived in both state and local sectors.Simultaneously, the mergers have been encouraged by the State government especially in the municipal sector.The municipalities have conglomerated in many ways, e.g.via forms of collaborative networks, joint ownerships or by strict mergers.A conglomerate form of management is typical to public sector organizations, creating a complex system per se with various corporate governance functions, deep administrative hierarchies, and multiple types of actors, like sectoral domains, in-house enterprises, subsidiaries etc.
Re-organization and re-structuring are not typically based on profound systematic analysis and design.The current state organizational structures form a hindrance to the recurring transformation efforts.In a network of organizations, the management structures should be transparent at high usability levels, to enable the comparative analysis of the as-is corporate structures of the ecosystem, before the design of the common goals implementations.Finnish Information Management Act 2011 necessitates PA actors to publicly model their EA.However, despite of the serious endeavors in launching the shared EA modeling tools among PA actors, the open sharing of the EA descriptions is not at adequate level, and the implementation and use of the method have been challenging [75].Innovations and best practice sharing has to be based on mutual agreement on personal level first.The search algorithms and comparisons are not profoundly supported at model element level.Furthermore, as Finnish administrations are trending towards citizens-as-partners type practices in service development, the customers and citizens might form a remarkable resource in innovating public services and structures, based on an open source EA description.

EAM in Ecosystems -From Problems to Solutions
The domain of EA methodologies has evolved towards the holistic organizational design and development [48].Al-Kharusi et al. [76] note in their study of EA at dynamic environments that the human and organizational aspects are neglected in target state design.While [77] acknowledge the EA as a way to cope with organizations' ever-increasing complexity, they argue that the EA methodologies do not efficiently advocate the cross-organizational interactions between business entities.They call for business ecosystem architecture models to allow filling the gaps between internal and external operating environments, such as customers, suppliers, and business partners.Drews and Schirmer [12] discuss the stages from the traditional EA to Extended Enterprise Architecture (EEA), and finally to the Business Ecosystem Architecture (BEA).Drews and Schirmer [12] also present challenges of extending EA towards a value-producing instrument in complex and networked environments.Based on four cases, 16 challenges for business ecosystem architecture management are displayed (ibid).The presented challenges are classified into four groups: (1) challenges regarding the (meta-)modeling of EEA and BEA; (2) challenges regarding the tool support; (3) challenges regarding the management of EEA and BEA; and (4) challenges regarding the socio-technical dimension.We divide the challenges into the two categories: the complicated problems, i.e. those that can be dealt with by using engineering practices; and the complex problems, i.e. those that mandate the use of heuristic practices.Next, these problems, along with our proposed answers for EEAM and BEAM for the PA as an ecosystem, are further discussed.

As-Is BEAM as a Complicated Problem
We outline a vision for the IS support of the government ecosystem EA at conceptual level, 1) to enable the comparative analysis across 'whole-of-government', and 2) to provide the real-time as-is information of the ecosystem for target state design.Our proposed solution to complicated problems is an ontology-based, shared EA repository for the-whole-of-government real time updating descriptions.
As discussed by Bakhshandeh [78], ontologies can be used for identifying and disambiguating concepts with formal semantics, facilitating knowledge transfer and computational inference, thus allowing the analysis and detection of logical inconsistencies.The use of logic-based ontologies as the representational basis of EA models makes the use of computational inference and mappings between elements of different domains possible, enriching the overall architecture description [78].Hinkelmann et al. [21] note that "because of the complexity of enterprise architecture, machine intelligibility of enterprise architecture descriptions is considered essential for agile enterprises".Further, as noted by [21], prior research shows, that an ontology could be a solution to the above mentioned problems.We suggest co-creating the public sector ontology of the different level government ecosystems (local, national, federal), and mapping the EA descriptions and metamodels to them.We would like to see the output as the contextual ontology of government ecosystem EA modeling and enterprise engineering, on which we could build the corresponding shared digital IS ecosystem for EA management and development.We yield below the design principles and some central functional requirements for this IS vision, illustrated by exemplary use cases.The envisioned system provides kind of a semantic web, enabling many types of data mining and comparative analyses.
For the design principles of as-is BEA realization we suggest the following: 1) Dynamic as-is contentsautomated updates or suggestions for updates.2) Scalability, from the local ecosystems to the national, and the federal ones.3) Open access EA information for citizens, and partners.4) Plug-in architecture optionsexternal organizations outside of the ecosystem are facilitated to plug into the government ecosystem EA.The plug-in architecture enables cocreation, and co-evolution of the ecosystem, offering the option to the new actors to join the ecosystems, thus supporting spontaneous evolution of the BEA.Next, we present three functional requirements (R1, R2, R3) for the as-is BEA realization: R1. Basic modeling and metamodeling functionalities, that are readily available in many modeling tools, (e.g.[26], [69]).Modeling techniques have still to be innovated more for the organizational coherency and co-evolution purposes.In our development work, e.g. the strategy architecture models of the city were iteratively designed for the best fit to the purpose.The model notations and templates are to be designed situationally, where the model elements and attributes may associate to each other.The real-time as-is descriptions can be automatically visualized via metamodel rules, based on the structural information yielded regularly in everyday-work of the civil servants.R2.Agile analyses and comparisons tools, that necessitates interdependent, commonly agreed ontologies, e.g. for business catalogues, and organigrams.For instance, the as-is management structures can be made transparent in real-time and used to categorize the EA descriptions and their elements.Each description model and element are associated to relevant management structures.Also, different types of organizations, different types of management structures, and different types of management classifications are represented in the shared ontology.They facilitate the management needs for re-structuring the model instances according to their needs.Leaders and enterprise analysts may search descriptions and their elements according to shared ontologies, into which the metamodels of different description types are associated.For instance, the Minister of Commerce may browse for the different organizational options of the municipalities entrepreneurial services, to decide whether each municipality has organized them as a subsidiary, in-house-enterprise, via joint ownership, or other.Along the organigrams, he might get the visualized volumes of the actors.The citizen can compare, e.g. the service catalogues between the municipalities.R3.Situational EA frameworks of the as-is description can be pulled out of the system according to given parameters.The system might offer different EA frameworks templates to different organization types, too.Each organization may instantiate their framework and choose the EA models they prefer in their EA.For instance, the CEO of a water supply subsidiary may request the outline of the EA descriptions realized in his organization, and in those of the neighboring cities.Next, concerning the as-is BEAM, we discuss the challenges by Drews and Schirmer [12], as well as our proposed solutions to the complicated problems, i.e. an ontology-based, shared EA repository for the-whole-of-government real time updating descriptions.
Challenges concerning modeling include inter-organizational interfaces on all layers, finding the right level of abstraction and identifying shared business objects.As a solution, we propose a shared ontology, which supports associating intra-organizational EA models interorganizationally.This shared ontology may represent the abstraction levels of the EA description and their elements, whereby comparative analysis is enabled inter-organizationally.Also, it provides a common search index for comparative analyses, which enables the recognition of shared architecture objects.
Further, challenges include those associated with ultra-large-scale architectures with a large number of actors in BEA.As a solution, the envisioned BEAM IS support semi-automatically provides the ultra-scale current state descriptions.Updates are based on content changes in structural documents and automatically visualized in all EA layers.Therefore, the ultra-largescale BEA descriptions remain continuously updated.
Challenges concerning tools include tool support for ontologies as well as those concerning open standards for data exchange (import/export).Here, we propose envisioned IS support per-se as described in the article.Common modeling standards such as ArchiMate, UML, and BPMN could be mapped to the (core) concepts of the shared ontology to enable search and comparison regardless of the modeling language.
The modeling and tool aspects in Drews and Schirmer's [12] challenges, is the part which our vision of ontology-based hits best, as the shared EA repository for the-whole-of-government, updating in real-time.It encounters with EEA and BEA modeling and tool challenges, since they can be seen as "complicated", engineerable ones.The management and socio-technical aspects are more related to the complex issues, where solutions can be considered mostly heuristic and situational in nature.Therefore, the practice of the target state BEAM design, given in the next section, tentatively answers these complex challenges.

To-Be BEAM as a Complex Problem
Concerning the complex problems, our proposed solution is the government EA target state analysis and design process outlined below.As stated by one of our interviewees, enterprise architecture still seems to be a solid option for the government ecosystem design and governance: "We have a development-model, and there, architecture has a distinct role.Architecture has a very tense role in everything before the implementation, where we model operations, data and business-architecture, stakeholders and actors and their dependencies, in order to get an understanding of the whole ecosystem.What we are developing and how it relates to everything else.And there we use enterprise architecture.When the project starts, it's more of making sure that everything matches the architecture."Another interviewee, an enterprise architect, stated that EA is even more important in ecosystemic environments than before, noting that the current and target states should be updated in an agile manner: "I think that it is even more important that we apply enterprise architecture ... but that does not mean that EA should not adapt to the change, when we are making it.We have the target state, to which we take some kind of agile transitions.But in this developing world, it does not mean that we would necessarily reach that target state.Also, the target state has to be developed from time to time.In my mind, the idea of enterprise architecture is that we have an idea of our operations, where we are making strategic change, a clear target state.And we take small steps towards it." Next, we discuss some relevant problems of broadening the focus of EA to BEA as discussed by [12], before proposing an ecosystem architecture target state design management model and principles.
Challenges concerning management, such as inter-organizational tasks and roles can be approached with more transparency both in inter-and intra-organizational levels via ontologies that apply to management structures [16].Managing the aspects concerning BEA service provision can be solved with open network structure of actors and service providers.Also, our Plug-In architecture enables new (and temporary) actors to attach and contribute towards the development of ecosystems and services.As noted by one of the interviewees, another enterprise architect, the modeling functionalities should be easy to use and agile enough so that each organization can develop fit for purpose descriptions, as well as enable co-creation between the actors in the ecosystem: "Modeling each organization's own architectures is something that different organizations could do themselves, because of the differing needs.But future scenarios, the big picture,it is something where cocreation in the ecosystem could enhance the understanding of the realm." Challenges concerning socio-technical aspects, e.g.citizens and consumers as actors, and the lifeworld of customers and partners [12].Our solution provides an open channel for citizens and consumers to suggest and peer-evaluate ideas for the development of the ecosystem.It seems, as noted by one interviewed manager, that in a public smart city ecosystem, the public administration needs to function as a central actor, though not necessarily as a leading actor: "The city could act as an operator, matching organizations.Ecosystems are grounded on voluntary participation.... I don't see the city as a leading actor, more like being a coordinator, ... but if the city can influence on the way things work out and bring other actors to the same table ... in that way, yes."This viewpoint of public administration acting as a facilitator rather than leading actor in idea co-creation and idea evaluation was a recurring theme in our interviews: "We have also another goal, which is enabling services outside of those produced by the public administration.Co-creating and co-innovating with, e.g.enterprises, so trying to find a role as a facilitator, where ideas and open data could develop business activity to the area", stated one manager.In prior research [79], roles within ecosystems are discussed.These include (1) niche provides, who form the majority of most ecosystems, (2) physical dominators, controllers of the bulk of the innovations occurring, (3) value dominators, who extract value from the ecosystem, and (4) keystone organisations, i.e. leaders.Further, ecosystems governance, i.e. decision-making covers two modes of governance: integrator and a platform hub (ibid).Drews and Schirmer [12] also discuss about the roles in BEA.While they suggest EEA to already extend to cover concerns such as customers, partners and suppliers, they argue that that for BEA, a central actor must have an overview of the whole ecosystem, i.e. the infrastructure and interfaces to all connected EEA's.Our results indicate that in smart city ecosystem, public administration sees itself as a facilitator, not a leader.In line, [31] presents cities as "platform hubs", which facilitate the interaction of third-party service providers with customers, citizens and companies.
Figure 1 suggests a management model for the government ecosystem architecture.The stages 1 to 4 illustrate the tentative target state design process for co-creating new services in the ecosystem.In the phase 1, idea co-creation, an initiative appears, e.g. from citizens, government actor, or private companies (cf.[17]).To support the innovation, the phase should be as open as possible.Idea evaluation in the ecosystem seemed to be both a challenge as well as richness of the ecosystem approach.One interviewee, who acted both as a manager and a business architect, noted the following: "It is a challenge… what kind on platform would enable the participation of citizens ..., and maybe some enterprise or an organization could seize those ideas."This creates a socio-technical dimension to the idea co-creation, which was noted also by the interviewees: "We have created models for co-creation, meaning a way to operate with enterprises and research institutes, when we are developing or helping enterprises to develop services."A challenge frequently mentioned was the storing of data and the creation of shared data models.
As an example, one interviewee mentioned, that majority of the interviewed cities belong to Helsinki Region Environmental Services, a municipal body, which produces waste management and water services.Although waste management is a vital theme in smart city and PA endeavours, no shared repository or data models exist.Caputo et al. [3] further discuss the vital themes of linking smart technology and big data in a smart city ecosystem from a systems thinking perspective.They conclude, that efforts should be made to make the data freely available, as value is generated from the usage of the data, not the data itself, although noting that smart technologies and big data are as key levers able to produce effects only as a consequence of actors' participation and collaboration.Fostering Big and Open Linked Data (BOLD) [62] seems to be a key to successful EA usage in the ecosystemic environments.
In Phase 2, the idea co-evaluation is done by a variety of stakeholders.For instance, public agencies might have a special interest in the financial analysis, whereas local citizens might appreciate the geographical locations of the services, and private enterprises can have goals of their own.The balance between financial and functional performance must be achieved [17], and those ideas recognized, which benefit the ecosystem as a whole.As stated by one of our interviewees, a manager: "We have this challenge with new services and ideas from the citizens.If we get a good idea somewhere, from citizens, it does not mean that we as a public actor can manage that.But maybe some enterprise or other community could do it with us." This is followed by Phases 3a Current state analysis, 3b Target state design, and 3c Gap analysis.In 3a, the participating actors are identified, resulting in the subset of necessary distinct EA's, covering concerns such as customers, partners and suppliers [12], i.e.EEA (see below).The as-is BEA updates semi-automatically by increments in the project implementation, finally fully reflecting the previous target state.The deployment may be ceased at any time based on the feasibility checks, too.Also, the architectures of each individual EEA participating can be updated alongside.Here, as well as in prior phases, the ontology discussed above is necessary to ensure consistent and coherent data content between different actors of the ecosystem.For instance, if different actors in the ecosystem would not have mutual naming conventions for their information architecture elements and data content, co-creation would not be realized optimally.
Phase 4, Project implementation starts with suitable project organization, involving the configuration of internal and external ecosystem actors, and IT-service providers.Almost all of the interviewees mentioned the usage of (open/public) data as well as sharing data between the actors of the ecosystem as a crucial aspect in service co-creation.The usage of data seems to cover the whole design process, from idea creation to implementation.As noted by one of our interviewees, an enterprise architect, "Data is the thing.We should understand the citizen-data and the essence of whole, so that we can use that data and implement services where needed ... with data we should provide services across the ecosystem, not just public services, but services provided by that area."This view was shared by a manager of another city: "In my mind the key is to gather data about the environment and use that data in design and management".The data can be used to create a sense of the whole ecosystem, as well as to decide which projects to implement: "Big enough picture is needed, but the experiments need to be small.Our idea is, that we take one segment, cluster some data ... and then begin the concrete project".
As discussed in Section 3, in DSR [60], the theoretical knowledge base and real-life environment are married for the researchers to create an artifact that is needed in the environment.In line with that thought, we refer to prior research, alongside our interview data, and propose principles (P1 -P6) for government ecosystem architecture management.Hedges and Furda [79] discuss architectural principles based on earlier research, offering three perspectives: decomposition, modularity and design rules, which cover four rules: simplicity, resiliency, maintainability and evolvability.Janssen and Kuk [46], examine the use of EAs in the Dutch public administration from a complex adaptive systems perspective, and based on analysis of 11 cases, derive eight architectural design principles, including development of modular architectures, stimulation of sharing and formation of coalitions.Further examples include the study by Lnenicka and Komarkova [62] who discuss developing a government enterprise architecture framework to support the requirements of big and open linked data with the use of cloud computing.Carter [53] discusses Systems Theory based architecture framework for complex system governance, and introduces a method, along with some principles.Jacobides, Cennamo & Gawer discuss ecosystems more generally.These valuable contributions offer a baseline for our pondering: P1. Dual nature and nestedness: government ecosystem architecture should, at its highest level of abstraction (to-be complex level), be simple; yet thrive to capture as-is complicated architecture accurately and unambiguously, harnessing latest technological achievements (see Section 6.1, cf.[79]).The ecosystem forms of different systems, such as participating actors.Although the ecosystem is emergent, systems-wide design and planning can be achieved at various levels.P2.Openness: ecosystem should strive to openness, where new actors could join the ecosystem (ibid).Openness does not only mean the lack of restricting new actors to join, but also actively promoting the ecosystem.This is done with Plug-In architecture (see Figure 1), (cf.[79]).P3.Evolvability, Needs-based utilization and Modularity: to foster the evolution of the ecosystem, not only should openness be fostered, new services should be designed in modular and agile way.[80] note, that while not regularly noted, an important characteristic of ecosystems is that they help coordinate interrelated organizations that have significant autonomy via modular architectures, which allow for coordination of independent yet interdependent firms through ecosystems In Figure 1, a particular project is implemented in means of modularity: participants include existing ecosystem members, as well as a new member, joining through the Plug-In architecture.The ecosystem evolves through projects, where participants are decided on demand.(cf.[46]) P4.Co-operability: much like in natural ecosystems, government ecosystem is based on cooperability, such as co-creation of services.In Figure 1, project implementation is achieved by a variety of voluntary participants.Although participating to any given project is voluntary for the ecosystem actors, public administration actors frequently act as facilitators (cf.[46], [80]).P5.BOLDness: from idea co-creation to new service provision, to automated As-Is BEAM, actions in the ecosystem are based on fostering Big and Open Linked Data (BOLD) [62].P6.Holism and Circular Causality: to foster the benefits of the ecosystem, a systemic stance is needed, embracing holism, e.g.interactions among actors, as well indirect causality among actors.Holism also includes notion of complementary viewpoints, where different actors have varying perspectives about the actions in the ecosystem (cf.[53]).These principles, along with the management model and the IS-supported, ontology-based EA repository form the tentative basis for the government ecosystem architecture design and management.As discussed prior (see Section 2), disciplines such as EA possess a dualistic natureconcerning both complex and complicated systems [44].We argue, that this is to be achieved by combining two perspectives: modeling the state of, e.g. the infrastructure and data of the organization (complicated problem) as well as managing social phenomena in the midst of ecosystemic environment (complex problem).We suggest the current state EA modeling to follow the engineerable path as the complicated problem, by semi-automated models of the as-is, whereas the target state design of BEA is left with situational, heuristic practices, however benefiting of the as-is repository.

Conclusions
Based on our research concerning Finnish national enterprise architecture (EA) adoption in long run, this study discussed the development of EA in order to support business ecosystem and organization design.We discussed, what kind of information system (IS) is needed in a complex socio-technical government ecosystem for real-time current state analysis, and what kind of management model is needed for the government ecosystem architecture target state design.Our research context indicates, beyond a federal government or a state one, that even a single municipality, like a city concern, can be perceived as an ecosystem of its sectoral domains, subsidiaries etc.The objectives of the study were, to: I. Outline some basic functional requirements of an ontology-based, shared EA repository for PA ecosystem and to propose a vision of the real-time information system support for such a repository.II.Further develop previously introduced [18] management model for the government ecosystem architecture target state design.In this study, we outlined a vision of an overall ontology-based, shared EA repository for thewhole-of-government current state descriptions.Further, the central design principles and functional requirements for such a system were specified, and some potential use cases were illustrated.A tentative management model for future state ecosystem architecture was discussed via a model of design process for co-creating new services in the ecosystem, and government ecosystem architecture management principles were outlined.We envision an IS solution for EA descriptions' accessibility, and automated update in government ecosystem.The IS vision and presented tentative model stand for design artifacts in terms of [60].As discussed prior, we used abductive logic reasoning to enhance our vision, which forms a 'process of discovery' where inferences are drawn to the next best explanation in each cycle, with wider set of data.As for our latest research cycle, we used interview data from four smart city cases in Finland, serving as representations of PA ecosystems.Thus, we propose EA as a concept for organizational design of a government entirety.
There are some limitations to our study, and, in the following reliability and validity are discussed in relation to our last interview round.Reliability is seen as to what degree the results are consistent.Validity concerns the accuracy of the measure, which means the degree to which measurements are what they should be.Concerning validity, there are at least few notions to consider.Interviewees interpret the questions in a way that is in concordance with their rendition of the reality in that particular time and place.We as scholars have made our own interpretations about the study material in the analysis phase, and therefore, some preconceptions may have affected the analysis.Therefore, although this research could be repeated with the exactly same layout, with same circumstances and with the same interviewees, different sentiments could occur.According to Hsieh and Shannon [73] threats to validity regarding content analysis further include the risk that the researchers fail to understand the whole context, and thus missing key categories.We tried to minimize this risk with analysis triangulation, where two authors both analysed the data.To enhance repeatability of the interviews (i.e.reliability), example questions of a manager interview are offered in the Appendix.The case studies reported were based on only a single country, its public sector, and four cities, and different aspects might be emphasized elsewhere.Therefore, more research is definitely needed, for instance, on other countries.
This article is based on a working paper, presented at the Workshop on Resilient Enterprise Architecture, in liaison with the International Conference on Perspectives in Business Informatics Research.Prior to the conference, the paper was reviewed by two blind reviewers.This could be seen as some form of cross evaluation, adding the soundness of the results and analysis.After the conference, the paper was further revised based on the discussion and additional data.Several pages were added, and the original management model was further enhanced, and design principles were outlined.
We presented the design principles and central functional requirements of the ontology-based as-is government ecosystem architecture repository, that is meant to be applicable to any chosen whole-of-government entirety.The proposed solution has several anticipated benefits.The system might maintain transparency and comparability across the entirety of the government, eliminate duplicate work, enhance the sharing of the best practices, and most importantly, support the co-evolution of PA structures towards higher coherency and synergies.Shared EA descriptions would support also co-creation and co-evolution of the ecosystem.However, the implementable solutions require further studies.The aim of the study is to encourage evolutionary studies, and pilots, especially constructive ones, to reach out to more specific specifications and design principles for the BEAM solution.Especially it requires the design of a future common, wider ontology of the public administration sector and concepts.This implies application of ontology engineering knowledgebase in further development and research of the subject (cf.[17]).Secondly, the tentative target state design process should be both tested at a real environment, and further enhanced based on the results.