• Nie Znaleziono Wyników

Punkty widzenia architektury INSPIRE

N/A
N/A
Protected

Academic year: 2021

Share "Punkty widzenia architektury INSPIRE"

Copied!
14
0
0

Pełen tekst

(1)

VIEWPOINTS ON INSPIRE ARCHITECTURE

PUNKTY WIDZENIA ARCHITEKTURY INSPIRE

Jerzy GaŸdzicki

Polish Association for Spatial Information, Poland Council for INSPIRE Implementation, Poland

Abstract

There is a clear need to define a uniform approach for describing and modeling the architecture of INSPIRE in all its complexity, with its hierarchical structure and numerous components, most of them being in transition to comply with the INSPIRE principles and specifications. The generic approach proposed in this paper is based on the following ICT concepts and solutions:

m The ISO/IEC 42010:2007 Systems and software engineering – Recommended practice for

archi-tectural description of software-intensive systems;

m The Enterprise Architecture Frameworks, in particular those recommended and used by the US

Federal Government, including: the Federal Enterprise Architectures of the Office for Manage-ment and Budget, and the Architecture Framework of the US DepartManage-ment of Defense;

m The European Interoperability Framework (EIF) for European Public Services; m The Unified Modeling Language (UML).

The approach is presented with reference to the current situation in Poland and in the context of INSPIRE development trends.

Keywords: system architecture, viewpoint, spatial information infrastructure (SII), spatial data infrastructure (SDI), INSPIRE

S³owa kluczowe: architektura systemu, punkt widzenia, infrastruktura informacji przestrzennej, infrastruktura danych przestrzennych, INSPIRE

1. Introduction

There are two fundamental aspects of the Infrastructure for Spatial Information in Europe (INSPIRE). Firstly, INSPIRE is an innovative and comprehensive project involving the European Commission and the governments of all EU Member States. It is described in terms of goals, stakeholders, scope, tasks, standards and work program, taking into account various feasibility studies. Up to now project activities have been concentrated on establishment of a design framework which results from the INSPIRE Directive and determines specifications for spatial data and services.

(2)

Secondly, INSPIRE, according to the author, represents an idea of uniform describing and monitoring of a common European space for the benefit of all European nations. This idea and activities related to it shall contribute to sociopolitical progress, economic growth and environmental protection in Europe. It is much broader than the project based on the INSPIRE Directive. The idea is not limited by time, money or technology and has more conceptual than technical character. The INSPIRE idea will influence the INSPIRE project, which will evolve to cope with new concerns and emerging opportunities.

In both cases INSPIRE can be described and analyzed in a broader context of information infrastructures (II), systems of systems (Bejár et al., 2009) or software-intensive systems. In particular, methodologies of software-intensive systems engineering have great potential in designing and optimizing any spatial data infrastructure (SDI), named here spatial information infrastructure (SII) after the INSPIRE Directive. They are useful when modeling INSPIRE architecture and its components – the infrastructures of Member States and in turn their components.

The purpose of this paper is to introduce (Chapter 2) the concept of INSPIRE Architecture based on the ISO/IEC 42010:2007 Standard Systems and software engineering — Recommended practice for architectural description of software-intensive systems which was originally developed as IEEE 1471 Standard and is under joint revision by the ISO and the IEEE (ISO/IEC, 2007). The standard requires an architecture framework suitable for INSPIRE. Such a framework has been proposed making use of a review of widely used frameworks (Chapter 3) and considering INSPIRE characteristics. This generic framework consists of eighteen viewpoints identified by three levels and six domains (Chapter 4 and 5) and discussed with reference to the current situation in Poland (Chapter 6). Its relation to the European Interoperability Framework (EIF) for European Public Services has been demonstrated and exploited in the context of INSPIRE development trends (Chapter 7). Some basic models to document views have been presented and the use of Unified Modeling Language (UML) recommended (Chapter 8).

2. Architecture modeling Based on ISO/IEC 42010:2007

The following definitions are used in ISO/IEC 42010:2007:

m System – a collection of components organized to accomplish a specific function or set of functions. Note: SII is a system.

m System stakeholder – an individual, team, or organization (or class thereof) with concerns relative to a system.

m Architecture – the fundamental organization of a system embodied in its

compo-nents, their relationships to each other, and to the environment, and the principles guiding its design and evolution.

m Architectural description (AD) – a collection of products to document an architec-ture.

m View – a representation of a whole system from the perspective of a related set of concerns.

Note: a view may contain one or more models.

m Viewpoint – a specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purpo-ses and concerns for a view and the techniques for its creation and analysis.

(3)

The next three definitions are proposed to be included in the revised version of the standard (Emery and Hilliard, 2009):

m View correspondence – a mapping between elements of views in an architectural

description, used to establish consistency.

m View correspondence rule – a declaration of a mapping between elements identified in multiple viewpoints.

m Architecture framework – a set of predefined viewpoints, concerns, generic stake-holders and view correspondence rules, used to capture common practice for archi-tecture descriptions in specific domains or user communities.

Figure 1 presents this ontology using a simplified UML diagram. SII as a system has its architecture, which is described by architectural description. This description consists of views, each of them presenting the SII from its corresponding viewpoint, i.e. according to viewpoint specifications. A view consists of models with elements that can be related (mapped) by means of correspondences observing their correspondence rules. Various stakeholders of the SII have their concerns relative to the SII and these concerns play important role as they determine the viewpoints. The set of viewpoints used in the architectural description creates an architecture framework.

Fig. 1. The ontology of the SII Architectural Description based on ISO/IEC 42010 6,, $5&+,7(&785(6,, 67$.(+2/'(5 $5&+,7(&785$/ '(6&5,37,21 $5&+,7(&785( )5$0(:25. &21&(51 9,(:32,17 9,(: 02'(/ &255(6321'(1&( &255(6321'(1&(58/(

(4)

The process of SII architecting includes the following activities:

m Framing and studying the vision, goals and functions of the system under considera-tion,

m Identifying stakeholders and their concerns, m Selecting viewpoints,

m Elaborating and integrating models and views, and producing the system architecture, m Overseeing system construction and implementation,

m Maintaining and evolving the SII architecture.

Consequently, the INSPIRE architecture, as SII architecture, can be defined as follows: The architecture of the Infrastructure for Spatial Information in Europe (INSPIRE Architecture), is the fundamental organization of this infrastructure embodied in its components, their relationships to each other, and to its environment, and the principles guiding its design and evolution.

3. Architecture frameworks

An architectural description, defined as a collection of products to document an architecture, is a representation of a system in its present or future status, physically existing or being only a conception. In the process of description, system components and their functions are identified as well as their relations to each other and to the environment. Architecture is visualized in various textual, graphical and tabular forms as specified by viewpoints that were selected to create the architecture framework.

Thus, the total result of architecture describing depends on the architecture framework adopted. The standard ISO/IEC 42010:2007 does not recommend any specific framework, because architectural concerns vary from system to system being influenced by system stakeholders’ concerns. The system architects may use various predefined frameworks, called also view models, earlier developed and easily available. The following ones belong to the most known.

The Reference Model for Open Distributed Processing (RM-ODP) introduced by the ISO/IEC 10746 Standard (ISO/IEC,1998) provides 5 generic viewpoints (Table 1).

Table 1. RM-ODP viewpoints P D O -M R S T N I O P W E I V CONCERNS t n i o p w ei v e si r p r e t n E Thepurposeandbehaviorsofthesysteminrealitontotheorganziaitonobjecitve s e s s e c o r p d n a t n i o p w ei v n o it a m r o f n I Nature,interpretaitonandconsrtainsontheuseofthe informaitonhandeldbythe m e t s y s l a n o it a t u p m o C t n i o p w ei v Finutencfraitconesaldecomposiitonofthesystemintoasetofcomponenstthatinteractat t n i o p w ei v g n ir e e n i g n E Mechansimsandfuncitonstosuppotrtheinteracitonsofcomponenst t n i o p w ei v y g o l o n h c e T Technologeisseelctedfortheimpelmentaitonofthesystem,inpatrciualrfor st n e n o p m o c f o n o it a ci n u m m o c

(5)

The US Federal Enterprise Architectures (FEA). In this approach of the Office for Management and Budget (OMB), the total enterprise system is treated on its three levels (OMB, 2007) and three types of related architectures are distinguished (Fig. 2). Each of these levels (enterprise, segment, solution) is characterized by four attributes (scope, detail, impact and audience).

 Fig. 2. Architectural levels and attributes (FEA Practice Guidelines, OMB)

The Enterprise Architecture is an established process for describing the current state and defining the target state and transition strategy for an organization’s people, processes, and technology. It is also a management practice for aligning resources to improve business performance and help agencies better execute their core missions. Enterprise Architectures are fundamentally concerned with identifying common or shared assets such as strategies, business processes, investments, data, systems, and technologies.

Segments are individual elements of the enterprise describing core mission areas, and common or shared business services and enterprise services. A Segment Architecture defines a simple roadmap for a core mission area, business service, or enterprise service. It is driven by business management and delivers products that improve the delivery of services to citizens and agency staff.

Segment Architectures inherit the framework used by the Enterprise Architecture. It reuses important assets defined at the enterprise level including: data, applications and technologies.

A Solution Architecture refers to an individual IT system which is part of a segment. Special attention is paid to segments and their architecture which comprise a series of work products describing baseline architecture, target architecture, and a transition strategy for a defined segment of the enterprise (Fig. 3). This strategy describes the overall plan for an organization to achieve the target (“to-be”) architecture within a specified timeframe.

(6)

The US Department of Defense Architecture Framework (DoDAF)

The DoDAF organizes architecture concepts, principles, assumptions, and terminology about operations and solutions into meaningful patterns to satisfy specific Department of Defense purposes. It supports change in organizations through the building and utilization of architectures that:

m enhance decision-making processes by leveraging knowledge and opportunities for

reusing existing information assets,

m respond to stakeholder, customer, and client needs for effective and efficient proces-ses, systems, services, and resource allocation,

m provide mechanisms to manage configuration of the current state of the enterprise and maintain validity of the expected performance,

m facilitate the design of future states of the enterprise,

m establish a baseline architecture for solutions under development.

In this framework the following eight viewpoints are defined and described in detail (Department of Defense, 2009).

1. The All Viewpoint provides information pertinent to the entire architectural description and refer to the interrelated conditions such as doctrine; tactics, techniques, relevant goals, concepts of operations, scenarios and environmental conditions.

2. The Capability Viewpoint captures the enterprise goals associated with the overall vision for executing a specified course of action.

3. The Data and Information Viewpoint presents the business information requirements for objects, attributes, characteristics, and interrelationships.

4. The Operational Viewpoint captures the organizations, tasks, or activities performed, and information that must be exchanged between them to accomplish DoD missions. 5. The Project Viewpoint provides a way of describing the organizational relationships between multiple acquisition programs, each of which is responsible for delivering individual systems or capabilities.

6. The Services Viewpoint captures system, service, and interconnection functionality providing for, or supporting, operational activities. DoD processes include war figh-ting, business, intelligence, and infrastructure functions.

7. The Standards Viewpoint includes the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements. Its purpose is to ensure that a system satisfies a specified set of operational requirements.

8. The Systems Viewpoint captures the information on supporting automated systems, interconnectivity, and other systems functionality in support of operating activities. The Department’s emphasis on Service Oriented Environment and Cloud Computing may result in the elimination of this viewpoint.

The Zachman Framework

The Zachman Framework (Zachman, 2008) is a widely known approach for enterprise architecture developed by John Zachman at IBM in 1987. This evolving framework uses five or six so called reification transformations (viewpoints) such as scope, business, system, technology and representations, and six communication interrogatives (abstractions):

m data (what),

(7)

m network (where),

m people (who),

m time (when),

m motivation (why).

The Open Group Architecture Framework (TOGAF)

The TOGAF provides a comprehensive approach to the design, implementation and management of enterprise architectures. It is based on four so-called architecture domains: m business architecture which defines the business strategy, organization and processes

of the enterprise,

m applications architecture which provides a blueprint for the individual application sys-tems to be implemented,

m data architecture which describes the structure of logical and physical data assets, m technical architecture, which describes the hardware, software and network infrastructure. The Architecture Development Method (ADM) is applied to develop an enterprise architecture meeting the identified business and IT requirements. The ADM process is iterative and cyclic (The Open Group, 2009).

4. Three levels of INSPIRE architecture

There are some common characteristics of SDIs, which influence modeling of their architectures:

m a large number of stakeholders and diversity of their concerns, m the focus on making spatial data widely and easily available,

m the establishment and maintenance based on cooperation and input of many organizations, m ensuring interoperability by means of legislation, standards and specifications, m a network services oriented architecture,

m a sound conceptual base.

In the case of INSPIRE Architecture, the overall framework shall be based on a subdivision into architecture levels (Fig. 4 and 5). In fact, the hierarchical structure of INSPIRE is formed by three levels:

m supranational, i.e. the European Union (EU) level, where INSPIRE as a European

infrastructure is formed; this level includes EU institutions and bodies as well as links to external systems;

m national, i.e. the Member State (MS) level, where for each MS a national SII is formed that may include national level thematic components and cross-border systems; m subnational, i.e. the level of regional and local (R&L) spatial information systems,

registers or infrastructures, that may be linked to its MS SII.

At the EU level, infrastructures of 27 Member States (MS SIIs) are aggregated to form the European infrastructure. At the MS level, the MS SII may include national level components such as national registers or spatial information systems mostly maintained by governmental agencies. At the Regional&Local level there are regional or local, e.g. municipal, spatial information systems or infrastructures that may function as components of the MS SII or its national level components.

(8)

Fig. 5. The hierarchy of INSPIRE Architecture levels

Fig. 6. The perspectives of INSPIRE stakeholders of three levels: EU, MS and R&L

6,,,1(8523( ,163,5(  066,, 1$7,21$//(9(/ &20321(17 5(*,21$//(9(/ &20321(17 (;7(51$/ 6<67(0 /2&$//(9(/&20321(17 ( 8  0 6 5 /  &5266%25'(5 6<67(0

Fig. 4. Three levels of INSPIRE: European Union, Member State, Regional&Local. L E V E L AREA DETAIL STAKEHOLDERS U E USUALLYLOW COMMUNITYINSTITUTIONSANDBODIES,OTHERS N O I T A M R O F N I L E V E L N A E P O R U E N I D E T S E R E T N I S M USUALLYMEDIUM MEMBERSTATECENTRALADMINISTRATION, L E V E L L A N O I T A N N I D E T S E R E T N I S R E H T O N O I T A M R O F N I L & R USUALLYHIGH REGIONAL&LOCALAUTHORITIES, OTHERS N O I T A M R O F N I L A N O I T A N B U S N I D E T S E R E T N I  6835$ 1$7,21$/   1$7,21$/  68% 1$7,21$/ EU

(9)

5. Viewpoints in inspire architecture modeling

At each of the INSPIRE Architecture levels a set of viewpoints must be used, for instance some of those discussed in chapter 3.

However, the key concept of INSPIRE is interoperability of spatial data sets and services. Dealing with interoperability INSPIRE must be closely related to the European Interoperability Framework (EIF) for European Public Services (European Commission, 2009). The proposed INSPIRE Network Services Architecture is well aligned with EIF (Network Services Drafting Team, 2008). In fact, INSPIRE is a pioneering and advanced implementation of EIF, because it involves all Member States and imposes strict regulations and specifications on interoperable multi-thematic spatial data sets and related services, organizational structures, semantic rules and technical standards.

This role of INSPIRE can be demonstrated by comparing the underlying principles and recommendations of the EIF with appropriate provisions of the INSPIRE Directive, its implementing rules, specifications and procedures (Table 2).

In the EIF, the political context and four types of interoperability are described as follows: 1) The Political Context – partners with compatible visions, aligned priorities, and

focu-sed objectives,

2) Legal Interoperability – legislation so that exchanged data is accorded proper legal weight,

3) Organizational Interoperability – processes in which different organizations achieve a previously agreed and mutually beneficial goal,

4) Semantic Interoperability – the precise meaning of exchanged information which is preserved and understood by all parties,

5) Technical Interoperability – technical solutions for linking computer systems and se-rvices.

Consequently, for each of the three levels (EU, MS, R&L) five domain viewpoints can be distinguished (political, legal, organizational, semantic, technical). In this paper, one more important viewpoint is considered – the economic one including economic aspects of building, maintaining and developing INSPIRE components, problems of financing and self-financing, costs and benefits. The three levels and six viewpoints create the proposed Generic INSPIRE Architecture Framework (GIAF) as a matrix of 3x6 viewpoints (Fig. 7), which correspond with INSPIRE concepts and approaches relevant for architecture modeling.

Fig. 7. The Generic INSPIRE Architecture Framework as a matrix of INSPIRE viewpoints (matrix elements) of three government levels (EU, MS, R&L) and six domains

(10)

S N O I T A D N E M M O C E R D E S O P O R P F I E T N E M N O R I V N E S E C I V R E S C I L B U P S N O I T U L O S D E T N E M E L P M I E R I P S N I D N A 0 . 2 N O I S R E V F I E N O I T A D N E M M O C E R IMPLIENMSEPNIRTAETION s k r o w e m a rf y ti li b a r e p o r e t n i ri e h t n g il a d l u o h s ) s A P ( s n o it a rt si n i m d A ci l b u P . 1 t n u o c c a o t n i e k a t o t r e d r o n i ) F I E ( k r o w e m a r F y ti li b a r e p o r e t n I n a e p o r u E e h t h ti w .y r e v il e d e ci v r e s ci l b u p f o n o i s n e m i d n a e p o r u E e h t E R I P S N I( C E / 2 / 7 0 0 2 e v it c e ri D . 4 2 .t r a , 1 .t r a ) e v it c e ri D y ci l o p y c a v ir p d n a y ti r u c e s n o m m o c , e t ai r p o r p p a n a n o e e r g a d l u o h s s A P . 2 . h si l b a t s e y e h t ) S P E ( e ci v r e S ci l b u P n a e p o r u E h c a e r o f INSPIREDriecitvear.t13. e r a t a h t s e r u t c e ti h c r a l a ci n h c e t d n a s m e t s y s n o it a m r o f n i n g i s e d d l u o h s s A P . 3 . S P E n a g n i h si l b a t s e n e h w m si l a u g n il it l u m r o f r e t a c o t r e d r o n i l a rt u e n y ll a ci t si u g n il INSPIREDriecitvear.t7,ar.t8 ci n o rt c el e r o f y ci l o p n o it a v r e s e r p m r e t -g n o l a r e h t e g o t e t al u m r o f d l u o h s s A P . 4 .s S P E o t d e t al e r s d r o c e r Impelmentedatnaitonalelvel g n i k a t el i h w S P E h si l b a t s e o t r e h t e g o t g n i k r o w n e h w s s e n n e p o r o v a f d l u o h s s A P . 5 .s t n i a rt s n o c d n a s ei ti r o ir p ri e h t t n u o c c a o t n i oINnSopPeIRnnEesimspelmentaitonsibased e t a r o b al l o c o t d n a s n o it u l o s e r a h s d n a e s u e r o t d e g a r u o c n e e r a s A P . 6 .s S P E g n it n e m el p m i n e h w s n o it u l o s n o m m o c f o t n e m p o l e v e d e h t n o Apatrciipatoryapproachsiused ,s n e zi ti c n o n o it u l o s l a ci g o l o n h c e t ci fi c e p s y n a e s o p m i t o n d l u o h s s A P . 7 .s S P E g n i h si l b a t s e n e h w s n o it a rt si n i m d a r e h t o d n a s e s s e n i s u b ItNecShnPoIRlogEyspneeucfirtacilaitonsare t n e m h si l b a t s e e h t g n i w o ll a ,l e d o m e ci v r e s d e s a b t n e n o p m o c a p o l e v e d d l u o h s s A P . 8 .s t n e n o p m o c e ci v r e s g n it si x e , el b i s s o p s a h c u m s a , g n i s u e r y b s S P E f o INSPIREDriecitvear.t11 d el p u o c y l e s o o l t c e n n o c r e t n i o t e m e h c s n o m m o c a n o e e r g a d l u o h s s A P . 9 .s S P E g n i h si l b a t s e n e h w e r u t c u rt s a rf n i y r a s s e c e n e h t e c al p n i t u p d n a st n e n o p m o c SINerSvPciIeRsEwRtiehgaumaleitnodnmoenntNetwork el i h w s r e h t o o t el b al i a v a n o it a m r o f n i f o s e c r u o s ci t n e h t u a ri e h t e k a m d l u o h s s A P . 0 1 y ti r u c e s e r u s n e o t m si n a h c e m l o rt n o c d n a s s e c c a e t ai r p o r p p a e h t g n it n e m el p m i . n o it al si g el t n a v el e r e h t n i n e e s e r o f s a y c a v ir p d n a 3 1 .t r a , 4 .t r a e v it c e ri D E R I P S N I p o l e v e d d l u o h s ,s S P E f o t n e m h si l b a t s e e h t s d r a w o t g n i k r o w n e h w ,s A P . 1 1 ci t n a m e s t a , m e h t n g il a d n a s e c r u o s ci t n e h t u a o t s e c a fr e t n i y r a s s e c e n e h t .l e v el l a ci n h c e t d n a n o n o it al u g e R E R I P S N I d n a st e s a t a d l ai t a p s f o y ti li b a r e p o r e t n i s e ci v r e s ,s S P E f o t n e m h si l b a t s e e h t s d r a w o t r e h t e g o t g n i k r o w n e h w ,s A P . 2 1 s n o it c n u f ci l b u p ci s a b f o y m o n o x a t n o m m o c a p o l e v e d y l e v it c el l o c d l u o h s . a t a d f o e g n a h c x e e r u c e s e h t o t st n e m e ri u q e r e ci v r e s m u m i n i m n o e e r g a d n a k r o w t e N n o n o it al u g e R E R I P S N I t n e m d n e m a h ti w s e ci v r e S d e ri u q e r st r o ff e y ti li b a r e p o r e t n i ri e h t r o f tr o p p u s l a ci ti l o p n i a t b o d l u o h s s A P . 3 1 .s S P E f o t n e m h si l b a t s e e h t r o f Inpirncipel,thsisuppotrexsist n o it a m r o f n i e h t o t d e k n il n o it al si g el t n a v el e r ll a r e d i s n o c y ll u f e r a c d l u o h s s A P . 4 1 t n e m h si l b a t s e e h t g n i g a si v n e n e h w , n o it al si g el n o it c e t o r p a t a d g n i d u l c n i , e g n a h c x e . e ci v r e s ci l b u p n a e p o r u E a f o st i d n a e v it c e ri D E R I P S N I h c a e f o w al e h t o t n o it i s o p s n a rt e t a t S r e b m e M e s e h t w o h n o e e r g a d n a s e s s e c o r p s s e n i s u b ri e h t t n e m u c o d d l u o h s s A P . 5 1 . S P E n a f o y r e v il e d e h t o t e t u b ir t n o c o t t c a r e t n i ll i w s e s s e c o r p INSPIREenforcesthsirequriement e n if e d y ll a ci t a m e t s y s d l u o h s s S P E f o n o i si v o r p e h t o t g n it u b ir t n o c s A P . 6 1 tr a p e h t r o f st n e m e e r g A l e v e L e ci v r e S d n a g n i d n a t s r e d n U f o a d n a r o m e M . e m u s n o c r o / d n a e d i v o r p y e h t e ci v r e S ci l b u P n a e p o r u E e h t f o t n e m e ri u q e r si h t s e c r o f n e E R I P S N I e g n a h c s u o r o g ir e n if e d d l u o h s s S P E f o n o i si v o r p e h t n o g n it a r o b al l o c s A P . 7 1 .s e ci v r e s h c u s f o y r e v il e d s u o u n it n o c e r u s n e o t r e d r o n i s e s s e c o r p t n e m e g a n a m INSPIREenforcesthsirequriement l a r o t c e s -s s o r c d n a ci fi c e p s -r o t c e s h t o b f o t n e m h si l b a t s e e h t tr o p p u s d l u o h s s A P . 8 1 e g a r u o c n e d l u o h s d n a y ti li b a r e p o r e t n i ci t n a m e s g n it a ti li c a f t a d e m i a s ei ti n u m m o c l a n o it a n h g u o r h t s ei ti n u m m o c h c u s y b d e c u d o r p st l u s e r f o g n ir a h s e h t .s m r o ft al p n a e p o r u E d n a 0 0 4 e m o s e r a e r e h t , e p o r u E n I s ei ti n u m m o C t s e r e t n I a t a D l ai t a p S d e t a d n a M y ll a g e L 0 0 2 d n a ) s C I D S ( n i d e v l o v n i ) s O M L ( s n o it a zi n a g r O f o s a ( t n e m p o l e v e d E R I P S N I ) 0 1 0 2 y r a u r b e F e r u s n e o t d e s u e b o t s n o it a ci fi c e p s d n a s d r a d n a t s e h t n o e e r g a d l u o h s s A P . 9 1 .s S P E g n i h si l b a t s e n e h w y ti li b a r e p o r e t n i l a ci n h c e t INSPIREDriecitvear.t18,ar.t22 y ti li b a r e p o r e t n i e s a b , el b i s s o p s a h c u m s a , d l u o h s ,s S P E g n i h si l b a t s e n e h w ,s A P . 0 2 s n o it a ci fi c e p s h c u s e s a c n i r o ,s n o it a ci fi c e p s d e zi l a m r o f g n it si x e n o st n e m e e r g a .s a e r a e m a s e h t n i g n i k r o w s ei ti n u m m o c h ti w e t a r o b al l o c ,t si x e t o n o d 8 1 .t r a e v it c e ri D E R I P S N I e h t o t h c a o r p p a e v it c e j b o d n a t n e r a p s n a rt , d e r u t c u rt s a e s u d l u o h s s A P . 1 2 .s n o it a ci fi c e p s d e si l a m r o f f o n o it c el e s d n a t n e m s s e s s a Suchapproachsiused s n o it a ci fi c e p s n e p o r e f e r p d l u o h s s n o it a rt si n i m d a ci l b u p ,l a u q e g n i e b s g n i h t r e h t O . 2 2 .s S P E g n i h si l b a t s e n e h w Thepirncipelofopenness siappleid t n a v el e r e r a t a h t s ei ti v it c a n o it a zi d r a d n a t s e h t n i e t a p i ci tr a p y l e v it c a d l u o h s s A P . 3 2 .s d e e n ri e h t o t SacDitvICtiseisandLMOspatrciipateinsuch Table 2

(11)

All of the numerous components of INSPIRE interact and rely on one another. This interconnectivity must be considered when using the holistic and interdisciplinary approach of GIAF with its levels, domains, viewpoints and correspondence rules.

Views produced according to a viewpoint depend on time and can describe either existing or planned status of any INSPIRE component. Thus, they can be used for planning INSPIRE implementation, in particular at national and subnational levels.

6. Justification of the GIAF: the case of Poland

In Poland, the existence of a strong and well functioning territorial self-government results in the need for a three level approach to architecture modeling. In most regions (voivodeships) and large cities some spatial information infrastructures are under development. A uniform methodology for their architectural design is critical to achieve necessary interoperability among them and within the national infrastructure.

Each of the six domain viewpoints have proved to be important in Poland:

1) Political – the legislative process to transpose the INSPIRE directive has been influen-ced by changing political situation in Poland,

2) Legal – obsolete geodetic and cartographic law hinders the initiatives to develop the SII,

3) Organizational – one of the key factors is fragmentation of spatial information resour-ces being under responsibility of numerous administration bodies,

4) Semantic – the problems of semantics must be considered due to interdisciplinarity of INSPIRE and fragmentation of spatial information resources,

5) Technical – the scope of issues is enormous, including selection of appropriate tech-nical solutions offered by ICT and geomatics,

6) Economic – it has always been the problem of using available limited resources in the most effective way.

7. Architecture modeling in the context of INSPIRE

development trends

The interest in INSPIRE architecture modeling will grow because of the INSPIRE development trends. The following ones may be predicted.

1. Expansion of INSPIRE in terms of geographical extent. This will result from the fact that the neighboring countries are more and more interested in the idea of INSPIRE. 2. Expansion of INSPIRE in terms of information content. New needs for spatial data

will emerge calling for new data themes, sets and services.

3. Integration of INSPIRE with other public services. INSPIRE is realized as a network of public spatial data services which are interconnected with other public services of e-government. The process of their integration is unavoidable.

4. Change of INSPIRE orientation. INSPIRE will become more citizen-oriented and less administration-oriented due to development of information society.

5. Use of top-down and bottom-up development strategies. INSPIRE is being developed following the top-down strategy. At present, the INSPIRE development is concentrated

(12)

at the EU level. In the near future, work at the MS level will become dominant. To meet the requirements of information society, the role of R&L level and, consequently, the role of bottom-up development approach will grow significantly.

6. Diversification of MS and R&L infrastructures. They will be developed to meet not only the INSPIRE requirements but also those resulting from national, regional and local priorities, experiences and conditions.

7. Proliferation of INSPIRE methodology and technology. This will stimulate develop-ment of new solutions and their innovative uses.

It means and that the overall diversity of INSPIRE components at MS and R&L levels will remain the dominant feature of INSPIRE Architecture. This confirms the need for introducing and using a uniform architecture framework.

8. Models

According to ISO/IEC 42010:2007, a view consists of models needed to present architecture. In order to describe models, the Unified Modeling Language (UML) proved to be useful. Examples of simple models for the INSPIRE Architecture Viewpoints are given in Table 3. More advanced UML architecture modeling is discussed in (Osvalds, 2004).

9. Conclusion

The generic approach proposed in this paper is based on related ICT concepts and solutions listed below.

1. ISO/IEC 42010:2007 Systems and software engineering – Recommended practice for architectural description of software-intensive systems. The standard presents ontology and the process of system (infrastructure) architecting.

2. Enterprise Architecture Frameworks, in particular those recommended and used by the US Federal Government, including:

m The US Office for Management and Budget – Federal Enterprise Architectures, m The US Department of Defense – Architecture Framework.

3. The European Interoperability Framework (EIF) for European Public Services with its recommendations and four types of interoperability.

4. The Unified Modeling Language (UML) as a useful tool for describing and modeling architectures.

In the context of these ICT concepts and solutions INSPIRE can be interpreted in three various ways.

First, it is a system, which can be described and analyzed using methodologies of software-intensive systems engineering. Such methodologies have great potential in designing and optimizing any spatial information infrastructure. In particular, they can be useful when modeling INSPIRE architecture and its components – the infrastructures of Member States and in turn their components. Using the ISO/IEC 42010, the architecture of INSPIRE has been defined.

Secondly, INSPIRE is a public enterprise understood both as a governmental organization and a large project. Available knowledge on enterprise architectures is a base for understanding the concept of architecture framework and using this concept for INSPIRE.

(13)

Table 3. Some basic models T N I O P W E I V MODELS EXAMPLESOFUML S M A R G A I D L A C I T I L O P POLITICALCONTEXTINTERNAL–Polticialcricumstance,s r e d n u II S e h t f o y r o ti rr e t e h t n i h ti w s n r e c n o c ri e h t d n a s r o t c a n o it a r e d i s n o c E S A C E S U d n a n o it a r e p o o C – L A N R E T X E T X E T N O C L A C I T I L O P d n a n a e p o r u E g n i d u l c n i s m e t s y s d n a s II S r e h t o h ti w s n o it c a r e t n i n o it a r e p o o c r e d r o b s s o r c E S A C E S U L A G E L LEGISLATION–Spatailinformaitonelgalacstandtheri II S e h t r o f t n a v el e r s a ,y h c r a r ei h CLASS,OBJECT k c al r o e c n ai l p m o c -n o N – E C N A I L P M O C L A G E L E R I P S N I s n o it al u g e r f o CLASS,OBJECT L A N O I T A Z I N A G R O COORDINATION–Authortieisresponsibelforcoordinaiton s el o r ri e h t d n a USECASE s n o it a zi n a g r o r e h t o d n a n o it a rt si n i m d a ci l b u P – N O I T A R E P O O C s p i h s n o it al e r ri e h t d n a ,I I S e h t g n i n i a t n i a m d n a g n i d li u b COMPONENT C I T N A M E S SEMANTICINTEROPERABILITY–Sectoralt/hematci e b o t n o it a m r o f n i e h t f o e h t g n i n a e m g n i n if e d s ei r al u b a c o v y c n e t si s n o c ri e h t d n a d e g n a h c x e T C E J B O , S S A L C L A C I N H C E T TECHNICALCOMPONENTS–Componenstthatareused II S e h t t n e m el p m i o t CCOLAMSPSO,NENT, E C N E U Q E S a t a d a t e m t n a v el e r r e h t o d n a t n ai l p m o c E R I P S N I – A T A D A T E M CLASS t n a v el e r r e h t o d n a t n ai l p m o c E R I P S N I – S T E S A T A D L A I T A P S n o it a zi n o m r a h a t a d ,s t e s a t a d l ai t a p s CCLOAMSPSO,NENT r e h t o d n a t n ai l p m o c E R I P S N I – S E C I V R E S K R O W T E N s e ci v r e s f o y ti li b it a p m o c ,s e ci v r e s t n a v el e r CCOLAMSPSO,NENT, E C N E U Q E S C I M O N O C E COSTSANDBENEFITS–Driectandindriect USECASE g n i c n a n if -f l e s f o e p o c s ,s e c r u o S – G N I C N A N I F USECASE

In the third place, INSPIRE is a pioneering and advanced implementation of EIF which influences INSPIRE Architecture and contributes to development of INSPIRE Architecture Framework embracing viewpoints of three government levels and six domains. The interrelationship INSPIRE « EIF must be taken into account when implementing INSPIRE and developing EIF.

The interest in INSPIRE Architecture modeling will grow because of the INSPIRE development trends predicted. The overall objective of standardization efforts in this field is to support the unity of INSPIRE in the European evolving diversity.

(14)

References

Bejár et al., 2009: Systems of Systems as a conceptual framework for Spatial Data Infrastructures.

Internatio-nal JourInternatio-nal of Spatial Data Infrastructures Research. Vol. 4.

Department of Defense, 2009: DoDAF Version 2, US Department of Defense. Volumes 1,2,3.

Emery D., Hilliard R., 2009: Every Architecture Description Needs a Framework: Expressing Architecture Frameworks Using ISO?IEC 420110. European Conference on Software Architecture, Cambridge. European Commission, 2009: European Interoperability Framework for European Public Services –

Ver-sion 2 (draft).

ISO/IEC 10746-1:1998: Information technology – Open Distributed Processing: Reference Model – Part 1: Overview.

ISO/IEC 42010:2007: Systems and software engineering – Recommended practice for architectural descrip-tion of software-intensive systems.

Network Services Drafting Team, 2008: INSPIRE Network Services Architecture. Draft, Version 3. OMB, 2007: FEA Practice Guidance. US Office for Management and Budget.

Osvalds G., 2004: Use of UML 2.0 Diagrams for Systems Architecture Modeling. Embarcadero Technologies. The Open Group, 2009: TOGAF™ Version 9. Van Haren, 2009.

Zachman J. A., 2008: John Zachman’s Concise Definition of the Enterprise Framework . Zachman International. Prof. Jerzy GaŸdzicki

Cytaty

Powiązane dokumenty