Business Architecture Development at Public Administration – Insights from Government EA Method Engineering Project in Finland

. Governments worldwide are concerned for efficient production of services to customers. To improve quality of services and to make service production more efficient information and communication technology (ICT) is largely exploited in public administration (PA). Succeeding in this exploitation calls for large-scale planning which embraces issues from strategic to technological level. In this planning the notion of Enterprise Architecture (EA) is commonly applied. One of the sub-architectures of EA is Business Architecture (BA). BA planning is challenging in PA due to a large number of stakeholders, a wide set of customers, and solid and hierarchical structures of organizations. To support EA planning in Finland, a project to engineer a government EA (GEA) method was launched. In this paper, we analyze the discussions and outputs of the project workshops, and reflect emerged issues on current e-government literature. We bring forth new insights into BA at PA and formulate them into suggestions for government BA development.


Introduction
The diffusion of e-commerce technologies in the private sector has made public administrations (PA) foster e-government initiatives and programmes (Cordella 2007).E-government refers to the deployment of Information and Communication Technologies (ICT) to promote more efficient and effective provision of high quality government services (Punia and Saxena 2004;Cordella 2007).This means a wider array of services for customers, as well as better and more secure communication between customers and government agencies.E-government is expected to bring administration closer to citizen's everyday life (Peristeras and Tarabanis 2000) and make government more accountable and transparent to customers (Punia et al. 2004;Janssen and Cresswell 2005).
Implementation of e-government is challenging in many ways.Much of government work is carried out by multiple government agencies working as vertically rigid 'silos' (Punia et al. 2004;Tarabanis, Peristeras and Fragidis 2001).This results in poor coordination, poor performance and poor quality of services.For mature egovernment development, there is a need for a sophisticate and centrally managed strategy function (Peristeras and Tarabanis 2004) based on a comprehensive view of processes, information, systems and technology in PA.This kind of view is provided by the notion of Enterprise Architecture (EA).Enterprise architecture is seen as a collection of artifacts that define and describe the structure and processes of an enterprise, the information being stored, processed and communicated in this enterprise, the systems used for these activities, and the technologies and infrastructure that the systems are implemented with (Leppänen, Valtonen and Pulkkinen 2007).Here, an enterprise is regarded as a public organization, a private company, or a virtual organization in the form of a network of organizational actors aiming at a common goal.
Enterprise architecture planning and development is difficult particularly in PA, due to a large number of government agencies, a wide and heterogeneous set of customers, as well as a formal, hierarchical structure of authority with a detailed, rationalized division of labor.EA planning means the definition of the overall target state of an enterprise including the transition plan as a road map of the transition projects to achieve the target state (Pulkkinen and Hirvonen 2005).EA development refers to an execution process of one of the transition projects for new EA arrangements, either as new organization structures, processes, information assets, eBusiness solutions, information systems, technology platforms etc. Business architecture development focuses on designing and implementing transitions (e.g., in services, structures or processes).
Various frameworks, models and methods have been suggested for EA planning and development (e.g., see reviews in Whitman, Ramachandran and Ketkar 2001;Schekkerman 2003;Pulkkinen et al. 2005), some of which have been largely applied at PA as well.Due to differences in laws, organizational structures, degree of privatization, culture etc., no framework or method as such is applicable in all the countries or even among various branches of administration, but they have to be customized.
In Finland, as part of the Interoperability Development Programme (IDP) at the Ministry of Finance, five subprojects were launched to implement the government policy decision on the development of IT management (Ministry of Finance 2006).In one of the subprojects a method for government EA (GEA) development was engineered, called the GEA method in this paper.The project group consisted of representatives from Finnish state administration, municipalities and consultants.The GEA method is composed of a large conceptual framework, a general-level process model and normative instructions for how to apply the framework.The framework covers four EA viewpoints and three description levels to be adapted in GEA modeling.The viewpoints cover four inter-related sub-architectures, namely business architecture (BA), information architecture (IA), systems architecture (SA) and technology architecture (TA).
Due to the strict time limit provided for the method engineering, the outcome can be seen as a first version of the GEA method for Finnish PA.The intention by the Finnish state government has been to develop the GEA method further, for instance by applying it in pilot projects.In this paper, our purpose is to search deeper insight into BA development especially in PA, and suggest improvements into methodical guidelines of BA development.We do this by analyzing the recorded and transcribed discussions in the workshops of the GEA method engineering and by comparing the emerged BA development related issues with conceptions and ideas presented in the literature.In this way we pursue to bring forth new ideas to be included in any EA method.Our analysis here covers only a small part of themes considered in the workshops.We focus on BA visions, customer activation at BA design, and BA implementation models.
The remainder of the paper is structured into four sections.In Section 2 we outline the GEA method engineering project and the GEA method.Section 3 describes the research method used in the study.In Section 4 we analyze issues raised at the project workshops by comparing them with conceptions presented in the literature.In Section 5 we present, as implications from the analysis, suggestions for improvements into methodical guidelines of BA planning.The paper ends with a summary and conclusions in Section 6.

CASE: the GEA Method Engineering Project
In autumn 2006, Interoperability Development Program (IDP) was launched at the Ministry of Finance in Finland to implement government policy decision on the development of IT management (Ministry of Finance 2006).The program involved five sub-projects: (1) to analyze the state of the art of the information systems architecture of the state government, (2) to engineer a government EA (GEA) method and to make a high level description of the target architecture, (3) to develop a GEA governance model and a GEA maturity model, (4) to model logical integration architecture for the target state, and ( 5) to analyze obstacles and potentials for reusing the current central state repositories and databases.
Here, we focus on the project pursuing the second goal, the GEA method engineering (ME) project (also described in Hirvonen, Pulkkinen and Valtonen 2007).The project group consisted of representatives of Finnish PA (i.e. the Ministry of Finance, ITM of the Council of State, Population Register Center, National Board of Taxes, Finnish Road Administration and ITC Management of the Ministry of Justice), a municipality (i.e.Turku town), a university, and the liable consultancy (Tie-toEnator Oyj), all bringing their expertise on different fields to the project.The work in the project comprised five tasks: (1) selection of a EA method, (2) adaption of the EA method for Finnish PA, (3) making a user manual for the GEA method, 4) applying the GEA method to a small-scale case and thus producing an exemplar document of the method use, and (5) high level target architecture planning and description.The project was organized into 15 workshops led by consultants.
As the project output, the GEA method was produced.It is composed of a conceptual framework (the GEA grid), a process model with stepwise and normative instructions for proceeding, and an array of description models.The GEA grid is structured by three description levels and four architectural viewpoints (Table 1).The description levels are: PA, domains (e.g., a branch of administration) and subdomains (e.g., a government agency).For the description of the target state EA, the domain level was thought to be, for example, a common goal of a network of organizations (called 'cluster' at the GEA method document and at the workshop).Subdomains in that case were, respectively, the subareas of the development goal of the cluster.The EA viewpoints correspond to four sub-architectures: business architecture (BA), information architecture (IA), systems architecture (SA) and technology architecture (TA) (cf. TOGAF, Open Group 2003;Hirvonen and Pulkkinen 2004).The sub-architectures include descriptions, for example, of stakeholders, customers, organizations, services and processes for BA, strategic data warehouses, information assets and vocabularies for IA, IS portfolios, IS lifecycles and systems services for SA, and technology policies, standards and reference models for TA.

BA
IA SA TA PA level

Domain level
Sub-domain level The GEA method is meant to be applied situationally (Ministry of Finance 2007).This signifies that a suitable approach to the situation at hand is to be selected.If the process-driven approach is selected, the first steps are taken to develop BA and IA focusing on services, processes and the information related to them.If the systemdriven approach is seen more suitable, the EA development may start with describing current information systems and how they might be harmonized or integrated.The domain level of development is defined to meet situational needs.The process model is composed of three phases: (1) outline a target state and the current state, (2) make plans toward the target state, and (3) make plans for implementation.In the first phase, the scope of the EA work is defined, descriptions of the current EA and needs for the changes are collected, the vision for the target EA state is outlined, and the development project is established.The second phase is to produce primary EA designs from the selected viewpoints and on the selected levels.This means that stakeholders are identified and analyzed, suitable description models are selected, issues affecting the EA at hand are analyzed, the EA is modeled, the EA vision(s) are reconsidered, and the defect analysis is carried out.The last phase aims to make plans for implementation projects (so called road-map), assess their benefits and risks, prioritize them, and distribute the outcomes of EA planning to the stakeholders (Ministry of Finance 2007).This process is applied either for EA planning or EA development.Regardless of the selected approach, an EA development process iterates through several viewpoints and description levels to implement a stated EA vision.

Research Method
This study was conducted as a case study (Yin 2003) to reveal the intricate phenomenon of BA development at PA, and by reflecting the case on e-government literature, to suggest improvements into methodical guidelines of BA development.
Data gathering and validation.The primary data was collected by the first author who was acting as a participatory observer at 13 workshops of the GEA method engineering project.The researcher acted partly as an outside observer and partly as an involved researcher commenting on issues (cf.Berger andBeynon-Davies 2004, orig. Walsham 1997).Discussions were written down as field notes in the first four workshops and tape recorded in nine consequent workshops.The recorded discussions (in average ca 3 h) were transcribed (altogether ca 500 pages) and coded during data analysis.As secondary data, the project documentation, minutes of meetings and results of the workshops were extensively exploited in data synthesis and analysis.In addition to these, all material of the overall interoperability program and its subprojects was available in a shared workspace offered by the Ministry of Finance.The researcher could not attend two of the workshops, and some of the tapes suffered from minor technical problems.Although the work at the consultancy could not be followed, outcomes were reported in the workshops and shared at the workspace.The primary data was in most cases checked by the group members in the beginning of the workshop that followed the one where the data was collected.All the delivered data was shared for the group members also in a shared workspace, and corrections were welcomed also by email.This arrangement enabled the validation of the data regardless of time and place.
Data analysis.The primary data was subjected to in-depth textual analysis.Secondary data allowed cross checking with the aim of a stronger substantiation of analysis and conclusions (cf.Berger et al. 2004).The primary data was organized as a thick text repository and analyzed interpretatively by semi-open coding to uncover the salient issues in the workshops.Therefore, a process of quoting, coding and categorizing was carried out in an iterative and converging fashion, forming the final themes by confirming or absorbing the previous ones.By a theme we mean a bunch of categories and their attached quotations which have been formed iteratively and converged based on the whole database.Representative quotations were selected by the authors.The results were validated by stakeholder reviews and by comparing them with the results of a parallel qualitative study at Finnish state administration with independent data set (Isomäki, Liimatainen and Valtonen 2008).The results in this paper are in accordance with those got from the aforementioned study.

Results
In this section we bring forth e-government issues related to business architecture planning based on interpretative analysis of workshop discussions, document analysis of the GEA method, and e-government literature.Issues are organized into three themes: (a) e-government business models, (b) customer-driven development, and (c) business process modeling

E-government Business Models
A large variety of e-business models have been suggested for private sector in the literature (e.g., Weill and Vitale 2001;Rappa 2002; cf. a review in Hedman and Kalling 2003).In the recent years, e-business models have excited interest in public administration as well (Janssen, Kuk and Wagenaar 2005;Lee and Hong 2002).Ebusiness models reflect the core business of an organization and describe the organization from the perspective of its main mission, and the products and services that it provides to its customers (Janssen, Kuk et al. 2005, orig. Wand, Woo andHui 1999).
Applying an e-government business model helps to define service strategies, to identify, categorize and structure the services, and to view the service production as a more organized set of processes.It may lead to changes in functions, roles, responsibilities, organization structures and infrastructures (Vitale, Ross, and Weill 2002) also in public administration.Janssen, Kuk et al. (2005) discuss the e-business model taxonomy of Weil et al. (2001) applying it for e-government.In the following, we shortly describe some of these e-government business models.
Based on the full service provider model, a full range of services is provided to an internet user in one service domain (e.g., health domain), directly or via allies.The aim is to own the primary consumer relationship.The value net integrator model supports establishing the coordination of processes across a value net by gathering, synthesizing and distributing information.Applying the content provider model means that information, digital products and services are provided via intermediaries.The content comes from one single organization and can be customized.Weil et al. ( 2001) also suggest the direct to consumer model, which provides "goods or services directly to the customer, often bypassing a traditional channel (Janssen, Kuk et al. 2005)".For a Finnish customer, this kind of service already exists, for example, a tax deduction card can be ordered online by-passing officers as a matter of course.In the virtual community model, an online community of people with a common interest enables interaction to enhance service provision.This has mainly potential in future until internet users are getting more accustomed to advanced services (e.g.., eBay: Resnick, Zeckhauser, Swanson and Lockwood 2006; future service production: Bjoern-Andersen 2007).
In the project, e-government business models were not explicitly mentioned although several examples of online services were highlighted to illustrate the goals and possibilities of e-government.For instance, a way to on-line support the various phases of building process was outlined.This e-service would collect information, such as blueprints by the design firm, and support license case processing actions of builders and officials.A consultant: "It is known, that with the help of an electrical desktop you can nicely try to guide or even force making of more thorough applications, i.e., collecting information.Thus, you get more prepared text and the officials for the supervision of the building might concentrate more on assessment… and not using their time on information collection and chasing it after".The GEA method does not refer to any specific e-government business model either.The vision of the target state BA can be created using a scenario technique described in the GEA method.Thereafter, to put it simply, the GEA method guides BA development (a) to take legislation, visions, trends and strategies as a starting point, (b) to identify customers and their needs, and (c) based on these needs, to outline services for customer profiles.Guidelines for e-government business models should be an integral part of any GEA method.The scenario technique, for example, might present different choices for e-government business models.This might provide managers with an analytical tool set for thinking through potential e-government business models and the consequences for realization.Weill et al. (2001) suggest this kind of approach as a tool for enterprise managers.E-government business models can also be seen to have clear impacts on how business processes should be structured, interrelated and designed.

Customer-Driven Development
The importance of customers' role in the development of e-services and processes is commonly recognized (Vitale et al. 2002).Also the literature on e-government brings forth this issue, for example, customers' needs-to-services mapping (Peristeras, Tarabanis and Loutas 2007), and involvement of potential users in the co-production of new content and services (Janssen, Kuk et al. 2005).Application of the customerdriven approach manifests itself, for example, as the provision of pro-active services.Web sites could be personalized in such a way that an email alert is got before the expiration of one's driving license (Janssen, Kuk et al. 2005).At the workshop discussions and in the GEA method a PA customer is referred as a citizen, a private sector organization, a non-profit organization, or another government agency inside PA.The government agency can act either at a local, state or European Union level (Peters, Janssen and Engers 2004).
The customer-driven approach was seen quite essential to BA development during the workshop discussions.The recognized dimensions of customer-driven development were transparency, automation of the non-value adding actions, pro-activity of services as well as the mapping of provider and customer processes during the BA development.Transparency of services was seen beneficial since it enables a customer to follow up steps by which her/his service request proceeds in a network of government agencies: "If it's a lengthy process, like applying an exceptional permit for a summer cottage, which may take even a year … I would have liked to see, if the case is at a standstill there at the municipality."Automation of service processes was seen as a means to eliminate the demand to execute non value-added operations.A citizen could be, for example, automatically subsidized by housing allowance, or at least informed about this possibility, if her/his income meets the stated income limits.The subsidy could be even channeled directly to her/his lessor: "They know it very well who owns the rental apartment, and the money can go straight to there."Several cases related to pro-active services were also discussed.For example, a security guard might routinely make an offer to help a victim in making the report of an offence.Special attention was given to the notion of life cycle in the context of customer-driven approach.E-government should be challenged to implement services based on the life-cycles of the publicly maintained information.For instance, based on the life-cycle of a building, several services were identified, for example counseling the construction planning, location registration, license services, accepting the building process supervisors, and customer involvement in the local area development planning.A life-cycle view may thus help to recognize essential life events (Trochidis, Tambouris and Tarabanis, 2007) to be implemented as e-services.
The customer-driven approach is clearly visible in the GEA method (Ministry of Finance 2007).The method guides principally to take customers and their needs as a starting point in the identification of customer profiles and service portfolios.Services would then be described, and among other things categorized into different service types (like core online service, information service or other).Services can also be characterized, for example, in terms of iterativeness measuring the number of interactions between customer and officials needed to conclude one case (Ministry of Finance 2007).

Business Process Modeling
Public administration is commonly afflicted by separate silos, having negative influence on the performance of processes and their coordination (Punia et al. 2004;Tarabanis et al. 2001).Many services require actions from more than one agency.To cope with that, the agencies have to be interoperable, not only at the technological level, but at the semantic and organizational levels as well (e.g., Peristeras et al. 2007).Co-operative service production and delivery requires cross-agency processes, or inter-organizational processes (IOPs) (Janssen and Cresswell 2005).The IOPs (or cluster processes, as the group also put it) were largely discussed in the workshops.An IOP was defined to mean a process which crosses the boundaries of branches of administration or service provider organizations.A service provider could also be a private or non-profit organization.'Silo' problems were recognized to be quite recurrent, as noticed: "At present, the processes break immediately when the boundary of an organization is encountered.… the responsibility is passed to a customer who is expected to act respectively [i.e. to trigger a process with another agency]".
There are many challenges related to the implementation of the IOPs.Firstly, it is difficult to define a strategy for an IOP, as stated in the group: "Even if a [IO] process was identified, it has no formal strategy."The group concluded that when developing an IOP co-operatively, you have to take into account and adapt the different BA requirements originating from several strategies of participating organizations.A PA representative: "But how do you cope with that in future, if you have a priority of one organization, and still all the others are supposed to act accordingly?"The consultant: "Then you have performed the requirements engineering and management wrong.You have to specify all the stakeholders and users, whether it is a bunch of three organisations or actors…" Secondly, special principles are needed to implement an IOP.Punia et al. ( 2004) list three ways to structure workflows in IOPs.In sub-process integration organizations link their sub-processes together creating a new process that spans all the organizations.Alternatively, a new public process is developed in the organizations, or bought from a third party, for linking their internal sub-processes.Sub-process execution could also be implemented through bidding.Organizations that want to use a service providing a sub-process make bids, and organizations that want to sell, respond to the bids.For us, it seems that implementation of a public process would result in extra administrative work in a long run, whereas integration of subprocesses, although more demanding for developers, would enhance and smooth current processes.
The group elaborated also another notion, called shared process, to promote organizational interoperability.A shared process means a chain of operations which are executed in the similar way in several agencies.Examples of typical shared processes are case processing, licensing (i.e.certification, cf.Peristeras et al. 2004), and financial administration.It was seen important to harmonize current practices through a process which could be shared, supported and possibly automated by a centralized system.For instance: "the process related to a building license is actually a generic licensing process containing parts that could be reused".Of course, implementation of a shared process into an agency may necessitate its re-localization, possibly reconfiguration.One should, however, be aware of risks resulted from going too far in this kind of centralization, as experienced in the NHS project in England where local socio-technical needs were not allowed in local implementation of the process, even though it would have been possible technically (Eason 2007).
The GEA method guides to categorize business processes into two process types, core processes and support processes.A core process refers to a way how an organization aims at fulfilling its purpose of existence.A support process creates good conditions for core processes.In addition, management processes are mentioned but neither defined nor discussed.Each process is to be identified, represented in a process chart, and described in a process diagram containing sub-processes, customers, service provider roles, services and information system(s).The GEA method recognizes IOP's (called cross-agency processes) and shared processes but no instructions are given to identify, organize and implement those processes.We suggest that any EA method should advice how to select a suitable implementation strategy for IOPs and shared processes.A choice is situational and depends, for example, on stated goals and applied e-government business models.
Furthermore, we suggest that any EA method should address how to identify and model, not only "coal-face processes" but also management and strategy processes (cf.Ould 2005).As noticed in workshops: "Through [EA] descriptions [e.g., process maps] we are aiming at understanding.… to make better decisions.… Details, however annoying, have to be brought forth somehow, since they have to be EXECUTED somewhere".Especially describing the management and strategy processes were seen a tricky task: "There are some issues, for instance planning, monitoring, concern reporting, and official statistics,.. such things where this kind of [administrative] hierarchy -a state administration, a branch of administration and an agency -creates us services which transfer information and understanding from a hierarchical level to another.And where have we described them?It is as they would not exist at all."Although these issues were recognized in workshops, neither are they mentioned in the GEA method nor operationalized into instructions for the identification and modeling of management and strategic processes.We suggest that a normative technique (cf.Ould 2005) would be exploited for this purpose.
Including the coal-face, management and strategy processes in BA description would increase understanding, for example, of what kind of structure and implementation strategy would be beneficial when a IOP or shared process are to support an applied e-government business model.In IOP planning an implementation strategy should be chosen in a deliberate manner in order to involve and commit the concerned parties with sufficient resources.Developing shared processes implies the centralization of IS support with few alternative options.One can aim to harmonize the way of action among all the parties in order to deploy one IS for all, or, alternatively, to harmonize the process to a chosen level and support it by a configurable system that might take into account local socio-technical needs (cf.Eason 2007).

Implications
Based on discussions in the workshops, the analysis of the GEA method, and literature on e-government we conclude with the following suggestions for business architecture development.
Elaboration of a shared vision among the involved organizations.A number of studies (e.g., Scott, Golden and Hughes 2004) show that technology-driven egovernment implementation fails because of stakeholder resistance at the time when changes in processes and organizational structures should be made.We suggest the use of e-government business models as a means to direct discussions toward strategic issues in order to establish a shared vision at the organizational level among the concerned government agencies and business enterprises.E-government business models may guide the concretization of the selected vision into new arrangements of organizational structures and processes.In addition to those referred to in Section 3 (Weill et al. 2001), the literature provides other e-government business models (e.g., life-event portals and one-stop-shops, cf.Chatzidimitriou and Koumpis 2007;Momotko, Izdebski, Tambouris, Tarabanis, and Vintar 2007) that might be considered in a situational manner.
Customer-driven requirements engineering.In order for e-government to provide customer-oriented services, requirements engineering should be carried out in a customer-driven manner.We suggest that the notions of life-cycle process and life event workflow are used to find a proper match between the customers' view and the provider's view in the following manner: (1) Model the service provider's view (i.e.lifecycle process) and the customers' view (i.e.life-event workflow) and try to find out which part of the life-cycle maintained by PA should be supported by online services for the customers, i.e. mapping the customer process and the provider process to support the design and implementation of both views.(2) Look for "blind spots" in the customer process that could be smoothed.Typically these are situations, where the customer is obligated to patronize with several officials or agencies in order to get one single case to be handled.(3) Ask the customers how they could be served pro-actively by relevant information, products or services.(4) Ask the customers, to which information they would like to have an access through electronic self-service channels, such as internet, mobile phone, or digital television.
Identification and description of processes.One of the conclusions from the GEA method engineering project was lack of understanding of business processes, especially management and strategy processes.We suggest that the identification and modeling of the management and strategy processes is supported by a systematical approach developed by Ould (2005).
Planning inter-organizational processes.To support the planning of interorganizational processes in situations where service production necessitates cooperation between several agencies, or even private organizations, we suggest that interorganizational processes are carefully planned based on a specific implementation strategy.As mentioned above, there are many alternative strategies (e.g., integrating sub-process, public processes, and e-marketplaces by Punia et al. 2004).
Designing IS support for shared processes.One of the issues discussed in the GEA method engineering project concerned shared processes and how these are recognized and re-designed in local agencies and municipalities in practices.IS support for shared processes may mean (1) the use of the same IS to enforce the agencies to act in the same way in service provision operations, (2) the use of the same IS to support different instances of a shared process differentiated by customers' needs, and (3) the use of different IS implementations based on socio-technical factors and adapted situationally from one common IS (cf.Eason 2007).

Conclusion
Enterprise Architecture planning is a big challenge in public administration due to a large number of stakeholders, a wide set of customers with heterogeneous needs, and solid and hierarchical structures of organizations.To support EA planning in Finland, a project to engineer a government EA (GEA) method was launched in 2006.A part of the discussions in the workshops of the project addressed one sub-architecture of the EA, namely business architecture (BA).In this research we have analyzed those discussions and the GEA method documents, and reflected emerged issues on current e-government literature.Our aim has been to find new insights into BA and formulate them into suggestions for BA planning.These suggestions are related to elaboration of a shared vision among the involved organizations through the use of egovernment business models, customer-driven requirements engineering, identification and description of processes, and designing implementation strategies and IS support for different types of public processes.
BA planning contains many other important issues we had to exclude.For instance, questions about managing the inter-organizational processes and how to relate legislation and architecture management and planning are vital in BA planning.In our future research we aim to enlarge our analysis to cover also these issues, as well as to reveal the themes of overall EA planning and method adaptation for PA.The lack of a proper theoretical framework for possible e-government business models seems evident.Also a more careful consideration of consequences of applying of an e-government business model is an interesting issue for future research (e.g., the use of different modeling approaches, depth of customer involvement and process implementation strategies) in order to devise a systematic way for enhancing BA at PA.

Table 1 :
Overview of the GEA grid.